Intent to Implement & Ship: RTCRtpReceiver.getSynchronizationSources()

65 views
Skip to first unread message

Henrik Boström

unread,
Oct 8, 2018, 11:51:26 AM10/8/18
to blink-dev
Contact emails

Spec

Summary
getSynchronizationSources() allow inspecting when the last RTP packet (audio/video frames) was sent out for playout.
We've already shipped the more edge-case version of this API, getContributingSources(), which is used when a single RTP stream is used to represent multiple sources.
Both APIs are useful for real-time information about active streams, such as implementing an audio-meter when remote participants are talking.

This intent also covers expanding both APIs (getSynchronizationSources() and getContributingSources()) to work for both audio and video receivers. The previous implementation was audio-only. The video use case is still useful because of the timestamps.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android and Android WebView)?
Yes.

Risks
None

Is this feature fully tested by web-platform-tests?
No but I'm adding tests as I'm implementing this.

Entry on the feature dashboard

Philip Jägenstedt

unread,
Oct 9, 2018, 11:26:46 AM10/9/18
to Henrik Boström, blink-dev
Hi Henrik,

Can you fill out the Interoperability and Compatibility section of template? In particular, would Blink be the first engine to support this, what do other vendors think, and are there bugs files for them?

Yay for "I'm adding tests as I'm implementing this" :)

Thanks!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5299e2bc-a24a-4417-afe1-acdf0aa66c2d%40chromium.org.

Henrik Boström

unread,
Oct 17, 2018, 8:31:48 AM10/17/18
to blink-dev, hb...@chromium.org
Risks / Interoperability and Compatibility

getContributingSources() is shipped on Edge/Chrome/Firefox. getSynchronizationSources() is shipped in Firefox.
Edge's implementation is already both audio and video. Chrome's and FIrefox's is audio-only. There was an agreement in the editor's meeting from all four browsers to support this for both audio and video.
The method is there on the RTCRtpReceiver regardless if kind is "audio" or "video", it just doesn't return anything in the "video" case for Chrome and Firefox. It is safe to assume that nobody is relying on video-receivers returning empty arrays.

Philip Jägenstedt

unread,
Oct 19, 2018, 9:21:43 AM10/19/18
to Henrik Boström, blink-dev
Alright, sounds like this is already on its way to interop, and it's
one more small step on the road towards overall WebRTC convergence!
Thanks for pushing this along, one API at a time :)

LGTM1
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a12af8c1-72cb-4f81-8a65-ebedf282ed69%40chromium.org.

Yoav Weiss

unread,
Oct 28, 2018, 1:50:35 PM10/28/18
to Philip Jägenstedt, hb...@chromium.org, blin...@chromium.org
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYddcPfEem%2BD-STwJqPe5CinkFUMg3Yu_y5bdoocY0rkWg%40mail.gmail.com.

Chris Harrelson

unread,
Oct 28, 2018, 2:59:01 PM10/28/18
to Yoav Weiss, Philip Jägenstedt, Henrik Boström, blin...@chromium.org
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEi-FobdezztTq_v53oahr2YW1%2BrcbS8UHvtFdcOpQTmpg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages