GNOME Bugzilla – Bug 616921
[PLUGIN-MOVE] video parsers should be moved to -good
Last modified: 2018-11-03 13:05:45 UTC
Plus: - the element uses GST_BOILERPLATE - the element has docs Minus: - there are no tests - the naming is weired (gst_mp3parse_*, but GstMPEGAudioParse and GstMPEGAudioParseClass) - should the GstMPEGAudioParse be renamed to GstMP3Parse or the other way around. I vote for GstMP3Parse to keep the element name Also there are no leagal issues around the parser, so it should leave -ugly.
I agree that we should move this into good (same for the other parsers). The main reason it went into ugly back in the days was that it wasn't considered useful without decoders from ugly like 'mad', but that's not the case any longer now that GStreamer is used more for transmuxing, streaming, etc. However, I would like to see mp3parse use the parser baseclass that the other audio parsers from -bad use before moving it to -good.
> - the naming is weird (gst_mp3parse_*, but GstMPEGAudioParse and > GstMPEGAudioParseClass) - should the GstMPEGAudioParse be renamed to > GstMP3Parse or the other way around. I vote for GstMP3Parse to keep the element > name. I think it should be GstMpegAudioParse and "mpegaudioparse". We can then also register "mp3parse" for backwards compatibility reasons, but I don't think we should let past mistakes (?) influence our future naming schemes. Or maybe GstMP123Parse? ;-)
Agree about the naming. How could we do the logistics for the baseparse porting? 1.) move baseparse from bad to good, then port mpegaudioparse and integrate to good. 2.) port mpegaudioparse and integrate to bad, then move everything to good? I'll try to write a test in the meantime.
I would add a new mpegaudioparse to -bad/gst/audioparsers/, and when we think it's good enough we can move that to -good and remove the mp3parse in -ugly. But putting a private baseparse.[ch] copy next to the -ugly mp3parse would work too, I just think the former may be easier.
Doh, right. When we have moved all the parsers to good, we can kill the one in ugly and add the mp3parse alias in good. Another point for calling the new one "mpegaudioparse" :)
I think Jan has played around with baseparse + mp3 a bit and one of the issues that came up is that baseparse currently doesn't support reverse playback, but mp3parse does.
mp3parse only supports reverse playback, poorly, with the hacky patch in bug #619204 baseparse has no support for reverse playback at the moment at all, so it would be a regression to port it as that stands. Implementing reverse playback support in baseparse would be a good thing to do, but needs someone with the time to do it.
Note that mpegaudioparse (based on baseparse) has now arrived in -bad (outranking mp3parse.) It only remains to test and/or review ... Baseparse also has reverse playback support now.
Re-purposing this bug as a general 'move audioparsers from -bad to -good' bug.
Also including videoparsers in this (see also bug #622276, comment #20).
audio parsers have been moved to -good now.
*** Bug 774538 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/19.