- From: Tony Herre via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 May 2024 09:02:34 +0000
- To: public-webrtc-logs@w3.org
I definitely agree some more numbers here to get a better sense of the sweetspot of the tradeoff. A previous design discussion came to the broad consensus that something like >10k Hz of events is probably too much, <100 Hz probably fine, but largely based on gut feeling iirc. The best evidence we've found for overheads in Chromium have been looking at trace recordings and pprofs, eg a single Audio Encoded Frame transform, so running at 50 Hz, was consuming increasing the CPU load of a Meet page by 0.2% just to get the audio data from webrtc wrapped in an ArrayBuffer and into a JS event (internal ref: http://shortn/_ZzJdD2pcQS). I'll try to get something less anecdotal that can be shared publicly indetail. Assuming this is representative though, and scales ~linearly, launches needing to get towards the kHz range to be useful would start being blocked as major CPU regressions. This did at least result in some V8 optimizations - eg crbug.com/40287747 - but there's still plenty of cost at high frequency. -- GitHub Notification of comment by tonyherre Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/20#issuecomment-2114600462 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 May 2024 09:02:35 UTC