[Webkit-unassigned] [Bug 185242] [MSE][GStreamer] Delete properly the stream from the WebKitMediaSource

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=185242

Alicia Boya García <aboya at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aboya at igalia.com

--- Comment #11 from Alicia Boya García <aboya at igalia.com> ---
Comment on attachment 339534
  --> https://bugs.webkit.org/attachment.cgi?id=339534
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=339534&action=review

> Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:516
> +        gst_element_set_state(stream->appsrc, GST_STATE_NULL);

This will deadlock whenever the streaming thread is waiting for some action that requires WebKit intervention. Note that:

a) Setting a source element state to NULL deactivates its pad and therefore attempts to tear down its streaming thread.

b) Tearing down a streaming thread is a stream-synchronized operation. The streaming thread is shared with other elements downstream. This means that we need to wait until no buffer or (stream synchronized) event is traveling through this stream.

c) A traveling buffer may be blocked waiting for something. For instance, usually the stream ends at the sinkpad of a queue element (the srcpad of the queue element starts a separate streaming thread, so for threading purposes that's separate stream). If the queue is full and won't gain any space until WebKit's main thread performs some action you've got yourself in a catch 22, deadlock.

This is what is causing YTTV 18. MediaElementEvents to deadlock after this patch. Note that even though the test finishes when WebKit reports playback has ended, several seconds worth of frames are still queued in the playback pipeline because of a change of duration to a shorter value. The pipeline is set to PAUSED when the shorter duration is reached, so those extra frames are not played, but still try to continue travelling through the pipeline. When the sink element receives a frame in this PAUSED state it has to wait for a state change to PLAYING before doing anything with it (see gst_base_sink_wait_preroll()). This blocks the streaming thread containing the sink. Streaming threads upstream still continue pushing buffers for some time until the queue becomes full, then get blocked as well.

Summarizing: in order to tear down the source element you need to tear down its streaming thread. In order to tear down the streaming thread you need to wait for the current flowing buffer to complete its journey in this streaming thread, but that won't happen until the queue at the end of this stream has available space and therefore stops blocking the thread. The queue won't have available space until the sink is set to PLAYING or the pipeline is flushed. That won't ever happen (moreso when the main thread is waiting), therefore you've got a deadlock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180516/5a7d897c/attachment-0001.html>