Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When exactly is an SSRC RTCRtpContributingSource object updated? #1091

Closed
taylor-b opened this issue Mar 21, 2017 · 3 comments
Closed

When exactly is an SSRC RTCRtpContributingSource object updated? #1091

taylor-b opened this issue Mar 21, 2017 · 3 comments

Comments

@taylor-b
Copy link
Contributor

Current text:

Each time an RTP packet is received, the RTCRtpContributingSource objects are updated. If the RTP packet contains CSRCs, then the RTCRtpContributingSource objects corresponding to those CSRCs are updated. If the RTP packet contains no CSRCs, then the RTCRtpContributingSource object corresponding to the SSRC is updated.

Is this meant to imply that the RTCRtpContributingSource object corresponding to the SSRC is only updated if a packet contains no CSRCs? I'd suggest having it always updated. There's no extra implementation burden and applications may want to know the SSRC audio level even when CSRCs are present.

@alvestrand
Copy link
Contributor

I think this makes sense.
I'm not sure it makes sense to have the SSRC listed in the contributing sources (it's not, after all, a contributing source), but having the level information consistently available is definitely useful.
(The SSRC doesn't seem otherwise available on an RTPReceiver.)

(Another puzzling question is what happens if we have both simulcast and CSRC. The RTP protocol header layout seems to indicate that CSRC happens per encoding. Is this yet another distraction?)

@taylor-b
Copy link
Contributor Author

Another puzzling question is what happens if we have both simulcast and CSRC

WebRTC doesn't support receiving simulcast, though. Or am I misunderstanding something?

@aboba
Copy link
Contributor

aboba commented Mar 22, 2017

Another puzzling question is what happens if we have both simulcast and CSRC

I've seen applications that have implemented Opus forwarding instead of mixing for audio conferencing, by forwarding up to N streams (to allow up to N people to speak at once). Each stream goes to its own receiver, with mixing in the browser.

In this scenario (which is not simulcast), the packets may arrive with a CSRC, representing the original source, with the SSRC being one of N allocated by the SFU. Since the packets are forwarded not mixed, and only a single source contributes to each packet, there will be no mixer-client extension. However, it would be useful to have the audiolevel corresponding to the SSRC, which could be used to show the level originating from the CSRC (the original source).

taylor-b added a commit to taylor-b/webrtc-pc that referenced this issue Mar 29, 2017
Fixes w3c#1091.

As described in the issue, there may be cases where an application
wants to know the SSRC audio level, even when a CSRC is present in the
packet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants