ABR adapts across variants with different roles #947
Assignees
Labels
status: archived
Archived and locked; will not be updated
type: bug
Something isn't working correctly
Milestone
Comments
bhh1988
pushed a commit
to bhh1988/shaka-player
that referenced
this issue
Jul 26, 2017
This fixes a bug where two audio tracks with the same language but different roles might be switched in and out due to ABR. Technically the DASH spec requires that the player not adapt in/out of a single AdaptationSet, but since the "variant" concept does not track the AdaptationSet that its component streams originate from, the closest thing we can go by is the "role", since two streams with different roles certainly come from different adaptation sets. Issue shaka-project#947
bhh1988
pushed a commit
to bhh1988/shaka-player
that referenced
this issue
Jul 26, 2017
This fixes a bug where two audio tracks with the same language but different roles might be switched in and out due to ABR. Technically the DASH spec requires that the player not adapt in/out of a single AdaptationSet, but since the "variant" concept does not track the AdaptationSet that its component streams originate from, the closest thing we can go by is the "role", since two streams with different roles certainly come from different adaptation sets. Issue shaka-project#947
bhh1988
pushed a commit
to bhh1988/shaka-player
that referenced
this issue
Jul 31, 2017
This fixes bugs in both filterVariantsByRoleAndLanguage and filterTextStreamsByRoleAndLanguage which would ultimately allow ABR to adapt across streams/variants with different languages/roles. There were multiple ways that this could happen, detailed in shaka-project#947 and shaka-project#918. The bug is fixed by some re-arrangment of the filtering logic and adding logic to the END of the filter methods that do a final pass to select a uniform set of variant/streams. Technically the DASH spec requires that the player not adapt in/out of a single AdaptationSet, but since the "variant" concept does not track the AdaptationSet that its component streams originate from, the closest thing we can go by is the "role", since two streams with different roles certainly come from different adaptation sets. Fixes issue shaka-project#947 and shaka-project#918
bhh1988
pushed a commit
to bhh1988/shaka-player
that referenced
this issue
Jul 31, 2017
This fixes bugs in both filterVariantsByRoleAndLanguage and filterTextStreamsByRoleAndLanguage which would ultimately allow ABR to adapt across streams/variants with different languages/roles. There were multiple ways that this could happen, detailed in shaka-project#947 and shaka-project#918. The bug is fixed by some re-arrangment of the filtering logic and adding logic to the END of the filter methods that do a final pass to select a uniform set of variant/streams. Technically the DASH spec requires that the player not adapt in/out of a single AdaptationSet, but since the "variant" concept does not track the AdaptationSet that its component streams originate from, the closest thing we can go by is the "role", since two streams with different roles certainly come from different adaptation sets. Fixes issue shaka-project#947 and shaka-project#918
|
The fix has been backported for v2.1.6. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If a video has multiple audio tracks, each with different roles (but with the same language), and there's no role-preference given, then the player is initialized with all of them as part of the same variant pool. The simple_abr_manager will then just adapt across them, so you could end up with different audio tracks playing in and out.
I have a fix for this, but I want to pose a more general question: was it an intentional design decision to not include the adaptation-set's ID into the variants? Technically according to the DASH spec, a player should not adapt across two different adaptation sets of the same type. But because the adaptation-set information is not currently captured in the "variants" structure, it's impossible for ABR to do the correct thing. Right now, we have to resort to using language/role combo as a signal for whether things are in the same adaptation-set or not, and this maybe tends to be fairly accurate but obviously can be not enough too.
The text was updated successfully, but these errors were encountered: