Intent to Prototype: Adding adaptivePtime to RTCRtpEncodingParameters.
Minyue Li
Contact emails
min...@chromium.org,jak...@google.com,elad...@chromium.org,hb...@chromium.org
Explainer
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
Daniel Bratell
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
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
Daniel Bratell
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.