- From: jesup via GitHub <sysbot+gh@w3.org>
- Date: Fri, 17 Mar 2017 05:49:03 +0000
- To: public-webrtc-logs@w3.org
Moving the point from packet reception to packet-coming-out-of-jitter-buffer (i.e. when it's played) is straightforward, and roughly what was intended. The only reason timestamps would make sense is that if the application is polling the stats, and it could set a timeout to update UI (and maybe switch elements around) in sync with the timestamp it got for the level. This might avoid something like: Poll - audio level change is still in jitter buffer for 1 more ms, audio level changes 1 ms later, and the next poll isn't for 100ms - so any update would lag by 99ms. Downside of timestamps is that you'll always be setting timers for updating the UI. In practice an app might apply UI changes either immediately (ahead of the change), or on the next poll/update. Probably applying changes immediately would be better, since in reality any indication you get of a change is more like "level changed sometime since you last polled". That brings us to (barring crazy jitter depths or applications that poll every 10ms) a place where the current text actually isn't bad in practice - getting the notification 'early' compensates for the lag due to polling. Not perfect, but a partial/rough compensation. The timestamp idea would make it a more correct approximation (modulo polling frequency), but in practice would mean every poll would be followed by a timeout to update the UI - multiplied by the number of sources you're displaying -- GitHub Notification of comment by jesup Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1085#issuecomment-287272819 using your GitHub account
Received on Friday, 17 March 2017 05:49:09 UTC