Re: Simulcast V1

On Aug 14, 2015, at 1:53 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:



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




On Aug 14, 2015, at 1:02 PM, Adam Roach <abr@mozilla.com<mailto: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.

Could you live with an array of RtpEncodingParameters with nothing specified? That would seem close to Adams proposal and I have no clue how to set the bandwidth in the JS before anything is known about the connection.