If http://www.mars.org/mailman/public/mad-dev/2001-May/000262.html is
to be believed, the last buffer must be followed by a number of 0 bytes
in order for the last frame to be decoded (at least in some cases).
Doing so seems to work here, fixing a missing 1152 samples when using
mp3parse before mad (not using mp3parse would yield the correct amount
of samples, if there's extra non-MP3 data after (eg, tag data)).
and use fixed caps on the srcpad. To correctly support
upstream renegotiation a52dec would need to check if the
caps of the downstream allocated buffer are the requested
caps or if the size is different.
Fixes bug #665989.
The mad mp3 decoder element shouldn't parse tags at all really, but we
have so far kept this code around for backwards-compatibility reasons
for people building manual pipelines for some reason. However, as it
turns out that code has never actually worked in 0.10 in practice,
since it only gets executed if mad_frame_decode() returns LOSTSYNC,
which doesn't actually seem to happen any more though because of the
preceding mad_header_decode(), which will discover and report the
sync loss if it runs into a tag and make mad_frame_decode() try to
resync right away.
Discovered this while trying to make it use gst_tag_list_from_id3v2_tag().
Parsing can return with an 'invalid' state, but this is not
actually fatal. For one, the mpeg2dec command line tool that
comes with the libmpeg2 library blithely ignores this condition
and merrily goes on. So we do this same, logging the error,
and going on with parsing. This makes something work that did
not use to work, and brings happiness to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=429476
Read the stream-format from "stream-format" and not from profile, also rename
the "bytestream" variable to "stream_format" so it's easier to understand.
Makes x264 select its stream-format based on what's available
on caps, the user selected option will be chosen as a fallback
when both options are available.
https://bugzilla.gnome.org/show_bug.cgi?id=644233
Although the element accepts subme values > 6, the annotation which is
visible through gst-inspect (for example) erroneously indicates 6 as the
maximum. Fix this by indicating 10 (which is the x264 max) as the maximum.
https://bugzilla.gnome.org/show_bug.cgi?id=653473
