[Webkit-unassigned] [Bug 194592] [MSE][GStreamer] Seek after reaching end of stream does not work

[bugzilla-daemon at webkit.org]

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

Philippe Normand <pnormand at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pnormand at igalia.com

--- Comment #2 from Philippe Normand <pnormand at igalia.com> ---
(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?

-- 
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/20190215/c81b8eae/attachment-0001.html>