Re: Towards Simulcast

On Oct 15, 2015 6:40 PM, "Bernard Aboba" <Bernard.Aboba@microsoft.com>
wrote:
>
> On Oct 15, 2015, at 17:44, Peter Thatcher <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".

True,  the new header extension, which is the reason for these benefits, is
very nice.  Perhaps putting he header extension into its own document could
be part of the backup plan.