v153 · iamf
Three APIs, one question
The platform has three ways to ask whether it can play something, and they do not return the same kind of answer. One is a boolean, one is a three-state string that includes "maybe", and one is a promise carrying three booleans. Asked about IAMF and about codecs this browser certainly has, side by side.
Every string, asked three ways
| content type | isTypeSupported | canPlayType | decodingInfo | what it is |
|---|---|---|---|---|
| Probing… | ||||
The italic rows are controls: codecs this browser has had for years. They are here so that a row of "no" against IAMF means something — without them, a broken probe and an unsupported format look identical.
Why they disagree
| API | returns | what it means, and what it does not |
|---|---|---|
| MediaSource.isTypeSupported | boolean | Whether Media Source Extensions can accept buffers of this type. It is synchronous and strict, and it is the right question for an adaptive player choosing a representation. |
| HTMLMediaElement.canPlayType | "" | "maybe" | "probably" | The oldest of the three, and the vaguest by design: "maybe" means the container is recognised but the codec parameters were not given or not checked. An empty string is the only definite answer it gives. |
| mediaCapabilities.decodingInfo | Promise<{supported, smooth, powerEfficient}> | Asynchronous, and the only one that says anything about how well: whether playback will keep up, and whether it will use hardware. It also needs a full configuration — channels, bitrate, sample rate — so it is the most work to ask and the most useful answer. |