Restricting bitrates

[sanbornhilland]

In #29 you mentioned these use cases:

1. Adaptation always enabled or disabled, and therefore set once programmatically.
2. Adaptation always controlled by some application UI element, and therefore set on interaction with that element.

I have a third use case that I am trying to figure out how to accommodate:

1. Adaptation enabled for some subset of all possible tracks

For instance, I need to be able to cap the bandwidth so that I can specify no tracks above a certain bandwidth are played. But there may be several available tracks below the given bandwidth and I would like adaptation to stay enabled so that switching can continue between those tracks.

It seems this can be done by disabling certain tracks based on bandwidth inside the StreamVideoSource#getVideoTracks method but I'm not sure this is the right place to do this.

[joeyparrish]

The only use case we've had so far for disabling certain tracks is due to licensing issues. For example, the user's platform may not be secure enough for a content provider to be comfortable providing the key for the HD tracks, so the license may only contain the key for the SD tracks.

A license server has to have a way to signal the client that these restrictions are in place, and we've seen providers do this by adding headers to the license response. (There may be other ways to communicate these restrictions using the new EME APIs, but this convention predates them.) DrmSchemeInfo has a field for a license post-processor, which serves two purposes:

1. Remove any headers from the license response which are specific to the application and not understood by the CDM.
2. Parse any restrictions specified by those headers and communicate them to the rest of the system.

We created shaka.player.DrmSchemeInfo.Restrictions to represent those restrictions, which to date, have only been max height & max width.

If you want to restrict based on bandwidth, here's one way we could proceed:

1. Add maxBandwidth to the Restrictions class.
2. Come up with an API on Player to set/update restrictions outside of the license post-processor flow, so that your use case is not tied to encrypted media specifically.
3. Your app can then set bandwidth limitations at any time.

Thoughts?

[sanbornhilland]

I was originally looking at the Restrictions class but saw that it was only getting called after a license request so was unsure what exactly this class was for. But it does seem like a more natural place to add bandwidth limits.

At the moment the solution I have provides methods for setting max and min bandwidth from the Player and then any tracks outside this range get filtered out when streamVideoSource.getVideoTracks() is called. This has the advantage of being settable at any time but I like your suggestion of adding maxBandwidth (and minBandwidth) to the Restrictions class even though from what I can tell it will involve more work. It's not immediately obvious to me what the best way to have restrictions update on setting.

Edit: Specifically what is unclear to me is where to call videoSource_.setRestrictions() if it going to get called outside of the license request callback.

[joeyparrish]

I see what you mean. I'll elaborate my thoughts on setRestrictions() in the conversation on your latest pull request. Thanks again for taking this on!

[joeyparrish]

Closing now that #36 is merged. Thanks again!