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

Need a mechanism for considering device conditions that affect media capabilities #43

Open
jdsmith3000 opened this Issue Jun 8, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@jdsmith3000

jdsmith3000 commented Jun 8, 2017

I noted issue #26 talked about environment, but then converged very specifically on dealing with scenarios where capabilities can change (e.g. when the display suddenly changes or is sent to a remote screen). There are also situations where steady considerations will affect the query response.

Some:

  • An EME keySystem can represent a software media pipeline or one that is in hardware. The capabilities of each would likely be quite different.
  • If a device is batteryPowered or not could affect the response. It's perhaps more likely that it would do so based on policy rather than a hard difference in capabilities between battery and AC power. Given the power consumed by very high quality video streams, users may wish to play HD content only on battery. Designs should be able to reflect this in the capabilities queries.

There could be others. I'd like to see some provision to include conditions along with audio and video configurations, perhaps as a MediaConditions addition to MediaConfiguration?

dictionary MediaConfiguration {
VideoConfiguration video;
AudioConfiguration audio;
MediaConditions conditions;
};

@chcunningham

This comment has been minimized.

Show comment
Hide comment
@chcunningham

chcunningham Oct 9, 2018

Collaborator

Working on adding key systems to the query. Explainer was updated a while back. Pull request posted recently.

No work done on the battery request. How would sites use this? They may learn that capabilities differ when unplugged, but have no way of knowing whether the user is planning to unplug. Users who don't unplug during the playback will not want sites to take the min(plugged, unplugged) capabilities.

Collaborator

chcunningham commented Oct 9, 2018

Working on adding key systems to the query. Explainer was updated a while back. Pull request posted recently.

No work done on the battery request. How would sites use this? They may learn that capabilities differ when unplugged, but have no way of knowing whether the user is planning to unplug. Users who don't unplug during the playback will not want sites to take the min(plugged, unplugged) capabilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment