Re: Proposal-ORTC Sender / Receiver Capabilities Based Model

On Sat, May 10, 2014 at 8:33 AM, Robin Raymond <robin@hookflash.com> wrote:

>
> [RR] See inline
>
>   Peter Thatcher <pthatcher@google.com>
>  May 9, 2014 at 8:44 PM
>
>
>
> On Fri, May 9, 2014 at 3:12 PM, Robin Raymond <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].
>

​Just to be clear: we decided we were going to do single-RtpReceiver
simulcast/SVC back in december, and now you're suggesting we throw it out?
 I would disagree with that decision, but I want to make sure it's clear
where we stand.​


>
>
>>
>>
>> [...]
>>
>>
> ​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].
>

Absolutely.  Capabilities should express everything the JS needs to know
about what the browser can do.  ​

>
>
>
>>
>> [...]
>>
>
> ​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!
>
>
>