Attempt to update RTCRtpContributingSource objects at playout time.

[taylor-b]

Fixes #1085.

May not be the correct terminology, but the intention is that the
contributing source objects are updated at playout time, such that if
an application is using them to drive an audio level UI, that UI will be
in sync with the audio played out by the browser.

[stefhak]

I would like someone that has been involved in the discussion about CSRC to review.

[burnburn]

As I said on the call, I believe this is a slippery slope that we will regret, since in general we have no control over when any MST will play out; it may be duplicated, sent elsewhere, delayed via other APIs, etc. I'm not going to officially object since I don't have a good alternative to propose, but I reserve the right to say 'I told you so' :)

[taylor-b]

I understand the concern. Maybe calling it "playout time" is the mistake, but what we ultimately need is some well-defined, post-jitter-buffer point of time, which the application has a way of correlating to playout time.

Even if the application does something with the MediaStreamTrack that introduces extra delay, the original problem is solved as long as the application has a way of estimating the additional delay and factoring it in when updating its audio level UI.

[alvestrand]

We may get implementor feedback on this item, but it clearly reflects WG consensus.
Can be merged once conflicts are resolved.

[taylor-b]

Merge conflicts resolved.

[vr000m]

What is the motivation of accessing audioLevel on the getContributingSources (I suppose this is the value from the RtpHeader extension instead of the actual audio level).

Clarifying: are we adding audioLevel to both the webrtc-pc and webrtc-stats APIs? I feel in this case, having the audio levels accessible in two places is just confusing.

See w3c/webrtc-stats#194

[taylor-b]

What is the motivation of accessing audioLevel on the getContributingSources (I suppose this is the value from the RtpHeader extension instead of the actual audio level).

For CSRCs, it's the value from the RFC6465 extension, yes. The motivation is that applications may want information about the speakers contributing to a mixed audio stream, which may be reflected in the application's UI.

The original reason to put the API on RTCRtpReceiver and not getStats was that we didn't want applications to be reliant on getStats for basic WebRTC functionality, since getStats calls may be expensive and time-consuming.

And I suggested adding the contributing sources to getStats as well, because we can put more granular information there, and it could provide value to services (like callstats.io?) that only have access to stats, and not individual RTCRtpReceivers. An example of it being more granular: the working group decided that even if the RTCRtpContributingSources are updated "post jitter buffer", the stats objects should be updated as soon as packets are received, which is consistent with other things in the stats.