BMWs Suck

Back in the long, long ago; in the before time, I had a black BMW 325e, dubbed "The Goth Mobile" by my mates at the time. I'm sure you can probably suss out the approximate years of ownership ;-). I loved that car. It had great handling, good HP/torque, and a sunroof (novel at the time). It also had an amazing little trip computer that showed me my average speed, and MPG. It also warned me if the temps went below 36°F, as well when I went above a driver-set speed limit. I loved that car, until things went wrong.

BMW doesn't seem to make anything with a standard part. Even their emergency jacks are proprietary, and woefully difficult to use. They also have horrible electrical systems. That lovely ahead-of-its time trip computer? Yeah, if you didn't drive the car for a couple of weeks, you had a 50/50 chance of the battery being dead when you went to start it up. They're also *awful* in the snow. Germany has snow! How can they fuck this up?!

Fast forward to today. Bill's aging-but-very-low-milage (well under 30k) white BMW 328i convertible can't keep a battery for more than a year without needing to be replaced. Because of this, he doesn't drive it often. He purchased a trickle charger, but that doesn't seem to help too much. Sometimes the car will start, other times, not so much. Consequently, the air pressure in his tyres is low. I thought, OK, well, I'll jack up the car (I've got a shop jack that makes this super easy), remove the tyre, then get it filled at the station about a mile away — except that I can't get the damned wheel off the axle. Yes, I've removed the bolts ;-) It's been on there so long, the wheel is seised to the axle. I don't want to put WD40 on it, as that's a bad idea for MANY reasons (near the brakes, bolt threads, etc). Fuck it. We'll drive it to the station with low air pressure and hope for the best.

Grrr.

More later.

The State of HTML5 Video Sucks

Mirrored from Localtype.

Comments are open over there. Use your LJ ID to reply

I’m sure we all remember when video on the web meant installing a huge number of plugins in order to play a myriad of video formats. Plugins limited your audience to only those who could download the appropriate plugin. People behind corporate firewalls were often not permitted to download plugins, and plugins were browser and platform specific. Worst of all, installing plugins lead to browser instability. Back in those days, a rogue plugin could actually cause your entire system to crash. Video quality has improved immensely over the last 16 years, sadly, the technical requirements for delivering web video are just as daunting as they were back in the day.

HTML5 added the <video> tag, theoretically freeing us from using the current de facto standard for video playback, the notoriously crashy Adobe Flash. The reality is sadly, much different. Of all the major browsers, not one of them fully support the tag. Firefox and Chrome can only play HTML5 video if it uses the WebM codec, while IE and Safari will only play back H264-encoded video. This means that if you want to use only HTML 5 video, you have to encode twice. Conceptually, multiple encodings isn’t such a huge problem. There are fantastic encoders for H264. The WebM encoders in contrast, are pretty weak and difficult to insert into many existing workflows. Then there is the majority of desktop browsers in use that don’t support the tag at all.

When you throw mobile browsers into the mix, things get even more confusing. Most mobile browsers use Webkit, the open source browser platform on which Apple’s Safari and Google’s Chrome is based. This would be great, but different mobile devices support different profiles and aspects of the highly complex H264 codec, which means potentially more encoding for those devices.

Once you have all this encoding stuff worked out, you’re still faced with the reality of the browser implementation. From what I’ve observed, all the major browsers fail to properly buffer content. Inevitably, the buffer stops filling, and the video stops playing, with no way to force it to continue. Often, the playhead continues to move forward, even though the video is not playing. Full screen playback is also a problem, in that it often doesn’t work, or it has strange interface anomalies.

Some browsers don’t even properly follow the parameters passed in the <video> tag. Safari, for example, will automatically download the entire video when the web page is loaded, even if you explicitly set auto-buffering to ‘false’. That will cost both content providers and users for exceeding their data transfer caps.

It all falls back to Flash. The Flash plugin ships standard with most browsers, and has an installed base that is something in the high-ninty-percentile of desktop systems. The more recent versions of the Flash plugin can understand H264 encoded video, when called through the Flash interface. While the plugin is becoming more well behaved, it’s still crash-prone, and notoriously resource intensive. On mobile devices, Flash is still far from ubiquitous, and still unreliable.

So where does that leave us? Unfortunately, for content creators, it means a lot of extra work doing multiple encodings for each permutation of browser, and a huge chunk of HTML, Javascript, and CSS coding to get all of it to work. Luckily, there are some emerging solutions that help get all of this in order.

Video for Everybody is a simple chunk of HTML that will properly cascade a variety of video options based on the browser. It even properly substitutes an image for those browsers that don’t support the <video> tag, and it even works for those who have disabled javascript. It doesn’t however, offer any options like skinning, or fixes for the various browser deficiencies.

VideoJS takes Video for Everybody, and adds the ability to skin the HTML5 player and javascript to fix browser deficiencies such as the auto-buffering bug in Safari. It also incorporates Flow Player, the freely available Flash video player which references the H264 video as a fallback. There are other HTML5 drop-in solutions, but VideoJS seems to be the least buggy.

So this is what I’m doing: I’m using a VideoJS Pro plugin for WordPress, but I am only encoding H264 video, as I can’t find a WebM encoder that will fit into my current workflow. Right now, I am only encoding a single video profile which works on the iPad, IE9, and Safari on the desktop, while the Flash fallback will be shown in Firefox, and Chrome. In the future, I will create reference movies in H264, so iPhones, and those with lower bandwidth will still be able to play back the video. I don’t foresee encoding into WebM until the codec can be integrated into my workflow. By then, I expect to see H265 to be in common use.