Intent to Implement and Ship: RTCRtpTransceiver.setCodecPreferences
Florent Castelli
Contact emails
Design doc/Spec
https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.2.6
Summary
The setCodecPreferences method overrides the default codec preferences used by the user agent.
This method allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.
This codec preferences is detailed in the SDP generated by createOffer() / createAnswer().
Motivation
Users can already emulate similar functionality by modifying the SDP from the offers or answers by hand and that is error prone (and not standard compliant as SDP should in theory not be modified).
This API allows users to have a standard compliant and safe way to do this.
Risks
Interoperability and Compatibility
Since this API ends up only modifying the SDP output, it keeps compatibility with existing WebRTC clients and shouldn't cause any problem.
Edge: No signals
Firefox: Public support (Bug)
Safari: No signals
Web developers: Positive
The design of the WebRTC API has been done by representatives from all vendors and they all committed to support it, although I can't find individual links for each vendor.
Ergonomics
This API is simple to use and much easier than modifying SDP by hand and is a big improvement over what users currently have to do.
Activation
It is easy to detect this API and fallback to modifying the SDP by hand if needed.
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?
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5242890959716352
Requesting approval to ship?
Yes
Chris Harrelson
--
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/CADRnnSXfEwQPquTj2NTcZyxN6BOsHXapmoxLE5rLc%3DKqyWJNNQ%40mail.gmail.com.
Philip Jägenstedt
https://wpt.fyi/results/webrtc/RTCRtpTransceiver-setCodecPreferences.html?label=experimental
is pretty red, hopefully a bit greener soon :)
Joe Medley
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeT7nhxo33JaE2QjTP%3Dgd0qq5w1cKVyHK96fK_mWu4E0A%40mail.gmail.com.
Yoav Weiss
Contact emails
Design doc/Spec
https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.2.6
Summary
The setCodecPreferences method overrides the default codec preferences used by the user agent.
This method allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.
This codec preferences is detailed in the SDP generated by createOffer() / createAnswer().
Motivation
Users can already emulate similar functionality by modifying the SDP from the offers or answers by hand and that is error prone (and not standard compliant as SDP should in theory not be modified).
This API allows users to have a standard compliant and safe way to do this.
Risks
Interoperability and Compatibility
Since this API ends up only modifying the SDP output, it keeps compatibility with existing WebRTC clients and shouldn't cause any problem.
Edge: No signals
Firefox: Public support (Bug)
Safari: No signals
Web developers: Positive
The design of the WebRTC API has been done by representatives from all vendors and they all committed to support it, although I can't find individual links for each vendor.Ergonomics
This API is simple to use and much easier than modifying SDP by hand and is a big improvement over what users currently have to do.
Activation
It is easy to detect this API and fallback to modifying the SDP by hand if needed.
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?
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5242890959716352
Requesting approval to ship?
Yes
--
Yoav Weiss
On Wed, Oct 3, 2018 at 3:38 AM Florent Castelli <orp...@chromium.org> wrote:Contact emails
Design doc/Spec
https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.2.6
Summary
The setCodecPreferences method overrides the default codec preferences used by the user agent.
This method allows applications to disable the negotiation of specific codecs. It also allows an application to cause a remote peer to prefer the codec that appears first in the list for sending.
This codec preferences is detailed in the SDP generated by createOffer() / createAnswer().
Motivation
Users can already emulate similar functionality by modifying the SDP from the offers or answers by hand and that is error prone (and not standard compliant as SDP should in theory not be modified).
This API allows users to have a standard compliant and safe way to do this.
Risks
Interoperability and Compatibility
Since this API ends up only modifying the SDP output, it keeps compatibility with existing WebRTC clients and shouldn't cause any problem.
Edge: No signals
Firefox: Public support (Bug)
Safari: No signals
Did you reach out to Edge and Safari? Are there open bugs on their trackers? If not, is it possible to open ones?Regarding compatibility, can you expand a bit on the feature detection story? What would happen if developers assume this feature is supported in browsers where it is not?