Prefer a codec continuity if possible

[peaBerberian]

Current track choice behavior

The track-choice API of the RxPlayer was until now very simple in terms of behavior:

• Either the application gives an explicit choice, usually by listening to the newAvailablePeriods event (whose first purpose is to indicate that new tracks/qualities choices can be made) and by calling API like setAudioTrack in this handler.

• Either it doesn't do that and the RxPlayer just defines an order purely based on the content.

  The content itself can indicate priorities explicitly (e.g. the selectionPriority attributes), implicitly (AdaptatationSet with role set to "main") or a third case that I would call "very implicitly": just the order in which they are defined in the Manifest.

That's the sole rules the RxPlayer used for initial track selection, in order of importance (from the most to the least).

Issue

We encountered cases where some multi-Periods Manifest do not indicate a preferred track priority and the application select none. In that case as I wrote earlier we just rely on declaration order in the Manifest (first declared is preferred).

However, those Manifests were not regular in that order, for some Periods in their case you would have AAC, then ec-3 declared, and for other Periods in the same content you would have the reverse.

This led to probably unwanted codec switching, even leading to many case to "reloading" phases, where the screen would switch to black and rebuffer temporarily.

My solution

I propose here a very simple solution both in terms of logic and conceptually: if a track choice has already been made in that content, and if the application did not choose a track for that Period, just stay consistent with the last chosen track (of the current playback session) of the same type in terms of codec: if we last chose ec-3 we continue with ec-3.

There is however a big question and risk with this feature, it is that it supersedes even explicit Manifest hints like DASH' AdaptationSet@selectionPriority.

I'm not sure 100% is what we want here. I'll have to check the spec and see how other players decide before being sure this is the right way.

[peaBerberian]

I looked at the spec to understand if there's an explicit order for the A/V track choice, especially where selectionPriority sits relative to codec continuity.

Turns out that DASH-IF IOP 5.0 has a dedicated chapter on initial selection for audio tracks in:
https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part8-v5.1.0.pdf

(chapter 6 Client recommendations)

So basically from what I understand, in order:

1. We should filter what is not supported support
2. The language (in case of audio) has priority
3. Then, and to me that's very ambiguous, we should look at other properties associated to the AdaptationSet. They cite:
   a. Viewpoint
   b. Role
   c. Accessibility
   d. AudioChannelConfiguration
   e. SupplementalProperty and EssentialProperty
   f. Others
4. Then @selectionPriority
5. Then, also ambiguous to me, either the "DASH client makes a choice for itself" (implying that step 3 is never "for itself" meaning always external - user or device - explicit reasons?) or random (this one is clear!)

So it depends on the intended "spirit" of step 3, and if DASH' codecs can be considered or not part of "others": codec continuity rely on DASH attributes and not doing it lower the user experience so in some ways it could enter the definition of step 3, but it's not as direct as Accessibility/Viewpoint/Role (e.g. dubbed or not) are...

They probably did not think of that case when writing this.

[github-actions]

✅ Automated performance checks have passed on commit e29a024608bdacc082c54f65825d56a0a666f97b with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	25.57ms -> 25.48ms (0.090ms, z: 0.60813)	36.30ms -> 36.30ms
seeking	204.47ms -> 209.83ms (-5.361ms, z: 0.38436)	18.75ms -> 18.60ms
audio-track-reload	32.86ms -> 32.87ms (-0.012ms, z: 0.04039)	48.75ms -> 48.60ms
cold loading multithread	54.84ms -> 53.28ms (1.558ms, z: 11.27069)	79.20ms -> 77.85ms
seeking multithread	138.60ms -> 137.81ms (0.793ms, z: 0.76487)	21.15ms -> 21.00ms
audio-track-reload multithread	32.02ms -> 31.99ms (0.032ms, z: 1.20743)	47.25ms -> 47.10ms
hot loading multithread	21.79ms -> 22.37ms (-0.585ms, z: 0.93638)	31.95ms -> 31.80ms