Issue 108: Section 9.4: multiStreamSupport

Bug filed based on discussion at the June 24, 2014 ORTC CG meeting. 

The Editor's draft contained the following: 

partial dictionary RTCRtpCodecCapability {
    boolean?                  multiStreamSupport = false;
};

We need to understand the problem addressed by this better (and whether in fact this is the solution to that problem). 

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. 

Some thoughts: 

a. Today most codec implementations only support one variant.  For example, since VP8 only supports SST-SS, there is no need for a VP8 capability or a parameter relating to multi-stream support and adding this could only confuse developers.   If a given codec name either does SS or MS, we could omit support for SS/MS capabilities or parameters.   Even if a given codec does supports both SS and MS, we can avoid the issue by creating a new codec name (e.g. H.264-SVC vs. H.264-SVC-MS).  

b. Developers are not likely to have a deep understanding of SS/MS issues - nor will they have a big motivation to gain such an understanding.  So best to "keep it simple".  

Therefore, can we remove multiStreamSupport and rely solely on the "Codec Name" to solve the problem?

Received on Wednesday, 25 June 2014 21:51:36 UTC