Re: Simulcast V1

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
[x=[128:16:1280],y=[72:9:720]]
   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.