- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Oct 2019 18:10:05 +0000
- To: public-webrtc-logs@w3.org
> 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). Implementation should pick the nearest valid audio frame size no larger then specified frame size. This way things, at least, will not fail. > 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.) I think we should either limit the audio frame size allowed to be used by browsers or allow develop set this up, but provide a reasonable default. I think 20, 40, 60, 80, 100, 120 ms audio frame set seems reasonable. Having predictable frame sizes would make both implementation and testing a lot easier. -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-537614101 using your GitHub account
Received on Wednesday, 2 October 2019 18:10:07 UTC