- From: Varun Singh via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Mar 2019 12:09:18 +0000
- To: public-webrtc-logs@w3.org
JitterBuffer are proprietary and the methodologies to mitigate these issues are also proprietary. However, I do agree that we should be able to measure jitterbuffer metrics, and there should be metrics for both audio and video: + Underflows -- there should be a metric that measures underflow, when the JB is empty. Adding concealment packets because the jitterbuffer is empty should still be counted in the underflow metric. The total number of samples added during those periods and the counter for underflowCounts should give an average. Similarly, framesDiscarded and underflowCounts should give the corresponding metric for video. + Overflow -- there should be a similar metric for overflows as for underflows. Now accelerated and decelerated samples -- we are changing the playback rate, right? should there not be metrics of how quick this was? how would we measure that? -- GitHub Notification of comment by vr000m Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/407#issuecomment-473884048 using your GitHub account
Received on Monday, 18 March 2019 12:09:20 UTC