[Webkit-unassigned] [Bug 272975] [MSE][GStreamer] Early flushes may deadlock WebkitMediaSrc

[bugzilla-daemon at webkit.org]

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

Carlos Bentzen <cadubentzen at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[MSE][GStreamer] Early      |[MSE][GStreamer] Early
                   |flushes may deadlock on     |flushes may deadlock
                   |FLUSH_STOP                  |WebkitMediaSrc

--- Comment #2 from Carlos Bentzen <cadubentzen at igalia.com> ---
I have a WIP patch, but needs a lot of refinement before proposing to merge it.

What I have found out so far:

1. In media-source-abort-resets-parser.html, we deadlock because FLUSH_START (which travels out-of-band), arrives at the playsink earlier than STREAM_START. STREAM_START is only handled when the sticky events are pushed after sending FLUSH_STOP. When handling that, it in turn blocks the video pad and waits for FLUSH_START, but FLUSH_START arrived at the pad before and thus it deadlocks.

In gstreamer code, STREAM_START will block in gstpad.c do_probe_callbacks() on GST_PAD_BLOCK_WAIT(pad); It would have been unblocked by a FLUSH_START in gst_pad_push_event_unchecked() via GST_PAD_BLOCK_BROADCAST(pad); (but remember, in the test we get the broadcast call first and then the block call).

Another thing that is important to trigger this is the fact that the media segment contains both video and audio, but no audio samples are pushed. The test is pushing half the bytes of the segment and aborting, but the audio samples are in the final 2% of the file. Why is that important? Because the audio stream's STREAM_START never arrives and thus doesn't trigger a reconfiguration in the playsink (see gstplaysink.c sinkpad_blocked_cb()), which would unblock the pads as well. To confirm this, simply change the manifest in the test from 'test-fragmented-manifest.json' to 'test-fragmented-video-manifest.json' and the issue goes away.

For fixing that, I added a synchronization point before FLUSH_START to wait for STREAM_START to have been handled in the playsink for all streams that pushed buffers. This was achieved with a probe in the playsink pad. Very ugly, but it works.

2. For media/media-source/media-source-current-time.html, the case above happens, but also the second level of racing: sending a FLUSH_START after all STREAM_START's have been handled, but before playsink has caps for the streams on its pads.

In this case

-- 
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/20240419/26b2440c/attachment.htm>