Intent to Extend Origin Trial: adaptivePtime property for RTCRtpEncodingParameters
jak...@google.com
Explainer
https://w3c.github.io/webrtc-extensions/explainer#a-new-flag-in-rtcrtpencodingparameters-for-adaptive-packet-rate
Specification
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 componentRisks
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 timelineM85 ~ M89
Reason this experiment is being extendedExperimentation 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)?Is this feature fully tested by web-platform-tests?
Tracking bug
