[Webkit-unassigned] [Bug 144040] [GStreamer] Adaptive streaming issues

[bugzilla-daemon at webkit.org]

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

--- Comment #28 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Ok, I think I've managed to fix this, but I'm not 100% sure because it's not always easy to reproduce all the deadlocks and threading issues are hard. Anyway, I've found two different deadlocks that are blocking the web process:

 - The first one is actually a set of deadlocks that can happen in many places. It happens because gst is using several threads to download manifest, fragments, monitor the downloads, etc. To download the fragments and manifest it always creates the source element in a separate thread, something that is not actually expected to happen in WebKit source element (see bug #152043). Our source element is always scheduling tasks (start, stop, need-data, enough-data and seek) to the main thread, and those downloads that use the ResourceHandleStreamingClient (there's no player associated) also happen in the main thread, libsoup calls all its async callbacks in the main thread. So, the result is that it can happen that we end up blocking the main thread in a lock until the download finishes, but the download never finishes because tasks are scheduled in the main thread that is blocked in a lock. I managed to fix this by always using a secondary thread for downloads made by ResourceHandleStrea

 - The second deadlock happens when the media player is destroyed by the garbacge collector and pipeline is set to NULL state. This always happens in the main thread, since the garbage colector frees the objects in the main thread. The situation is the following one:

Main Thread:
  - blocked on GST_PAD_STREAM_LOCK (post_activate() gstpad.c)

Secondary Thread:
  - blocked on GST_MANIFEST_LOCK (gst_adaptive_demux_src_event() reconfigure gstadaptivedemux.c)
  - has EXPOSE_LOCK of gstdecodebin2 taken from source_pad_blocked_cb()

Secondary Thread:
  - blocked on EXPOSE_LOCK (no_more_pads_cb() gstdecodebin2.c)
  - it seems to have GST_PAD_STREAM_LOCK of gstpad taken from gst_pad_send_event_unchecked()
  - has GST_MANIFEST_LOCK of gstadaptivedemux taken from _src_event, got fragment EOS

Secondary Thread:
  - infinite loop waiting for fragment download to finish (gst_adaptive_demux_stream_download_uri()

I haven't been able to fix or workaround this from WebKit code, the only chnage the seemed to work was releasing the manifest lock in gst_adaptive_demux_expose_streams before calling gst_element_no_more_pads) can taking it again. But I have no idea if the change is correct or just a workaround, the gst code is full of locks and conditions that is very difficult to follow.

So, I'll submit the WebKit patch here as WIP for now, and if Sebastian confirms the gst changes makes sense, I'll submit the patch to gst too. A possible workaround for WebKit, to avoid depending on changes in gst would also be appreciated. Please, try both patches and let me know if it fixes the problem for you. In the mean time I'll run the layout tests to make sure I haven't introduced any regression.

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