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 15:57:37 -0700
Message-ID: <CAOJ7v-06r33mdMQgXqnUqVthri+FoY6M8zevNEsVv71Ar7Ejyw@mail.gmail.com>
To: Adam Roach <abr@mozilla.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, Byron Campen <docfaraday@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Aug 14, 2015 at 1:55 PM, Adam Roach <abr@mozilla.com> wrote:

> On 8/14/15 15:51, Justin Uberti wrote:
> This feels somewhat ad-hoc, in that it acts like a DWIM API
> To be clear, it's a "do what the MCU clearly and explicitly says" API. All
> we're doing is opening up enough room for him to say what he wants to.

Not sure I agree. For example, how does the browser know to offer two
different profile/level combos? e.g.

   m=video 49300 RTP/AVP 97 98
   a=rtpmap:97 H264/90000
   a=rtpmap:98 H264/90000*   a=fmtp:97 profile-level-id=42c01f;
max-fs=3600; max-mbps=108000
   a=fmtp:98 profile-level-id=42c00b; max-fs=3600; max-mbps=108000*
   a=imageattr:97 send [x=[128:16:1280],y=[72:9:720]] recv
   a=imageattr:98 send [x=[128:16:1280],y=[72:9:720]]

a=simulcast send 97;98 recv 97

> In fact, it's 100% congruent with the way we handle "offerToReceiveVideo"

That control surface controls how many additional video streams we want to
receive, not send, and it's really only there because of the rules of SDP,
so I don't really agree that these things are structurally similar, even if
they are superficially similar.

> 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.
> Is that something you think is realistic to do in the 1.0 timeframe?

I think that a do-what-I-say API that requires no SDP changes is much more
likely to happen than an approach that requires changes to how
createOffer/setLocal/setRemote are specified and implemented.
Received on Friday, 14 August 2015 22:58:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC