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.
New libav will not call the release_buffer callback anymore when
avcodec_default_get_buffer() is called from get_buffer. Releasing of the
memory in a picture should now be done by registering a callback to the
avbuffer objects in the picture. There is some compatibility code to
wrap the memory we provide in get_buffer in avbuffer with a callback to
release_buffer but that is not done when avcodec_default_get_buffer()
is called.
Work around this by adding a dummy avbuffer object to the picture that
will release the frame.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721077
The VC-1 decoder should handle that. Before avdec_wmv3 handled
it, but then we added format=WMV3 to its sink pad template
caps, at which point nothing handled WMVA any longer.
https://bugzilla.gnome.org/show_bug.cgi?id=697665
... so as to focus on providing *a* buffer rather than one (too) tied
to a frame, in particular allowing multiple allocations related to a frame.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=697806
... by also removing it from the pending list of frames,
where it may still be in if it has never been submitted to _finish.
This could happen if is a decode-only frame, or in skipped decoding
situation, ...
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=693772
Actually avdec_mjpeg does not deal well with incomplete buffers and try
to decode incomplete frames. A parser which will also acts as
an accumulator needs to be inserted before it.
https://bugzilla.gnome.org/show_bug.cgi?id=709352
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.
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
As part of the changes to support the "avc3" variant of the ISO-BMFF
(see bug #702004) a new stream-format has been created
(video/x-h264, stream-format="avc3", alignment="au") that requires
changes to gstavcodecmap to exclude this format because avdec_h264
expects the SPS and PPS to be in the codec_data.
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation data
(e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV box
(moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in the
first sample of every fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
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
libav can write slightly after the plane end in some SIMD optimized
functions. The extra padding value needs to be at least 16+stride_align
for each plane, so just increase the bottom padding value for the output
frame.
https://bugzilla.gnome.org/show_bug.cgi?id=694299
