New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 883287 link

Starred by 6 users

Issue metadata

Status: Duplicate
Merged: issue 893158
Owner:
Closed: Dec 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue webrtc:9770



Sign in to add a comment

Implement RTCRtpReceiver.getSynchronizationSources()

Project Member Reported by hbos@chromium.org, Sep 12

Issue description

This is similar to the already shipped getContributingSources(), only some minor changes are needed for the plumbing to support getSynchronizationSources().

This allows identifying which SSRC is being received for an RTCRtpReceiver's RTP stream or what the latest packet timestamp is for each SSRC.

Spec: https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getsynchronizationsources

Enables use cases:
- Reusing the same receiver for multiple SSRCs and knowing about it.
- Funding out if a receiver is "active" or not without expensive getStats() calls.
 
Blocking: 883289
Cc: ovelius@google.com
I noticed that the spec and current third_party/webrtc implementation only cares about audio. I see no reason that this would not work for video as well. I filed spec issue: https://github.com/w3c/webrtc-pc/issues/1983
Cc: zstein@chromium.org
 Issue 775668  has been merged into this issue.
FYI: I had a CL for this before ContributingSource/SynchronizationSource changed from an interface to a dictionary here: https://chromium-review.googlesource.com/685975
#5: Thanks. I noticed the interface/dictionary difference too, I think I'll do the cleanup interface -> dictionary first and split work up into smaller CLs.

#3: The working group didn't have time to go through the PR (spent a lot of time on getDisplayMedia) but my impression was that doing this for video makes sense and that Edge already does it.
Blockedon: webrtc:9770
Mergedinto: 893158
Status: Duplicate (was: Started)
Blocking: -883289

Sign in to add a comment