After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 797182 - vaapih264dec: deadlock when PTS or DTS delta is zero
vaapih264dec: deadlock when PTS or DTS delta is zero
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-09-20 14:54 UTC by Matteo Valdina
Modified: 2018-11-03 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
workaround for not exausing PROXY_SURFACE (5.99 KB, patch)
2018-09-20 14:54 UTC, Matteo Valdina
rejected Details | Review

Description Matteo Valdina 2018-09-20 14:54:42 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
Comment 1 Víctor Manuel Jáquez Leal 2018-09-20 15:42:21 UTC
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.
Comment 2 Víctor Manuel Jáquez Leal 2018-09-20 15:44:09 UTC
(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.
Comment 3 Víctor Manuel Jáquez Leal 2018-09-20 15:45:21 UTC
marking as needinfo to remind you if it is possible to share a fault stream.
Comment 4 Matteo Valdina 2018-09-20 16:51:57 UTC
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.
Comment 5 Matteo Valdina 2018-09-21 02:58:19 UTC
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
Comment 6 GStreamer system administrator 2018-11-03 15:55:53 UTC
-- 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.