Skip to content
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

Open
jyavenard opened this issue Dec 11, 2024 · 4 comments
Open

AudioDecoder.configure should not throw for invalid config #861

jyavenard opened this issue Dec 11, 2024 · 4 comments

Comments

@jyavenard
Copy link
Member

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

@Djuffin
Copy link
Contributor

Djuffin commented Dec 11, 2024

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.

@jyavenard
Copy link
Member Author

jyavenard commented Dec 13, 2024

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

 comment: 'Opus with >2 channels but no description', 
 config: { 
   codec: 'opus', 
   sampleRate: 48000, 
   numberOfChannels: 6, 
 } 

be expected to throw as invalid

but this one

   comment: 'Opus with more than two channels and without description', 
   config: { 
     codec: 'opus', 
     sampleRate: '48000', 
     numberOfChannels: 3, 
   }, 

isn't considered as invalid, just not supported and expect supported to be false instead?

(that's the test as it is)

@Djuffin
Copy link
Contributor

Djuffin commented Dec 13, 2024

Oh, I see, we need to fix WPT (and UAs). Both of these should be unsupported.

@tguilbert-google
Copy link
Member

See also #826 for related discussion of Opus "invalid" versus "unsupported".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants