Re: [webrtc-stats] Define reception time for jitterBufferDelay stat (#549)

Taking a closer look at the spec definition and discussing with libwebrtc colleagues:

I think the intent of the spec is that it is the time spent in the jitter buffer, i.e. the time it is inserted until the time it is exited. I think the spec should be clarified to say "time it enters" rather than "is received". This is well defined enough that different webrtc implementations could be confident that they're measuring the same part of the pipeline, and simple enough to implement.

As I understand things, there isn't additional _buffering_ going on prior to the jitter buffer other than perhaps network card and OS level buffering before the packet reaches webrtc, which we don't have a metric for, probably don't want to have a metric for, and isn't what your CL attempts to calculate anyway.

I think what your CL is trying to catch is some implementation-specific stuttering... the packet arrives and there's a thread jump before it is put in the jitter buffer. I don't think jitterBufferDelay should include such a thing. A different implementation might stutter in a different way (maybe it is slow at reading packets from the OS buffer), and it wouldn't be testable which thing is measured.

jitterBufferDelay should not be a proxy for measuring CPU glitches or how slow the pipeline is at reading packets on the network thread.

While more metrics that tries to cover as much ground as possible is nice to have I don't think this particular problem should be solved in jitterBufferDelay because it makes the stat definition and implementation of the metric more complicated.

And there are other delays too (like network RTT). What is it we really want to measure? For end-to-end delay metrics there is this (currently unresolved) issue: This problem might gain more traction when we have RTP header extensions for the capture time.

GitHub Notification of comment by henbos
Please view or discuss this issue at using your GitHub account

Received on Friday, 7 February 2020 14:25:09 UTC