Regression: choosing lowest-bandwidth codec leads to always picking audio-only variant for HLS #861
Assignees
Labels
component: HLS
The issue involves Apple's HLS manifest format
status: archived
Archived and locked; will not be updated
type: bug
Something isn't working correctly
Milestone
Comments
|
Given #824, where we can't switch to audio-only variants anyway, we should probably solve both problems at one by filtering out audio-only variants in cases where there are audio+video variants available. |
joeyparrish
pushed a commit
that referenced
this issue
Jul 17, 2017
In situations where there are variants with video and audio, and variants with only one of the two, this filters out the less-complete variants. This removes the possibility of the player switching to an audio-only variant and breaking MediaSource. It also solves the regression where audio-only variants have the lowest bandwidth and thus are chosen preferentially on weak connections. Closes #824 Closes #861 Change-Id: Ic37543d98962ddd83a85224e26e5225d142b844e
|
The fix for this has been cherry-picked and will be released in v2.1.5. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This was introduced by 434f1bf (CL that fixed #841). The fact that we started grouping variants by codecs and choosing the group with the smallest average bandwidth led to the player always choosing audio-only variants for HLS content that has at least one.
We can't switch from audio-only variants to audio+video, so we end up being stuck with audio-only.
A manifest to repro: https://nexxplayplus6.streaming.mediaservices.windows.net/32de1b7d-822c-43b2-b3a5-1cd97f0e9ae7/242391_src.ism/manifest(format=m3u8-aapl)
(Discovered by investigating #860).
The text was updated successfully, but these errors were encountered: