Add support for preferred video role flags
See original GitHub issueUse case description
Some manifests can include alternative video tracks for example for sign language interpretation of the same video. The manifest parser is able to parse the roles included on these representations and is accessible via format.roleFlags
. A client should be able to give a preferred role flag for video from those defined in C.java
to the track selector in the same way preferred language or audio role flags are catered for. Right now this is possible with setting a custom selection override, but that also entails including all other filters such as bitrate and viewport width filtering in a custom override rather than using the default trackselector’s built-in support.
Proposed solution
DefaultTrackSelector.ParametersBuilder
would have a setPreferredVideoRoleFlags(int flags)
that would accept single or combined flags for instance setPreferredVideoRoleFlags(ROLE_FLAG_ALTERNATE|ROLE_FLAG_SIGN)
. In the case of a single flag the track selector would select tracks that may have more flags than those specified, but includes at least all of the specified flags, so in the example above, it would be able to select a track with flags=ROLE_FLAG_SIGN|ROLE_FLAG_ALTERNATE|ROLE_FLAG_SUPPLEMENTARY
but not one with flags=ROLE_FLAG_ALTERNATE|ROLE_FLAG_EASY_TO_READ
. If the specified flags are not available on any video track, revert to ROLE_FLAG_MAIN
or 0
, which is the default flag if none is specified.
Alternatives considered
The order of filtering related to other parameters, such as maxVideoBitrate
, might be a point that needs some thought. Should flags be filtered on after bitrate filters are already applied or rather bitrate filter be applied after role flags are already filtered. In my opinion the latter is preferable, as that would be most compatible with user needs.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (4 by maintainers)
Top GitHub Comments
Thanks! There is one small change I’d propose for the existing logic, which is to boost the “exact match” case so that tracks whose flags match exactly are preferred over tracks that also declare additional flags, in the case that both are present.
Would you expect this logic for audio and text as well, because we don’t enforce the part in bold for those at the moment. We should probably make sure all three work in the same way, else it’s going to be pretty confusing for someone who’s using more than one of them.