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.
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
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.
Later: Your App Needs an Editor