GNOME Bugzilla – Bug 797182
vaapih264dec: deadlock when PTS or DTS delta is zero
Last modified: 2018-11-03 15:55:53 UTC
Created attachment 373716 [details] [review] workaround for not exausing PROXY_SURFACE Hi all, This is a nasty issue that I quite to be struggling to reproduce in a synthetic environment (aka gst-launch-1.0). Here there is my trying to explain my understanding of the problem. Scope gstvaapidecoder.c and gstvaapidecode.c The main problem is a deadlock in the decoder due to an exhaustion of PROXY_SURFACE. This means also stopping the pipeline or manipulating the pipeline will not work The VAAPI decoder needs these buffers to continue the decoder and if there is no new buffer available will wait on a conditional variable until some PROXY_SURFACE are freed. I noticed that the trigger of this issue is when a bugged stream () will force the decoder to produce a frame with PTS or DTS near identical in time to the previous frame. That means the gap between the previous PTS or previous DTS is 0. My suspect is that there is a reference leak when we hit this condition and this cause the exhaustion of PROXY_SURFACE. I work around the issue of detecting this condition in the push_frame and marking the frame as DECODE_ONLY. When the frame is popped out during the gst_vaapidecode_push_decoded_frame I'll drop the frame with gst_video_decoder_drop_frame. I believe that the easy way to reproduce the problem is programmatically generating this bug condition (0). I can reproduce in my cases due to a looped stream from a remote source (via a network, RTP). I reproduce the issue on the 1.14.3 and VAAPI 2.2.0. Attaching the workaround to better understanding my poor explanation. Sorry about that. Best Matteo
Review of attachment 373716 [details] [review]: Obviously this is a hack to solve a specific problem, breaking not only the H.264 spec, but all the other codecs, since the touched code is the generic one. The issue explained here is similar to the one explained in bug 795770 It would be nice if you could get a stream with these issues and share it.
(In reply to Matteo Valdina from comment #0) > I can reproduce in my cases due to a looped stream from a remote source (via > a network, RTP). > I reproduce the issue on the 1.14.3 and VAAPI 2.2.0. I guess you can save the stream in a file.
marking as needinfo to remind you if it is possible to share a fault stream.
Hi, You can found an example of the stream, here: https://drive.google.com/file/d/1gEh8_T0jYclHtjUUGNUqJhBmcpDP2UVJ/view?usp=sharing it is a pcap that you can be play gst-launch-1.0 filesrc location=slide-1.pcap ! pcapparse dst-port=6002 ! application/x-rtp, payload=98, media=video, clock-rate=90000, encoding-name=H264 ! rtph264depay ! vaapih264dec ! queue ! vaapipostproc ! waylandsink Unfortunately, this issue is happening rarely in this command line (1 of 20). And yes, I know that this is an ugly/nasty patch but it adds some useful log and context to describe better the problem. It is not be intended to be committed. Best and thanks Matteo Valdina P.S. I'll be at the GStreamer conference so I can share and discuss more this issue if you don't have enough information.
Thanks, To point out the other bug, the description is very similar but in my stream, there is no B frame and I didn't notice any error in a stream analyzer (Elecard). I think the problem is not related to h.264 only but how the decoder output the frame. So, all decoder that generates this condition. To better understand what I have done. The last code will drop the decoded frame (gst_video_decoder_drop_frame) but after the decoder. Is it right? So, if my understanding is correct this nasty workaround will act like a "skip frame" but the decoder should continue operating normally. Is it right my understanding? Please note that I saw a similar workaround when the play rate is below 0. Best Matteo
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/107.