Prefer a codec continuity if possible - #1839
Conversation
80fdc55 to
90546cf
Compare
|
I looked at the spec to understand if there's an explicit order for the A/V track choice, especially where Turns out that DASH-IF IOP 5.0 has a dedicated chapter on initial selection for audio tracks in: (chapter So basically from what I understand, in order:
So it depends on the intended "spirit" of step 3, and if DASH' They probably did not think of that case when writing this. |
90546cf to
46ed882
Compare
470c3f8 to
3dde189
Compare
46ed882 to
691b795
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
Doesn't that go against this:
It's from there, https://dashif.org/webRTC/report.html |
Here in this PR we're in the case of a content that had Period already playing before were "codec continuity" (like h264 -> h264) will take precedence over
The sentence is very loose with thay "may". I don't quite get the "strength" that |
peaBerberian
added
the
Priority: 2 (Medium)
691b795 to
2793b73
Compare
2793b73 to
55d8df1
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
55d8df1 to
b7e0552
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
|
@Florent-Bouisset I dived into this a little more so we can decide what to do with this. To me the specs are too ambiguous (voluntarily or involuntarily I don't know), about the ordering between So to break the ambiguity, I thought that the final answer would be to look at what the other DASH players are doing.
So it seems all players I look at agree that |
OK, I think we can adapt the logic for the encountered use case because the spec is a bit vague about what is included in |
b7e0552 to
3770fd0
Compare
|
✅ Automated performance checks have passed on commit DetailsPerformance tests 1st run outputNo significative change in performance for tests:
|
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 I written earlier we just rely on declaration order in the Manifest (first declared is preferred). However, thoses Manifest 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 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.
3770fd0 to
2e3a962
Compare
2 participants
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
newAvailablePeriodsevent (whose first purpose is to indicate that new tracks/qualities choices can be made) and by calling API likesetAudioTrackin 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
selectionPriorityattributes), implicitly (AdaptatationSetwithroleset 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-3we continue withec-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.