[Webkit-unassigned] [Bug 170401] New: Immediately seeking on Media element before loading fails

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 3 07:08:22 PDT 2017


            Bug ID: 170401
           Summary: Immediately seeking on Media element before loading
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Macintosh
                OS: macOS 10.12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: robert.bryer at bbc.co.uk

The issue concerns attempting to seek at the beginning of a live stream – for our simulcast streams, we immediately seek forward to the current live time. Since Safari 10.1 was deployed, we have seen that this initial seek has been failing, although a later manual seek still works.

To reproduce (Webkit Nightly / Safari 10.1; MacOS 10.12.4):
1. http://dashif.org/reference/players/javascript/v2.4.1/samples/dash-if-reference-player/index.html?url=http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd
2. Press the Load button

It would be expected for this stream to start at the current live point. Instead, the initial seek fails and it waits at the beginning.

On that page, at dash.all.debug.js:26230, we set
    element.currentTime = currentTime;

This is failing during the asynchronous seeking procedure, that is, element.currentTime is immediately updated to currentTime, and then it is only some real time later, element.currentTime is set to NaN by WebKit. element.seeking remains true throughout.

This is happening for both audio and video.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170403/da1d1720/attachment-0001.html>

More information about the webkit-unassigned mailing list