Intent to Implement and Ship: RTCRtpcSender.get/setParameters()

[orp...@chromium.org]

Contact emails
orp...@chromium.org, hb...@chromium.org

Spec
https://w3c.github.io/webrtc-pc/#rtcrtpsender-interface

Summary
The get/setParameters() methods return or update the RTCRtpSender object's current parameters for how a track is encoded and transmitted to a remote RTCRtpReceiver.

A subset of all the options that are currently implemented in the lower WebRTC layer will be exposed to users:

• RTCRtpParameters.rtcp.cname

• RTCRtpParameters.rtcp.reducedSize

• RTCRtpParameters.encodings.active

• RTCRtpParameters.encodings.priority

• RTCRtpParameters.encodings.maxBitrate

• RTCRtpParameters.codecs.payloadType

• RTCRtpParameters.codecs.mimeType

• RTCRtpParameters.codecs.clockRate

• RTCRtpParameters.codecs.channels

Motivation
This feature adds the possibility for users to update various parameters on a live stream, for which there was no other way to do so.

Interoperability risk
Firefox: Shipped
Edge: No public signals
Safari: No public signals
Web developers: Positive

Firefox currently supports a subset of RTCRtpSender.get/setParameters() options with little overlap with the proposed parameters. Since Firefox uses the same WebRTC library, future additions are expected to be interoperable.

Compatibility risk
Considering the low amount of options currently implemented in any UA, usage is currently very low and no compatibility risks are foreseen.

Unimplemented options will be ignored.

Ongoing technical constraints
None

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?

No, only a subset is tested

https://github.com/w3c/web-platform-tests/issues/9395

https://wpt.fyi/webrtc/RTCRtpSender-setParameters.html

OWP launch tracking bug
https://crbug.com/803494

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5678876931915776

Requesting approval to ship?
Yes

[Philip Jägenstedt]

I think that since Firefox has this and it's useful, clearly we should ship it, I just have some questions about the supported set of parameters.

Comparing Gecko's IDL to the list of bits you'd like to support initially, it looks like what your list is a strict subset of what is Gecko's IDL. Is it that Gecko has a bunch of stuff in their IDL that doesn't actually work? What are the bits that really do work in Gecko, and out of the things that they do support and are in the spec, are there any that we wouldn't ship initially?

Feature detection with dictionaries is complicated and in this case would require actually calling the method, so in practice people might not even think to try that. So, I think the main risk to look out for here is that we support less than Firefox does, in which case some existing code written against Firefox wouldn't work, and trying to feature detect what works would be hard.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb80eade-3337-4299-8cad-440d03466fe3%40chromium.org.

[orp...@chromium.org]

I've talked to Firefox engineers and they confirmed only 3 working fields:

- RTCRtpParameters.encodings.maxBitrate

- RTCRtpParameters.encodings.rid

- RTCRtpParameters.encodings.scaleResolutionDownBy

Of those, only maxBitrate will be implemented for now. rid requires transceivers, which we don't have right now, and they implemented scaleResolutionDownBy outside of the WebRTC library.

They can't update those parameters live either (see https://bugzil.la/1253499 ), so I wouldn't worry about interoperability right now.

[Philip Jägenstedt]

Thanks for checking that out, Florent, seems like the IDL is just a placeholder then. (Pretty harmless for a dictionary, but still observable in the same way that feature detection works.)

Sound like scaleResolutionDownBy is the only thing that could make sense to implement. I searched httparchive for "scaleResolutionDownBy" and found nothing, and on GitHub only test code and such in the first few and last few pages. So yeah, it probably can't become a compat problem in practice, if code that even uses it is this hard to find.

LGTM1!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/efa60b08-f80c-4d2e-ab64-c1dcab57a44b%40chromium.org.

[Harald Alvestrand]

I think most WebRTC developers are waiting until we proclaim support for these APIs before even trying them.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcYSVeED8qG0p2-XAGzF%2Be7JRpFuapFDUFd340zeYhrqg%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/CAOqqYVHTWk_4F-JV4tDo3QWtfHsfRinaC2niLS%3DYgZE%3Dag2Twg%40mail.gmail.com.

[Emily Stark]

Are these parameters newly exposed to the web with this change, or are they already exposed to web content in some other way? If the former, could they contain any new persistent identifiers or data that could be used for fingerprinting?

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

[Harald Alvestrand]

A lot of the fingerprint-relevant settings (available header extensions, codecs and operational modes, for instance) are already exposed in the SDP used to negotiate the connection.

http://w3c.github.io/webrtc-pc/#dom-rtcrtpparameters gives the IDL for the interface; offhand, I think the only thing that is not exposed in the SDP is the degradation preference (this being a local choice rather than something we need to negotiate support for).

The specification says that if it is unset, this defaults to "balanced", so one would also expect this to be the value returned when it's not set - which makes it useless for fingerprinting.

[Rick Byers]

LGTM3

LGTM2

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/CAARdPYcYSVeED8qG0p2-XAGzF%2Be7JRpFuapFDUFd340zeYhrqg%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/CAOqqYVHTWk_4F-JV4tDo3QWtfHsfRinaC2niLS%3DYgZE%3Dag2Twg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[tha...@google.com]

If I'd like to add an additional parameter would a new intent to implement be necessary?  Was this one intended for the SetParameters function itself or just the particular initial supported fields?

Webrtc now supports configurability of DSCP values per media channel, allowing one to prioritize audio and video differently for example.  This specification would expose this as an additional parameter.

Here is the design doc that covers Hangouts Meet's efforts to improve DSCP generally for interested enterprises.

Thanks,

Tim

[Harald Alvestrand]

DSCP is a reasonably large chunk of new functionality, so a new i2i/i2s is reasonable.

What's a channel in this context?

[tha...@google.com]

On Thursday, November 1, 2018 at 4:25:41 PM UTC-7, Harald Alvestrand wrote:

DSCP is a reasonably large chunk of new functionality, so a new i2i/i2s is reasonable.

Just to clarify, the new functionality is not dscp in general but being able to change the priority on the fly.  I'll work through the template.

 

What's a channel in this context?

A cricket::MediaChannel

[Harald Alvestrand]

On Fri, Nov 2, 2018 at 1:21 AM thaloun via blink-dev <blin...@chromium.org> wrote:

On Thursday, November 1, 2018 at 4:25:41 PM UTC-7, Harald Alvestrand wrote:

DSCP is a reasonably large chunk of new functionality, so a new i2i/i2s is reasonable.

Just to clarify, the new functionality is not dscp in general but being able to change the priority on the fly.  I'll work through the template.

 

What's a channel in this context?

A cricket::MediaChannel

Which corresponds to the WebRTC/Javascript "RtcRtpEncoding", if I read the source correctly.
I think there's nowhere those don't map 1:1 (and when simulcast is not in use, a MediaChannel maps 1:1 to a RTCRtpSender/Receiver, which sends or receives a single MediaStreamTrack).

Right?
 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e52c48fc-3770-484a-ab71-57b6934da481%40chromium.org.

[Tim Haloun]

Tim

On Thu, Nov 1, 2018 at 5:36 PM Harald Alvestrand <h...@google.com> wrote:

On Fri, Nov 2, 2018 at 1:21 AM thaloun via blink-dev <blin...@chromium.org> wrote:

On Thursday, November 1, 2018 at 4:25:41 PM UTC-7, Harald Alvestrand wrote:

DSCP is a reasonably large chunk of new functionality, so a new i2i/i2s is reasonable.

Just to clarify, the new functionality is not dscp in general but being able to change the priority on the fly.  I'll work through the template.

 

What's a channel in this context?

A cricket::MediaChannel

Which corresponds to the WebRTC/Javascript "RtcRtpEncoding", if I read the source correctly.
I think there's nowhere those don't map 1:1 (and when simulcast is not in use, a MediaChannel maps 1:1 to a RTCRtpSender/Receiver, which sends or receives a single MediaStreamTrack).

Right?

Yes that is correct.  While the parameter struct is also forwarded to the WebrtcVideoSendStream associated with the particular encoder, this field is parsed and applied at on the MediaChannel which should be 1:1 with the RtpSender.