isConfigSupported: definition of "invalid"
aboba opened this issue · comments
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');
}
}
}
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/.
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.
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.
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?