What should the scalability mode be when the preferred scalability mode is not supported on the requested codec?

[alvestrand]

Consider the following code snippet:

  const pc1 = new RTCPeerConnection();
  const transceiver = pc1.addTransceiver(track1, {
    sendEncodings: [{ scalabilityMode: 'L3T3' }],
  });
  // Pick a codec known to not have L3T3 support
  const capabilities = RTCRtpSender.getCapabilities('video');
  console.log(JSON.stringify(capabilities.codecs, null, 2));
  const codec = capabilities.codecs.find(c => c.mimeType === 'video/VP8');
  transceiver.setCodecPreferences([codec]);
 ... negotiate ...

What should the result of getParameters.encodings.scalabilityMode be?

Possible alternatives:

• Missing or empty string, corresponding to "platform made its own choice"
• The scalability mode that the platform is actually using
• L3T3, becaue that's what the user requested

At the moment, Chrome chooses the third alternative.

[aboba]

I would say that when the codec has been negotiated, it should be 'The scalability mode that the platform is actually using'. Prior to negotiation of VP8, 'L3T3' makes some sense since that mode is what the application requested and what would be installed if VP9 were to be negotiated. But once VP8 is negotiated and it can be determined that 'L3T3' is not supported, it should be what the platform is using. Does this make sense?

[alvestrand]

I agree that getParameters should always (no exceptions) return the currently used scalability mode. (This also offers a way of feature-detecting if the SVC extension is supported)

Before negotiation is completed, this should be the mode asked for, or, if no mode has been asked for, the default mode of the most preferred codec (both of these things are already implementation dependent).

[aboba]

Closed after merger of PR 64.