We expect it to be a int or uint, however it changed the type to a
int64_t in later versions of ffmpeg. As such it would be passed as a 64
bit value to varargs functions, while the consumer of the arguments
assumes only 32 bits. This causes crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=771092
When switching playback modes, like from TRICKMODE or TRICKMODE_KEY_UNITS
back to regular playback, we need to make sure we set the skip mode
back to the default setting.
While this field would be properly reset when we *have* feedback from
downstream (i.e. diff != G_MAXINT64), it would not be reset during
the initial phase (i.e. when the decoder hasn't pushed a buffer yet,
and therefore the sink hasn't sent back QoS information).
This avoids dropping plenty of frames when going back to regular playback
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
