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

Yes that may make the most sense. In general, codecs like H.264 offer many options and so it is very common for two implementations of this "standard" to fail to interoperate. This can be fixed either by creating lots of capabilities and parameters and hoping that implementations can find a viable intersection, OR by clearly defining what a WebRTC implementation with a given codec name must support if the spec is vague (e.g. WebRTC implementations of H.264 MUST support packetization mode 1). IMHO the latter is more likely to succeed, and will also be easier for developers (fewer capabilities and parameters).





On Jul 18, 2014, at 4:26 PM, "Peter Thatcher" <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

So you're saying we need "H.264/MS" (which is a more appropriate name for two reasons :) is needed anyway?  Well, if we need it anyway, then we don't need "supportsMultiSsrcLayering" on top of that (at least not yet).


On Fri, Jul 18, 2014 at 4:16 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
Our implementation of H.264/SVC only supports SST-MS, so if there is a separate name we do not need the flag. Might need the separate name anyway because of other differences (e.g. packetization modes, PACSI NAL usage, etc.). H.264/SVC SST-SS has a profile from UCI Forum but SST-MS does not.

On Jul 18, 2014, at 3:45 PM, "Robin Raymond" <robin@hookflash.com<mailto:robin@hookflash.com>> wrote:


As I understand it Microsoft does have need SST-MS codecs they want to use. Right Bernard?

This isn't theoretical.

I know we'd prefer to use SST-MS codecs if they become available.

--
Robin Raymond



On July 18, 2014 at 5:41:12 PM, Peter Thatcher (pthatcher@google.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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>.