YouTube Hints At Support For Free/Open Formats With HTML5 133
shadowmage13 writes "After the recent post about YouTube, so many votes were put in for HTML5 using Free and Open formats that Google has already cleared them all out (to make space for others) and issued an official response (requires Google login): '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.' Now all the top ideas are concerning copyright and DMCA abuse."
Re:is html5 going to provide faster better video? (Score:5, Informative)
Video tags are easier to accelerate. They can be handled by just about anything. That means rather than being locked to Flash, it can be played with Xine/GStreamer on Linux, Quicktime on OSX, DirectShow on Windows, DSP codecs on your phone, etc.; it might also be possible to use VLC on any platform, although that defeats the "accelerate" part.
And of course, you've always got Flash as a fallback.
P.S. Posted before, but this might be of interest to someone: Javascript-free HTML5/Flash video embedding, which works on desktops as well as devices like the iPhone: http://camendesign.com/code/video_for_everybody [camendesign.com]
Re:is html5 going to provide faster better video? (Score:5, Informative)
VLC generally supports acceleration when os/driver/card support exists
Re:Can we dump flash now? (Score:5, Informative)
If you use Firefox, have you tried some greasemonkey script that replace the Flash player with an embedded version? Like http://userscripts.org/scripts/show/46219 [userscripts.org]
Re:Well then... (Score:5, Informative)
Re:Google's purchase of On2 (Score:3, Informative)
OGG Theora is based on On2 VP3.
On2 VP8 is a much better codec than VP3 ever was.
You always could. (Score:4, Informative)
If you use zsh:
youplayer () {
mplayer "http://youtube.com/get_video?"${${${"$(wget -o/dev/null -O- "${1}" | grep -e watch_fullscreen)"}##*watch_fullscreen\?}%%\&fs=*}
}
If not:
youplayer() {
mplayer $(youtube-dl -g $1)
}
Re:is html5 going to provide faster better video? (Score:3, Informative)
Most users *absolutely* do care about having hardware decoding – on their cell phone.
Re:is html5 going to provide faster better video? (Score:5, Informative)
-- http://embedded-computing.com/fujitsu-full-h-264-codecs [embedded-computing.com]
That's half a Watt encoding HD, a general purpose CPU would be consuming tens, or even a hundred watts to do that.
Re:Well then... (Score:3, Informative)
There are many reasons why this is happening:
1. ACTA agreement and license fees are up for renewal.
http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx [mpegla.com]
All OEM product makers and content encoders are now waiting on the 2010 agreement from the mpegla licensing aggregation company . It will be stiff fees apparently, although not confirmed yet. What is even stranger is that we are now in 2010, and they have still not released the new licensing terms. Very weird; What are they waiting on i wonder ? Maybe ACTA resolution ?
Most China OEMS don't pay the fees, and hence why ACTA is being "negotiated" so secretly also.
http://www.eetasia.com/login.do?fromWhere=/ART_8800463180_499501_NT_5bb04467.HTM [eetasia.com]
So this is a "double whammy" waiting to explode.
2. There are many other codecs around to choose from and why not test the water for others.
There is much discussion in this area. But its a chicken and Egg game.
You can make a fantastic codec, but you gotta have GPU support, otherwise its pointless.
See below for how this can happen in the Long Tail version.
3. Google knows that its Chrome OS is reaching a tipping point where they need to decide how they will handle video - they need to resolve this and get their ducks in a row.
They can do flash on ARM CPU now, but i am sure they wish they did not have to.
And they also know that with JavaScript and HTML% coming through like a train, Flash days are definitely numbered. See Sproutcore JavaScript framework for example of one of the many "flash replacements".
And they have OpenGL covered with O3D and WebGl also moving forward very fast now with working implementations and even content conversion thinks to the Collada Open 3d format specification not fully entrenched.
they can do NACL (NativeClient), and have already implemented a NACL c language h264 decoder. This was one of the first libraries they did !!
Native Client FAQ: http://code.google.com/p/nativeclient/wiki/FAQ [google.com]
H264 Implementation: http://geekglue.blogspot.com/2008/12/google-native-client.html [blogspot.com]
So the cards on the table are all congealing based on the above factors, and its a good time for Google to see where the cards fall for them and their various business models.
So, why not ask the users too.
I think it will come down to the h264 licensing terms to be released, and the ability for GPU's and embedded GPUs to handle video decoding.
Re:Can we dump flash now? (Score:3, Informative)
YouTube HTML5-ifier: https://chrome.google.com/extensions/detail/kchoimdlcbapmcdnheaahjcdpdjdpfco [google.com]
Re:is html5 going to provide faster better video? (Score:3, Informative)
Can you explain why it would be a mistake? If we were to assume for a second that performance on the client end would be exactly the same, then what would be the mistake in using standards instead of a proprietary stuff?
But anyway, it will provide some benefits. They're already encoding all their video in h264, but they're using Flash as the player, which is pretty inefficient. For one thing, Flash means no hardware decoding. Also, Flash itself can be a bit of a resource hog. Providing the same video stream but allowing the browser to hand it off to a better decoder will be much better.
Re:is html5 going to provide faster better video? (Score:2, Informative)
That's half a Watt encoding HD, a general purpose CPU would be consuming tens, or even a hundred watts to do that.
They wouldn't have to put that into the youtube web-servers, because, as you said later in your post, they'd only have to do it once. They would certainly pre-encode all the videos and put them on storage somewhere (cloudy place).
Also: noone forces them to use an embedded device, even if the chip was specifically made for use in such.
Re:is html5 going to provide faster better video? (Score:3, Informative)
Actually, accelerating Theora is high on our priority list due to it being one of the few codecs that Redhat can sponsor and ship.
We have no plans to add h.264 acceleration to any GPU driver at the moment, although patches are welcome.
The hardware can decode h.263 (Theora) just as well as it can decode h.264.
Re:is html5 going to provide faster better video? (Score:3, Informative)
When open-source video drivers begin to get video acceleration for modern formats, Theora will be first on the list due to Redhat's endorsement. h.264 will not be supported in default builds on many distros.
Additionally, if you're using fglrx, you aren't getting video acceleration (fglrx doesn't support it using the standard APIs) so it doesn't matter which codec you use.
Oh, and Android has Vorbis support out-of-the-box. I don't think we lost, not at all. :3