This removes the internal interleave loop and always negotiates
the native output layout of the libav decoder. Users can use
audioconvert to interleave if necessary.
Special care has been taken to leave the encoder unaffected by
the changes in avcodecmap, since GstAudioEncoder doesn't support
the non-interleaved layout yet.
https://bugzilla.gnome.org/show_bug.cgi?id=705977
We were ignoring these before the port to 4.0, interpreting them
as GST_FLOW_ERROR / GST_ELEMENT_ERROR causes check failures.
We should start using GST_*_DECODER_ERROR in latter commits,
for now simply restore the previous behaviour.
The remaining use of CODEC_ are codec flags that has been moved into the
new codec private properties or have been deperated. Will be fixed in
later patches.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
Otherwise we will consider them as one frame of raw audio that is still
pending, and shift all timestamps by the amount of time spent with header
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=765797
libav always uses planar audio formats nowadays, not much use in
us trying to allocate anything here until we add support for planar
aka non-interleaved audio formats at least in audioconvert.
We use have_data (that comes from libav), instead of only trying 10
times, to know if there are more samples available. The old code was
machine dependent as different amount of samples could be decoded by
different type of (more powerful) machines, and 10 times was not always
sufficient.
https://bugzilla.gnome.org/show_bug.cgi?id=737144
A AVCodecContext needs cleaning up before being freed.
Go through all of the allocations/setups to ensure none of them
can leak a context or its contents.
It can happen that negotiation fails during get_buffer(), but then
we don't retry later and never return NOT_NEGOTIATED upstream...
and instead run into assertions.
https://bugzilla.gnome.org/show_bug.cgi?id=708769
We need to reload the defaults for the codec after closing it,
otherwise we can't access codec information like the supported
sample rates and can crash.
https://bugzilla.gnome.org/show_bug.cgi?id=707040
Calculate output buffer size based on the number of
samples, channels and bytes per sample. The buffer
size was calculated based on linesize, which may
be larger than what's required.
https://bugzilla.gnome.org/show_bug.cgi?id=690940
The base audio decoder wants a 1:1 mapping for input and output
buffers, so this decoder must accumulate data in an adapter and push
it all at once after all input has been processed.
https://bugzilla.gnome.org/show_bug.cgi?id=689565
