Returns either `probably`, `maybe` or '' (definitely not) for whether a browser is able to play a MIME type.
As the method returns strings anyways and `maybe` is pretty unhelpful, I request the return be changed to '¯\_(ツ)_/¯' (which is equally unhelpful, but at least a bit more fun).
MediaCapabilites.IsTypeSupported was very unhelpful when used to check if mimetype is supported for encoding instead of decoding. But perhaps that's not what it was created for.
It’s true. “video/mp4” really means nothing. At most, it’s a mime type for the file container, but exposes no information on the video and audio codecs contained in it. A better approach would be using this API for querying whether the video, audio and subtitle elements are playable, in addition to the container.
It's a very old API that was speced before promises were a thing. Once you ship an API, sites start using it, and if you change behavior, you break them. If your browser ships the behavior change first, and breaks a website, people just assume your browser is the one that's broken, and switch browser. So browsers don't like to change behavior, especially before other browsers have, or if other browsers won't.
At least in Firefox's case, it's hard to be confident that the decoders we use for H.264 (the most commonly used codec at the time) would support a given mime type.
Firefox uses the operating system's H.264 decoders, because we had a policy of not feeding the patent trolls. H.264 has a plethora of different levels, profiles and features [1]. The documentation for operating system's H.264 decoders often isn't very clear as to what profiles/levels/features they support. Sometimes the user has installed codec packs which affect what codecs are playable. Sometimes the user is on Windows K/N which ships without H.264 codecs. So the only way to give an accurate answer to the question, is to actually start up Windows Media Foundation, and run some video through them. This requires loading DLLs from disk, and obviously we don't want to be blocking on disk IO in the browser's JS event loop in order to accurately answer this question, and we might not have an example file for the specific combination of profile/level/features the script was asking about. In the end, we ended up doing a "test decode" on startup of the common profiles and caching the result in the user's profile. But again, if the user asks about an obscure profile or level combination we've not tried, we can't necessarily be confident that we'll actually be able to play this.
Saying "yes" optimistically and being wrong would be bad, as then the player would appear to be broken in your browser, leading users to switch browser. So the idea was script would try a few profile/level/feature combinations and pick the best to which the browser returned yes.
We probably could have done a more accurate job here if we had more time, but it's always a trade off between marginal benefits here, verses fixing something else.
The problem that I had was I couldn't figure out what string I needed to pass here. I found some docs in the AV1 spec like:
> For example, codecs="av01.0.04M.10.0.112.09.16.09.0" represents AV1 Main Profile, level 3.0, Main tier, 10-bit content, non-monochrome, with 4:2:0 chroma subsampling co-located with (0, 0) luma sample, ITU-R BT.2100 color primaries, ITU-R BT.2100 PQ transfer characteristics, ITU-R BT.2100 YCbCr color matrix, and studio swing representation.
But how the hell am I supposed to reliably figure that out. It would be awesome if the browser devtools or the Media API could spit out the right string for a video file.
A “video file” is a misnomer. A “video file” (such as mp4) is actually a container with several different tracks, which can be one or more video tracks, audio, subtitles, metadata (chapters, DV, synchronization) and others. If the browser is not aware of any of these, it will not be able to provide the information you require (but is a probably good indicator that the track is t supported).
I appreciate the addition of features. However I often wonder for how long these features will be supported. The trend is for these things to be disabled due to security concerns or depreciated in favor of another implementation which offers the same thing. Warnings abound. In other areas of computing, depreciation errors usually evolve into hard errors.
I appreciate that this method exists, but it has to be one of the whackiest designs I've seen for a major platform API. I came across it while implementing a WebRTC application and was both relieved and baffled by its existence.
I'm sure there is a reason why this can't return a boolean, but the return values here seem suspect at best. Do you actually get any more information out of a 'maybe' response than a 'probably'?
The return values are definitely terrible, but the information I’m inferring is:
- Maybe: the mime type is likely a container, and there are a wide range of possible contained formats… some supported, some not. As in the example, mp4 is such a container.
- Probably: this is either a known format that’s definitely supported (boolean true) or a container format with a narrower range of contained formats, all of which are likely to be supported if any are. Newer or more obscure containers will more likely fall in this category.
I hate to imagine the bikeshedding that must have gone into this API.
> I hate to imagine the bikeshedding that must have gone into this API.
I can't imagine any comprehensively bikeshedded API that wouldn't result in a number being returned here. And it's in the HTML5 spec., which has a reputation for being dictatorially authored by a single individual.
It seems clear that they're trying to communicate confidence level, for which a boolean would be insufficient. But I can't see why it couldn't have been a % value in that case.
I thought it might be that each value is specified to correspond to some specific confidence, but the spec. is extremely and deliberately vague, which makes the whole thing even more useless as that will inevitably just lead to different implementers returning inconsistent values for arbitrary confidences.
Take a moment to reflect on how many people were involved in the proposal, design and implementation of this function. And yet, at no point was this awkward design shot down by any of them - despite going against widely accepted ground principles in software design and engineering.
How come so much incompetence is concentrated in those places, and what can be done about that?
Many professionals, including actual browser implementers, have carefully specified, reviewed, and ratified the proposal. And you think they're incompetent, and you know better?
Has it crossed your mind that you are less informed about the trade-offs and limitations of browser media stacks 15 years ago, and the design is baffling to you, because your opinion comes from ignorance?
As the method returns strings anyways and `maybe` is pretty unhelpful, I request the return be changed to '¯\_(ツ)_/¯' (which is equally unhelpful, but at least a bit more fun).