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

Use data saver mode signal to inform ABR decisions #855

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

Comments

Projects
None yet
3 participants
@hbengali
Copy link

commented Jun 6, 2017

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 this to the v2.3.0 milestone Jun 6, 2017

@joeyparrish joeyparrish modified the milestones: Backlog, v2.3.0 Jun 16, 2017

@joeyparrish

This comment has been minimized.

Copy link
Member

commented Jun 16, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 29, 2018

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

@joeyparrish

This comment has been minimized.

Copy link
Member

commented May 31, 2018

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

Make AbrManager restrictions "soft"
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

@shaka-bot shaka-bot closed this in baad08e May 31, 2018

joeyparrish added a commit that referenced this issue Jun 1, 2018

Make AbrManager restrictions "soft"
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

Default max 360p for ABR when saveData == true
Closes #855

Change-Id: Ib3b838a05bd147d60a91903bcc54176f86bc9f9d
@joeyparrish

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

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

joeyparrish added a commit that referenced this issue Jun 1, 2018

Make AbrManager restrictions "soft"
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

Default max 360p for ABR when saveData == true
Closes #855

Change-Id: Ib3b838a05bd147d60a91903bcc54176f86bc9f9d

@shaka-bot shaka-bot added the archived label Jul 30, 2018

@google google locked and limited conversation to collaborators Jul 30, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.