Re: Towards Simulcast

I'm sad about sounding like Cassandra here, but.....

On 10/16/2015 12:03 AM, Adam Roach 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).
>
> The simulcast draft is pretty mature. It's been baking for a year now,
> and the changelog from -01 to -02 lists only 4 changes: adding RID,
> adding the ability to specify codec preference ordering, and two
> editorial updates.

These are pretty drastic changes, though - they change the draft from
specifying one mechanism to two mechanisms. (If the mechanisms had been
more complex, they would double the complexity of implementing them; as
it is, they're pretty ho-hum as complexity goes; most of the complex
parts are elsewhere)

The dates on the draft are October 27 for the individual, Jan 20 for the
WG -00 (no changes), July 21 for -01 (with the authors saying that was
an unchanged keepalive) and October 6 for -02. So effectively we've had
two iterations on the draft, one year apart.

Discussion on the list has been pretty nonexistent; from March to
September, there was a single message with "simulcast" in the title.

And this is not because there are no issues; picking out a random topic
from discussion:
We still don't have a defined interpretation for

m=video .... 117
a=imageattr:117 send [x=40:180 y=40:180]
a=simulcast: send rid=11;12
a=rid:11 send pt=117 max-width=80
a=rid:12 send pt=117 max-width=200

(that is - if rid and imageattr with pt apply to the same stream, do
they both apply, or does one override the other? If they conflict, is
the stream invalid and should be rejected?)

And the RID draft still doesn't reference a definition of a bitrate for
the (extremely useful) "max-br" field; given the time we've spent on
bitrate definitions in the past, this is not encouraging.

The lack of clarity on these things is not indicative of a document
that's close to "done".

>
> So that leaves the RID draft. Setting aside for a moment the differing
> opinions about how much work is left on that mechanism, I think we
> agree in principle that finishing that draft in the timeframes
> required would provide for a complete solution.
>
> Does that match everyone's understanding?

No, not really.

>
>
>
> Addendum: At the face-to-face interim in Redmond, there was a
> discussion around using the currently defined API points
> (clone/applyConstraints) as a kind of poor-mans' simulcast. As
> reflected in the minutes, this approach is problematic enough with
> scalable coding that both Justin and Cullen deemed it "a non-starter."
> Bernard also described a set of issues with this approach that made it
> "unsatisfactory", although the details slip my mind, and didn't make
> it into the minutes.
>
> -- 
> Adam Roach
> Principal Platform Engineer
> abr@mozilla.com
> +1 650 903 0800 x863