Intent to Prototype: Adding adaptivePtime to RTCRtpEncodingParameters.

138 views
Skip to first unread message

Minyue Li

unread,
May 28, 2020, 5:03:25 PM5/28/20
to blink-dev

Contact emails

min...@chromium.org,jak...@google.com,elad...@chromium.org,hb...@chromium.org


Explainer

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



Design docs/spec

Specification: https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime


TAG review

https://github.com/w3ctag/design-reviews/issues/517


Summary

A new flag adaptivePtime should be added to the RTCRtpEncodingParameters(https://w3c.github.io/webrtc-pc/#rtcrtpencodingparameters). This new flag is used to set a sender in a real-time communication (RTC) system to enable/disable adaptive packet rate.


Motivation

As the packet rate is a big determining factor to the overall bitrate of an audio stream, an optimal congestion control should be allowed to adapt the packet rate. The audio packet rate is analogous to the video frame rate, which also plays an important role in the video bitrate adaptation.


Although adaptive packet rate may be ubiquitously beneficial, we need this API for applications to enable and disable it, since, otherwise, it may introduce interoperability problems. Some implementations have taken a fixed packet rate as an assumption, and thus may fail or perform sub-optimally with an adaptive packet rate.


Therefore it is needed to add a flag for applications to enable or disable the adaptive packet rate.


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.


Firefox: Mixed public signals (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.


Edge: No public signals

Safari: No public signals

Web developers: Positive



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


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5752004691361792



This intent message was generated by Chrome Platform Status.

Minyue Li

unread,
Jun 3, 2020, 4:41:45 PM6/3/20
to blink-dev, Minyue Li
kindly ping for review

Daniel Bratell

unread,
Jun 4, 2020, 2:47:31 PM6/4/20
to Minyue Li, blink-dev

I'm not 100% sure who you want to review your suggestion but here are some comments from an api owner:

Since this is not a shipping request I've not done a formal full review but I would say it looks reasonable. For a change like this I would primarily look at interoperability, is it well specified, is there an agreement on the api, ..., as well as the compatibility risks and all of that seems to be on the right track.

Not all pieces need to be at their final position when implementation is started (it's a prototype after all) so the intent to prototype step is mostly about getting started on the process, and to give those interested a chance to give feedback. I would interpret lack of feedback mostly as "no objections".

/Daniel

--
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/8c81e075-2c10-46cd-94c2-71fd829a3ac3n%40chromium.org.

Minyue Li

unread,
Jun 4, 2020, 5:09:54 PM6/4/20
to blink-dev, min...@google.com
Hi Daniel,

Thanks a lot for the reply!

We target for running this as an origin trial in M85. Could you suggest what we'd best do?

As this is not fully implemented, we filed this "intent to prototype", but we aim for a follow-up of "intent to experiment".

Should we better file the "intent to experiment" ASAP?
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Daniel Bratell

unread,
Jun 5, 2020, 10:07:04 AM6/5/20
to Minyue Li, blink-dev

I think that is a question of whether you are ready for an original trial or not. The actual approval to run one is not the big part. The big part is to prepare a partner or several partners that will help evaluate the feature and give feedback. And to make sure that the experiment will be able to answer the questions you want answered.

Assuming you have read the documentation on original trials, which mentions quite a lot of things to think about, if you think it's ready, then do file an experimentation intent.

/Daniel

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/da678a9c-de78-4186-a2ce-284d4232b007o%40chromium.org.
Reply all
Reply to author
Forward
0 new messages