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`.
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
The version of libavutil is printed in the log instead of libavcodec
because avutil_version() returns LIBAVUTIL_VERSION_INT. This can be confusing,
so we should be replace it with avcodec_version().
See https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/41#note_142808
The switch to the new ffmpeg property system changed the type of the
bitrate property from int to int64, which potentially breaks many
existing applications at runtime as properties are usually set via
g_object_set().
As such, override the type to int until GStreamer 2.0.
.. and other formats where ffmpeg gives us multiple
subframes per input frame.
Since we now support non-interleaved audio, we can't
just concat buffers any more. Also, audio metas won't
be combined when buffers are merged, so when we push
out the combined buffer we'll look at the meta describing
only the first subframe and think it covers the whole
frame leading to stutter/gaps in the output.
We could fix this by copying the output data into a new
buffer when we merge buffers, but that's suboptimal, so
let's add some API to GstAudioDecoder to push out subframes
and use that instead.
https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/49
The start time is supposed to be the ts of the first frame.
FFmpeg uses fractions to represent timestamps and the start time may use a
different base than the frame pts. So we may end up having the start
time bigger than the pts because of rounding when converting to gst ts.
See https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/51
for details.
When building with MSVC, if the 3rd operator is a double, the entire
expression always promoted double, and is then cast to int64.
When TRUE, this evaluates to (gint64) (gdouble) (INT64_MAX)
which overflows to INT64_MIN on MSVC, but not on C99 compilers.
This causes us to fail the g_return_if_fail inside g_param_spec_int64
when built with MSVC.
