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.
I have the TP-Link AV2000 and found them good. My office has a bunch of metal laundry appliances and concrete walls between my desk and the wifi router, so wifi signal is terrible there. Solved it with the AV2000.
I also tried using a mesh wifi network, and was able to bounce a signal around the dead zone and get a WiFi signal with a higher bandwidth than the powerline ethernet, but I still found I got a lot of glitches in video calls, so went back to the powerline ethernet.
I've not noticed the problems other commenters here had with their adapters with the AV2000.
I initially tried a cheaper powerline ethernet, and it was worse than WiFi, so I'd recommend you buy the most expensive/best one that you can afford.
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...