|
Back in the day, I worked on this API in Firefox. 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. [1] https://blog.pearce.org.nz/2013/11/what-does-h264avc1-codecs... |