YouTube fails to deliver on HTML5 promises

The vote for YouTube to support HTML5 with open video formats was a huge success.

Right now, the "Support HTML5 open web video with open formats" option has more than 12 000 votes, whereas the most popular request that is unrelated to HTML5 has about 5 000 votes. The HTML5 requests were so popular that YouTube had to hide them to give other options a chance to be seen:

We've heard a lot of feedback around supporting HTML5 and are working hard to meet your request, so stay tuned. We'll be following up when we have more information. We're answering this idea now because there are so many similar HTML5 ideas and we want to give other ideas a chance to be seen.

However… …

Yesterday, YouTube's blog was updated with news on HTML5. They explained that the number one request was "that YouTube do more with HTML5", and as a "response", they pointed to their existing experimental HTML5 page which only supports H.264 encoded video

Sadly, it seems that YouTube has failed to deliver on the most popular requests, despite claims to the contrary in their blog. Their enthusiastic words about HTML5 as an open standard decidedly ring hollow when you are required to use a closed, proprietary format to view video in the first place.

Come on, YouTube (and Google!), you can do better than that! Show us that you can walk the walk and not just talk the talk when it comes to open standards.

Advertisements

55 thoughts on “YouTube fails to deliver on HTML5 promises

  1. Originally posted by ouzoWTF:

    And they were.

    Oh, I thought they where removed entirely. Guess not. But, voting is no longer…

  2. Originally posted by usatonycuba:

    Originally posted by Chris DiBona:

    ..If [YouTube] were to switch to theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the Internet…

    Claims like these without demanding substantiation, are just unfair and unreasonable. Cuz Theora is competitive and even superior to some of the files that Google is distributing today on YouTube.. So?

    Go to tinyvid.tv (ogg-based video sharing site) and download, say, a 720p movie trailer. Then go to YouTube, download the same 720p trailer. Compare them closely. Then use a program like MediaInfo to check the video bitrate of each trailer, or just look at the file size though the audio component would distort that figure. Personally I've found the tinyvid.tv videos to be lower quality, though I see some issues with color that lead me to believe they are doing something wrong on their end. Besides that, I've found the tinyvid.tv videos to use bitrates 2-2.5x as high as those from YouTube for same-resolution videos. I don't know if that would cripple the internet (I doubt it) but it does make for a significant increase in storage required; and bandwidth on both the part of YouTube and the person viewing the video.I do agree though that YouTube can generate some really poor h.264 videos. Last I new they were using something like an 800th revision x264 and the current version is somewhere around the 1400th revision with several HUGE quality (VAQ, Psy-RD, and MB-tree being three of the biggest) and speed improvements in the intermittent period.

  3. Originally posted by hellspork:

    So there are patents on the method itself? Not just the proprietary code, but the very nature of its output? So all of these other codecs are differently coded implementations of one method, and must all pay royalties? In this case, if one must pay royalties no matter what, which implementation is more efficient or affordable? DivX looks like one winner, with its relatively broad adoption in home electronics. Vanilla MPEG-4 also has strong support, though more in handheld media players.

    So yeah, the patents are on the general methods of encoding and decoding but not on the specific code to encode or decode. An analogy might be like an art teacher saying his/her students can only use certain tools to make a piece of art and the students might produce art of varying quality but all conform to the teacher's requirements. That's why mpeg2 encoders have been able to marginally improve over time and why Theora looks better than the VP3 it is derived from.x264, the new DivX encoder, Ateme, and other h.264 encoders are all different implementations of encoding h.264 and pay royalties. So far as that goes, x264 is the most affordable and fastest (and likely the highest quality encoder though Ateme may be competitive).Decoders are what's implemented in home electronics and that's the bread and butter of DivX. They've done really well in partnering with different companies to get their decoder and label on products. In general though if a device says "DivX" on it, the video need not have been encoded with DivX as Xvid and others should work too so long as they use appropriate settings. DivX (the DivX before the new DivX HD) IS the same as vanilla mpeg-4, just that they require the video to have certain specific things within the standard, making the products that their decoder is present on a more specific target for people generating video.Similarly, more than one Theora encoder could be developed that fit within the standard, with better or worse quality than the one currently in development though if it's going to be done by the community they may as well just contribute to the current encoder. Neither x264 nor Theora are at the end of their development and both can improve. The problem is that because Theora only uses older technologies it will always be playing catch up. I don't mean to denigrate Theora by saying that though and there are things in x264 that could possibly be ported over to Theora without violating patents. They won't make it better than h.264 though and as I've stated before that's because of architectural limitations of the Theora standard.Addendum, I just came across this: https://trac.xiph.org/changeset/16812I'm not sure if this is like VAQ in x264 but it looks good for theora.

  4. Thanks, Dillon. This was exactly what I'd hoped you could cover in more detail. Makes a lot more sense now. Given the circumstance of a free browser, there must be some affordable option to include h.264-compliant code. After all, Flash is everywhere and free to the end-user. This moves the cost to the provider. Even fairly cheap media player hardware may decode MPEG-4, and the cost of h.264 playback continues to drop. I did not realize that x264 already WAS the youtube standard, thanks!The hope then, would be a very affordable volume client license. Possibly fast decoding could be implemented with GStreamer builds. I doubt Vega was built with the intent of hardware-accelerated video decoding, but I doubt there'd be any complaints from us if it did.

  5. Why would youtube think its a good idea to use a proprietary codec as a web standard? This only inhibits progress. I knew this would happen when google released its own browser. I call B.S. On google

Comments are closed.