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
... since they handle separate cases in video decoder with different requirements.
Consider e.g. x264enc ! rtph264pay ! identity drop-probability=0.1 ! rtph264depay
to illustrate a need for such separation.
Since gst_buffer_pool_set_config() takes ownership of the config structure,
it is only necessary to free the structure before using it when the true
branch of if (gst_buffer_pool_config_validate_params) hasn't run.
gst_buffer_pool_set_config() always takes ownership of the structure
regardless of success or failure. Which means the return, checked with
if (!working_pool), has no relation to the state of the structure.
