Re: Proposal-ORTC Sender / Receiver Capabilities Based Model

[RR] See inline

> Peter Thatcher <mailto:pthatcher@google.com>
> May 9, 2014 at 8:44 PM
>
>
>
> On Fri, May 9, 2014 at 3:12 PM, Robin Raymond <robin@hookflash.com 
> <mailto:robin@hookflash.com>> wrote:
>
>
>     [...]
>
>
> ​If RtpCapabilities needs to contain more ​info, then we should 
> identify what info it needs and add it.  We should start there and 
> then worry about what comes on top.
[RR] It does need more. So I will explain each one so we can decide if 
we want to add now, later, never, etc.
>
>     [...]
>
>
> ​I don't think SVC is even a use case that we should worry about much 
> with createParameters/filterParameters.  ​I mean, it might still 
> function properly, but I don't think we should worry about it too 
> much.  createParameters/filterParameters is really meant for simple 
> use cases.  If you're doing SVC, you're doing multiway video, which is 
> an advanced use case.  Build the RtpParameters yourself.  It's not 
> that hard.  Or use a library someone built.
[RR] "Build it yourself. It's not hard" is true only if we have the 
proper information available. We don't (yet). [more later]
>
>
>     [...]
>
>
> We debated the multi-RtpReceiver vs. single-RtpReceiver a lot before, 
> and I thought we agreed on allowing multi-RtpReceiver, and I thought 
> the arguments for it were pretty compelling.  Or you no longer in 
> agreement with the decision?​
[RR] I'm saying that we've tossed simpler stuff from the API for less 
reasons. This is a major addition in surface API that provides minimal 
additional value (in my opinion) and could be done via JS abstraction 
layer for those who need to switch rendered receiving streams based on 
stream activity events (which must be supported anyway). This makes the 
ORTC 1.1 API a lot bigger to implement out of the gate. Plus, the way we 
originally defined simulcast via encoding params doesn't appear to 
actually work [well] when combining with SVC. I did propose changing it 
to make it work while using SVC cleanly. I find the argument strange 
that my proposal is "way too complex" when I rearrange and add missing 
stuff when we are adding such a big thing like simulcasting straight 
into the sender/receiver which is far more complex, needs more knobs, 
and already has alternative methodologies which can work to achieve 
simulcasting without it [AFAIK].
>
>
>>
>>     [...]
>
>
> ​Bernard brought up temporal scalability and sort of proposed adding a 
> field for it, which I think makes sense.  Adding one field is pretty 
> easy and looks simple.  ​But what you have, no offense, seems like a 
> huge change and very complex.
>
[RR] He's pecking at it one issue at a time. I went head long into it 
and tried to make sure it was complete for the use cases. There's more 
issues than that for SVC (and other things). It's merely one example.
>
>
>>     [...]
>
> ​
> Again, let's make sure the Capabilities give the information the JS 
> needs.  Then you can do whatever you want with the Parameters.  It 
> sounds like your needs are specific enough that you shouldn't be using 
> createParameters in the first place.  ​
> ​
[RR] Do you agree to expanding the role of Capabilities so that writing 
such a JS abstraction layer is possible? That was not its original 
intent [as I understood it].
>
>
>     [...]
>
>
> ​Maybe if you broke it down into very small pieces so I can understand 
> it.  Like, make the diff (or diffs) as small as possible.​  Right now, 
> it hurts my head.

[RR] Fair comment. I can do that. Sorry for the headache! I likely owe 
you a bottle of Tylenol!
>