- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2019 12:28:20 +0000
- To: public-webrtc-logs@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