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.
<rdar://problem/31442028>
Robert do you have a workaround for this in the meantime?
Our workaround is to repeat the seek every two seconds if the mediaElement reports currentTime to be NaN - This is working for all the Mac devices on 10.1 that I can get hold of, and our monitoring shows it works for many people, but from our complaints, it's clearly not working for some other people. If you know of a better way to workaround this, I'd like to hear! There's a significant set of users for whom our only suggested fix is to use a different browser at the moment. For the Safari users who do eventually play, they have an artificial delay added to the startup time.
So, the reason you're getting a NaN is the seek operation is occurring before there are any seekable ranges. (i.e., video.seekable.length == 0). And the reason the seekable range is empty is because the MediaSource.duration is positive Infinity and the live seekable ranges are empty. Can you try to implement a workaround where, after setting MediaSource.duration, but before seeking, you call MediaSource.setLiveSeekableRange(start, end)?
(Continuing...) WebKit still has some bad behavior; instead of seeking to NaN, we should (according to the spec) cancel the seek operation and reset seeking to false.
I don't know whether we have this test case on WPT or not but we pass except one here: https://wpt.fyi/results/html/semantics/embedded-content/media-elements/offsets-into-the-media-resource/currentTime.html?label=master&label=experimental&aligned=&q=currentTime