W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

Re: [webrtc-pc] Add adaptivePtime to RTCConfiguration (#2309)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Sep 2019 14:58:35 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-535544291-1569509913-sysbot+gh@w3.org>
> Its not a range, its a set of discrete values (which actually applies to ptime) ...

fippo, [ptime ](https://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters-ptime) can be taken from a range, but it is itself a single value, so I don't think we can use that to determine the range of allowed adaptive values.

> The range adaptivePtime can use would be limited by maxptime as an upper bound ...

maxptime is an Opus-specific fmtp line, so I'm not sure it's useful for a codec-agnostic flag.

> doing a local renegotiation is perfectly possible

The web-app can only call getStats so often. The browser is at a better position to make quick decisions about the frame length.

> ... adapting within a 1s window should be fast enough?

1. Adapting within a 1s window sounds suboptimal to me.
2. Also, the logic for adapting the frame length would now to be baked into the web-app. It could be argued that this would not be making the Web better.

> ... how does the application developer know this tradeoff fits the use-case?

It's obvious in the extreme cases, and grey otherwise. E.g., if you're building a streaming service for high-end networks, requiring 50mbit/s as a barrier to entry, likely the trade-off is not for you.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-535544291 using your GitHub account
Received on Thursday, 26 September 2019 14:58:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC