Intent to Experiment: MediaCapabilities API for WebRTC

[Johannes Kron]

Contact emails

kr...@google.com

Explainer

None

Specification

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

Summary

Extends the MediaCapabilities API to support WebRTC streams. The MediaCapabilities API helps web sites to make informed decisions on what codec, resolution, etc. to use for video playback by providing information about whether a configuration is supported and also whether the playback is expected to be smooth. This feature extends the MediaCapabilities API to also include WebRTC streams.

Blink component

Blink>Media>Capabilities

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: Positive (https://www.w3.org/2011/04/webrtc/wiki/December_02_2020)

WebKit: Shipped/Shipping (https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/)

Web developers: No signals

Other signals:

Goals for experimentation

The MediaCapabilities API returns a tuple of booleans representing supported, smooth, powerEfficient. Whether smooth=true or smooth=false is returned for a particular configuration depends on an internal threshold. The goal of the experiment is to find a good tradeoff for how this tunable threshold should be set.

Reason this experiment is being extended

Ongoing technical constraints

None

Debuggability

N/A

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

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

MediaCapabilitiesWebRtc

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1187565

Launch bug

https://crbug.com/1170306

Estimated milestones

OriginTrial desktop last	103
OriginTrial desktop first	100

OriginTrial android last	103
OriginTrial android first	100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242376685191168

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/lE1qySPAEMs/m/29OgzgyoAgAJ

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

On Wed, Mar 2, 2022 at 9:22 AM 'Johannes Kron' via blink-dev <blin...@chromium.org> wrote:

Goals for experimentation

The MediaCapabilities API returns a tuple of booleans representing supported, smooth, powerEfficient. Whether smooth=true or smooth=false is returned for a particular configuration depends on an internal threshold. The goal of the experiment is to find a good tradeoff for how this tunable threshold should be set.

I think what you're saying here is you need field data to optimize the thresholds for returning true or false, is that right?

If so, I'd recommend instead launching the feature with a default threshold, and then tuning it via A/B experimentation. WDYT?

Estimated milestones

OriginTrial desktop last	103
OriginTrial desktop first	100

OriginTrial android last	103
OriginTrial android first	100

One small comment: 100 already branched, which makes it a bit late for connecting to standard ways to reach developers about that milestone.

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242376685191168

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/lE1qySPAEMs/m/29OgzgyoAgAJ

This intent message was generated by Chrome Platform Status.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFJBoCR3marbZsVSOmeimizJY9Q%3DbTp0PCfaNawn3XZuXkmvNA%40mail.gmail.com.

[Johannes Kron]

Thanks Chris for your feedback! See my responses below.

On Thu, Mar 3, 2022 at 6:17 PM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Mar 2, 2022 at 9:22 AM 'Johannes Kron' via blink-dev <blin...@chromium.org> wrote:

Goals for experimentation

The MediaCapabilities API returns a tuple of booleans representing supported, smooth, powerEfficient. Whether smooth=true or smooth=false is returned for a particular configuration depends on an internal threshold. The goal of the experiment is to find a good tradeoff for how this tunable threshold should be set.

I think what you're saying here is you need field data to optimize the thresholds for returning true or false, is that right?

If so, I'd recommend instead launching the feature with a default threshold, and then tuning it via A/B experimentation. WDYT?

Your interpretation is correct.

I would be happy to skip the origin trial. I was considering going for a full launch followed by an A/B experiment but was uncertain how the API would be perceived if it somehow changed slightly in behavior over time. My assumption was that web developers would be more understanding of this kind of change during an origin trial. I have a few internal partners such as Google Meet whose feedback I will use to tune the thresholds.

Given this additional information, do you still recommend launching the feature without an origin trial?

 

Estimated milestones

OriginTrial desktop last	103
OriginTrial desktop first	100

OriginTrial android last	103
OriginTrial android first	100

One small comment: 100 already branched, which makes it a bit late for connecting to standard ways to reach developers about that milestone.

Okay, would it still be possible to get it into 100 or is it too late?

[Chris Harrelson]

On Thu, Mar 3, 2022 at 12:51 PM 'Johannes Kron' via blink-dev <blin...@chromium.org> wrote:

Thanks Chris for your feedback! See my responses below.

On Thu, Mar 3, 2022 at 6:17 PM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Mar 2, 2022 at 9:22 AM 'Johannes Kron' via blink-dev <blin...@chromium.org> wrote:

Goals for experimentation

The MediaCapabilities API returns a tuple of booleans representing supported, smooth, powerEfficient. Whether smooth=true or smooth=false is returned for a particular configuration depends on an internal threshold. The goal of the experiment is to find a good tradeoff for how this tunable threshold should be set.

I think what you're saying here is you need field data to optimize the thresholds for returning true or false, is that right?

If so, I'd recommend instead launching the feature with a default threshold, and then tuning it via A/B experimentation. WDYT?

Your interpretation is correct.

I would be happy to skip the origin trial. I was considering going for a full launch followed by an A/B experiment but was uncertain how the API would be perceived if it somehow changed slightly in behavior over time. My assumption was that web developers would be more understanding of this kind of change during an origin trial. I have a few internal partners such as Google Meet whose feedback I will use to tune the thresholds.

Given this additional information, do you still recommend launching the feature without an origin trial?

I think launching and then tweaking makes sense, especially since other browsers have already shipped and presumably give different answers anyway than what Chromium might. This feature sounds inherently like it's the kind of thing that will have to be tweaked over time regardless, since it seems to depend on not just device capabilities, but fast-paths and other optimizations added to Chromium over time.

 

Estimated milestones

OriginTrial desktop last	103
OriginTrial desktop first	100

OriginTrial android last	103
OriginTrial android first	100

One small comment: 100 already branched, which makes it a bit late for connecting to standard ways to reach developers about that milestone.

Okay, would it still be possible to get it into 100 or is it too late?

If your code is already in place in the M100 branch and has all the necessary parameters for an Origin trial, it'll still work, and I don't consider it a blocking issue. Just wanted you to be aware.

 

 

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6242376685191168

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/lE1qySPAEMs/m/29OgzgyoAgAJ

This intent message was generated by Chrome Platform Status.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFJBoCR3marbZsVSOmeimizJY9Q%3DbTp0PCfaNawn3XZuXkmvNA%40mail.gmail.com.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFJBoCQq4bGpAHt%3DyH2ysNdBxM7mL_6n2jQ0a12zrPj48XhMCQ%40mail.gmail.com.

[Johannes Kron]

Great, thanks again for the feedback.

I've discussed this with my team and will abandon the Intent to Experiment and instead prepare an Intent to Ship.