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.
Change default alignment from 16 to 32 bytes, which fixes crashes
when decoding H.265 using AVX2-based decoder code paths and when
using ximagesink/glimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=754120
Make sure the alignment requirement in GstAllocationParams
matches the GstVideoAlignment requirements. This fixes
issues with avdec_h265 crashing in the avx2 code path when
used with playbin and ximagesink/glimagesink as videosink.
The internal video pool would allocate buffers with an
alignment of 15 even though GstVideoAlignment specified
a stride_align requirement of 31 (which comes from ffmpeg).
https://bugzilla.gnome.org/show_bug.cgi?id=754120
Some check where incorect and also unsafe. The only reliable information
in get_buffer2 is the picture width/height really. The side effect is
that the width/height of the internal pool endup padded, so when we
switch we also need to switch to the a new width/height, hence we save
the pool info.
https://bugzilla.gnome.org/show_bug.cgi?id=753869
The size in the AVFrame in get_buffer2 don't match the output size,
instead they match ffmpeg's memory requirements, so we can't compare
them from the values of the output AVFrame. Those are comparable to
the values in the passed AVCodecContext.
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
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.
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
finish() is called at EOS, drain() is called at all other times
when the decoder should be drained out. gst-libav decoder behaviour
is the same in both cases, so use the same implementation
See https://bugzilla.gnome.org/show_bug.cgi?id=734617
We use have_data (that comes from libav), instead of only trying 10 times,
to know if there are more frames available. The old code was machine
dependant as different amount of frames could be decoded by different
type of (more powerful) machines, and 10 times was not always sufficient.
https://bugzilla.gnome.org/show_bug.cgi?id=736515
have_data is not propagated from gst_ffmpegviddec_video_frame to
gst_ffmpegviddec_frame. have_data is only set to 1 in
gst_ffmpegviddec_frame if a frame pointer is passed. However, this is
not true while draining, which means that have_data from libav will be
ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=734608
gst_video_decoder_get_max_decding_time doesn't return a GstClockTime
but a GstClockTimeDiff, and thus one needs to compare it against
G_MAXINT_64.
The returning of a boolean and the extra subsequent code in _video_frame
was uselessly complicated.
The previous behaviour led to artefacts when the decoder tried to
hurry up.
https://bugzilla.gnome.org/show_bug.cgi?id=730075
As we don't know how many output buffers we need to operate, we need to
avoid pool that can't grow. Otherwise the pipeline may stall, waiting
for buffers. For now, we require it to be able to grow to at least
32 buffers, which I think is a fair amount of buffers for decoders.
https://bugzilla.gnome.org/show_bug.cgi?id=726299
Fixes crash on EOS when no buffers have been received for some
reason, e.g. because the parser didn't output any.
fakesrc num-buffers=0 format=time ! avdec_h264 ! fakesink
The output-corrupt property will set the CODEC_FLAG_OUTPUT_CORRUPT flag
in the codec context. The user can now decide whether libav outputs
corrupt frames or not.
Previous libav versions had this flag always set.
https://bugzilla.gnome.org/show_bug.cgi?id=722453
A AVCodecContext needs cleaning up before being freed.
Go through all of the allocations/setups to ensure none of them
can leak a context or its contents.
