[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
https://bugs.webkit.org/show_bug.cgi?id=170401
Bug ID: 170401
Summary: Immediately seeking on Media element before loading
fails
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