[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