Re: A clarification on Capabilities, Parameters, createParameters, and filterParameters.

I completely understand that as an application developer I can ignore 
"createParams" and "filterParams". But as an editor on the ORTC draft, 
they must be defined precisely what they must do without any hand waving 
(and provide example usages). These methods need to operate in a 
predictable manner and must be implementable from reading the 
specification(s) alone.

In doing that process of defining the API rules, I discovered that 
"createParameters" only provides marginal value "as is" and could be 
made a whole lot more useful with a bit of input without making it 
overly complex to implement. If we are going to add a convenience method 
at all, I would hope it to make it have good value (bang for buck).

If you actually look at the preferences I described, _most_ of them are 
actually just moved from 'encoding parameters' into this preferences 
dictionary since those are the knobs most people want to tweak. This 
keeps a separation from the simple stuff away from the complex. For 
example, that's where specify maxBitRate. Why? Because then you don't 
have to monkey with a the more complex "params" structure. It's easy to 
describe simple engine preferences like "maxBitRate" outside of having 
to explain them in the context of 'encoding parameters' (which is meant 
for the advanced users who know RTP stuff).

And again, small "hints" in "createParameters" can actually eliminate 
the need to touch the "parameters" for the most part. I see that as 
positive. The less use cases where developers must mess with detailed 
"params", the better. Yes, it can be done as a JS abstraction (and 
likely should), but why force many uses cases to not only have to mess 
with "params" but also reading "Capabilities" to be able to setup 
"params" properly. If if we are providing convenience, make it count.

Without this, I'm going to have to dive deep into expanding Capabilities 
so that such a JS abstraction layer can be possible. It will need to 
read and generate these "params" based upon Capabilities so we'll need 
to expand "Capabilities". I can anticipate the complaint when I do "you 
are adding too much; it looks complex". But it's will be the only option 
for many use cases if we don't make createParams more useful out of the 
box. That's the catch-22.

As for "filterParams" I discovered the use cases can be written entirely 
without every touching it (and way easier). That's why I demonstrated 
using filterParams vs not using it. Since "filterParams" adds to 
marginal value "as is", and it's ill-defined what it actually does, 
makes use cases more complex, and it won't likely work for advance use 
cases anyway, why keep it?

-Robin


> Peter Thatcher <mailto:pthatcher@google.com>
> May 9, 2014 at 8:49 PM
>
>
>
> On Fri, May 9, 2014 at 3:28 PM, Robin Raymond <robin@hookflash.com 
> <mailto:robin@hookflash.com>> wrote:
>
>
>     [RR] See inline
>
>>     Peter Thatcher <mailto:pthatcher@google.com>
>>     May 9, 2014 at 5:31 PM
>>     [...]
>     [RR] I think my understanding of "filterParameters" was/is
>     inconsistent with yours. I was under the impression it had to be
>     able to filter advanced stuff (like SVC) and not just the bare
>     bones simple stuff. If it only filters the basics, I honestly
>     don't think it adds much value and I think filtering the complex
>     stuff is a lot harder than it seems and requires complex rules and
>     expanded Capability definitions. As it stands though, the exact
>     rules of how it operates needs to be defined otherwise nobody else
>     can implement this API. Perhaps I'm a thick in the skull, but I
>     can't figure out how to make it truly work well for anything
>     beyond the most simple, and I also don't think it's very "future
>     proof". I would still suggest it's a candidate for elimination. We
>     can make the API work for simple use cases without it anyway.
>
>
> Advanced use cases can build RtpParameters themselves.  Or, they can 
> do a mix: ​call createParameters to fill in the basic stuff, and then 
> add the layering/simulcast stuff you need.  Really, it doesn't seem 
> that hard to me.  I don't think we need to make 
> createParameters/filterParameters be everything to everybody.  Just do 
> the basics and then let the JS do advanced stuff.
>
>
>>
>>     I can also understand #2, as I mentioned before.  But it would
>>     need to be very simple, and every time I think of a simple set of
>>     options to pass in, I think: why not just do this in a JS
>>     library, or learn how to use RtpParameters?  Again, playing with
>>     RtpParameters isn't that hard.  It's not SDP munging :).
>>
>     [RR] I think it should be simple too. I don't think what was
>     included was rocket science but certainly it would be useful to go
>     through each item. As for "why not just do this in a JS library".
>     Personally, I 100% agree and would love to do exactly that, except
>     currently the target level Capabilities we were originally
>     planning lacks sufficient information to be able to write said JS
>     abstraction. To be possible, we'd need to expand the target
>     definition of what Capabilities should include to not be solely
>     for other browsers engines' consumption but to also enable writing
>     JS "createParameter" abstraction layers.
>
>
> ​I may be wearing you out having to hear this, but if the 
> RtpCapabilities are lacking important things, let's add them.  If you 
> don't like createParameters/filterParameters for you use cases, then 
> just ignore them.  Don't use them.  But people with simple use cases 
> will appreciate them.  There are lots of use cases that don't involve 
> simulcast and layering.  The 1.0 spec doesn't even include them at all!
>