Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section 9.4: multiStreamSupport #108

aboba opened this issue Jun 25, 2014 · 6 comments

Section 9.4: multiStreamSupport #108

aboba opened this issue Jun 25, 2014 · 6 comments


Copy link

aboba commented Jun 25, 2014

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.

Copy link
Contributor Author

aboba commented Jun 25, 2014

Copy link
Contributor Author

aboba commented Jul 8, 2014

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.

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014

Added Identity support, as described in Issue w3c#78
Reworked getStats method, as described in Issue w3c#85
Removed ICE restart method described in Issue w3c#93
Addressed CNAME and synchronization context issues described in Issue w3c#94
Fixed WebIDL issues noted in Issue w3c#97
Addressed NITs described in Issue w3c#99
DTLS transport issues fixed as described in Issue w3c#100
ICE transport issues fixed as described in Issue w3c#101
ICE transport controller fixes made as described in Issue w3c#102
Sender and Receiver object fixes made as described in Issue w3c#103
Fixed RTCRtpEncodingParameter default issues described in Issue w3c#104
Fixed 'Big Picture' issues descibed in Issue w3c#105
Fixed RTCRtpParameter default issues described in Issue w3c#106
Added a multi-stream capability, as noted in Issue w3c#108
Removed quality scalability capabilities and parameters, as described in Issue w3c#109
Added scalability examples as requested in Issue w3c#110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue w3c#111
Removed header extensions from RTCRtpCodecParameters as described in Issue w3c#113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue w3c#114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue w3c#116
Added layering diagrams as requested in Issue w3c#117
Added a typedef for payload type, as described in Issue w3c#118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue w3c#121
Added explanation of Voice Activity Detection (VAD), responding to Issue w3c#129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue w3c#130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue w3c#131
Addressed ICE terminology issues, as described in Issue w3c#132
Separated references into Normative and Informative, as noted in Issue w3c#133
Copy link

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.

Copy link

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.

Copy link
Contributor Author

aboba commented Jul 21, 2014

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.

Copy link
Contributor Author

aboba commented Aug 18, 2014

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.

@aboba aboba closed this as completed Aug 18, 2014
robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014

Clarified onerror usage in sender and receiver objects, as noted in:

Clarified SST-MS capability issue noted in:

Clarification of send() and receive() usage as noted in:

Changed ICE state diagram as noted in:

Removed getParameters methods and changed send() method as noted in:

Changed definition of framerateScale and resolutionScale as noted in:

Substituted "muxId" for the "receiverId" as noted in:

Clarified the setting of track.kind as described in:

Added SSRC conflict event to the RTCRtpSender, as described in:

Addressed the "end of candidates" issues noted in:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants