The default audio track in Dash.js 5.0 is different from the one in Dash.js 4.

[testeur-990]

Hello,
The default audio track in Dash.js 5.0 is different from the one in Dash.js 4.
Please see the attached screenshot.

After analyzing the issue on our side, we observed that it is related to the addition of:
if (tmpArr.length > 1) {
tmpArr = getTracksWithHighestEfficiency(tmpArr);
}
in _trackSelectionModeHighestSelectionPriority in Dash.js 5

Could you please check?

[dsilhavy]

I don't consider this a bug. We are trying to use the track that provides the highest compression efficiency if multiple tracks are selectable. You can define the initial track using our track selection functionality: https://dashif.org/dash.js/pages/usage/track-selection.html

As an alternative you can define your own custom initial track selection function: https://reference.dashif.org/dash.js/latest/samples/advanced/custom-initial-track-selection.html

[stschr]

Worth noting here:

In general, dash.js would apply some selection based on provided preferences. Since all audio AdaptationSets don't signal any properties, this is not applicable here.

With this, multiple track still remain:
The first option (which is configures as default) is for the content provider to signal a prioritization via the @selectionPriority. Unfortunately, this is also not present in this MPD.

Next, since dash.js has to make a selection, multi heuristics are available in dash.js: highest bitrate, first track, highest efficiency or widest range.
When highest selection priority is configured (as per default), you end up exactly with the code you already mentioned and the order of subsequent heuristics is fixed.
If you prefer a different one (and not using the selectionPriority), you can configure this in Settings via the selectionModeForInitialTrack property.

Using the initial track selection function as mention by Daniel is the final option, but you need to keep in mind that this will replace all of the beforementioned functions.

[testeur-990]

Hello @dsilhavy , @stschr ,
Thanks for your response. I understand that Dash.js aims to select the track with the highest compression efficiency when multiple tracks are available. However,from what I see in the code, the getTracksWithHighestEfficiency function evaluates efficiency as follows:

  function getTracksWithHighestEfficiency(trackArr) {
        let min = Infinity;
        let result = [];
        let tmp;

        trackArr.forEach(function (track) {
            const sum = track.bitrateList.reduce(function (acc, obj) {
                const resolution = Math.max(1, obj.width * obj.height);
                const efficiency = obj.bandwidth / resolution;
                return acc + efficiency;
            }, 0);
            tmp = sum / track.bitrateList.length;

            if (tmp < min) {
                min = tmp;
                result = [track];
            } else if (tmp === min) {
                result.push(track);
            }
        });

        return result;
    }

For video tracks, this calculation makes sense since resolution = width * height. However, for audio tracks, width and height are not applicable, meaning resolution will be 1 . As a result, the calculation effectively reduces to selecting the track with the lowest bitrate.

Is this the intended behavior? Does "efficiency" have any real meaning when applied to audio track selection?

I would appreciate your clarification.

[stschr]

Hello @testeur-990 ,

you're right, for audio, this does not make sense.
I'll come up with a small change soon.

[stschr]

@dsilhavy :
What about "elevating" the selectionPriority?

Wouldn't it make sense to first prioritize based on selectionPriority and then, only if this didn't provide a unique track, to apply the heuristics configurable via selectionModeForInitialTrack?

[dsilhavy]

Thanks for the clarification @testeur-990 .

What we use today by default is the mode TRACK_SELECTION_MODE_HIGHEST_SELECTION_PRIORITY. This means we check for selectionPriority first. Only if we don't find a unique track, we fallback to getTracksWithHighestEfficiency or other functions.

How about not using getTracksWithHighestEfficiency for audio, but instead moving to the next selection mechanism in the list, which would be getTracksWithHighestBitrate in _trackSelectionModeHighestSelectionPriority.