Video on the Web – A 1953 Ford Pickup Truck

… with 4 different sized wheels.

* 1953 because function is so primitive
* 4 different sized wheels because stubborn browser developers can’t agree upon common formats.

Yes, this is a rant … by a recovering web purist. (1)

Before I rant, a HUGE THANK YOU to a great group of folks who answered the plea in the previous post and tested a series of videos for us. They proved we were making progress with all sorts of PCs, tablets, and even some phones. THANK YOU Patrick Anderson, Brander “Badger” Roullett, David Taylor, Daniel in Austrailia, Steve Longley, Kevin Wilkinson, Marge, Doug F., Rick Hayhoe, Jim Marsh, and Shannon Rogers.

The 1953 Ford pickup truck

So….. what’s wrong with video on the web? It would be easier to answer what’s not wrong.

It has about as much function as that ole 1953 truck. Just play. No fast forward, no rewind, no slow motion, full screen works sometimes, sometimes not, just like the windshield wipers.

OK, OK, I get it that some of those things need complex encoding and require lots of bandwidth and more vacuum than the engine produces. We’ll suffer some inconvenience in the name of slow networks and constrained bandwidth. Right?

Hey, have you noticed how fast networks are running these days? (hint: Google “dark fiber”)

Flash – R.I.P.

As a little preface, the best way I know to describe Flash to woodcarvers, especially traditional / classic woodcarvers, is to think of Flash as a Dremel tool. ‘Nuf said?!

Steve Jobs killed Flash (2) … and for purists, that’s a very good thing. Oooops, almost forgot; I’m a recovering purist. Well, in reality, I’m just someone wanting to make a decent video-centric web site and am da*ned irritated with the state of web video affairs.

The first 4 versions of HTML had no special accommodation for video. We survived 20 years of cramming inefficient arcane bulky (and balky) code into a nondescript container called an “object” and then duplicating it in a container called “embed.” Along with the bulky code came clunky slow running players and equally inefficiently encoded video data. We put up with duplicating code in both “object” and “embed” containers because 2 browser developer were at war for world domination and neither would yield to a common standard. We put up with Flash and all of its energy sucking inefficiency because Adobe (nee Macromedia) managed to get the plugin bundled “free” with virtually every browser on the planet. Flash gained dominance and still holds dominance in certain ways.

The dominance started to crumble about 10 years ago with the emergence of a “better” encoding technology, H.264. Coincidentally, some web standards purists started lobbying for a real “video” container in HTML. It would be a lot more flexible than either “object” or “embed” and a whale of a lot more efficient. Long story short, HTML5 has a video container and we’re all happy. Right?

BZZZZZZT!!! The new found video container offered browser developers a path for building video players right into the browsers. No more plugin video players!!! No more waiting for player shells to download!!! Fast, quick, wam, bam!!! … and we’re all happy. Right? All we need are some simple “video” statements and video material comes screaming out through built-in video players. Eureka!

BZZZZZZT!!! Guess what the browser developers can’t agree upon? That’s right, encoding methods. Some like H.264. After all, there are now hardware co-processors that ecode H.264, making things easy for some developers. Yet, others are concerned that H.264 is patent encumbered and the patent holder really is collecting royalties. Two of those developers want a patent free encoding method and and have chosen two completely different encoding methods (WebM and OGG).

There goes the idea of easily playing video. If we want to play videos in the native players built into the latest browsers, we need at least 4 versions of each video, one for each of the stubborn browser variants (mp4, webM, ogg) and a Flash version (still!) to fall back to for the older browsers that people (one of my younger brothers, for example) still have on their old feeble computers.

But still, those built-in players alleviate downloading all sorts of other players, and really streamline video delivery. Right?

BZZZZZZT!!! Try playing H.246, mp4 files, encoded as “Baseline” (the very simplest) on my Samsung Galaxy 10.1 tablet (OS=Honeycomb). When the player isn’t stalling and sputtering, it crashes in the middle of a video. We tried videos coded at high bitrates, which re-buffered every 30 seconds, videos with moderate bitrates which really stuttered during re-buffering, and videos with low bitrates that played OK but crashed when their buffer space was filled before playback consumed the content. However, abandoning purity and playing those very same videos (all 3 bitrates) in Flash mode with JW Player worked perfectly.

OK. Be a purist and encode in 4 different versions, OR… wait for it… encode only ONE version nicely in H.264 mp4 format and distribute it with JW Player which will wrap it in Flash and play it on almost anything but iPads, and will intelligently serve the raw mp4 file to the iPads, iPhones, and MacBooks.

So there, Mr Jobs! The dreadful Flash is dead … but it’s going to hang around for a very long time.

Have you ever seen a business cycle “S-curve?” It talks to the cycle of innovation, how the next generation replaces the previous, sometimes very slowly. The S-curve cycle is directly relevant to what’s happening with web video. Casual reading here.

OK, rant ends. —–=====*****=====—–

1. Let’s explain “purist.”

My 40 years of computer engineering gave me many opportunities for honing high skills. I was incredibly fortunate in spending my last fifteen years in IBM’s highly regarded Research division. There, I had access to the brand new ‘world wide web’ thingy way back in 1992 (go check the date of HTML1). I merely followed that interest for a few years, but got more deeply involved over time. I ended up developing world class skills in 2 areas: HTML / CSS, and Accessibility (enabling technology for people with disabilities). My interest in both of those areas, the skills I built, and the place I worked all came together so that I ended up directly on standards committees, or working directly with colleagues who were on standards committees for web and accessibility technologies.

There are two sorts of people on standards committees, those who have ideas about “the right way” of doing things (the purists), and those who are representing a business interest that wants “their way” adopted as the standard. For the areas where I was engaged, IBM didn’t have a “my way” interest. I was there as the purist.

Been there! I’ve seen how the standards are made, how the compromises are arrived at, and how agonizingly long it take for new technology to develop, be agreed upon, be embodied in a standard, be implemented in the real world (first with a lot of interpretation errors, then with corrections (1a)), and actually become common.

1a. Early in the life of new standards, interpretation errors are often made. The unfortunate reality of these errors is that they hang around for a —very— long time.
For example, a bug in Apple’s iOS version 3 (first iPad) prevents a video from being played if there is a “poster” image included in the HTML5 video container. (fixed in iOS4) The “poster” is the still image that is displayed when the player first appears. We like posters because they provide extra visual information about the content. So we really like including them.

The dream of most coders is to have a single block of code serve the most clients. Yet, bugs like this crash that dream. Include the poster and millions of early iPads fail to show the video. Remove the poster, for the sake of “backward compatibility,” and punish all the other millions of browsers that get it right. Which leads to using patches, bandages, and tourniquets (or increasingly complex <script>s) to make up for early injuries that take forever to cycle out of the universe.

2. Steve Jobs killed Flash!

Well, not directly, but he effectively engineered the death blow. Walter Isaacson tells us in his biography about Jobs that 1999 was the year Jobs wanted to tie video cameras and computers tightly together with Firewire connectivity. One of the things he needed was good video editing software. He approached his “old friends” at Adobe and asked them to make a version of Adobe Premiere for the Mac. They refused, saying the Mac market wasn’t big enough. Jobs went furious, which he apparently did several times a day anyway. He settled the score by forbidding Flash on the iPad. Condemning an already dying technology by forbidding it on one of the most popular devices on the planet is a great way to kill it. Ding-dong the witch is dead! (but not really; we still need it for my little brother’s ancient computer.)

Long live the 1953 Ford pickup truck!