Intent to Implement: Media Capabilities: decoding

[Mounir Lamouri]

Contact emails

chcunn...@chromium.org, mlam...@chromium.org

Spec

https://wicg.github.io/media-capabilities/

Summary

This specification intends to provide APIs to allow websites to get more information about the decoding abilities of the device/system/browser. This enables the website to make optimal decisions when selecting media streams for the user.

Motivation

Today, media sites “choose” a media format (codec, profile, resolution, bitrate) without clear feedback on device decoding abilities. The Media Capabilities API allows them to make more informed choices on the media format that yields  the best streaming experience for their users. This works both ways - a) it ensures that when a user meets certain thresholds of performance, their experience can be enhanced and b) it ensures that when a user doesn’t meet all required criteria for an enhanced media experience, the site knows a priori to trying and failing.

Interoperability and Compatibility Risk

This is an API web developers are eager to use. It was the most requested common browser media platform feature at the latest FOMS event. During the event, we also got positive feedback from other browser vendors.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/690364

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5869632707624960

Requesting approval to ship?

No.

[PhistucK]

The smooth and powerEfficient fields sound a bit like the old document.implementation.hasFeature API that gave incorrect information (either by outright lying, or by accident)...

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

This all makes good sense, hope it works out. I've filed some spec issues and commented on existing ones.

[Emily Stark]

Hey Mounir -- is this a new fingerprinting vector? Have you considered adding a Security/Privacy Considerations section to the spec?

Thanks,

Emily

[Mounir Lamouri]

We actually have a privacy considerations in the explainer [1] but it
did not make it yet to the specification yet because not the entire work
has moved to the spec. TL;DR: we believe that the information returned
by the API will match a class of device and will not be user specific,
therefore it shouldn't add significant new fingerprinting vector.

[1]
https://github.com/WICG/media-capabilities/blob/master/explainer.md#privacy-considerations

-- Mounir

On Sun, 19 Feb 2017, at 22:26, Emily Stark wrote:
> Hey Mounir -- is this a new fingerprinting vector? Have you considered
> adding a Security/Privacy Considerations section to the spec?
> Thanks,
> Emily
>
> On Mon, Feb 13, 2017 at 5:34 AM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
>

> > *Contact emails*
> >
> > *chcunn...@chromium.org* <chcunn...@chromium.org>,
> > *mlam...@chromium.org* <mlam...@chromium.org>
> >
> > *Spec*
> >
> > *https://wicg.github.io/media-capabilities/*
> > <https://wicg.github.io/media-capabilities/>
> >
> > *Summary*

> >
> > This specification intends to provide APIs to allow websites to get more
> > information about the decoding abilities of the device/system/browser. This
> > enables the website to make optimal decisions when selecting media streams
> > for the user.
> >

> > *Motivation*

> >
> > Today, media sites “choose” a media format (codec, profile, resolution,
> > bitrate) without clear feedback on device decoding abilities. The Media
> > Capabilities API allows them to make more informed choices on the media
> > format that yields the best streaming experience for their users. This
> > works both ways - a) it ensures that when a user meets certain thresholds
> > of performance, their experience can be enhanced and b) it ensures that

> > when a user doesn’t meet *all* required criteria for an enhanced media

> > experience, the site knows a priori to trying and failing.
> >

> > *Interoperability and Compatibility Risk*

> >
> > This is an API web developers are eager to use. It was the most requested

> > common browser media platform feature at the latest *FOMS*
> > <http://www.foms-workshop.org/foms2016/> event. During the event, we also

> > got positive feedback from other browser vendors.
> >

> > *Ongoing technical constraints*
> >
> > None.
> >
> > *Will this feature be supported on all six Blink platforms (Windows, Mac,
> > Linux, Chrome OS, Android, and Android WebView)?*
> >
> > Yes.
> >
> > *OWP launch tracking bug*
> >
> > *https://crbug.com/690364* <https://crbug.com/690364>
> >
> > *Link to entry on the **feature dashboard* <https://www.chromestatus.com/>
> >
> > *https://www.chromestatus.com/feature/5869632707624960*
> > <https://www.chromestatus.com/feature/5869632707624960>
> >
> > *Requesting approval to ship?*

> >
> > No.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to blink-dev+...@chromium.org.