Section 9.4: multiStreamSupport

[aboba]

ORTC API 1.1 does not support Multi-Session Transmission (MST) as defined in RFC 6190. While the API can in theory support this, there is no WebRTC implementation that has expressed an interest in supporting MST.

However, within Single Session Transmission (SST), there are Single Stream (SST-SS) and Multiple Stream (MS) variants. An SST-SS implementation will send all SVC layers using the same SSRC. An SST-MS implementation will send each SVC layer with a distinct SSRC. As examples, existing implementations of VP8 with temporal scalability are based on SST-SS, and the UCI Forum H.264/SVC Transport Profile is based on SST-SS. However, Microsoft's H.264/SVC implementation is based on SST-MS.

The question then arises as to how to discover what transport variants are supported by a given codec, as well as how to configure a codec for a given variant. Since most codec implementations only support one variant, in most cases, the developer shouldn't have to do much, if anything.

[aboba]

Revised issue statement:
http://lists.w3.org/Archives/Public/public-ortc/2014Jun/0065.html

[aboba]

Need text to explain that svcMultiStreamSupport is a boolean and therefore that if a given codec supports both SST-SS and SST-MS that there will be two codec entries, one with svcMultiStreamSupport = true and the other with it set to false.

[pthatcherg]

I like the idea that you propose of making the codec name indicate MS vs SS. If we really need a better solution later because a given codec can do either, we can make a better solution at that time. I'd propose we just remove svcMultiStreamSupport.

[robin-raymond]

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.

[aboba]

Now that the SSRCs have to be filled in to RTCRtpParameters, if you don't know if a codec is SST-SS or SST-MS and you fill in the wrong SSRCs, an exception is generated. Also, the SSRCs can be changed by the browser, and there is no way to retrieve the ones that are being used.

[aboba]

With the clarifications on SSRC handling, this issue is now better defined. If the application allows the browser to select SSRCs, then the browser will do the right thing for a given codec. If the codec supports SST-SS, then the browser will select only one SSRC for all layers; if the codec supports SST-MS, it will choose distinct SSRCs for each layer. However, if the application chooses the SSRCs, then it needs to know which transport mode the codec supports, so that it can figure out how many SSRCs it needs to allocate and populate within RTCRtpEncodingParameters.