Slashdot Mirror
YouTube Hints At Support For Free/Open Formats With HTML5
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."
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
VLC generally supports acceleration when os/driver/card support exists
Climate Progress - Hell and High Water
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
Dilbert RSS feed
I would prefer "be less like vimeo" because the only difference between them that affects me is that the youtube player decodes video efficiently enough that my processor can handle it, and vimeo is a browser locking slideshow.
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)
}
-- http://embedded-computing.com/fujitsu-full-h-264-codecs
That's half a Watt encoding HD, a general purpose CPU would be consuming tens, or even a hundred watts to do that.
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
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
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
H264 Implementation: http://geekglue.blogspot.com/2008/12/google-native-client.html
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.