[Webkit-unassigned] [Bug 217713] currentTime reported as NaN shortly after seeking for MSE playback

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from sycy700 at gmail.com ---
Yes, it's not GTK specific. The issue has been seen on WPE too.

Anyway, the issue can be also reproduced on Webkit GTK 2.30.1 without any patches (the 1 second sleep). It was also reproduced on GNOME Web 3.28.6. To do it, timings in the Javascript code must be adjusted.

The usual flow between appending a buffer and seeking is as follows:

1. SourceBuffer::appendBuffer appending a buffer.
2. AppendPipeline::appsrcEndOfAppendCheckerProbe, posting a task to handle end of buffer.
3. AppendPipeline::handleEndOfAppend is called, it updates buffered ranges.
4. We are setting the current position. There is logic in HTMLMediaElement::seekWithTolerance which posts a task HTMLMediaElement::seekTask to the queue when the seek was from DOM.
5. HTMLMediaElement::seekTask is executed. There are buffered ranges available (because they were updated while executing AppendPipeline::handleEndOfAppend), it sets the m_lastSeekTime to some valid value.
6. HTMLMediaElement::currentMediaTime is called. Because we are still seeking, then the value of m_lastSeekTime is returned as the current time.

To reproduce the issue, HTMLMediaElement::seekTask must be called before AppendPipeline::handleEndOfAppend. It's possible to do it with short timeouts in Javascript code like the seek will happen 1ms after calling SourceBuffer::appendBuffer. Additionaly, after the issue will happen, the controls of HTML audio element are unusable and the audio can't be played.

The updated way to reproduce the issue:
1. Prepare audio media:
gst-launch-1.0 audiotestsrc num-buffers=3000 ! avenc_aac ! mp4mux ! filesink location=audio.mp4
ffmpeg -i audio.mp4 -movflags frag_keyframe+empty_moov -movflags frag_keyframe+empty_moov+default_base_moof output.mp4
2. Use the updated attached HTML file with MSE code.
3. Try to launch the browser a few times or refresh and at some point it should happen.

When the race condition is not hit, then everything works fine. The current time returned is always 0.0 and audio can be played. However, when the issue is reproduced, the current time right after seeking is returned as NaN (it is often also the value of duration if EOS was injected quicker). After injecting EOS, the position is seeked to the end and the audio element becomes unusable during interaction.

I attached screenshots from GNOME Web when the issue was reproduced and also when everything went fine.

The issue can't be reproduced with Chrome 84.

-- 
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/20201015/770846ea/attachment.htm>