Re: [ortc] Section 9.4: multiStreamSupport (#108)

Oh, wait.  Would we need to actually define "H.264/UC" right now?  All my
comments were assuming we didn't need it yet.  It looks like I just
completely misunderstood that.  I missed the part of your email that says
"MS's H264/SVC uses this."   In that case, all my comments about 'cross
this bridge when we come to it" were bogus because we are that bridge.

In that case, "H.264/UC" seems kind of ugly after all, and I think I'd
switch my opinion back to "let's go with the flag".  Can we call it
something like "supportsMultiSsrcLayering", instead of
"multiStreamSupport"?  I'd be OK with that.

Sorry for the confusion.


On Fri, Jul 18, 2014 at 3:25 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

>  Can we at least say in the spec what each codec will do? For example:
>
>  VP8 = SST-SS
> H.264/SVC = SST-SS
> H.264/UC = SST-MS
>
> On Jul 18, 2014, at 2:41 PM, "Peter Thatcher" <pthatcher@google.com>
> wrote:
>
>   We can figure that out when if it becomes a real issue.  For now, it's
> just a theoretical issue.
>
>
> On Fri, Jul 18, 2014 at 2:28 PM, Robin Raymond <robin@hookflash.com>
> wrote:
>
>>
>>  I don’t have an issue with having two codes, one which supports SST-SS
>> and SST-MS. That’s perfectly fine. My concern is being able to determine
>> which is which by parsing the codec name. I much prefer to have the boolean
>> flag that we have now to know the operating mode of the codec SS vs MS). We
>> have all we need from an API to support MS versions, we just need the flag
>> in the capabilities we have now to tell us the operating mode of a
>> particular SVC codec.
>>
>>  --
>> Robin Raymond
>>
>>    On July 18, 2014 at 4:50:47 PM, Peter Thatcher (pthatcher@google.com)
>> wrote:
>>
>>   If we ever get to the point where we need "VP8-MS", we can come up
>> with a better solution if we want.  I don't think it's worth adding
>> complexity for a problem we may or may not have in the future.
>>
>>
>> On Fri, Jul 18, 2014 at 1:40 PM, Bernard Aboba <
>> Bernard.Aboba@microsoft.com> wrote:
>>
>>>  If a given codec can only handle a single transport mode it is not an
>>> issue. But it would be strange to have to have "VP8" and "VP8-MS" codec
>>> names, one denoting SST-SS and the other SST-MS.
>>>
>>> On Jul 18, 2014, at 12:05 PM, Robin Raymond <notifications@github.com>
>>> wrote:
>>>
>>>   Maybe I don't understand the proposal but I don't like "magic" codec
>>> names where I parse out meaning from the name. I'd rather have a flag and
>>> be clear if the codec supports MSS vs not supported. You still need two
>>> codecs in that case if the codec supports either operating mode but I don't
>>> like the idea of parsing out "-mss" or something to know the codec supports
>>> it.
>>>
>>> —
>>> Reply to this email directly or view it on GitHub
>>> <https://github.com/openpeer/ortc/issues/108#issuecomment-49468028>.
>>>
>>>
>>
>