Bruce Lawson's personal site

What are the business benefits of HTML5 video?

My hubcap-thieving Scally chum Jake Smith emailed, expressing concern about the the fact that the codec impasse means we have to encode video twice, once as Ogg and once as H264 to deliver in HTML5:

My concern is from that of a business. Encoding as OGG will only further questions from clients, rather than answering them. “So, this video you’re encoding… I can’t watch it on my Mac (safari)? And I still can’t see it on my iPhone?”

There’s the obvious “be damned with licenses” and encode as MP4 anyway, but then I have to encode twice, which is ok for the odd video, but could be a right arse long term, as that’s more cost to client, and as far as they’re concerned why not pay once for encoding to FLV?

From my (business) point of view, there is no point in chasing HTML5 for video. No matter how much I want to do the right thing…

I’ve only worked for quasi-public sector sites for whom profit isn’t an imperative, and I’ve been absorbed thinking about open-ness and standards, so hadn’t given Jake’s perspective much thought.

To me, the negatives are:

The advantages to using open HTML5 video are

Any one care to wade in with some business reasons for or against double-encoding and using HTML5 video?

15 Responses to “ What are the business benefits of HTML5 video? ”

Comment by kl

For Flash you’d encode (and have to pay for) H.264 anyway. Old Flash codecs, with their poor size/quality ratio don’t make much sense either.

Encoding of Theora is fast. You’ll have off version before H.264 encoder even warms up.

Comment by Tom Leadbetter

I agree with Jake’s concerns.

That “Sublime” video is a perfect example. I’d heard about it using the video tag and that it was awesome, sorry Bruce, I mean, “super”. I visited it in Firefox and it didn’t work. That’s bollocks to be honest.

HTML5 seems to be arriving faster than I thought it would and browsers are running along it with but the video encoding issue needs to be addressed.

If HTML5 was right here, right now, I would deliver a video in Flash.

Double-encoding to meet the requirements of the browser and the video tag is no different from having to use conditional comments and hacks. Yes, it gets the job done but we don’t like it and we quite rightly bitch about it. It would be nice we could avoid some bullshit for once.

Comment by Rob Larsen

The double encoding will be a non-starter in an agency environment. I can’t imagine many places where it would be acceptable, but considering the number of revisions (and time spent in the media lab, doing compression) we used to go through at my (video heavy) last job, there’s no way in hell we would have done anything to ADD complexity to that process.

And THEN to pay double for storage with a CDN? Nope. Not going to happen. With the competing codecs, the video element is a novelty.

Sadly, FLV wins, no matter how much of a pain in the ass it can be to deal with*

*ymmv

Comment by Jake Smith

Thanks for posting this Bruce, makes for great discussion.

I have a few points to add.

@kl
You say Theora codec is quick at compression, yet OGG does not have any supporting hardware for compression or playback. While h264 maybe slow to compress for you via software, any serious users will be working with h264 accelerated hardware.

To be really cantankerous and say OGG does not matter (something I do not believe, by the way, I’m just throwing this out there…) I could simply code ONLY for h264 (with hardware acceleration, quicker) deliver the h264 file via HTML5 to supporting browsers, then dish up a Flash video stream for browsers that don’t support OGG. Flash can point at the exact same h264 .mp4 file as is being sent to the HTML5 page, so I only have to encode once… I must note I’ve not done this, but in theory it should work.

And if we look ahead and follow the curve of browsing and the explosion of the mobile web, both the iPhone and Google Android provide hardware playback acceleration for h264 content. Again, there are no hardware accelerators for OGG, which makes me think it will not take off full stop.

Whaddya think?

Comment by Codesquid

If we’re talking business, then the sad fact is that most people browse the web with some version of internet explorer, and none support the HTML5 video tag. No business in their right mind is going to want to exclude most of the market from viewing their content. Moving to html5 video is the right thing to do, but it’s going to have to be a gradual process.

Comment by Bruce

@John Dowdell

I disagree that there is no such thing as html5 video. There is, in html5, a native video element, with an API defined that allows scripting of controls etc.

Comment by Divya

My only concern with all the advantages mentioned is that there is a lot of “eventually” there. I am definitely all for standards compliance, but the video element does not seem to have standardized yet, with no agreement on an open codec. I fear, this will lead to yet another silo-ridden system with JavaScript hacks to work around the multiple codec system.

Definitely Flash is not the best out there, but I think now is definitely not the time to deploy video elements to production-ready sites. In a year or two, I am sure we will have more developments, who knows, even Adobe might start supporting the video element in its flash browser plugin!

Comment by Dan

From a technical standpoint H.264 is probably the better choice for reasons already outlined above. But the big problem is the licensing. HTML has always been “free for all” and i’d like it to stay that way. So IMO you can’t force people to pay royalties for a patent all of a sudden.

That’s like inviting someone into your house and then charging them when they want to leave again. With Wikipedia behind Theora the future is wide open.

Personally, i plan to use video on the web this way for now: http://camendesign.com/code/video_for_everybody

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.