- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Oct 2019 08:04:22 +0000
- To: public-webrtc-logs@w3.org
> My question is still -- why is this a boolean vs a set of allowed ptimes? For instance, I would see being able to set this to 20, 40, and 60 ms and let the UA pick one dynamically. > > This is much easier to verify being handled correctly then support 3, 10, 18, 20, 46 ms frames that technically are possible, but troublesome when transcoding or designing jitter buffers. Your suggestion of a list of allowed ptimes sounds good. However, my internal devil's advocate came up with the following objections: * What if the applications specifies values that the UA does not support? (Either all of the values, some, or none, could be supported by the UA.) Web developers would be confused if some magical values produced good results, but other values were ignored (or threw an error). * Web developers would need to concern themselves with matters which are not their area of expertise, such as which sets of frame-lengths would produce the optimal behavior. This is not as easy as the alternative of simply opting in to a new feature. (Please remember that domain specialists like you can still vary the ptime directly from their app, using the methods you had listed earlier, rather than use this feature. Acceptance of adaptivePtime is orthogonal to the discussion over the deprecation of ptime.) -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-537383657 using your GitHub account
Received on Wednesday, 2 October 2019 08:05:07 UTC