Add a canDecodeType utility

[domenic]

Right now decodeAudioData says

Audio file data can be in any of the formats supported by the audio element.

From a layering perspective, this is a circular dependency: we would like to explain <audio> in terms of web audio, but here web audio has taken a dependency on <audio>.

Practically, this screws me when trying to implement <audio> as part of HTML as Custom Elements.

I think web audio should have something like AudioContext.prototype.canDecodeType() that returns the same "", "maybe", "probably" enum. Then we could explain HTMLMediaElement.prototype.canPlayType in those terms.

[cwilso]

This is part and parcel of "we need a different approach for decoding". The decoding API we currently have is actually NOT suitable to built support on top of - a major part of support is that it supports streaming audio, and decodeAudioData can't support that. I'd mentioned to Alex before that we'll need a new decoding API (or just describe completely in JS ;) in order to properly layer this.

I'd rather NOT add this API, independent of a rework for decoding. (That's represented by #337 #335 #7 #283 among others.)

[domenic]

Yeah, I was kind of anticipating that might be the case. I've started looking into MSE as a potential solution, but didn't get too far yet.

[cwilso]

#7 is also relevant.

[billhofmann]

Still marked as v1 - should this be deferred?

[padenot]

I think we should push that to v.next, since we don't have proper layering anyway.

[rtoy]

Add Needs WG review for a final decision.

[rtoy]

Per teleconf, moving to v.next, per
#371 (comment)

[mdjp]

This will now be handled by https://discourse.wicg.io/t/webcodecs-proposal/3662