ffmpeg doesn't provide the final's image width & height in the get_buffer2()
callback, so it's not possible to create an output state for GstVideoDecoder
at this stage. So only try to do direct rendering if the buffer pool has already
been negotiated based on the final decoded size.
This partially reverts the effects of 2e621f8dbhttps://bugzilla.gnome.org/show_bug.cgi?id=752802
This reverts commit ac3437153d.
Doesn't actually make sense as it will put the (uninstalled) library paths
into the installed .la files. How does this all work?
If it is created earlier and the stride is invalid, then the frame
will be freed and it won't be possible to use it in the fallback path.
Not doing this causes a segfault because it will try to use
already freed memory.
It's needed only for subtitle charset conversion, and we don't
use the ffmpeg subtitle support anyway.
Also disable d3d11va and dxva2 support, we don't use the hardware
codec support.
VideoDecodeAcceleration framework is deprecated in 10.11, and currently
cuases linker errors when compiling on OSX. Oddly, --disable-hwaccels
did not also disable h264_vda already.
https://bugzilla.gnome.org/show_bug.cgi?id=751838
ffmpeg seems to be the one of the two forks, which is most widely used by
Linux distributions and in general. Also Google is using it for e.g. Chrome
and has engineers working on finding and fixing security issues in it.
https://bugzilla.gnome.org/show_bug.cgi?id=751607
gstavvidenc.c: In function 'gst_ffmpegvidenc_flush_buffers':
gstavvidenc.c:733:7: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
GstFFMpegVidEncClass *oclass =
^
cc1: all warnings being treated as errors
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.
The context contains the information from the latest input frame, we're
however interested in the information from the latest output frame. As we have
to negotiate for the buffer that is about to come next.
This should fix some crashes that happened when both information got out of
sync. If that happens now, we will do fallback allocation until the output
is renegotiated too.
https://bugzilla.gnome.org/show_bug.cgi?id=750865
There exist few formats (deprecated though) used by mjpeg decoder
and encoder that maps to the same GStreamer format. To properly
pick the right format, also lookup each Codec list before accepting
the format. This fixes error when trying to use mjpeg encoder.
Note that this may results in faded colors. In fact, these special
format are meant to specify that this is full range YUV. Colorimetry
in gst-libav is not yet implemented, hence is ignored in general. So
I think it's fine to first fix the issue before addressing the missing
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=750398
