I think this is still going to be hard to implement, considering all the corner cases with DTX/CNG, and possibly also clock-drift compensation. I don't know the background, but was it ever considered to accumulate the delay for each packet or frame, without multiplying with number of samples. Then it would have to be normalized by the number of frames decoded (in analogy with the video counterpart). The benefit is that both the delay accumulation and the incrementing of the frames counter will likely be made at the same place in an implementation. What you lose is the weighting with frame size. -- GitHub Notification of comment by hlundin Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/246#issuecomment-332493130 using your GitHub accountReceived on Wednesday, 27 September 2017 11:35:45 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:42 UTC