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

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>.
>>
>>
>