New metric to report minimum jitter buffer delay

[ivocreusen]

There are various reasons why the jitter buffer delay might be increased to a higher value, such as to achieve AV sync or because a playoutDelay was set on a RTCRtpReceiver (see https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-playoutdelay). When using one of these mechanisms, it can be useful to keep track of the minimal jitter buffer delay that could have been achieved, so WebRTC clients can track the amount of extra delay that is being added.

I would like to propose a new stat to track this minimum achievable jitter buffer delay. This stat should work similar to RTCInboundRtpStreamStats.jitterBufferTargetDelay, except that it should not be affected by playoutDelay (see link above) or AV sync or any other mechanisms. The metric should be purely based on the network characteristics such as jitter and packet loss. A proposal for a name is RTCInboundRtpStreamStats.estimatedMinimumJitterBufferTargetDelay

[henbos]

Makes sense, can you write a pull request?

We're currently in the process of moving unimplemented metrics to webrtc-provisional-stats but if you intend to also implement it, adding it to webrtc-stats still makes sense. We want all metrics in this doc to have at least one implementation.

[henbos]

The PR to add jitterBufferMinimumDelay merged yesterday but the spec still does not have it...? @dontcallmedom

[henbos]

"Latest editor's draft" points to a June 14 version

[henbos]

I filed #646 to follow up on this, I think we can close this issue in the meantime since I can confirm that jitterBufferMinimumDelay exists on tip of tree