isConfigSupported: definition of "invalid"

[aboba]

The behavior of isConfigSupported API for unsupported configurations is different on Chromium and Safari.

The specification says (for Audio and Video encoders and decoders):

"If config is not a valid.... return a promise rejected with TypeError."

However, the definition of "invalid" appears to differ between implementations.

On Chromium, when an unsupported scalabilityMode value is provided, the promise resolves with supported set to "false", but on Safari, the promise is rejected.

Live example: https://webrtc.internaut.com/wc/isup2/

A snippet:

async function modeProperties(mode, enc, config) {
  config.scalabilityMode = mode;
  if (enc == 'true') {
    // check whether the encoder supports the configuration
    try {
      const encoderSupport = await VideoEncoder.isConfigSupported(config);
      if (encoderSupport.supported) {
        addToEventLog('For encode ' + preferredCodec + ' ' + mode + ' is supported');
      } else {
        addToEventLog('For encode ' + preferredCodec + ' ' + mode + ' is NOT supported');
        //addToEventLog('Config details:\n' + JSON.stringify(encoderSupport.config));
      }
    } catch (e) {
     // Safari will end up here for unsupported scalabilityMode values, Chromium will not
      addToEventLog('For encode ' + preferredCodec + ' ' + mode + ' is considered INVALID');
    }
  } else {
    // check whether the decoder supports the configuration
    try {
      const decoderSupport = await VideoDecoder.isConfigSupported(config);
      if (decoderSupport.supported) {
        addToEventLog('For decode ' + preferredCodec + ' ' + mode + ' is supported');
      } else {
        addToEventLog('For decode ' + preferredCodec + ' ' + mode + ' is NOT supported');
      }
    } catch (e) {
     // Safari will end up here for unsupported scalabilityMode values, Chromium will not
      addToEventLog('For decode ' + preferredCodec + ' ' + mode + ' is considered INVALID');
    }
  }
}

[padenot]

The spec is clear what should happen: https://w3c.github.io/webcodecs/#valid-videoencoderconfig. Safari is incorrect, best to write a WPT and to file https://bugs.webkit.org/.

[sandersdan]

Note that TypeError will also result when using an enum value that the implementation does not have in its IDL, and so can be a correct result in a backwards-compatibility scenario.

'Invalid' here means 'invalid types', where we've additionally (beyond WebIDL) specified some types to be nonzero/nonempty.

[dalecurtis]

I made a similar mistake when fixing this for Chromium, in this case scalabilityMode is a DOMString not an enum, so we shouldn't apply enum rules.

[aboba]

As of today (only 48 hours after filing this issue!), there is no longer a discrepancy between Chromium and Safari with respect to handling of scalabilityMode.

Do we still need a WPT test, and if so, what should it cover?