-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AudioDecoder.configure should not throw for invalid config #861
Comments
I don't see a space for ambiguity here. The spec clearly specifies what is an invalid audio decoder config, the same is done for video encoder and decoder configs. Unsupported config in one UA can be supported in another, invalid config can't be accepted by any UA. If you think that we should change WPT or the config validity criteria in the spec, let's discuss it (PRs are always welcome), but concept of invalid config seems useful to me. |
If there was no ambiguity, the test wouldn't be incorrect to start. Like how can this configuration test
be expected to throw as invalid but this one
isn't considered as invalid, just not supported and expect supported to be false instead? (that's the test as it is) |
Oh, I see, we need to fix WPT (and UAs). Both of these should be unsupported. |
See also #826 for related discussion of Opus "invalid" versus "unsupported". |
Per spec https://w3c.github.io/webcodecs/#dom-audiodecoder-configure
"If config is not a valid AudioDecoderConfig, throw a TypeError."
I think this is ambiguous, and there's even inconsistency in the tests where in one place we check that the config isn't valid and in the other that the same config is also not supported (I lodged
web-platform-tests/wpt#49636 for this one)
Rather than throwing when a configuration isn't valid, we should just mark it as not supported; particularly when there's a lot of discrepancies already in what is considered a "valid" configuration (WPT checks that bitrate isn't 0, or too big, that the Opus description is greater than 9 bytes etc) which aren't in the spec and doesn't have broad acceptance across UAs
The text was updated successfully, but these errors were encountered: