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

Re: Towards Simulcast

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 15 Oct 2015 17:43:39 -0700
Message-ID: <CAJrXDUGb00v35COzSkr4U6Vtb1-zmOxMN9cW+oV5Ysey7TtZwA@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Adam Roach <abr@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

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