Bug 194592 – [MSE][GStreamer] Seek after reaching end of stream does not work

• Status: NEW
• Component: WebKitGTK

[Sergey Krutikov]

Created attachment 361917 [details]
Test HTML5 application

Performing a seek after reaching end of stream (EOS) has no effect. 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 the issue is caused by switching of readyState of a media source to "closed" whereas it should be "ended". This happens because "MediaPlayerPrivateGStreamer::didEnd" function pauses private player and moves GStreamer pipeline to "ready" state (https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L2194). When a seek after EOS is triggered, the "source-setup" signal is generated and its handler in "MediaPlayerPrivateGStreamerMSE" class causes issuing of "error" event for media element (https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/HTMLMediaElement.cpp#L2217) and switching from "ended" to "closed" state in media source (https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/mediasource/MediaSource.cpp#L925). We fixed the bug by not switching the pipeline to "ready" state, 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 from a position near the end.
* Wait for approximately 7 seconds - EOS will be reached and a seek will be triggered.

Expected result: video playback position has changed, frame at the destination position is displayed, video playback is paused.
Actual result: nothing happens.

WebKitGTK version: 2.23.3

[Michael Catanzaro]

These are great bug reports. Thanks!

[Philippe Normand]

(In reply to Sergey Krutikov from comment #0)
> Created attachment 361917 [details]
> Test HTML5 application
> 
> Performing a seek after reaching end of stream (EOS) has no effect. 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 the issue is caused by switching of
> readyState of a media source to "closed" whereas it should be "ended". This
> happens because "MediaPlayerPrivateGStreamer::didEnd" function pauses
> private player and moves GStreamer pipeline to "ready" state
> (https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/
> graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L2194). When a seek after
> EOS is triggered, the "source-setup" signal is generated and its handler in
> "MediaPlayerPrivateGStreamerMSE" class causes issuing of "error" event for
> media element
> (https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/
> HTMLMediaElement.cpp#L2217) and switching from "ended" to "closed" state in
> media source
> (https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/
> mediasource/MediaSource.cpp#L925). We fixed the bug by not switching the
> pipeline to "ready" state, but we are not sure this is the proper fix.
> 

This isn't the right solution indeed.
I haven't checked this, but what about pre-rolling the pipeline again if a seek is triggered after the EOS event was received?

[Sergey Krutikov]

To be honest, I am not very experienced in WebKit code. I would prefer to wait until your investigation has been accomplished.

[Michael Catanzaro]

This looks like another good MSE bug that could receive some attention.