Re: Simulcast V1

On Fri, Aug 14, 2015 at 1:23 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>
>
>
>
> On Aug 14, 2015, at 1:02 PM, Adam Roach <abr@mozilla.com> wrote:
>
> Regardless of how you differentiate the simulcast encodings, what I'm
> proposing for the API works just fine.
>
>
> [BA] I understand why it is useful to have maxSimulcasts as a capability,
> but not as a setting on RtpSender the way you have proposed it. What
> benefit does this have beyond track cloning?
>
> What's important *here*, in the W3C WebRTC working group, is that my
> simple proposal works regardless of the outcome of those IETF discussions.
>
>
> [BA] There is no need to drag in the MMUSIC draft to solve the simple case
> you describe, so in that sense you are correct. However since what you need
> to do seems possible with additional capabilities but without an RtpSender
> addition, and more complex support requires something more like Peter's
> RtpEncodingParameters PR, the case for a half measure is pretty weak.
>

I agree with Bernard. This feels somewhat ad-hoc, in that it acts like a
DWIM API, and is not aligned with the previously proposed approach
(RtpEncodingParameters) which offers direct control.

I would rather see an approach that was consistent with
RtpEncodingParameters - i.e. instead of maxSimulcastCount, perhaps an array
of RtpEncodingParameters with just their max bitrate specified.