Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

The First Problem

January 18th, 2011 by Multimedia Mike

A few years ago, The Linux Hater made the following poignant observation regarding Linux driver support:

Drivers are only just the beginning… But for some reason y’all like to focus on the drivers. You know why lusers do that? Because it just happens to be the problem that people notice first.

And so it is with the HTML5 video codec debate, re-invigorated in the past week by Google’s announcement of dropping native H.264 support in their own HTML5 video tag implementation. As I read up on the fiery debate, I kept wondering why people are so obsessed with this issue. Then I remembered the Linux Hater’s post and realized that the video codec issue is simply the first problem that most people notice regarding HTML5 video.

I appreciate that the video codec debate has prompted Niedermayer to post on his blog once more. Otherwise, I’m just munching popcorn on the sidelines, amused and mildly relieved that the various factions are vociferously attacking each other rather than that little project I help with at work.

Getting back to the “first problem” aspect– there’s so much emphasis on the video codec; I wonder why no one ever, ever mentions word one about an audio codec. AAC is typically the codec that pairs with H.264 in the MPEG stack. Dark Shikari once mentioned that “AAC’s licensing terms are exponentially more onerous than H.264′s. If Google didn’t want to use H.264, they would sure as hell not want to use AAC.” Most people are probably using “H.264″ to refer to the entire MPEG/H.264/AAC stack, even if they probably don’t understand what all of those pieces mean.

Anyway, The Linux Hater’s driver piece continues:

Once y’all have drivers, the fight will move to the next layer up. And like I said, it’s a lot harder at that layer.

A few months ago, when I wanted to post the WebM output of my new VP8 encoder and thought it would be a nice touch to deliver it via a video tag, I ignored the video codec problem (just encoded a VP8/WebM file) only to immediately discover a problem at a different layer– specifically, embedding a file using a video tag triggers a full file download when the page is loaded, which is unacceptable from end user and web hosting perspectives. This is a known issue but doesn’t get as much attention, I guess because there are bigger problems to solve first (c.f. video codec issue).

For other issues, check out the YouTube blog’s HTML5 post or Hulu’s post that also commented on HTML5. Issues such as video streaming flexibility, content protection, fullscreen video, webcam/microphone input, and numerous others are rarely mentioned in the debates. Only “video codec” is of paramount importance.

But I’m lending too much weight to the cacophony of a largely uninformed internet debate. Realistically, I know there are many talented engineers down in the trenches working to solve at least some of these problems. To tie this in with the Linux driver example, I’m consistently stunned these days regarding how simple it is to get Linux working on a new computer– most commodity consumer hardware really does just work right out of the box. Maybe one day, we’ll wake up and find that HTML5 video has advanced to the point that it solves all of the relevant problems to make it the simple and obvious choice for delivering web video in nearly all situations.

It won’t be this year.

Posted in HTML5 | 4 Comments »

4 Responses

  1. Martin Storsjö Says:

    As you say, almost all of the debate seems to be about what codec to use, as if that were the only question. Codecs aside, there doesn’t seem to be much (public) discussion on how to handle proper streaming (aka realtime, live). Apple are the only ones with at least something in place, which does work, but isn’t really usable for the really-low-latency scenarios. There was some discussion around October (I think) about something similar for the WebM family, too (don’t remember where, a quick google didn’t find it for me), but it’s not at all that well-known to the average joe online commenting and discussing these issues. Sure you can stream WebM right over HTTP without anything fancy, too – but last summer, that worked quite ok on Opera, worked sometimes if you were lucky on Firefox, and didn’t work at all on Chrome…

  2. Atrawog Says:

    What seems to get very little attention is that we where close to a great video codec schism within the wider Open Something community. With Chrome, Chromium, Firefox, Flash, Linux, Android, Theora, YouToube, Wikipedia, Archive.org going into different directions.

    With opening up WebM and dropping H.264 Google has set a direction everybody within the Open Something community is pretty happy about and everybody will switch to WebM pretty fast after the WebM specification dust has settled.

  3. SriNaam Says:

    Dude,

    you don’t get it. They do not want people to be able to bypass the ads/insecurities and watch the videos. Proof: youtube could give an URL with the location of the video so those who don’t want to use flash will see it.

    Not only it doesn’t but also changes the youtube API every now and then to break automatic downloaders and they killed pwnyoutube.com.

    In this spirit, the HTML5 circa is just a way to avoid the critisisms and say “yeah flash is bad, but we are working on it with HTML5″. It’s not meant to be solved nor ready soon…

    pingback for next year

  4. cdman Says:

    I know I’m coming a little late to the party, but here are my $0.02: browsers should only download the embedded video if “autobuffer” is set on them, as per http://hacks.mozilla.org/2009/12/autobuffering-video-in-firefox/

    Also, I’ve read somewhere that with proper support from the HTTP server (ie. support for the byte-range header), the download will be minimal (ie. it will use it to find the end of the video file, rather than downloading the whole file).

    Best regards.

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.