Dash.js: Define order of AdaptationSet preference

Created on 10 Jul 2019  路  7Comments  路  Source: Dash-Industry-Forum/dash.js

I am working with three rendition sets in my MPD to maximize platform support. They are h.264, h.265 and VP9. The logic assumes the highest bitrate amongst the AdaptationSets is the best option, but due to h.264 being less efficient than the others it is chosen erroneously. Pretty much as described by BitMovin.

I've also tried putting the all renditions into a single AdaptationSet but I didn't succeed getting that configuration to work.

Is there a way to indicate which AdaptationSet should be taken as a priority?

Feature Request

Most helpful comment

We have similar scenario where we also use HEVC and VP9, but have another issue that might be worth looking into.

We provide streams with both these codecs in their own AdaptationSets to a TV set that claims support for both of these codecs. Both HEVC and VP9 have the same bitrate so selection according to that won't help. If both codecs are supported, dash.js then picks the first AdaptationSet under these circumstances, which is VP9 that in turn fails to play on that device. HEVC is working fine there.

We cannot switch the order of AdaptationSets with their associated codecs as that is needed elsewhere. Suggested viewport attribute has its own purpose, so using it for this seems like a rough workaround. Role attribute should not be used for setQualityForSettingsFor either as that would be another workaround.
What we would likely need here is to have an application that could instruct dash.js, which codec to pick as default if multiple ones are supported. Then player application on one platform can choose VP9 as default while another platform would choose HEVC.

Alternatively, dash.js might attempt to switch to the other AdaptationSet with HEVC by itself if VP9 fails, however, we haven't found a way to achieve this. Moreover, this approach is not related to what this ticket is asking for.

All 7 comments

So this issue appears to be addressed different ways depending on the project. Shaka for example took some basic logic choices to go with the lower average bitrate for the same set of resolutions - which from my testing is a better method than the current mode.

If the current behavior is depended on then another option is implementing the selectionPriority.

Unless there is some other way to hack around the issue, an alphabetic sorting of an obscure field I'm not aware of for instance, then I am very interested in one of the more serious options given above.

Hi @japettyjohn. Thanks for the feedback.

There are different ways in dash.js to affect somehow to the initial adaptationset (track, as it called internally in dash.js source code). Let me explain a bit of all of then:

  • You can use Viewpoints to force dash.js to go for a specific adaptationSet. You can get some details about how to do this here #2045. The inconvenient is you need to previously define viewpoints in your mpd and implement the adaptationSet selection logic yourself.
  • Alternatively, you can let dash.js decide. Dash.js implements 2 different logics for initial AdaptationSet selection, that you can enable using the method setSelectionModeForInitialTrack of the MediaPlayer (doc). These 2 modes are:

    • TRACK_SELECTION_MODE_HIGHEST_BITRATE('highestBitrate'): this mode makes dash.js select the adaptationSet with the highest bitrate. This is the default mode.

    • TRACK_SELECTION_MODE_WIDEST_RANGE('widestRange'): This mode makes dash.js select the adaptationSet with the widest range of bitrates (highest number of renditions).

I am happy to hear new ideas regarding this. If there is a new method that could be useful for the community I am open to add it to dash.js.

Thanks @epiclabsDASH for the data on that.

I'm providing webm/VP9 and fMP4/h.265 for any clients which can support it, then an h.264 fallback. But h.264 is taken as the default as it has a higher bitrate due to the lower quality of encoding. Each adaptation set has the same number of of renditions (6 in my case), so one doesn't have a wider range over the other. In this scenario a lowest bitrate would do it.

This method allows for a wide range of device support while still getting the encoding efficiency improvements offered by more modern codecs.

We have similar scenario where we also use HEVC and VP9, but have another issue that might be worth looking into.

We provide streams with both these codecs in their own AdaptationSets to a TV set that claims support for both of these codecs. Both HEVC and VP9 have the same bitrate so selection according to that won't help. If both codecs are supported, dash.js then picks the first AdaptationSet under these circumstances, which is VP9 that in turn fails to play on that device. HEVC is working fine there.

We cannot switch the order of AdaptationSets with their associated codecs as that is needed elsewhere. Suggested viewport attribute has its own purpose, so using it for this seems like a rough workaround. Role attribute should not be used for setQualityForSettingsFor either as that would be another workaround.
What we would likely need here is to have an application that could instruct dash.js, which codec to pick as default if multiple ones are supported. Then player application on one platform can choose VP9 as default while another platform would choose HEVC.

Alternatively, dash.js might attempt to switch to the other AdaptationSet with HEVC by itself if VP9 fails, however, we haven't found a way to achieve this. Moreover, this approach is not related to what this ticket is asking for.

A general principle of "default order from MPD + override by app callback" might be useful here. Plus some logic to handle "when to fallback VS when to fail". If a good and universal workflow is worked out on this topic for dash.js, I imagine this would also be a valuable contribution to DASH-IF interoperability guidelines, to encourage other players to follow suit.

@BucherTomas This is what I was thinking, something like choosing the default codec and then obviously what it optimum for bandwidth within that codec, if that codec isn't supported, switch to the next priority and of course we don't want inter-codec switching to occur between segments.

My use is an MPD that has H264, H265 and VP9, I would want H265 to play on iOS, VP9 to play on Android, and older devices to fallback to H264. Either the priority of codecs would be defined for all such as "Always try VP9 first, if that doesn't work H265, and if that doesn't work H264" or some sort of default codec to be defined.

This is a sample of what I'm talking about, it takes the h264 in preference of h265 or VP9.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mihaiav picture mihaiav  路  5Comments

carlanton picture carlanton  路  5Comments

bbert picture bbert  路  5Comments

mattlohkamp picture mattlohkamp  路  4Comments

ruslandinov picture ruslandinov  路  4Comments