"GStreamer" (GNOME Bugzilla)
2018-09-20 14:54:42 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=797182
Bug ID: 797182
Summary: vaapi H.264 decoder deadlock when PTS or DTS delta is
zero.
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---
Created attachment 373716
--> https://bugzilla.gnome.org/attachment.cgi?id=373716&action=edit
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
Bug ID: 797182
Summary: vaapi H.264 decoder deadlock when PTS or DTS delta is
zero.
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---
Created attachment 373716
--> https://bugzilla.gnome.org/attachment.cgi?id=373716&action=edit
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
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.