Intent to Implement and Ship: RTCRtpSendParameters.degradationPreference

[Florent Castelli]

Contact emails orp...@chromium.org Explainer https://w3c.github.io/mst-content-hint/#degradation-preference-when-encoding Design docs/spec Specification: https://w3c.github.io/mst-content-hint/#degradation-preference-when-encoding https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSendParameters TAG review This API was already part of the WebRTC 1.0 review then moved to the Content Hint specification. Summary When encoding video, and some constraint (bandwidth, CPU) prevents encoding at the configured framerate and resolution, the encoder must make a choice on how to modify the encoding parameters. An attribute is defined for RTCRtpSendParameters that allows this to be explicitly indicated for an RTCRtpSender. Motivation Developers need to be able to control how the quality degrades as different types of content have different requirements. On a screenshare presentation, users will probably prefer to be able to read what is being presented on the screen rather than having super smooth animations. But on a normal video call, a smooth framerate is probably more important than having a higher resolution. Developers need to be able to signal what is preferred for their application and possibly update it as desired. Risks

Interoperability and Compatibility Parts of the functionality attached to this setting is already shipped by users agents. There's been consensus on formalising it and exposing a direct control surface for it. Firefox: Public support (https://github.com/mozilla/standards-positions/issues/101#issuecomment-598735123) Edge: No public signals Safari: No public signals Web developers: No signals Ergonomics This API is used with MediaStreamTrack contentHint feature and are specified together. It is set with RTCRtpSender get/setParameters() which has been released for a while now and developers are familiar with it, no risks are expected.

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? Not quite Tests check setting and reading the value back. Actual behaviour depends on a lot of realtime factors and can't reliably be tested in WPT right now, just like many other WebRTC features. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1061408 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5135353876840448

[Yoav Weiss]

LGTM1

--
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/CADRnnSXLHGvrEyvAarrjMDEh5awwpbuV1hapwFwa6w8PBO3PxQ%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh%2BLVhGuP%2BOpSt3qujxF5G%2B2W_u0q_7%2BdrxNoLE1VW_KA%40mail.gmail.com.

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw83k-CxnZd9hGdqTR-5S0t%3DDHWrRahmUZX%3D_g%3Deez22RA%40mail.gmail.com.