W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

Re: Simulcast V1

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 17 Aug 2015 17:11:17 -0700
Message-ID: <CAJrXDUHnd1MhuoT2LT73w0x2X5N509MkAPnhQbDW=Pr9YrfvjQ@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: Adam Roach <abr@mozilla.com>, Byron Campen <docfaraday@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Aug 14, 2015 at 1:23 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>

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


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