Improving startup performance with element.currentTime

[LloydW93]

Currently, if a video element has a currentTime before playback is started in dash.js, it will first attempt to load the first fragments for the stream, then load the ones for the current playback time, immediately discarding the initially loaded media.

The use case for this is when resuming content, e.g. the user was previously 15 minutes through an hour long piece of content. In our implementation we also currently use this to implement failover between our different suppliers (CDNs), although I suspect that will change once multiple BaseURL support is added.

In 1.6.0, we did 716241b to resolve this, but the more I think about this code, the more I think that this possibly caused problems elsewhere, for example with multiperiod content.

Does anyone have thoughts on how else this issue might be tackled, or whether this code definitely has side effects? It works great in our simple use case, but I suspect it may be a factor for some of the issues some people are having with 1.6.0.

[dsparacio]

Just to note this does infact break Multi Period for some stream test. We also think that you should not use the element to store time as you switch but rather to store in player and append as #s=TIME on the new CDN MPD. Leave change in for now until Multi period work is done

[LloydW93]

That's okay - I believe this can be re-used as at the time we added it there was no support for time URL fragments. We can change our implementation to use this going forward instead.

If it's going to be removed though, better to do that in a 2.0.0 rather than a 2.1.0?

[dsparacio]

OK if you are ok with removing this for 2.0 then I will issue that change today. Did not want to just pull the rug out. Thanks for the confirmation.

[dsparacio]

@LloydW93 Can I close?

[LloydW93]

Yep!