Open aboba opened 7 months ago
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?
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 withsupported
set to "false", but on Safari, the promise is rejected.Live example: https://webrtc.internaut.com/wc/isup2/
A snippet: