an API to limit playable/seekable range

[msokalski]

I'd like to have seekable/playable range limiter as specified here:

https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_HTML5_audio_and_video#Specifying_playback_range

var url = 'some_path/my.mpd' + '#t=10.0,20.0';
var src = new shaka.player.DashVideoSource( url, icp, ewma )

Thanks!

[joeyparrish]

You're referencing something with HTML5 video which doesn't apply to manifests. It also conflicts with "MPD Anchors", section C.4 in the MPD spec (ISO/IEC 23009-1:2014). MPD anchor syntax allows for t=start, but no end. So if we did what you're suggesting, we would limit our ability to add MPD anchors later.

If there is significant interest, we could offer an API to accomplish the same goal, but we will not implement this through a fragment in the manifest URL.

[msokalski]

For me, it is fine to have it in api, could be even in 'declarative' taste via Player constructor.

[joeyparrish]

Okay, then I've renamed the issue to "an API to limit playable/seekable range". We will not make it a priority right now, but we will re-evaluate after v2.0 is out.

[jaredscheib]

@joeyparrish any thoughts on this now that v2.0 (beta) is out? Seeking to determine whether it's currently possible to limit a download to a video fragment (start-end range). And, if that's possible but not yet implemented, what the status might be? Or if it's on the back-burner at the moment, does it seem like something that I (or someone outside of the core team) could take a crack at? Thank you for your help!

[joeyparrish]

We have a lot left to do to finish v2.0.0, so this is still on the back-burner. You are very welcome to take a crack at it.

We would prefer to discuss the API design with you before you send us a PR, to make sure it fits with our vision of v2. If you want to get in touch via email, you can find my address in the CONTRIBUTORS file. Or we can discuss the details right here on github.

One last thing: Please read CONTRIBUTING.md. We have a small amount of bureaucracy that you have to go through before we can accept a PR. Thanks for offering to contribute!

[ismena]

@msokalski @jaredscheib I'm about to start looking into this. Could you provide some context to help me design it right: when we're talking about limiting the playable/seekable range, are you just interested in not letting a viewer "go" beyond the specified time range? Or is there something more you'd like to do with the specified part of the video (like make a loop out of it and play it repeatedly or something along those lines?)

[msokalski]

@ismena In our case, we needed it to 'nicely' behave when user resumes DRM controlled playback. One of possible scenarios should not allow user to seek behind already presented video (-30sec margin).

[ismena]

@msokalski To clarify: are we talking about live video or VOD?

[msokalski]

@ismena VOD only.

[ismena]

Sorry for the delay, I was on vacation, but now I'm back and ready to look at this.
Let me clarify a few things to make sure we're on the same page.
Let's say I have a 60 second presentation. I use the API to set the range to {start: 10, end: 40}.

1. Should the presentation start from 0 and show first 10 seconds, but not let me seek back to 0, or should it start from 10?
2. Once we reach 40 seconds (the end of the window), should the presentation stop or continue to the end without letting me seek past the end of the window?

[msokalski]

Hi :)
-If current play position is <10 it should immediately seek to 10.
-Player should automatically pause on 40 (if playing).
-Seek bar should not allow moving current position before 10 and after 40.
-Above could be also realized (as a separate boolean param) by mapping 10 to leftmost and 40 rightmost position.

[joeyparrish]

It sounds like we can reuse the existing seekRange functionality we have for live streams, but with a static, configurable range.

[ismena]

I added playRangeStart and playRangeEnd configs to PlayerConfiguration, so you can use player.configure() to set these.
Same as other configurations, they wil take effect starting from the next load() call.

Let us know if you have any questions!