W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2017

Re: [webrtc-pc] Attempt to update RTCRtpContributingSource objects at playout time.

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Apr 2017 21:34:49 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-293714529-1492032887-sysbot+gh@w3.org>
> 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 `RTCRtpReceiver`s. An example of it being more granular: the working group decided that even if the `RTCRtpContributingSource`s 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.

GitHub Notification of comment by taylor-b
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1098#issuecomment-293714529 using your GitHub account
Received on Wednesday, 12 April 2017 21:34:57 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC