Handling of unknown scalability modes is underspecified

[alvestrand]

Consider the following snippet:

    const pc = new RTCPeerConnection();
    t.add_cleanup(() => pc.close());
    const { sender } = pc.addTransceiver('video', {
      sendEncodings: [{scalabilityMode: 'TotalNonsense'}],
    });
    const param = sender.getParameters();
    const encoding = getFirstEncoding(param);

What should the value of encoding.scalabilityMode be?

This matters a lot for the case where "supported scalability modes" is not part of the API.
(At the moment the Chrome implementation returns 'TotalNonsense')

[aboba]

'TotalNonsense' isn't a valid scalabilityMode for any codec. This is an argument for addTransceiver throwing an exception. On the other hand, the text for addTransceiver in WebRTC 1.0 API doesn't specify any validation steps for sendEncodings. So one could argue that {sendEncodings: 'totalNonsense'} would also not throw an exception.

[Orphis]

In the SVC spec https://w3c.github.io/webrtc-svc/#error-handling:

However, an error will result only if the requested scalabilityMode value is invalid for any supported codec.. I guess this should throw an RTCError with description hardware-encoder-error or just an OperationError. We should probably be more clear about what to do there.

While it doesn't apply for addTransceiver, we may want to make sure that setParameters only checks the negotiated codec list or the subset indicated by setCodecPreferences prior negotiation.

[alvestrand]

This section should probably be written in imperative language. Something like:

Add to the operation of setParameters step 6:

If any scalabilityMode of any encoding is not supported by any codec in parameters.codecs, reject p with a newly created
InvalidModificationError.

Add to the operation of addTransceivers step 8:

If any scalabilityMode is not supported by any codec in RTCRtpSender.getCapabilities(kind).codecs, reject p with a newly created OperationError.

[aboba]

Closed after merger of PR 64.