Bug 194499 – [GStreamer][MSE] Seek while seeking freezes playback

• Component: WebKitGTK
• Status: NEW

[Sergey Krutikov]

Created attachment 361679 [details]
Test HTML5 application

Performing a seek while another seeking operation is in progress sometimes freezes playback. This happens consistently at the beginning of our test MSE video. The test scenario works properly in Chrome and Firefox, but fails in MiniBrowser and in our proprietary component which is also based on WebKitGTK.

Our investigation has shown that seek is delayed due to the seek position being outside of buffered ranges. However, the seek position is very close to one of the buffered ranges. This leads to a seek completion by media source code since it checks whether a position is buffered with some tolerance (https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/mediasource/MediaSource.cpp#L240), whereas GStreamer private player uses exact matching (https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp#L297). Thus, the whole class stack in WebKit related to MSE playback goes to an invalid state. We fixed the issue using exact matching check in media source code as it is done in the private player. But we are not sure this is the proper fix.

Steps to reproduce the bug:
* Unzip the attached archive.
* Host and load mse.html - MSE video should start playing.
* Wait for approximately 2 seconds - double seeking will be triggered.

Expected result: seek operation succeeds, video playback continues.
Actual result: video playback freezes and never recovers.

WebKitGTK version: 2.23.3

[Alicia Boya García]

Thank you for your report and your testcase.

I can reproduce the stall indeed. On the other hand, I can't not reproduce the fix. I made this change, making hasBufferedTime() behave the same as isTimeBuffered().

--- a/Source/WebCore/Modules/mediasource/MediaSource.cpp
+++ b/Source/WebCore/Modules/mediasource/MediaSource.cpp
@@ -374,14 +374,7 @@ bool MediaSource::contentTypeShouldGenerateTimestamps(const ContentType& content
 
 bool MediaSource::hasBufferedTime(const MediaTime& time)
 {
-    if (time > duration())
-        return false;
-
-    auto ranges = buffered();
-    if (!ranges->length())
-        return false;
-
-    return abs(ranges->nearest(time) - time) <= currentTimeFudgeFactor();
+    return buffered()->contain(time);
 }
 
 bool MediaSource::hasCurrentTime()

After building and running the test, I noticed no difference. Indeed in both cases there is this line in the logs:

0:00:02.545226604  3505      0x13afef0 DEBUG              webkitmse MediaPlayerPrivateGStreamerMSE.cpp:263:doSeek: [Seek] Delaying the seek: In async change PAUSED --> PAUSED

This implies doSeek() returns before actually reaching any call to isTimeBuffered().

[Sergey Krutikov]

This is another kind of the problem we have also faced. Usually, it happens when you do seek while seeking not at the beginning of the test video. We have no idea how to fix it. Hopefully, you will be able to sort it out.

The fix I mentioned before works on our platform. Maybe, this "async change PAUSED --> PAUSED" just do not happen in our case.

[Xabier Rodríguez Calvar]

(In reply to Sergey Krutikov from comment #2)
> The fix I mentioned before works on our platform. Maybe, this "async change
> PAUSED --> PAUSED" just do not happen in our case.

AFAIK, this is the way GStreamer has to inform that a seek is finished. I'd recommend you implement it in your platform.

[Sergey Krutikov]

We completely rely on WebKitGTK in everything what concerns GStreamer. So if WebKit properly handles this state transition, we do not need to do it ourselves. But one aspect of the reported problem is that WebKit gets stuck during seeking if "PAUSED --> PAUSED" transition happens.

[Xabier Rodríguez Calvar]

(In reply to Sergey Krutikov from comment #4)
> We completely rely on WebKitGTK in everything what concerns GStreamer. So if
> WebKit properly handles this state transition, we do not need to do it
> ourselves. But one aspect of the reported problem is that WebKit gets stuck
> during seeking if "PAUSED --> PAUSED" transition happens.

Ok, it hangs, I guess we'll investigate it then. From your comment I understood that your platform or your GStreamer plugins were not announcing that state transition, which is necessary.

[Sergey Krutikov]

In fact, we have seen WebKit getting stuck in two cases. The first one is what I reported first and what we fixed changing MediaSource::hasBufferedTime. The second one happens along with this transition message "Delaying the seek: In async change PAUSED --> PAUSED". Unfortunately, we have no idea how to fix it.

[Michael Catanzaro]

(In reply to Xabier Rodríguez Calvar from comment #5)
> Ok, it hangs, I guess we'll investigate it then.

Maybe this got forgotten.