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

Regression - choose lowest-bandwidth codec when the browser can do multiple #841

Closed
joeyparrish opened this issue Jun 1, 2017 · 1 comment
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@joeyparrish
Copy link
Member

I seem to recall that we used to choose codecs based on lowest average bandwidth. Choosing codecs by bandwidth would allow us to prefer, for example, VP9 over H.264 when it would save bandwidth.

Since then, it seems we have regressed. We currently have no way to prefer codecs based on bandwidth. Once the initial selection has been made, we stick with it, but the initial selection is based on available bandwidth only. If there is much bandwidth available, we wind up choosing the least efficient streams.

To reproduce:

  1. Load the demo app in Chrome. The demo defaults to the multicodec "Angel One" clip.
  2. Open the JS console.
  3. Increase the initial bandwidth estimate: debugConfig = { abr: { defaultBandwidthEstimate: Infinity }};
  4. Click "load".

The system will choose h.264, even though vp9 could have been played and would have saved bandwidth.

@joeyparrish joeyparrish added the type: bug Something isn't working correctly label Jun 1, 2017
@joeyparrish joeyparrish added this to the v2.2.0 milestone Jun 1, 2017
@joeyparrish joeyparrish self-assigned this Jun 1, 2017
shaka-bot pushed a commit that referenced this issue Jun 5, 2017
 - Make FakeStreamingEngine injectable by removing Period argument
   - FakeStreamingEngine can now have its spies manipulated before we
     call player.load().
 - Do not poke into player's manifest_ and streamingEngine_ members in
   chooseStreams(), since load() sets those already.
 - Instead of setting activeStreams in the constructor, set them in
   init().  This is a more accurate fake, and this is important for
   upcoming tests related to early filtering, since filtering takes
   into account the active streams.

Leads into a fix for #841

Change-Id: Ia893053490cde819e32907c7a1a2030c29022f62
joeyparrish added a commit that referenced this issue Jun 5, 2017
 - Make FakeStreamingEngine injectable by removing Period argument
   - FakeStreamingEngine can now have its spies manipulated before we
     call player.load().
 - Do not poke into player's manifest_ and streamingEngine_ members in
   chooseStreams(), since load() sets those already.
 - Instead of setting activeStreams in the constructor, set them in
   init().  This is a more accurate fake, and this is important for
   upcoming tests related to early filtering, since filtering takes
   into account the active streams.

Leads into a fix for #841

Change-Id: Ia893053490cde819e32907c7a1a2030c29022f62
joeyparrish added a commit that referenced this issue Jun 5, 2017
Before asking AbrManager to choose streams, we should choose codecs.
Choose the most efficient codecs, and do it after we have filtered
out the codecs that the platform cannot use.

Closes #841

Change-Id: Ifbdd22b33254d4584f77db6456ab238f7c04c755
@joeyparrish
Copy link
Member Author

Cherry-picked to v2.1.3.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

2 participants