W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2015

Re: Towards Simulcast

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Fri, 16 Oct 2015 01:40:19 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: Adam Roach <abr@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <75834DEE-FDB4-4CC9-8B23-BC7FE7F01A73@microsoft.com>
On Oct 15, 2015, at 17:44, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

Finally the decision at the f2f that we don't want track cloning to be our solution to simulcast should not be interpreted as a requirement that simulcast must be WebRTC 1.0.

[BA] Right.  But I think there was consensus that if we do want to send simulcast, that explicit API support is required. Track cloning doesn't provide the information the browser needs to do a reasonable job of sending simulcast (as opposed to just sending two streams from the same camera).

I also think we should realize that RID + Plan X is not the only option available.  It's still possible to get simulcast into WebRTC 1.0 even without the RID draft or the simulcast draft.

[BA] From an RTP perspective, the basic requirements we discussed (e.g. enabling simulcast sending without eating PTs for breakfast) can indeed be satisfied without the RID or the simulcast drafts, just via the API portion of Plan X.

That said, the RID draft does add considerable value:

1. It makes it possible to handle incoming streams (including possibly FEC and RTX) prior to receipt of the answer.
2. It makes it possible to survive an SSRC conflict without requiring another O/A.

On wireless networks where loss (including burst loss) is common, and signaling can be delayed significantly, #1 seems like it could result in a noticeable improvement in "time to first video".
Received on Friday, 16 October 2015 01:40:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC