Jumping back in live stream before startup collapses seek window

[jkarsrud]

When seeking backward/jumping back in a live stream by setting video.currentTime, the seekrangechanged event fires as expected, with the start and end properties moving along correctly. After the seekrangechange event has triggered a couple of times, the end property is equal to the video element's currentTime.

This only happens in Chrome 45 on Windows 10, in Chrome 45 on OS X it works as exptected.

[tdrews]

Thanks for the report.

I'm not exactly sure I understand what you see: so, you seek back into the middle of the seek range, but then after some time passes, seek.end gets set to the current time, so you cannot seek back to the live-edge?

[jkarsrud]

Yes, that's correct.

A better example: When I start streaming I get a start of 5000 and end of ~11000 through the seekrangechanged event. If I set the currentTime to ~7000, the end will — after a few seconds — become ~7000 instead of the expected ~11000. So the live-edge seems to be moved back to where I seeked.

If I seek by using the scrubber, the seeking works as expected, with the live-edge staying where it's supposed to.

I haven't been able to figure out where in shaka-player this happens other than what events are fired, or if it might be an issue with the streaming server sending some data that's misinterpreted. I will keep digging to see if I can figure out why this happens.

[joeyparrish]

@jkarsrud We have been unable to reproduce on Windows 10 with Chrome beta (47). We have QA giving it another try with Chrome stable (46). Are you still seeing this issue?

[joeyparrish]

Unable to reproduce with Chrome 46, either.

[joeyparrish]

Since we can't reproduce, I'm removing this from the v1.6.0 milestone.

[joeyparrish]

I have repro for this now. Good news: it isn't platform-specific!

Here's the simple repro. Load the live sim into the demo app: http://shaka-player-demo.appspot.com/?asset=http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd

Then run:

app.loadDashStream();
setTimeout(function() { video.currentTime = 0; }, 50);

It's a race, so it doesn't trigger 100% of the time, but I'm losing this race fairly often. When we do, app.player_.videoSource_.liveEdgeOffset_ is extremely large, effectively collapsing the seek window.

I believe we can fix this in v1.6.0. Stay tuned.

[jkarsrud]

Sorry I haven't been able to get back to you on this, but it's great that you eventually found a way to repro and fix this! 👍

[joeyparrish]

Glad we could catch it! It's never fun to mark "unable to repro".