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
ID3 tags are usually handled by id3demux, and should be handled
by id3demux. Tag handling in mad based on libid3tag is very basic
and mostly unnecessary really, so just build this plugin without
ID3 tag support if libid3tag is not available.
The element downstream of mp3enc might only accept certain sample rates or channels,
make sure we relay any restrictions that do exist to upstream when it does a
get_caps() on the sink pad. That way upstream elements like audioresample or
audioconvert can pick a sample rate / channel configuration that will be accepted,
instead of just negotiating to the highest, which might then be rejected.
https://bugzilla.gnome.org/show_bug.cgi?id=641151
When variable framerate is disabled in libx264 (which occurs when using
the zerolatency tuning), libx264 ignores timestamps but still uses the
timebase leading to messed up rate control with our nanosecond timebase.
We work around this issue by setting the timebase to the reciprocal of
the framerate and we validate that the framerate is suitable.
This has been fixed upstream in libx264 but there are non-fixed versions
in the wild so this workaround is still needed.
Fixes bug #632861
