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

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

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Sep 2019 12:28:20 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-535479454-1569500899-sysbot+gh@w3.org>
> Another possibility is to change adaptivePtime to a dictionary that holds the allowed range.

Its not a range, its a set of discrete values (which actually applies to ptime)
`3, 5, 10, 20, 40, 60, or an arbitrary multiple of an Opus frame size rounded up to the next full integer value, up to a maximum value of 120`
(from RFC 7587).

The range adaptivePtime can use would be limited by maxptime as an upper bound, similar to how maxBitrate in the senders parameters is effectively limited by b= settings in the SDP. Oddly, while some of the opus drafts had a minptime fmtp that didn't make it to the RFC...

> The same rationale goes for varying the frame length, and the overhead it consumes, I believe.

Note that if that is the only parameter you're changing, doing a local renegotiation is perfectly possible. Been there, done that, used it for bandwidth adaption until setParameters became available. Not going to miss it :-)

> Yes. I'd add that the browser is likely to be able to react faster than the web-app to changes in bandwidth; the web-app can only call getStats so often.

True, but adapting within a 1s window should be fast enough? And its a trade-off, how does the application developer know this tradeoff fits the  use-case?

GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-535479454 using your GitHub account
Received on Thursday, 26 September 2019 12:28:22 UTC

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