Re: Issue 108: Section 9.4: multiStreamSupport

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.


On Wed, Jun 25, 2014 at 2:51 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

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