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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Nov 18 00:46:58 UTC 2016


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

--- Comment #8 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #7)
> 
> We should rethink the whole surface_ready_mutex mechanism.
>  
Totally agree! though I have no idae of this currently.

> > With libav decoder, the video frames(with invalid pts) are all dropped and 
> > working fine.
> 
> Where does libav do that?
> 
> I only see the "ghost" frame removal: 
> https://cgit.freedesktop.org/gstreamer/gst-libav/tree/ext/libav/gstavviddec.
> c#n1583
> 
> I don't know, perhaps that's our problem.

Drop's done in VideoDecoder in gst_video_decoder_clip_and_push_buf

[libav]
Seek
-> got buffer from upstrem, but pts is out of segment
-> decoded
-> dropped this frame in gst_video_decoder_clip_and_push_buf until valid
pts(inside segment) comes.

[vaapi]
Seek
-> got buffer from upstrem, but pts is out of segment
-> decoded
-> because of what i mentioned above, guessed timestamp in
gst_video_decoder_prepare_finish_frame, which results in pts inside segemnt
-> pushed continuously.
-> surface exhaustion until ASYNC_DONE in audio pipeline.

Note that in case of libav decoder, it's packetized, which means doesn't call
add_frame/have_frame in GstVideoDecoder. So it's not being through what i
mentioned in  gst_video_decoder_get_timestamp_at_offset, which is called only
in have_frame. So it doesn't have to guess timestamp because pts is not
GST_CLOCK_TIME_NONE, but out of segmet and dropped finally

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


More information about the gstreamer-bugs mailing list