Intent to Extend Origin Trial: adaptivePtime property for RTCRtpEncodingParameters

52 views
Skip to first unread message

jak...@google.com

unread,
Dec 3, 2020, 3:54:14 AM12/3/20
to blink-dev, Minyue Li
Contact emails
https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime

Design docs
https://w3c.github.io/webrtc-extensions/explainer#a-new-flag-in-rtcrtpencodingparameters-for-adaptive-packet-rate

Summary

Adds the adaptivePtime property to RTCRtpEncodingParameters (https://w3c.github.io/webrtc-pc/#rtcrtpencodingparameters). This new flag sets a sender in a real-time communication (RTC) system to enable/disable adaptive packet rate.

We would like to extend this origin trial to M89 since we were unable to start experimenting until M87 and one milestone will not be enough to gather data.

Blink component
Blink>WebRTC

Search tags
Pending

Risks
Interoperability and Compatibility

First, the new flag is introduced to prevent potential interoperability issues with its underlying feature of adaptive packet time. Regarding the implementation of the flag itself, Mozilla has been involved in the discussions of technical details of adaptive packet rate, and has said that the feature seemed fine, although they have not expressed a signal to implement it. Other vendors have not been contacted. There is no compatibility risk. Setting the flag does NOT mean that the sender must change its frame rate dynamically, since the sender may decide to stay on the same packet rate, due to, for example, a stable network. Thus there is no behavioral difference between the case that the feature is not implemented, and the case that the feature is implemented but packet rate adaptation logic actively decides to keep the packet rate.

Gecko: No signal (https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-538463368) Mozilla has said that the feature seemed fine, although have not expressed a signal to implement it.

WebKit: No signal

Web developers: Positive

Goals for experimentation

Goal remains the same as when filed for Intent to Experiment:

Verify that an adaptive audio packet rate can in practice help avoiding network congestions. The adaptive audio packet rate can in principle help to optimize bandwidth usage of real-time communication applications, thus avoiding network congestions. However, an ultimate success relies on a good implementation. An experiment can help to verify that at least one implementation will achieve expected improvements. The improvements can be measured by a set of WebRTC statistics.

Experimental timeline

M85 ~ M89

Reason this experiment is being extended

Experimentation was not able to start until M87 due to unforeseen delays in prerequisite work. Gathering data will take time and we would therefore like to extend the origin trial by two releases to end on M89.

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, to be added

Tracking bug
https://crbug.com/1086942

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5752004691361792

Links to previous Intent discussions

Mike West

unread,
Dec 9, 2020, 8:48:53 AM12/9/20
to blink-dev, jak...@google.com, Minyue Li
Extending the origin trial to M89 in order to get feedback from partners that weren't able to start as expected LGTM.

-mike

Reply all
Reply to author
Forward
0 new messages