Re: Towards Simulcast

So, I generally agree with this, but there is one additional point, in-line.

On Thu, Oct 15, 2015 at 3:03 PM, Adam Roach <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).
>
> 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.
>

​I would add that there seems now to be broad agreement that using the
payload type alone runs the risk of exhaustion​.  Working through that at
the MMUSIC interim took a bit of time, but I think there were several folks
who had initially been skeptical who saw the issue in a new light.  That's
important, in my view, because it clears one of the critical objections to
working on RID--whether it is required to achieve scalable simulcast.

regards,

Ted



>
> 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?
>
>
>
> 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
>