WebRTC-SVC: Issues 3, 4 and 14

Issues 3, 4 and 14 relate to limitations of the current API model, which is based on pre-canned scalability modes.

Issue 3<https://github.com/w3c/webrtc-svc/issues/3> points out that the current API proposal cannot support custom scalability modes.
Issue 4<https://github.com/w3c/webrtc-svc/issues/4> points out that the current API proposal does not allow layers to be de-activated/de-activated, as is currently possible with simulcast on multiple RIDs/SSRCs.
Issue 14<https://github.com/w3c/webrtc-svc/issues/14> points out that encoding parameters cannot be applied to layers within scalability modes, as is currently possible with simulcast.

An example scenario that would encounter these limitations would a situation where spatial scalability is desired and we want to send both full resolution as well as a thumbnail video where the thumbnail is quarter resolution in both width and height.  Since the resolution ratio between the spatial layers is not 2:1 or 1.5:1, the L2T1 or L2T1h spatial scalability modes do not apply.  Also, even if we were to add a new scalability mode with a 4:1 ratio, it would not be possible to make the higher resolution layer inactive so as to stop sending it.

The ORTC API addressed these limitations by adding the encodingId and dependencyEncodingIds attributes to the RTCRtpCodingParameters dictionary<http://draft.ortc.org/#rtcrtpcodingparameters*> as shown below:


partial dictionary RTCRtpCodingParameters<http://draft.ortc.org/#dom-rtcrtpcodingparameters> {
    DOMString<https://heycam.github.io/webidl/#idl-DOMString>           encodingId<http://draft.ortc.org/#dom-rtcrtpcodingparameters-encodingid>;
    sequence<https://heycam.github.io/webidl/#idl-sequence><DOMString<https://heycam.github.io/webidl/#idl-DOMString>> dependencyEncodingIds<http://draft.ortc.org/#dom-rtcrtpcodingparameters-dependencyencodingids>;
};

encodingId of type DOMString

An identifier for the encoding object. This identifier should be unique within the scope of the localized sequence of RTCRtpCodingParameters<http://draft.ortc.org/#dom-rtcrtpcodingparameters> for any given RTCRtpParameters<http://draft.ortc.org/#dom-rtcrtpparameters> object...

dependencyEncodingIds of type sequence<DOMString>

The encodingId<http://draft.ortc.org/#dom-rtcrtpcodingparameters-encodingid>s on which this layer depends. Within this specification encodingId<http://draft.ortc.org/#dom-rtcrtpcodingparameters-encodingid>s are permitted only within the same RTCRtpCodingParameters<http://draft.ortc.org/#dom-rtcrtpcodingparameters> sequence.... In order to send scalable video coding (SVC<http://draft.ortc.org/#dfn-svc>), both the encodingId and dependencyEncodingIds are required.


While this approach does appear to address Issue 4<https://github.com/w3c/webrtc-svc/issues/4> as well as Issue 14<https://github.com/w3c/webrtc-svc/issues/14>, in previous discussion on this list, reviewers previously expressed concern about the potential complexity.  We would like to solicit comments on whether this approach (or some other idea you might have) is worth pursuing to address the open issues.

In particular, with respect to encodingId/dependencyEncodingId, we would appreciate comments on:

  *   Can the complexity concerns be addressed by also supporting the scalabilityMode approach, so that encodingId/dependencyEncodingIds won't be needed most of the time?
  *   Can complexity be contained by limiting usage scenarios to spatial scalability?