Without this fix, running the command below will get an error randomly.
Example:
gst-launch-1.0 videotestsrc ! vp9enc ! avmux_ivf ! fakesink
ERROR: pipeline doesn't want to preroll.
0:00:02.388528491 30148 0x5601b424a370 ERROR libav :0::
Tag [1]V[0][0] incompatible with output codec id '167' (VP90)
When the `max-threads` property is not specified, GStreamer defaults to
the amount of CPU threads in the system.
The number of threads used in avdec has a direct impact on the latency
of the decoder, which is of as many frames as threads. Therefore, big
numbers of threads can make latency levels that can be problematic in
some applications.
For this reason, ffmpeg emits a warning when more than 16 threads are
requested.
This patch limits the default number of threads to 16. This affects only
computers with more than 16 CPU threads when using avviddec without
setting `max-threads`.
Was never hooked up to meson build it seems, and only ever used
by the uninstalled autotools dev env to locate gst-libav plugins
for use in unit tests in other modules.
Some plugins (like libcdio) registers empty long_name field. Calling strncmp on this field leads to a segmentation fault.
Signed-off-by: Kevin Joly <joly.kevin25@gmail.com>
AVBufferRef -> GstFFMpegVideoDecVideoFrame -> GstVideoCodecFrame -> AVBufferRef
Instead of holding additional ref there, set read-only which would not be
reused by ff_reget_buffer()
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/63
... if ffmpeg would reuse the allocated AVBuffer. Reused AVFrame by
the ffmpeg seems to break our decoding flow since the reused AVFrame
holds the initial opaque data (GstVideoCodecFrame in this case), so
we couldn't trace the our in/out frames.
To enforce get_buffer() call per output frame, hold another reference
to the AVBuffer in order to mark the AVBuffer as not writable.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/62
When thread_type is set to FF_THREAD_FRAME, per the documentation
a latency of one frame per thread is introduced:
<https://ffmpeg.org/ffmpeg-codecs.html>, search for thread_type.
Additionally, we need in that case to calculate the automatic
number of threads ourselves, so as to accurately calculate the
latency.
The thread-type property allows specifying preferred
multithreading methods by user. Note that FF_THREAD_FRAME
may introduce additional latency especially on non-filesrc usecase,
since it introduces a decoding delay of (number of threads) frames.
https://bugzilla.gnome.org/show_bug.cgi?id=797254
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
libavutil/mem.h:342:1: error: ‘alloc_size’ attribute ignored on a function returning ‘int’
av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t size);
^~~~~~~~~~~~~
Hopefully fixes build on jenkins.
