"Probably" and "maybe" values are, uh, probably not good enough.

I thought you were being facetious. Sigh. Damn, but that's broken.

I've worked with video format streaming, though, and encountered a situation where there was a driver on a certain Android device manufactured by a major hardware vendor that you've certainly heard of, and their driver silently corrupted video that was using low-latency streaming options. And by "corrupted" I mean that, while a few of the pixels looked almost right, sometimes, it was mostly just garbage and blank grey screens.

I gave them a sample stream that failed, and they verified that yes, it's their fault. And that no, they weren't going to ship an update for it. Sorry. Device had been out for two years. Apparently no one thought to actually test the various standard options in that video codec. It works with the "normal" options? Ship it!

So I totally understand the need to look at UA strings. I had to look for that particular device hardware profile and disable the low-latency streaming options in order for our product to work on that device.

That sort of feature detection is likely not sufficient for detecting if a video will play well or correctly. There's been a number of bugs in MSE in the past which means that YouTube has to fall back on browser version checks to avoid a bad user experience.

To be fair, a certain school of thought would say that those bugs are the browser's to fix, and that websites should deliver the browser whichever video it claims to support. If the browser advertises support for something it doesn't support, then it is up to browser developers (not web developers) to fix either the support or the advertisement thereof.

Edit: Not saying that's always correct, but there does seem to be a tension between: "make sure your code can work well, even in a bad environment" and "don't mask bugs, instead fix them where it makes the most sense to do so" (in this case: in the dozens of browsers instead of in millions of websites).

Another school of thought is that it doesn't matter if it's the responsibility of the browser because the customer perception will be that your website does not work for them.

If a mechanism exists to prevent your customer from perceiving this, as a business the smart decision is going to be to use it.

Partly true, because if they try with another browser and get a good result they'll blame the browser and not the website. In this case, they'll probably say the the new Firefox broke YouTube. See one of the comments at www.pclinuxos.com/forum/index.php?topic=135323.0

"i'm getting a lot of corrupt unsupported browser when accessing video on other sites, so i'm using chrome. i can't figure out if it's flash or firefox but i'm tired of opening the hood, i'm done with FF for now"

Most of them looked for a workaround and spoofed the user agent, but they are the kind of people that fiddle with settings. Normal users probably either don't notice or change browser.

YouTube's compatibility hacks are against buggy versions of browsers. Regardless of whether a bug is eventually fixed, once it is released, there is some segment of the user base that has it. If that segment is large enough, and the bug easy enough to hack around, then YouTube will provide a workaround rather than lose revenue.

Sounds like the ultimate solution here is to just give browsers a killswitch, so they'll eventually just stop working if you don't keep them up-to-date. (I'm not sure whether I'm joking.)

While you're right that it's up to the browser to fix, that can be a very time consuming process (especially for something as tricky as video). YouTube doesn't want to wait around for browser vendors to fix things, so they work around it themselves (just like happened in the opposite direction for this bug).

Finding workarounds for browser bugs is a common theme for the work that web developers do. Yes, browser vendors should fix the bugs, but in the meantime, there's no reason to have a bad user experience.