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.
>
It's not just a PR. It's merged:
https://github.com/w3c/webrtc-pc/blob/master/webrtc.html#L2772
Although all you can do currently is change the .active and .priority of a
given encoding. I have PRs for adding .maxBitrate and .payloadType. We
don't have a PR for *adding* encodings or controlling the resolution/scale
(although I would be glad to write one :).