Several decoders will only be able to report a real latency (has_b_frames)
once they're actually initialized (i.e. when they return their first frame).
Doing it earlier (in set_format) doesn't guarantee that the AVCodecContext
has_b_frames has been properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=766362
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
Various functions in libavcodec need them, like the format, sample rate, etc.
and just having them in the context is not enough.
This fixes draining for codecs like MP2 that require a fixed frame size and
require libav to pad the last frame if required.
The GObject macros either for GstFFMpegVidDec and GstFFMpegVidEnc can
break the compilation because they are not GTypes, since each av video
elements are registered in runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=764162
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
It has its own allocator that is not necessarily doing the same as malloc and
will then usually crash. E.g. on Windows or when memalign() is available.
In ffmpeg this is the same as FRONT_CENTER, but we distinguish between
FRONT_CENTER and MONO in GStreamer. Add an explicit mapping for this special
case in the translations functions.
https://bugzilla.gnome.org/show_bug.cgi?id=759846
Handling slice_offset in avviddec is resulting in invalid memory read.
Since rv decoders anyways handle slice_offset, removing the same to fix
memory mishandlings
https://bugzilla.gnome.org/show_bug.cgi?id=758726
Error out if system's libav* libraries are not
provided by FFmpeg. Libav-incompatible changes
were introduced to support the latter so we
can no longer support both.
https://bugzilla.gnome.org/show_bug.cgi?id=758183
If downstream does not provide a (usable) pool, we would use our internal
pool. But the internal pool might be configured with a different width/height
because of padding, which then will cause problems if we push buffers from it
directly downstream.
Instead create a new pool if the width/height is different.
This prevents crashes with vaapisink and d3dvideosink for example.
Based on the debugging results and discussions with
Nicolas Dufresne <nicolas.dufresne@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758344
... since they handle separate cases in video decoder with different requirements.
Consider e.g. x264enc ! rtph264pay ! identity drop-probability=0.1 ! rtph264depay
to illustrate a need for such separation.
Multithreaded encoders are going to free this dummy codec data twice, e.g.
with this pipeline
gst-launch-1.0 videotestsrc num-buffers=40 ! \
videoconvert ! avenc_mjpeg ! fakesink
Since gst_buffer_pool_set_config() takes ownership of the config structure,
it is only necessary to free the structure before using it when the true
branch of if (gst_buffer_pool_config_validate_params) hasn't run.
gst_buffer_pool_set_config() always takes ownership of the structure
regardless of success or failure. Which means the return, checked with
if (!working_pool), has no relation to the state of the structure.
Change default alignment from 16 to 32 bytes, which fixes crashes
when decoding H.265 using AVX2-based decoder code paths and when
using ximagesink/glimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=754120
