Archive for June, 2012

Video on the Web – A 1953 Ford Pickup Truck

Wednesday, June 27th, 2012

… 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

photo of 2 rusty broken down 1953 F100 trucksSo….. 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!

One more round of video testing

Tuesday, June 19th, 2012

Many of you were very helpful when I asked to test a video a week or so ago. It was really a spontaneous thing with a video that wasn’t at all suited for the web. It had a bitrate about 100 times bigger than normal web bandwidth. Those of you who know I live in NY also know that we don’t have palm trees here. I was in a beautiful tropical area with only an Android tablet and no serious web development tools.

THANK YOU! I really appreciate all of your helpful comments. They gave me some leads into a more serious adventure.

Now, I’m back at home and come begging again. This time, more organized and for a very specific reason. Some of you might have seen that the great woodcarver,  Mary May, has plans for an online video woodcarving school. I’m helping wrestle through some of the geeky web aspects and am sorting out how to get videos to play in the widest ranges of browsers and devices. It sure is handy to carry a tablet computer to the workshop and watch instruction at the bench!

We will very much appreciate your help with video testing again. I’ve set up 4 test blogs to try different players and different formats. Please try as few or as many as you can and let us know how they work, or don’t. Please START HERE.

Now defunct.

Many of you responded. Your remarks helped tremendously, and we appreciate your help.



Liturgical Woodcarvings – Sámara Costa Rica

Saturday, June 9th, 2012

Sámara is a very small costal town on the Guanacoste peninsula of Costa Rica. Tourists are attracted to Sámara by a south facing protected cove on the Pacific which harbors modest surf, perfect for people learning to surf. An attraction even more important to some than the beautiful Pacific cove is a first rate Spanish language school that has a prominent spot right on the beach. Students ranging from college age through all adult ages make the school the center of the little town’s economy.

While in a gorgeous location, where the morning wake up call is a chorous of howler monkey “conversations” an delightful songs from sparkling yellow great kiskadees, the town is definitely not a “tony” tourist destination. It is a simple place where many of the 70 or so native families can trace their lineage to a family of 9 children (the “seven sisters” and 2 brothers) who settled and started the village about a century ago. Today, many of those families offer rooms for students at the school. There is little visible wealth, just a little town with one booming business, a few modest hotels and restaurants, a couple of grocery stores and laundries, and a lot of simple, practical housing. One of the reasons it is still small and relatively undiscovered is because it had no access by paved roads until only a few years ago. In fact many of the vehicles in town are rugged old land cruisers that date from the pre-paved roads era.

It is a simple place. There is little ornamention, except at the Catholic church. One can imagine that quite a collection must have been gathered to have the entrance doors decorated with carvings. An image of Jesus with a lamb decorates the door on the right, with Mary and infant on the door on the left. The carvings cover a large part of each door, probably 4 feet tall and are low relief. Whether one appreciates the style or not, one thing is readily apparent. In a place where there is scant evidence of artisan talent, or the wealth to afford artisan talent, these doors were carved by someone well practiced in carving. Note the crisp shadow lines, the well developed linen folds, and the background stipling. The work is on what appears to be oak or a very near relative.

In a place with little other ornamentation, these doors tell us the value people place on their church. The doors are special.







Sometimes it rains

Monday, June 4th, 2012