Audio track selection depends on initial tracks order

[TheBeastLT]

Version

Media3 main branch

More version details

No response

Devices that reproduce the issue

Any mobile device

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

When audio tracks are selected on some conditions the selected track will be different depending on how these tracks are ordered in the original video container, due to this block:

media/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/trackselection/DefaultTrackSelector.java

Lines 3951 to 3954 in 2b54b1e

	Ordering<Integer> qualityOrdering =
	isWithinConstraints && isWithinRendererCapabilities
	? FORMAT_VALUE_ORDERING
	: FORMAT_VALUE_ORDERING.reverse();

Let's say we have 2 audio tracks one with 2ch and other with 6ch, on mobile devices due to spatializer logic these would be parsed to AudioTrackInfo { channelCount: 2, isWithinConstraints: true }, AudioTrackInfo { channelCount: 6, isWithinConstraints: false } (all other parameters would be the same). With such an order the 2nd track would be picked up, but if audio tracks in the container would be switched then it would pick the 1st audio track with 2ch.

Not sure if such a behaviour was intended, but in general sorting comparators should produce the same end results regardless of the initial order.

Expected result

Selected audio track is the same regardless of the initial order.

Actual result

Selected audio track depends on the initial track order.

Media

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[tianyif]

Hi @TheBeastLT,

Do you have the real sample media to reproduce? I quickly tried a unit test, and this can pass no matter the order I defined with TrackGroupArray trackGroups = wrapFormats(beyondConstraintFormat, withinConstraintFormat) (I also tried the swapped order).

public void selectTracksPreferTrackWithinConstraint() throws Exception {
    Format.Builder formatBuilder = AUDIO_FORMAT.buildUpon();
    Format beyondConstraintFormat =
        formatBuilder.setId("beyondConstraintFormat").setChannelCount(6).build();
    Format withinConstraintFormat = formatBuilder.setId("withConstraintFormat").setChannelCount(2).build();
    TrackGroupArray trackGroups = wrapFormats(beyondConstraintFormat, withinConstraintFormat);

    Map<String, Integer> mappedCapabilities = new HashMap<>();
    mappedCapabilities.put(withinConstraintFormat.id, FORMAT_HANDLED);
    mappedCapabilities.put(beyondConstraintFormat.id, FORMAT_HANDLED);
    RendererCapabilities mappedAudioRendererCapabilities =
        new FakeMappedRendererCapabilities(C.TRACK_TYPE_AUDIO, mappedCapabilities);

    trackSelector.setParameters(defaultParameters.buildUpon().setMaxAudioChannelCount(2).build());
    TrackSelectorResult result =
        trackSelector.selectTracks(
            new RendererCapabilities[] {mappedAudioRendererCapabilities},
            trackGroups,
            periodId,
            TIMELINE);
    assertFixedSelection(result.selections[0], trackGroups, withinConstraintFormat);
}

In fact, given that these two tracks are true and false in the field isWithinConstraints, the comparison chain will already have a decision on the comparison at this line:

media/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/trackselection/DefaultTrackSelector.java

Line 3975 in 4acd1b9

.compareFalseFirst(this.isWithinConstraints, other.isWithinConstraints)

unless there are any preferences set via the track selection Parameter or media or the system, which can lead to a decision even earlier than isWithinConstraints.

Please feel free to send us the sample media to reproduce the real case of the issue.