Bug 313098 – media/media-source/media-managedmse-resume-after-stall.html is an intermittent failure

• Component: Media
• Status: RESOLVED FIXED

[Jean-Yves Avenard [:jya]]

Times out from time to time.

[Radar WebKit Bug Importer]

<rdar://problem/175395328>

[Jean-Yves Avenard [:jya]]

can be reproduced locally with `run-webkit-tests --release --no-retry --repeat=50 --exit-after-n-crashes-or-timeouts=1 media/media-source/media-managedmse-resume-after-stall.html` 

[4/50] media/media-source/media-managedmse-resume-after-stall.html failed unexpectedly (test timed out, text diff)
Exiting early after 0 crashes and 1 timeouts. 4 tests run.


2 tests ran as expected, 2 didn't (46 didn't run):


Unexpected flakiness: timeouts (1)
  media/media-source/media-managedmse-resume-after-stall.html [ Pass Timeout ]

[Jean-Yves Avenard [:jya]]

This is a regression from the MediaContainment feature.

What's happening is that when we re-enqueue samples on the SourceBuffer, we override samples. This cause the renderer's tracks to be flushed.

When new samples have been re-appended and the buffered range no longer have a gap, we call AudioVideoRenderer::play() on the main thread.
Samples are enqueued by the SourceBufferPrivate on the MediaSourcePrivate's queue. 

If the play() command runs first, setting the rate on the synchroniser before any audio samples being re-enqueued: setRate appears to fail and is a de-facto no-op.

Once audio is appended, playback never resume.

[Jean-Yves Avenard [:jya]]

Analysis above ended up not being the cause.

In this test the interaction with the renderer should be as followed:
play() -> stall() -> flush() -> enqueueSamples() -> play()

from time to time it becomes:
play() -> stall() -> play() -> flush() -> enqueueSamples() 

When this happens, and play() is called while the synchroniser and audio/video renderer have been suspended me make it resume, this makes the synchroniser time to stop progressing, the flush / enqueue doesn't resume things.

This is a race between the MediaSource calling play() on the main thread and the SourceBufferPrivate performing the flush/re-enqueue on its queue. The order of operations is no longer deterministic when it used to be (everything was on the main thread before)

[Jean-Yves Avenard [:jya]]

Pull request: https://github.com/WebKit/WebKit/pull/63480

[EWS]

Committed 311992@main (09ea5e2ced87): <https://commits.webkit.org/311992@main>

Reviewed commits have been landed. Closing PR #63480 and removing active labels.