Clarify scalabilityMode = ""

[chcunningham]

In #182, @aboba wrote:

The only tricky part is interpreting the meaning when the decoder returns no scalabilityModes attribute. This means "all modes supported" when the encoder indicates that it supports at least one scalabilityMode value and "no modes supported" otherwise. This works as long as there are no implementations that support scalable encoding but not decoding. If that assumption seems like a bridge too far, we could add a "*" value to explicitly indicate support for all scalabilityMode values on the decoder.

IIUC, the meaning of = "" changes depending on surrounding circumstances. I want to understand this better and double check that MC is capable of following this model.

Attempting to learn more, I read https://www.w3.org/TR/webrtc-svc/#dom-rtcrtpcodeccapability-scalabilitymodes

scalabilityModes of type sequence<DOMString>

An sequence of the scalability modes (defined in Section 6) supported by the encoder implementation.

In response to a call to RTCRtpSender.getCapabilities(kind), conformant implementations of this specification MUST return a sequence of scalability modes supported by each codec of that kind. If a codec does not support encoding of any scalability modes, then the scalabilityModes member is not provided.

In response to a call to RTCRtpReceiver.getCapabilities(kind), decoders that do not support decoding of scalability modes or that can decode any scalability mode (such as compliant VP8, VP9 and AV1 decoders) omit the scalabilityModes member. However, decoders that only support decoding of a subset of scalability modes MUST return a sequence of the scalability modes supported by that codec.

I think I understand what this is saying, but I'm not able to reconcile it with @aboba's earlier statement. Is that behavior documented elsewhere in webrtc-svc?

Also, I like the bit about compliant decoders, but I worry that it creates ambiguity. As we've learned in #182, some Vp9 decoders unfortunately don't support SVC at all. How do we distinguish those from compliant decoders?

Ping w3c/webrtc-svc#49 so folks reading there see mention of this relevant issue.

[chcunningham]

@drkron FYI - good to get clarity on this before we ship

[chcunningham]

@aboba friendly ping
@alvestrand FYI

[alvestrand]

This actually ties in with the question of whether there should be an "L1T1" scalability mode, or similar explicit reprsentation of the "no scalability layers" configuration. w3c/webrtc-svc#48

If there is an explicit representation of the "no scalability" mode, that solves the problem of empty array having two meanings.

[aboba]

The "L1T1" scalability mode has been added to the WebRTC-SVC list of modes, so as to allow the encoder to be configured with "no scalability layers". Also, there is now PR 54 to remove RTCRtpReceiver.getCapabilities().

[aboba]

Can we close this issue?

[chcunningham]

Yes. No longer applicable given recent direction in #182 (delete to use referenceScaling rather than scalabilityMode for decode capabilities).