Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define order of AdaptationSet preference #3022

Closed
japettyjohn opened this issue Jul 9, 2019 · 9 comments
Closed

Define order of AdaptationSet preference #3022

japettyjohn opened this issue Jul 9, 2019 · 9 comments
Assignees
Milestone

Comments

@japettyjohn
Copy link

japettyjohn commented Jul 9, 2019

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?

@japettyjohn japettyjohn reopened this Jul 10, 2019
@japettyjohn japettyjohn changed the title ABR logic where smaller rendition is better Define order of AdaptationSet preference Jul 10, 2019
@japettyjohn
Copy link
Author

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.

@epiclabsDASH
Copy link
Contributor

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 Initial Track Selection for Tiled video #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.

@japettyjohn
Copy link
Author

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.

@BucherTomas
Copy link

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.

@sandersaares
Copy link
Member

sandersaares commented Jul 15, 2019

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.

@Sorqan
Copy link

Sorqan commented Jul 16, 2019

@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.

@japettyjohn
Copy link
Author

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

@dsilhavy
Copy link
Collaborator

We should add the possibility to define a initial track selection algorithm in the app. It should be called in MediaController.selectInitialTrack

@dsilhavy dsilhavy modified the milestones: 4.0.0, 4.0.1 Jun 1, 2021
@dsilhavy dsilhavy modified the milestones: 4.0.1, 4.1.0 Jun 27, 2021
@dsilhavy
Copy link
Collaborator

dsilhavy commented Sep 3, 2021

With #3672 it is now possible to define a custom function that selects the initial track. An example can be found here: https://reference.dashif.org/dash.js/nightly/samples/advanced/custom-initial-track-selection.html .

@dsilhavy dsilhavy closed this as completed Sep 3, 2021
@dsilhavy dsilhavy assigned dsilhavy and unassigned FritzHeiden Sep 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants