... 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
It is enabled although we pass --disable-hwaccels apparently and
makes the build fail on Windows because libav looks for the d3d headers
in the wrong places. We can't make use of these features via libav.
https://bugzilla.gnome.org/show_bug.cgi?id=706601
