- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2019 14:58:35 +0000
- To: public-webrtc-logs@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