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

Re: Simulcast V1

From: Justin Uberti <juberti@google.com>
Date: Fri, 14 Aug 2015 13:51:02 -0700
Message-ID: <CAOJ7v-0Ji4WUgPPjSB97ZnBzEM93pwzv13jnp25nNdX62nq-KA@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.

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.
Received on Friday, 14 August 2015 20:51:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC