[Bug 774254] vaapi: deadlock during seek of certain media in gst-validate

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774254

--- Comment #3 from Hyunjun Ko <zzoon at igalia.com> ---
This issue is about timestamp.
First of all, definately I'm not a specialist of decoder/encoder, but I'm
trying to describe what this problem is.

In case of this media, vaapih264dec decodes 2 frames per one gst buffer from
upstream, which is unusual (to me at least :P...)
At the moment, for the first frame of two, it can't get pts from
gst_video_decoder_get_timestamp_at_offset, because offset is not enough to get
pts from preserved list, then set GST_CLOCK_TIME_NONE.
(See
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/video/gstvideodecoder.c#n1968
)

With this timestamp, decoder calls finish_frame and pushed it to downstream
with "guessed timestamp", which might be wrong after seek (if buffer with
invalid pts is passed from upstream... this media is the case)

Then let's see this deadlock.
If a pipeline running this media has only video pipeline, seek is working fine.
But with audio pipeline, deadlock happens as the following.
1. seek
2. video pipeline reaches ASYNC_DONE, but waiting for another pipeline.
3. audio pipeline failed to reach ASYNC_DONE.
=> Because video pipeline is trying to push buffers downstream even though the
buffer has invalid pts. Pushing buffer succeeds after change with guessed pts. 
But after some push, surface exhaustion happens finally.

With libav decoder, the video frames(with invalid pts) are all dropped and
working fine.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.