Change in behavior of selection override in 2.16.0

[moneytoo]

Follow up on #9649. (@tonihei)

I applied eb678a7 on top of r2.16.0 but I still have issues working with selection overrides. The same code which works on 2.15.1 doesn't work on 2.16.0. (Is there possibly more to this issue?)

for (int rendererIndex = 0; rendererIndex < mappedTrackInfo.getRendererCount(); rendererIndex++) {
    if (mappedTrackInfo.getRendererType(rendererIndex) == C.TRACK_TYPE_TEXT) {
        final TrackGroupArray trackGroups = mappedTrackInfo.getTrackGroups(rendererIndex);
        final DefaultTrackSelector.SelectionOverride selectionOverride =
                trackSelector.getParameters().getSelectionOverride(rendererIndex, trackGroups);
        DefaultTrackSelector.Parameters parameters = trackSelector.getParameters();

        if (parameters.getRendererDisabled(rendererIndex)) {
            Log.d("Test", "Disabled");
        } else if (selectionOverride == null) {
            Log.d("Test", "No selection override");
        } else {
            Log.d("Test", "Index=" + selectionOverride.groupIndex);
        }
    }
}

On 2.15.1, I can use this to detect subtitle index. (Testing with the same video file as in the linked issue)

On 2.16.0, the selection override is always null.

I noticed that methods like DefaultTrackSelector.ParametersBuilder.setSelectionOverride() etc. are deprecated but nothing from the code above(getSelectionOverride). (I would still expect the code to work the same though).

• ExoPlayer version number: 2.16.0
• Android version: Android 10
• Android device: OnePlus 7

[tonihei]

I believe this is working as intended, although I can see how it might not be obvious why.

ExoPlayer 2.16.0 introduced new track selection APIs in the Player interface. In particular, TrackSelectionParameters allows to set track overrides. The "old" way of using DefaultTrackSelector still works, but has a different set of (now deprecated) selection overrides, which work in a slightly different way. Your code snippet above checks the old overrides, but StyledPlayerView started setting the new overrides, that's why you can't see them anymore.

In any case, the selection overrides are the input to the track selection algorithm, not the output that tells you which tracks are actually selected. So to check which text track is selected, you should not query the configuration parameters, but the actually selected tracks:

for(TrackGroupInfo groupInfo : player.getCurrentTracksInfo().getTrackGroupInfos()) {
  if (groupInfo.getTrackType() == C.TRACK_TYPE_TEXT && groupInfo.isSelected()) {
    Log.d("Test", "Selected text language: " + groupInfo.getTrackGroup().getFormat(0).language);
  }
}

There are still two things to fix here:

1. trackSelector.getParameters().getSelectionOverride should be deprecated in line with all the setters so that it would have been clear to you that this code is not up to date.
2. We are missing some documentation for how to use the new track selection APIs in general.

[moneytoo]

What would be the best way to detect user selected "Auto" audio track (in StyledPlayerView)? Right now I'm detecting it by analyzing Format mime type of TrackSelectionOverrides from ExoPlayer.getTrackSelectionParameters(). But that doesn't seem like the best way as I do not filter it by C.TRACK_TYPE_AUDIO...

[tonihei]

I think this is the only way to make sure, yes. We have a private method TrackSelectionOverride.getTrackType which returns the track type, seems we could make this public.

[krocard]

What would be the best way to detect user selected "Auto" audio track (in StyledPlayerView)?

The only way right now is to check if any trackGroup in ExoPlayer.getCurrentTracksInfo() is currently overridden. This is the same as the old override.

Just looking for any overrides of a given type doesn't give the expected information because that override could be left from a previous Media. Eg. VideoA has an override, VideoB starts playing, the VideoA override is still present but ignored as it doesn't match any trackGroup from VideoB (the player doesn't remove overrides on track transition).

@tonihei I had considered to change the selected boolean in each TrackInfo to a selectedReason flag. That would allow to specify why each trackGroup was selected (eg, override).
I had

[tonihei]

Ah, yes, for playlists you'd also need to check if the track overrides are actually part of the current item.

I had considered to change the selected boolean in each TrackInfo to a selectedReason flag. That would allow to specify why each trackGroup was selected (eg, override).

I wonder if this is confusing because you can also select tracks by specifying a preferred language for example and for someone looking at the selected tracks, this is probably the same case (=a specific parameter preference has caused this selection). But if we include these settings in the reasons then it becomes hard to track which specific setting was responsible for selecting a track.

[tonihei]

I'll close this issue for now because all immediate bugs/questions have been addressed I believe.