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 :).Received on Tuesday, 18 August 2015 00:12:26 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC