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

So here is the weird thing. For some codecs the decoder can decode anything, but it is the encoder that decides what to send. As long as no problem is created at the decoder, there may be no need for a setting on the receiver.

For example, with VP8 the sender object could be set up to send temporal layers. The receiver can decode whatever the sender decides to send. So what does the developer pass to receive()? I would say it could just fill in "VP8", and the payloadType and this should work.  The browser can choose and fill in the first (and for SST-SS, the only SSRC).  What is returned from getParameters? The browser could return what it is currently receiving (e.g. 3 layers of temporal, with appropriate frameScale values). But you could also ask if this is useful info a developer really needs.

What I am trying to say is that if a decoder can handle either SST-SS or SST-MS then an encoder can do either and no setting is required by a receiver.

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


We do need the flag because we need to know as we are looking at each codec without pre-knowledge of the codec if it's an SST-SS vs SST-MS so we can configure the layering properly with or without SSRCs when we are creating our parameters. I would rather not have an engine that has to have pre-knowledge of codec behaviour based on codec name just to work properly.

I do think the flag is necessary to generate generic routines to handle codecs configuration.

--
Robin Raymond


On July 18, 2014 at 7:25:58 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>.