Support setMinVideoBitrate in Parameters ?

[sravan1213]

I've a use case where I've to set minimum bitrate for video playback. I didn't find any such method in DefaultTrackSelector.Parameters.

Right now I am getting all available tracks and using setSelectionOverride with required video tracks. Curious is there any easy way to do it?

Thanks in advance.

[ojw28]

Could you clarify what the use case is? Thanks!

[sravan1213]

In our application we show three options High, medium,low quality.

These options are distributed over 7 bitrates.

1080p and above High

720p to less than 1080p Medium

And less than 720p (480p, 360p, 180p) is low.

This can be done easily if we have setMinVideoBitrate in Parameters.

Hope I have clarified the use case.

Thanks,

[ojw28]

So to clarify, if the user selects "High" but has insufficient bandwidth for 1080p, you explicitly want to give the user re-buffering rather than having the player seamlessly adapt down to 720p until the bandwidth improves? And if so, why?

[sravan1213]

Yes, Because it is a user preference that video should be played in 1080p. I think it is a bad user experience if we do ABR even after user selecting 1080p.

[ojw28]

Do you want ABR at all if the user selects an option? If not, you can use track selection overrides to select the specific track you want to play.

[sravan1213]

@ojw28 I need ABR on tracks within particular bitrate range. So, if user selects Medium ( we have three bitrate ladders 480p, 720p and 900p which fall under this ), ABR should apply on only these tracks. Even if the network is bad it should not fall below 480p and restrict to 900p even if the network is better.

Thanks,

[ojw28]

Got it. And given the choice of specifying the minimum bound in terms of resolution or bitrate, which would you prefer? We may add support for one (or both), although it'll likely be handled as a low priority request.

[sravan1213]

Thanks for acknowledging.. i think resolution is already supported (setting video max size). Anyways.. I prefer bitrate over resolution.

[ojw28]

Setting the video min size isn't though, right :)? Which I think is the resolution equivalent of setting the min bitrate.

[sravan1213]

Ahhh.. got it. My bad.
Both approaches will solve my problem.

As we can have various bitrates for same resolution, it makes more sense to have resolution specific parameter.

Let me know if you have any thoughts on this :)

Thanks.

[szaboa]

@ojw28
This would be about to just add a similar logic as com.google.android.exoplayer2.trackselection.DefaultTrackSelector.ParametersBuilder#setMaxVideoSize? If this is the case, and it is open for contribution then I can do it :)

[ojw28]

At a high level, yes. And yes, please feel free to send a pull request.

• It's probably worth adding support for minimum resolution, bitrate and frame-rate all at the same time, to keep the available sets of min and max constraints consistent.
• It's going to be necessary to split isWithinConstraints in DefaultTrackSelector.selectFixedVideoTrack into separate satisfiesMaxConstraints and satisfiesMinConstraints booleans, because they'll need to be handled a little differently. In particular:
  • exceedVideoConstraintsIfNecessary should only apply to max constraints. It's probably not worth an analogous parameter for the min side. We can likely just always violate a min constraint if we need to in order to select a track. It's hard to imagine a scenario where anything else would be preferable.
  • When tie-breaking between two tracks that are both under the min constraints and are within the renderer capabilities, we should pick the one with the higher pixel count (or bitrate). This is the opposite to how we tie-break between two tracks that are both over the max constraints, where we pick the one with the lower pixel count (or bitrate).
  • We need to decide what to do when we have to select between two tracks, one of which violates the max constraints and another of which violates the min constraints.

[szaboa]

Thanks for the guidance, I appreciate it.
So, I've split isWithinConstraints into satisfiesMaxConstraints and satisfiesMinConstraints, but it is not entirely clear how to handle tie-breaking. Assuming that if a track satisfies min constraints worths the same as when it satisfies max constraints, I've incremented the trackScore by 1 in both cases.

In this case, I see six tie-breaking cases (perhaps am I wrong?):

1. selectedTrack's satisfiesMin=true satiesfiesMax=true and track's satiesfiesMin=true satiesfiesMax = true
2. selectedTrack's satisfiesMin=true satiesfiesMax=false and track's satiesfiesMin=true satiesfiesMax = false
3. selectedTrack's satisfiesMin=true satiesfiesMax=false and track's satiesfiesMin=false satiesfiesMax = true
4. selectedTrack's satisfiesMin=false satiesfiesMax=true and track's satiesfiesMin=true satiesfiesMax = false
5. selectedTrack's satisfiesMin=false satiesfiesMax=true and track's satiesfiesMin=false satiesfiesMax = true
6. selectedTrack's satisfiesMin=false satiesfiesMax=false and track's satiesfiesMin=false satiesfiesMax = false

So in case 2 and 5 we can use the pixel count (or bitrate) logic, but not clear how to handle the remaining cases :)
Commit without handling tie-breaking: szaboa@dfec033.

[ojw28]

I think we'd want:

1. If isWithinCapabilities pick the higher quality (i.e., pixel count, or bitrate), else pick the lower quality. This is what the existing tie-breaking logic does.
2. Pick the lower quality, because that's what gets us closest to satisfying the violated max constraints. This is what the existing tie-breaking logic does.
3. I think you just need to decide whether min or max constraints are going to be deemed more important, and code this by giving one a higher score than the other (which effectively removes this case from ever ending up in a tie-break scenario). Which ones are more important seems a bit arbitrary, so I think you should feel free just to pick one and document it!
4. Ditto.
5. If isWithinCapabilities pick the higher quality (i.e., pixel count, or bitrate), because that's what gets us closest to satisfying the violated min constraints. If isWithinCapabilities is false, pick the lower quality because it's most likely to play successfully.
6. If isWithinCapabilities, pick the higher or lower quality according to which out of the min or max constraints you deem as being more important in (3). If min constraints are deemed more important, be consistent here and pick the higher quality to get closest to satisfying them. If max constraints are deemed more important, the consistent thing would be to pick the lower quality. If isWithinCapabilities is false then always pick the lower quality because it's most likely to play successfully.

[szaboa]

Thanks for the tips! I've made a pull-request where I handled these cases as written above.

[ojw28]

Merged into dev-v2.