- From: Peter Thatcher <pthatcher@google.com>
- Date: Thu, 15 Oct 2015 17:43:39 -0700
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: Adam Roach <abr@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUGb00v35COzSkr4U6Vtb1-zmOxMN9cW+oV5Ysey7TtZwA@mail.gmail.com>
While I agree that RID + Plan X would qualify as a workable solution, I think we need to be more clear about where the RID draft needs to be for WebRTC 1.0 to depend on it. Saying "on a trajectory to finish in 6 months" is too vague and too long away. It's too easy for us to end up depending on something that drags on far too long. If it's going to be in 1.0, I think we need to have a milestone much sooner and more clear that if we don't hit, we're let it go. Like, a clear milestone coming out of IETF 94.[[ 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. And I think it would be wise for us to have such a backup plan if RID doesn't get done in time. It could be as simple as a single "a=" line the remote description, for example. As for what "Plan X" needs, Bernard is correct: what I proposed would not use the simulcast draft at all, only the RID draft. And it would only use a subset of the RID draft. For example, it would not use "max-width", "max-height", "max-fps", "max-fs", "max-pps", or "depend". And there are, as far as I can tell two unresolved questions with Plan X (other than being dependent on the unfinished RID draft): 1. The RID draft may need to compensate for endpoints that don't implement "max-width", "max-height", etc, perhaps with something in the SDP indicating what things are supported. 2. The RID draft may need a way to indicate the relative size/order of the layers even if there is just a bare "a=rsid" line with no "max-width", "max-height", etc, and the API needs a way to choose the order. 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. Not having simulcast in WebRTC 1.0 is still an option. On Thu, Oct 15, 2015 at 4:54 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > On Thu, Oct 15, 2015 at 3:03 PM, Adam Roach <abr@mozilla.com<mailto: > abr@mozilla.com>> wrote: > > "Coming out of the MMUSIC interim meeting, I wanted to take a step back > and look at the moving pieces that would be necessary to get simulcast into > WebRTC for the 1.0 timeframe. At a high level, we need three things to > happen if this is to succeed: > > 1. Define a simulcast API in the WebRTC 1.0 specification > 2. Get the simulcast draft in the IETF on a trajectory to finish inside > 6 months > 3. Get the RID draft in the IETF on a trajectory to finish inside 6 > months > > At the moment, we have a reasonable API proposal on the table (Peter's > "Plan X" seems as good as anything else)." > > [BA] To be clear, Peter's proposal does not really depend on #2, only on > #1 (which this WG can handle) and #3. > > IMHO, #3 would be more likely to complete in a timely way as a separate > document within a WG such as AVTEXT. > > > > >
Received on Friday, 16 October 2015 00:44:47 UTC