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`.
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
We were ignoring these before the port to 4.0, interpreting them
as GST_FLOW_ERROR / GST_ELEMENT_ERROR causes check failures.
We should start using GST_*_DECODER_ERROR in latter commits,
for now simply restore the previous behaviour.
avcodec_align_dimensions2 uses context->pix_fmt to make its
calculations, we thus need to make sure it is adequately set
when calling it.
Fixes:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080 \
! avenc_mpeg4 ! avdec_mpeg4 ! xvimagesink
This showed invalid writes under valgrind, then segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
The remaining use of CODEC_ are codec flags that has been moved into the
new codec private properties or have been deperated. Will be fixed in
later patches.
https://bugzilla.gnome.org/show_bug.cgi?id=792900
This reverts commit 4284d791bc.
It causes crashes on various h264 and DNXHD/VC3 streams, where the
decoders write to arbitrary memory far after what we've allocated.
As a side effect, left/right green bars goes away when using
xvimagesink. I just think that xv cropping is broken, so this is
probably just hiding a bug.
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
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
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
