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.

Sign up for GitHub

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

Jump to bottom

Use data saver mode signal to inform ABR decisions #855

Closed
hbengali opened this issue Jun 6, 2017 · 4 comments
Closed

Use data saver mode signal to inform ABR decisions #855

hbengali opened this issue Jun 6, 2017 · 4 comments
Assignees
@joeyparrish
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone
v2.5

Comments

@hbengali
Copy link

hbengali commented Jun 6, 2017 •
edited

An API to signal when the user has turned on data saver mode is being discussed here:

WICG/netinfo#42

Once this signal is available, Shaka player should respect the user's intent and change the stream selection logic to limit data consumption. The preferred mechanism for this would be to allow developers to restrict to a different max resolution/bandwidth when data saver is turned on, vs when it is not.
@joeyparrish joeyparrish added the type: enhancement New feature or request label Jun 6, 2017
@joeyparrish joeyparrish added this to the v2.3.0 milestone Jun 6, 2017
@joeyparrish joeyparrish modified the milestones: Backlog, v2.3.0 Jun 16, 2017
@joeyparrish
Copy link
Member

Moving this to the backlog, since it does not appear to be available from the browser yet.

@joeyparrish joeyparrish modified the milestones: Backlog, v2.4.0 Oct 8, 2017
@joeyparrish joeyparrish modified the milestones: v2.4.0, Backlog Dec 4, 2017
@joeyparrish joeyparrish modified the milestones: Backlog, v2.5 Mar 29, 2018
@joeyparrish
Copy link
Member

This should be available now, so we just need to decide how our behavior will differ when the user enables data-saver mode.

@joeyparrish joeyparrish mentioned this issue Apr 5, 2018
Closed
@joeyparrish joeyparrish self-assigned this May 31, 2018
@joeyparrish
Copy link
Member

When the browser indicates that we should save data, we will default AbrManager's restrictions object to a max height of 360. Apps can still override this, and users can still select higher resolution tracks when ABR is disabled. The restrictions object will be treated as "soft" restrictions, meaning that if the restrictions cannot be met, we will not fail playback.

shaka-bot pushed a commit that referenced this issue May 31, 2018
@joeyparrish
Make AbrManager restrictions "soft"
ed0f37b 
This change makes restrictions on AbrManager into "soft" restrictions.
This means that if these restrictions cannot be met, AbrManager will
still choose something instead of throwing an error.

This is in contrast to top-level restrictions or DRM-based
restrictions, which are "hard" restrictions that will stop playback if
necessary.

This change also fixes some minor issues with the SimpleAbrManager
tests, such as cross-test pollution in the restrictions object.

This is a lead-in to issue #855, where AbrManager's restrictions will
have their defaults changed when the "saveData" signal is present in
the browser.

Change-Id: Icdb2ff5df7ceb0d94f1267bf81e59dede3c2baf9
joeyparrish added a commit that referenced this issue Jun 1, 2018
@joeyparrish
Make AbrManager restrictions "soft"
a48c0ef 
This change makes restrictions on AbrManager into "soft" restrictions.
This means that if these restrictions cannot be met, AbrManager will
still choose something instead of throwing an error.

This is in contrast to top-level restrictions or DRM-based
restrictions, which are "hard" restrictions that will stop playback if
necessary.

This change also fixes some minor issues with the SimpleAbrManager
tests, such as cross-test pollution in the restrictions object.

This is a lead-in to issue #855, where AbrManager's restrictions will
have their defaults changed when the "saveData" signal is present in
the browser.

Backported to v2.3.x

Change-Id: Icdb2ff5df7ceb0d94f1267bf81e59dede3c2baf9
joeyparrish added a commit that referenced this issue Jun 1, 2018
@joeyparrish
Default max 360p for ABR when saveData == true
6f90250 
Closes #855

Change-Id: Ib3b838a05bd147d60a91903bcc54176f86bc9f9d
@joeyparrish
Copy link
Member

Cherry-picked for v2.3.9 and v2.4.1.

joeyparrish added a commit that referenced this issue Jun 1, 2018
@joeyparrish
Make AbrManager restrictions "soft"
48c23c2 
This change makes restrictions on AbrManager into "soft" restrictions.
This means that if these restrictions cannot be met, AbrManager will
still choose something instead of throwing an error.

This is in contrast to top-level restrictions or DRM-based
restrictions, which are "hard" restrictions that will stop playback if
necessary.

This change also fixes some minor issues with the SimpleAbrManager
tests, such as cross-test pollution in the restrictions object.

This is a lead-in to issue #855, where AbrManager's restrictions will
have their defaults changed when the "saveData" signal is present in
the browser.

Backported to v2.4.x

Change-Id: Icdb2ff5df7ceb0d94f1267bf81e59dede3c2baf9
joeyparrish added a commit that referenced this issue Jun 1, 2018
@joeyparrish
Default max 360p for ABR when saveData == true
b20a59f 
Closes #855

Change-Id: Ib3b838a05bd147d60a91903bcc54176f86bc9f9d
@shaka-project shaka-project locked and limited conversation to collaborators Jul 30, 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.
Assignees

@joeyparrish joeyparrish

Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Milestone
v2.5
Development

No branches or pull requests
3 participants
@joeyparrish @hbengali @shaka-bot