Okay, this news hit my inbox and the OSNews queue this morning (and another ten million times during the day) but since I was doing more important things than OSNews today, I only now have the time to dive into this. A site I’ve never heard before claims that Google will open source the VP8 video codec next month, providing the world with a high-quality, royalty and patent-free codec, which will most likely cause the internet to spontaneously start farting unicorns.
Google acquired On2 last year, the company behind VP3, the technology that would eventually become Theora. On2 claimed that VP8 would be vastly superior to H264, so when Google acquired the company, people started hoping that they would open source VP8, delivering a patent-free open source codec that would surpass H264 in every way. It’s only a rumour at this point, and I can’t vouch for the site in any way. We’ll have to see how this unravels.
The rumour also states that Firefox will include support for the codec, instantly covering most of the HTML5-capable browsers available. Opera will surely follow soon (they prefer open standards too), so the question will be what Apple and Microsoft will do.
My hope is that alongside the announcement of the open source codec, Google will announce that the HTML5 version of YouTube will use the new codec, forgoing H264 altogether. Browsers not capable of VP8 would then be served the Flash version, which would hopefully force Microsoft and Apple into adopting VP8 as well. It would be a perfect way for Google to slap Apple in the face for suing HTC.
Time will tell. Everything that helps to prevent the prospect of a web shackled to yet another proprietary and patented-up-the-wazzoo technology is welcome, and Google holds the trump card here: YouTube.
This won’t be a fast thing. Tools need to be written/improved and a lot of code needs to be written (DSP code for phone SOCs preferably)
Google is in this for the long run. H264 will be there for a long time, but maybe the 1080p versions of videos will be VP8 next year, maybe later. That would give software and hardware vendors an incentive to implement the free codec as an added feature.
Eventually all videos could be VP8 and h264 be just declared lecacy like RealVideo now. But that is a long long way still to go .. my guess is 2016 at best, maybe 2020.
I agree and from what ive read about vp8 “it was designed with arm in mind” “On2 cooperated closely with chip maker ARM on the development of VP8” I’m confused after reading that google will fund ogg/theora/vp3 on the ARM platform whats the point when vp8 is technically superior and already has these features?
Edited 2010-04-13 18:45 UTC
Maybe Google is looking to merge Theora with VP8? Who knows? Since Xiph hasn’t been unsuccessful with VP3, maybe they could do wonders with a more modern codec backed by Google and an ironclad patent pledge.
being that theora is based on an earlier codec from on2. google could just drop the code and then theora would be better than h.264 overnight.
VP8 is not the same codec as VP3. If Google were to open source VP8, implementations of it would not be called Theora, but something else.
Google is just funding everything, so whatever happens they will be covered. Look at Chrome: they’re improving Flash support and promoting HTML5 at the same time.
Because there are already integer based decoders for both vorbis and theora. i.e. no floating point co-processor is needed to decode them.
Not sure if such a thing exists yet for VP8…
I have never heard about the same site, but I’ve seen the news on ArsTechnica !
I still need Google to confirm the opening of code.
And 1 month is a long period
Ars uses the same source.
I can’t vouch in any way if their sources are reliable, but I’ve read NewTeeVee on and off over several years, so at least they’re not just some overnight rumour mill.
If Google wanted to be Funny, and vengeful. I’d suggest wording the license to allow for an implementation on any software/hardware platform as long as it was not written with the iphone SDK.
Why should they open the source, make gifts and all? They payed a nice amount of money for On2.
Goodwill, independence, control over the technical course of a ubiquitous codec. Google needs an open web to serve as many ads as they can. They probably have their reasons if they do what the rumor says.
That’s why I asked. It’s a rumor until someone from Google says otherwise.
Thats why I gave some reasons they might open source it. It might be worth more open than closed.
So why have they moved closer to Flash in the past few years?
Because in the last years there was no alternative?
Google has to do something, to not loose or simply take market share.
Google definatly has the resources to do this and even smaller companies, like Sun has given a lot of stuff away. Mostly their own, but they still had to pay a lot for development. Oh and open sourcing doesn’t really mean giving it away. If Google wants to HTML5 video tags they invest into it and that’s what they do, if the rumour is true. Also the Firefox stuff could be true, because Firefox is open source and why not develop something for them so they are more likely to include it (soon)?
However it’s just a rumour and we don’t know what Google wants, but it wouldn’t be the first time they invest into open source
Last, but not least: Would the investment make any sense, if they don’t use it or what do you think they are going to use VP8 for?
Edited 2010-04-14 11:06 UTC
So why have they moved closer to Flash in the past few years?
One word? Ubiquity.
Realization: Maybe I should have not used the word open. I should have used low barriers for access.
Edited 2010-04-14 11:11 UTC
First of all, YouTube was always Flash-based, because at the time there was no alternative with the same installed base.
As for their recent decision to bundle Flash with Chrome: the way I see it, Flash is one of the keys to their strategy. If they can get Flash support for VP8, it will be a whole lot easier getting VP8 universally accepted.
Also note that Adobe can only gain by the decision to support VP8. They don’t want to be rendered hopelessly irrelevant when H.264 ceases to be the preferred format.
Edited 2010-04-14 18:31 UTC
It benefits them in the long run to not have to use theora on youtube.
This is a great read…
http://x264dev.multimedia.cx/?p=292
Wow, 6 thumbs up for a link to a site that has already been cited 54 times prior on OSNews alone?
http://www.google.com/search?hl=en&q=site%3Awww.osnews.com+http…
Edited 2010-04-13 21:13 UTC
The Interwebs has no memory. This stuff needs to be re-explained in every thread.
many thanks for sharing this link. though I don’t understand all the details in video, encoding etc. Still its an excellent article.
as for Google opening up VP8 (still a rumour), it will only benefit all (including Google) I hope and Theora too.
That is a good read. So apparently two big problems with the codec that Google is going to open source is that it’s proprietary and they charge fees? I think those problems may well be cleared up quite quickly. I think they have the resources to fix encoder bugs too.
On the quality front, he’s basically admitting VP8 is going to beat H.264 which I was skeptical of at first, since the main source for that claim was On2 themselves. Coming from a competitor that’s a pretty good review.
Apparently if you take every large computer media company (Adobe, Apple etc.) and a bunch of commercial encoder specialists (e.g. Mainconcept) all competing in the marketplace, working on an ISO spec, chock-full of 900 patents and you put them up against a single beleaguered, also-ran, proprietary codec producer then they will all be beaten (Apple and Adobe) or “nearly” matched (Mainconcept). And that’s despite the encoder not (yet) being tuned for psycho-visual optimizations?
And assuming it’s BSD-licensed they can just adopt it into their products as-is, for free.
Isn’t that worrying for H.264 fans?
Edited 2010-04-14 11:00 UTC
Isn’t that worrying for H.264 fans?
I’d say very, very worrying. Judging by the monumental backlash against even suggesting “ancient” VP3 Theora as an alternative, VP8 is probably akin a nuclear strike.
If VP3 or VP8 was completely ridiculous as an alternative, H.264 proponents would have laughed very heartily, whished the VP3/VP8 crowd good luck and then turned away to silently work on progressing the roll-out of the H.264 infrastructure. They didn’t. They brought pitchforks and torches and started screaming “The Pixels! The Pixels!”.
In my book that speaks to the merits of the alternative most of the time.
He isn’t basically admitting anything. He said that the early H.264 encoders were crap. However, now that they have matured (especially x264), the file size improvements that were to be gained from using VP8 aren’t there anymore. You should re-read the Addendum.
No, he says VP7 beat all early H.264 encoders (“dramatically better” than most of them) in the first half of the decade. That much is plainly stated and based on something like fact rather than supposition.
“VP7 was released in ~2003, around the same time as H.264. It made waves due to being dramatically better than practically all H.264 encoders at the time”
He also makes a prediction:
“Overall, I expect VP8 to be surely better than MPEG-4 ASP (Xvid/DivX) and WMV9/VC-1. It will likely be nearly as good as Mainconcept’s H.264 encoder (one of the best non-x264 encoders)”
and earlier on:
“Adobe’s H.264 encoder in Flash Media Encoder is so utterly awful that it is far worse than ffmpeg’s H.263 or Theora;”
And he’s said similar things about Apple’s H.264 encoder so I think you’d agree given those statements together that he’s saying VP8 is going to beat Apple and Adobe’s H.264 encoders, probably by a fair margin.
So it’s nearly as good as Mainsoft and not too close to x264 “assuming they still believe that blurring out the entire image is a good idea” (this means tuning for PSNR, and not using psy-optimisations that hurt PSNR but help subjective quality).
So if they dump out what they’ve got now it’s nearly matching the best of the H.264 encoders that don’t employ psy-optimisation. What happens if they fix that by changing the encoder? It’s caused major gains for both x264 and Theora, all without tweaking the decoders or the specs. If that’s what makes the difference between x264 and all of its competitors, why can’t a similar magnitude of improvement happen for VP8?
Why doesn’t he even consider the potential of this happening given his conclusion:
“If there’s anything to take away from this, it’s that psy optimizations are the single most critical feature of a modern video encoder.”
I hope Google (or whoever) look into using these methods to tune their VP8 encoders, but even without them, VP8 is (in the words of a developer of a rival codec) nearly toe-to-toe with the best out of a big field of encoders that companies like Adobe or Apple could embed into their proprietary software.
I’d say its future is looking surprisingly rosy.
Edited 2010-04-14 12:44 UTC
From the original article, Google are said to be almost “partnering” with Mozilla in the venture.
Mozilla is the party who funded Xiph to optimise Theora:
http://blog.mozilla.com/blog/2009/01/26/in-support-of-open-video/
http://arstechnica.com/open-source/news/2009/01/mozilla-contributes…
AFAIK there is no reason why the essential principles of optimisations used at Xiph (funded by Mozilla) to improve Theora (based on VP3) couldn’t also be applied to On2’s VP8.
If Google are prepared to open VP8, and indeed are partnered by Mozilla in this venture, then it is surely in Mozilla’s best interest to contribute these same principles of optimisation to VP8.
Yes, I said early H.264 encoders. Using the term ‘first half of the decade’ makes it sound as though the decoders are a decade old. Both specs are ~7 years old, so the first half of the decade is less than 2 years of encoder development for H.264. Anyways, did you read his account on why the quality was low?
The x264 developer said he expects VP8 to be better than MPEG-4/Xvid, and probably better than an H.264 encoder that was
Thus explaining why most web companies use x264 for encoding and not other products/projects. The quality of Mainconcept’s encoder will not matter if few websites (if any) use it. The comparison is between a Google/On2’s VP8 encoder and x264. However, if VP8 is a simplified VP7 (for software/mobile decoders), then I don’t expect any of the initially touted benefits (1/2 of H.264 file size).
Edited 2010-04-14 13:26 UTC
So VP7 beat all the H.264 implementations in 2003 because one had been worked on for years, and the others for months. That sounds plausible.
Yet here we are 7 years(!) later and according to an x264 developer there’s still one single H.264 encoder implementation (out of how many?) that can convincingly beat the *only* existing VP8 codebase (and VP8 is after all only a simplified VP7).
And that conclusion is provisional on the fact that this single implementation has not adopted the psy techniques that he himself has blogged frequently about, has said is a big factor in the difference between his encoder and other H.264 implementations, and which Theora have adopted in their version of VP3 with large improvements shown. Encoder changes which require little more than them paying attention to what the two highest profile competitors are doing and copying it? No spec breaks, no decoder revisions, no new hardware chips, no ninja-level coding skills.
Is it just me or is that a good review? I know you only want to talk about a single, GPL’d encoder because you think that is the (only) one that shows the true potential of H.264. Why not consider the true potential of VP8 and what it could become when opened up, it certainly seems like it will be good enough, right now, to get the benefit of the doubt.
BTW, I don’t know where the 1/2 H.264 bitrate claim comes from, but since there’s probably at least two H.264 implementations that could claim that against a carefully chosen list of H.264 competitors, I don’t see it being that wild a claim as long as properly qualified. Certainly it could apply if Adobe or Apple include this code in their products, or your average screencasting or video-chat application etc. Not everything revolves around encodes done on servers or by free software enthusiasts.
Edited 2010-04-14 14:43 UTC
Since most H.264 discussions that I’ve seen so far at Osnews have revolved around HTML5, I’m not going to look at other uses for H.264. The article implies that other companies aren’t spending the money required to compete with a free product (x264).
It was a good review … that is 7 weeks old. It provided insight into the reasons why Flash (and H.264) won’t die anytime soon when it comes to web video. VP8 may have potential, but until I see something tangible (e.g. benefits on YouTube), I’m holding off judgement.
I remember reading the 1/2-size somewhere. Can’t find it now, but I think it was made when x264 encoders were immature.
Ran across it on hacker news, but someone already had it in the submission queue so I restrained myself 😉
I have been hoping for this to be true ever since they bought On2. Google is pretty much the only company in the world that has any (real) say in what we will be standard for HTML5, since youtube is almost synonymous with internet video.
It’s not pretty much the only one. That’s also Microsoft who makes the most used browser – Internet Explorer. Youtube maybe the most viewed video sharing site but IE is 60% of web browsing.
If IE doesn’t support youtube, people will switch browsers. youtube + facebook = the internet for most of the people who use it.
YouTube would support IE. All it would require is a plugin for IE. After all, the existing Flash video for YouTube already requires a plugin, so what is the difference from an IE users point of view?
If Google were to switch YouTube to HTML5/VP8, they could do it as soon as they own VP8 if they wanted.
They would have the VP8 codec, they would have the CPU power to run conversions, and they would have a suitable plugin all ready to roll: Google Chrome Frame would do it.
The speculation is that Google and Mozilla would co-operate with this, and both browsers would support HTML5/VP8 as soon as this is announced.
That they have the CPU power to run the conversion is pure speculation.
Youtube now has so much content it is insane. Just do a search for “Guido” and be amazed at how much crap is on YT. Millions and millions of videos. Petabytes and I don’t know if Google has the idle CPU power to convert it all in a reasonable time frame.
I guess they would have to have both h264 and VP8 for a long time and only store new videos in VP8 and use idle CPU time to convert. But that is a major task and very costly. It would make sense to wait a few years for CPUs and encoders to improve.
openvideo.dailymotion.com have converted 300,000+ videos to Theora.
http://blog.laptop.org/2009/05/27/dailymotion-supports-open-video/
Google platform:
http://en.wikipedia.org/wiki/Google_platform
100 video conversions for each server would take perhaps an hour (could do this easily if there is GPU assistance), and convert 45 billion video clips in that time.
Edited 2010-04-14 05:25 UTC
Google servers have no GPU. YT has around X00.000.000 videos in different sizes, so my guess that they are approaching the billion soonish or have crossed that already. h264 has to decoded and VP8 encoded. Decoders are fast now, but VP8 encoders are probably still very immature atm.
And it is not like Google can stop all operation to do a conversion. It is quite save to assume that Googles servers are running pretty maxed out most of the time.
And 450.000 x 100 is 45 billion? .. OK
Edit: I would guess that if they wanted to convert they would first write a special encoder that takes the best quality h264 and then en-/transcodes that into VP8 in different VP8 sizes. If Google could use the computation that is already in h264 that would speed up things a lot. But such a special encoder has to be written first.
As I said, this is a multi-year process because of many factors, everybody who thinks otherwise is delusional IMO.
Edited 2010-04-14 06:10 UTC
450,000 x 100 = 45,000,000 45 million. Oops, sorry.
That is for 100 conversions per hour per server, a little less than two a minute, or a background task, if you will.
To get to convert 45 billion video clips in the background, it would take 1000 hours (if 450,000 servers is accurate). Unlike people, servers run for 24 hours a day, so we are talking, what, 45 days?
A billion video clips per day? Seriously, it won’t take all that long, given the compute grunt that Google has.
PS: Google bought On2, and On2 have the VP8 codec source code. So Google has the codec source code, the rights (copyrights and patents) to it, it has the major video hosting site on the web, it has a huge audience for that site, it has the video clips, it has the compute power to convert them, it apparently has a partner in Mozilla, and it has a huge self-interest in not being dependent on the whims of MPEG LA for permission to run a vital part of its business.
Google will not succeed in freeing themselves from being beholden to MPEG LA unless they open source VP8, join with Mozilla, put an open VP8 decoder in Google Chrome, Firefox and Google Chrome Frame (and probably Opera as well), and host VP8 videos on Youtube.
It is all do-able.
Why wouldn’t Google do it?
Edited 2010-04-14 07:04 UTC
They’re not going to throw all of their servers at this conversion, they still have other things to do… like letting running a massive search/mail/data engine. You’re also assuming that they could convert 100 videos per hour per server, which is also just a guess.
I think the contention isn’t that they won’t do it, but rather that it’ll take some time.
Why not? The more servers they throw at the task, the less each one has to do.
Google servers run linux. Have you ever heard of this cool thing called “multitasking”?
Yep. Its a guess. My own humble machine could do this as a background task, so I’m guessing that my guess is a some-where-in-the-region guess.
I think the contention is that they have started it already, some time ago, they have measured how long it is really going to take as a background task, and they know when it will finish.
What was this rumour about planning an announcement in about a month’s time?
FTA:
Edited 2010-04-14 10:19 UTC
You never stop do you?
They are not doing it already. That would mean that they had to have storage space for all YT videos in h264 and VP8. All YT videos take thousands and thousands of 2 TB disks (remember they have always a few backup copies, we are talking many petabytes) That just makes no sense whatsoever, that is just a brainfart.
First you need to make VP8 popular and then you can slowly convert without keeping h264 around. We are years away from that day.
EOD for me.
http://en.wikipedia.org/wiki/Google
One million linux servers, each with only a modest 200GB storage, works out to …
10^6 * 2*10^2 * 10^9 = 200*10^15 = 200 petabytes.
That is without taking into account any machines with larger disks or multiple disks, as some of them surely must have.
Google know how to do distributed storage, distributed processing, and fault tolerance for a very-large-but-quantisable task.
It is kind of what Google do.
Edited 2010-04-14 11:30 UTC
Their servers don’t work the same as your machine. It’s not a matter of a background task, its a matter of putting a job on a grid (which if anything is even easier once everything is set up, especially since transcoding is an inherently parallelizable task.)
What you aren’t taking into account is they have all that computing power for a reason, and they are not going to divert all resources for a property that doesn’t come closing to approaching the revenue that some of their other services generate. I don’t think it would be an impossible task, but it definately wouldn’t be a trivial one, even for google.
It is a rather momentous day though lemur, because for once, you and I actually agree on something 😉 open sourcing VP8 would be in everyone’s best interests, including googles. I have been waiting for this news since they bought On2, and while its still a rumor, I think there is a very high chance of this playing out at this years Google I/O conference.
Yes, this is the point. Re-encoding Youtubes videos under VP8 is indeed an inherently parallelizable task, and it is exactly the type of task that Google’s infrastructure is uniquely best able to cope with.
This is what “nice” is for. Re-encoding videos would of course be a task that was undertaken only when there was nothing better for a given server to be doing. It would be done in the “idle time”. It would be a very “nice” task, giving up CPU to everything else.
Now, given the peakiness of demand that Google can accomodate, the peak load on any given server would be a lot higher than its average load. Google would need this in order to be able to handle the peaks when they came. However, almost as a side-effect, this yeilds a great deal of available CPU resource when machines are not at peak load.
Not trivial, no, but definately achieveable given Google’s infrastructure. It is a task of the order of weeks or months, though, and not many years as some have tried to claim.
It is indeed nice to see your horizons expanding and your understanding improving like that.
Edited 2010-04-14 23:59 UTC
Yes, of course I’ve heard of multitasking, but that just proves that you’ve totally missed the point.
The point is: there is a finite amount of computing power available to Google (although it is very high). If they use it to process videos, and if this exceeds their total slack time (the slack-time being the times where the computer is inactive) their OTHER services will slow down.
Sigh!
Google servers run Linux. If you ever get a chance to sit at a Linux machine, open a command-line terminal and enter the command “man nice”.
If not, you can read about it here:
http://linux.die.net/man/1/nice
Duh. But you’re saying they can do it on the order of months/weeks. As I say, if this exceeds the slack cpu-time they have available then either they’ll fail that deadline, OR they’ll have to slow other processes down to do make it.
Your reasoning is totally off-base. You have to reason about the slack-cpu time they have available, not absolute number of servers, or ability to re-nice processes.
I’m not saying you’re wrong about the conclusion of it taking weeks/months, I’m saying this line of reasoning doesn’t support your conclusions.
I think it’s reasonable to think that Google has a lot of spare CPU slack time they could throw at this. It’s just common sense, they need to keep ahead of the growing demand and will want to have plenty available in case traffic spikes. Then they’ve got to plan for what happens if one of their centers gets hit by an earthquake and goes offline, the others need to be able to pick up the slack.
I wouldn’t be surprised if they have a policy that avg CPU use should be under 75%, at least, and they keep adding more servers whenever that becomes a problem.
Converting the videos in a couple months seems very doable, but i doubt there would be a hard cutover date, so more likely they would just convert all the most popular clips ahead of time and queue up all the older ones for ongoing processing. They could just fall back to flash/h264 in the meantime for clips that hadn’t been converted yet, something which certainly wouldn’t be going away anytime soon.
Exactly.
This is so obvious, I’m astounded that anyone would even have questioned it.
I don’t know that there would even be a need to sort the processing order. Just queue the lot, let the CPUs go at it in their slack time, and it gets done when it gets done.
Zero impact, zero cost to Google, web video freedom is the outcome for all. Its a win-win.
Edited 2010-04-15 06:39 UTC
Well, I like to think something through, and make sure my brain is engaged when I read something. I apply this to both Linux/FOSS and non-Linux/FOSS discussion, this may be the difference.
Some other points to consider that do not make this a trivial conclusion:
You can renice a process, but you can’t do the same with the memory or IO that it requires to perform.
You were guessing 100 video conversions per hour per node, YouTube (I believe) has a wait-time of about 15 minutes – 2 hours for a video to go live. That’s a maximum of 4 videos/hour/node.
The encoder for VP8 is probably slower than what they have now for their current solution. So probably less than 4 videos/hour/node.
Distributing the task among ALL their servers means they have to replicate (at least send) all that data around, that’s not free or instantaneous.
A combination of these factors makes me not immediately accept the notion that this could be completed on the order of months.
You assume here that the wait time to go live is due to encoding the video. I doubt that very much. You are thinking “one server”, not “one million servers”. The wait time to go live is, very probably, due to the need to get the new video indexed on all of the servers that serve YouTube. All of the YouTube servers will need to know exactly where the new video is stored, inforamtion about it, and how to access it.
You still haven’t quite got the gist of distributed storage, have you. YouTube’s files are already distributed. There would be perhaps four copies of each file (in order to achieve fault tolerance), with each copy somewhere on a different one of Google’s one million servers. (If any one server dies, its files would be re-copied onto the new replacement server from another copy stored elsewhere).
So anyway, for the VP8 re-encode task, you would just get each server to process the YouTube video files it already stores locally.
No need to send anything anywhere. As long as there is a consistent way of storing the VP8 file relative to the existing file on each local server, existing indexes worldwide could automatically be adjusted to find the new VP8 versions without having to re-index.
Edited 2010-04-15 12:12 UTC
But then you don’t take advantage of all of Google’s servers, only the ones which contain the videos.
Then you need to know that they distribute the videos evenly over all servers, which is another unknown.
Also, you STILL have to send the files around (assuming you don’t want to encode the same thing twice) so that the other servers that have copies also now have a copy of the VP8 encoded video.
Nope. You still haven’t got the gist of it.
Each Youtube video is stored a small number of times (for redundancy) on separate servers. All YouTube servers have an index, so they all know the global “map” of all the YouTube files. When someone connects to YouTube, the system will connect them to one of their country’s YouTube servers. When someone asks to play a particular video, their request is re-directed (using the “map” or index) to one of the small number of servers that has a copy of the particular file they wish to play. That other server actually serves the video file data back to the original requester.
All one million of Google’s servers will have some number of YouTube videos stored locally.
This is distributed storage, and distributed handling of requests for service.
All that is required to re-encode the YouTube video collection to VP8 is to ask each server to encode those YouTube videos that each particular server has stored locally, and to place the new VP8 video on that same server’s local disk at a deterministic location and name relative to the existing video file. This is the best way to do it, rather than send files between servers, because the bandwidth available to a CPU to files on its own local disk is far greater than the bandwidth available to get the file to or from some other server. This way, all YouTube servers can update their indices without having to transfer any information between them.
This is distributed processing of the re-encode task.
None of the overhead that you imagined that this task would incur is actually required, if you do it right.
Edited 2010-04-15 13:29 UTC
Do you know that Google spans YouTube across all of its servers, or just some of them? This is really a key point, without this knowledge you can only take very poor guesses at the computational power they could throw at this.
Give it up, already. Why on earth would Google concentrate YouTube videos on only a small subset of its servers, and thereby cause needless congestion, when the very simple measure of spreading them out over all servers suits their purpose far better in every way imaginable?
Edited 2010-04-15 15:08 UTC
Seriously, this whole discussion is entirely pointless.
You’re throwing your own estimates about the server count, their current usage (or lack thereof), the copies of the videos, the CPU time needed for reencoding them, etc, etc.
Estimates built on estimates built on estimates built on estimates that you know NOTHING about and then you claim it’s all zero-cost for Google and they could easily do it.
…right.
Yeah, you just have to give up because Lemur will never stop posting his uninformed brain farts.
Google servers always run pretty much maxed out. If one data center explodes then indexing low priority websites will die or other non-essential tasks.
Lemur knows nothing about Googles internals and how much RAM/CPU/disk/bandwidth VP8 encoding would block etc..
It is just guesses after guesses after guesses, but he is sure they are doing it already and they can be done next month and running memory intensive tasks like video decoding and encoding (they might need 2 passes) works great when just reniced .. yeah right.
Sorry, but he is a weirdo.
You do realise that YouTube video is distributed to a large number of Google’s servers, right? You can see this for yourself by watching the status bar on your browser, and noting where the browser is fetching information from, as soon as you click “play” on a YouTube video.
If each server had a list of the videos stored locally (which is only reasonable, after all), sorted by hit count, and if the re-encode process started with the most popular video on each machine, then one million of the most popular videos would be re-encoded within the first few minutes of the task starting. Another million in the next few minutes. Tens of millions within the first hour …
Nobody misunderstands that Google has a distributed architecture at their disposal, or that this would allow them to leverage a large amount of computational power.
The unknowns here are what makes your argument unconvincing:
– How long does an encode take (likely with an immature encoder)
– How evenly is the video data distributed? Can they leverage 100%, 10%, 1% of their servers for this task?
– Encoding takes not only raw cycles, but also memory and could be fairly IO intensive (reading and writing a stream of data). How much can this be spared on each server, you can’t renice memory or IO AFAIK.
So you don’t know how long the task will take, or how much spare time they have available. As someone else said, it’s guesses on top of guesses, and unconvincing as an argument.
Pffft.
The whole power of Google’s platform comes from its distributed nature. Widely distributed load = small load for any given machine or node. Concentration of any of Google’s services = congestion, bottlenecks and poor performance.
You still haven’t come up with a single reason why Google should lump Youtube’s video on a small subset of servers. To do that would be stupid. It would waste most of the Google platform, and un-necessarily bog down the parts that weren’t wasted.
Forget your fantasy … it will be no trouble at all for Google to re-encode video’s, and if they choose to do it it will happen remarkably quickly.
YouTube actually has their own video servers, I suppose separate from Google’s. Originally they were managed hosting, now they are colocated for more versatility.
http://highscalability.com/youtube-architecture
So my “fantasy”, as you put it, seems to be fairly real.
I don’t how Google’s layout works, I think they generally keep this information non-public. Some general stats they release, yes, but not he inner workings (as far as I’m aware, I could be wrong).
The inner workings of the massive distributed computing that Google has going on are a mystery to me.
Duh. There is no deadline. There is only a low-prority but sizeable task, a resource (slack-time of their 1 million CPUs), and an average rate at which the task gets performed. The amount which gets completed clearly depends on the demands on their resources for other things, or the integral over time of the level of slack, if you will.
If you know the total size, and the avearge rate of burn-down of the work remaining to be done, then you will have an estimate for the end date.
It is low priority (compared with other jobs) – it takes as long as it takes. Duh.
MOST OBVIOUS RUMOR EVER
RUMOR: ORACLE TO STOP GIVING AWAY SOLARIS FOR FREE
DERRRRRRR
This rumor has been going on for a while now and I hope Google make it official before the HTML 5 standard is finalized. Other people have already mentioned that it will take a while for these videos to become commonplace since a lot of mobile hardware is already out there that only suppport h264. With that said, it would be nice if the W3C allowed for multiple sources for a single video file in HTML 5 just like they offer multiple options in the “face” attribute of the “font” element. This would allow sites to offer high-quality VP8 files for those browsers that support it and an h264 version of the file to fall back on.
Apparently that can be done by using multiple “source” elements inside the “video” element. (See near the bottom of http://diveintohtml5.org/video.html)
A fair amount of mobile hardware (phones) have short lives. The fact that there is dedicated hardware in these devices isn’t as constraining as one would first think.
If one simply uses a more general-purpose GPU, the video/graphics hardware can be programmed for any codec via languages such as GLSL and GPGPU. Hardware as low-spec as netbooks, smartbooks, internet tablets and “pads” all support a general-purpose GPU.
Apparently GPU shaders are terrible at video decoding; that’s why we have PureVideo and such. Unfortunately, neither approach is helpful with a new codec.
Source?
GPU shaders are possibly not efficient at decoding H.264/avc, which is very complex and demanding of computational grunt, but Theora at least is considerably easier, and possibly the same is true of VP8.
My source for backup:
http://en.wikipedia.org/wiki/Theora#Playback_performance
By metioning only dedicated decoder chips and very low resource devices (iPods and similar devices with limited computing power), this text actually avoids mentioning the possibility of a GLSL or GPGPU based decoder in any device with a little more resources (i.e. a GPU), such as netbooks, smartbooks, tablets and “pads”.
However, the text does mention that Theora is less demanding of resources to decode, and it also says that for small screen resolutions (i.e. iPods and similar devices with limited computing power), dedicated decoing hardware may not be necessary at all.
There are a bunch of different steps to video decoding, and they all run with varying levels of suitability on shaders. Parts can’t be run on shaders at all, others run mediocre, and some run very well.
In practice, the first type end up getting run on the CPU while the rest run in shaders, and it ends up being a lot better than running everything on the CPU. But there’s still a significant bit there that can’t be shoved over to the GPU, and the general purpose shaders tend to be a lot more power hungry than a small fixed function video decoder, which makes the specialized hardware very nice to have.
Read again. That doesn’t say anything about GPU.
And as smitty said, there’s stuff you just can’t do practically on shaders. Basically the idea with GPGPU is that you have loads and loads of threads. If you can’t multi-thread some part of the decoder by massive amounts, it gets VERY slow. For one, I’ve never heard of any video format use an entropy coding that would run well on shaders. Of course I could be wrong here. (There might be dedicated hardware for some entropy coding on modern GPUs, but that’s another story and depends on the video format.)
True, but all GPUs have either PureVideo or AVIVO.
As I said, PureVideo and AVIVO don’t help you with a new codec like VP8. So if you can’t decode VP8 with PureVideo and you can’t decode it with shaders, then you’re going to be stuck using the CPU.
You mean DirectCompute, CUDA or OpenCL. GLSHL is a shader language and GPGPU is just the concept of using GPU for doing computations.
We don’t need those because we already have DXVA, VDPAU and XvBA – a set of APIs that allows hardware to do video decoding.
The hardware decoding within GPUs that is accessed via DXVA, VDPAU and XvBA is limited to specific codec(s), and encumbered by DRM. This is the antithesis of what is required for the open access web. It is a requirement that web standards be at least royalty-free for anyone to use and implement, if not patent free.
Therefore, for web video decoding, graphics hardware support (at least for existing video cards) will have to be added via either GLSL or GPGPU.
http://en.wikipedia.org/wiki/GLSL
http://en.wikipedia.org/wiki/Gpgpu
The only viable candidate codec at this time is Theora, but this very thread is speculation that this may soon change, and Google may also make VP8 a viable alternative candidate meeting the requirements.
The applications for GPGPU are listed here:
http://en.wikipedia.org/wiki/Gpgpu#Applications
They include the following:
My bold.
Note that GPGPU can be applied to accelerate both the decoding and the encoding processes.
PS: AFAIK, CAVLC/CABAC are used only by H264.AVC.
PPS: AFAIK, there is already a GPU shader Theora decoder written in GLSL as a Google SoC project.
Edited 2010-04-14 02:57 UTC
How can you even misunderstand your own source you linked couple of posts earlier?
From:
http://en.wikipedia.org/wiki/Theora#Playback_performance
“There is an open source VHDL code base for a hardware Theora decoder in development.[54] It began as a 2006 Google Summer of Code project, and it has been developed on both the Nios II and LEON processors.”
That has nothing to do with GLSL.
Agreed. AFAIK there is a GPU shader Theora decoder written in GLSL as one Google SoC project, and there is also an open source VHDL code base for a hardware Theora decoder in development.
The hardware design is called leon3:
http://people.xiph.org/~j/bzr/theora-fpga/leon3/
The GLSL (GPU shader based design), which AFAIK was also a GSoC project, has absolutely nothing to do with the leon3 VHDL hardware decoder design. They are entirely different things.
You are quite correct.
Which could be as late as 2022
http://www.zdnetasia.com/html-5-may-not-be-finalized-before-2022-62…
The thing with the w3c is that its not a standards body, its a consortium of companies with competing interests, so it moves even SLOWER then a standards body. It usually takes about 15-20 years for them to get a recommendation out the door.
That being said, browser support tends to happen WAY before that, and once there is support from most of the vendors, devs start using it.
Then why let w3c decide how HTML 5 will be like? Why not ISO?
ISO ratifies specifications, you still need the commitee to come up with the specification. Submitting to ISO would be great, cause then we would have standards, not just consortium recommendations, but the real problem is actually building the spec. And the problem there is the amount of conflicting interests involved. There are a lot of politics, and a lot of sabotaging going on.
Now, you could say “Why not get a neutral third party to make the spec, submit it to ISO, and don’t let the vendors be part of the process at all?” That would be great, but historically, even WITH the vendors having a say, it is still really hard to get them to all implement things the same way. And that aside, the people who decide the way things are done and who is listened to is the vendors, and they like it this way.
Assuming you’re not just trolling with that regularly debunked talking point, the HTML5 spec will be published in the next year or so. The 2022 date is when they expect two independent implementations to cover the whole spec interoperably.
That may seem a long time, but it’s a lot nearer than never, which is when that’s going to happen for HTML 4.
So a spec is not a recommendation. They build out the spec, then they build out tests, then they argue about tests, then they wait for at least to implementers to agree with the tests, and pass them.
CSS 2.1 took about a decade to go from spec to a recommendation.
the farting unicorns! That would be hilarious.
Google is not Apple, they haven’t really been big on strong arming standard through and I don’t see this changing anytime soon. Google will release vp8 as open source all right, but I don’t seem them switching youtube off h.264 for a long time. It will take a while for Apple and Microsoft to implement vp8 even if Google can convince them to do so.
So why did Google aquire vp8 if they aren’t going to switch youtube to it immediately? If I had to guess, I would say its a bargaining chip, the more viable alternatives to h.264 exist, the less leverage the mpeg-la has on Google. If people actually switch over that goods too, but the main goal is making sure that if the mpeg-la goes crazy google does have a backup plan.
Thats my take anyway
It is not required for Apple and Microsoft to implement vp8. All that would be needed is for Youtube to implement VP8, and for YouTube to provide a link to install a plugin for HTML5/VP8 video for IE users.
Apple can go jump.
Edited 2010-04-14 00:16 UTC
But they would still need to have h264 available for the iPhone, iPad & Windows Phone 7, Windows Mobile 6 and Kin phones & Nokia phones and phones from other companies. Almost all of these smart phones can already play h.264. Before they can switch completely, they would need to convince a lot of companies.
Also, remember, all these companies have already paid the fees for h.264. Moving to something new isn’t going to save them any money, and none of these companies are going to do extra work unless it benefits them somehow.
Edited 2010-04-14 15:55 UTC
That’s my take too. They are defending against MPEG LA’s “monopoly” over HD codecs and keep their VP8 codec as a trump card.
All I have to say is consider the source of this news. Do you find this to be a reliable source of information? In other words I would not hold my breath on this until it is actually confirmed by either Google or a actual reputable news source (not some blog).
I think google is very very talented and all, but giving themselves only a month figure out how to fart unicorns without getting poked in the buttox?? Isn’t that a bit optimistic?
They like Flash, they want to stick with it, please stop kidding yourself when it comes to their intentions.
My guess is that they long ago decided to use H.264 for technical reasons and if they open source VP8 it will mainly be a fruit basket for the FOSS crowd and a long play against the MPEG group by seeding a competitive alternative.
They probably don’t think any of the alternative codecs are worth supporting but want to make it look like they support open source. Reminds me of that South Park episode where the town decided that it was best to be for the war while acting like you are against it.
Flash is included with Chrome so that it can be updated silently (like Chrome itself) and to improve the user experience. I applaud that. You can always download the version without Flash included if you so desire.
If they were serious about open source codecs they would have had a plan to dump Flash from the moment they purchased YouTube.
However Google has moved closer to Flash since their purchase and they also clearly support H.264.
If Google convinces Adobe to support VP8 in Flash then it’s game over, within a year VP8 support will be over 100% (meaning many users will be able to receive it natively in HTML5, via Flash, via Silverlight pluggable codecs, via Java, via Chrome Frame plugin etc.)
You might think this sounds crazy but Adobe Flash already supports VP6 and had an licence option on using VP7. It also seemed a bit crazy to me that Adobe started supporting H.264 and didn’t even force you to put it in their FLV container and instead let you use the exact same file that you can serve to HTML5 or let people download.
What difference is there to supporting a royalty bearing standard that’s included in all new desktops and phones, and supporting a royalty-free codec with the weight of Google behind it, from Adobe’s point of view. Either way they’ve not got lock-in via the codec itself, but this makes them more useful for real world deployments.
They’ll also get a viable BSD-encoder for free, where currently Adobe’s H.264 encoder is a joke and so Adobe is only part of the workflow.
Game over for who? Flash? What makes you think content providers want to distribute a pure video format? Ever notice the ads on Flash videos? Hulu has already stated that they aren’t interested in HTML5 because there is no content protection.
I’m all for HTML5 video but I also know that major media providers use Flash for more reasons than video.
Google however could end Flash dominance by requiring an alternative plugin for YouTube but that plugin would have to be technically superior to Flash and not just in video quality but also in functionality that sites like Hulu require. Otherwise the other major sites would just stick with Flash.
If anything they will open source VP8 as a way of seeding an alternative and to appease critics. If they really cared about open source codecs then they would not have been so adamant about using H.264 in HTML5.
Why not allow Theora to be the default codec in HTML5 since it doesn’t prevent sites like Hulu from using plugins with any codec that they want? Especially since Flash is already a de facto standard and uses H.264. This is the question that Theora advocates need to ask Google.
Google haven’t been adamant about using H.264 in HTML5. Google’s initial YouTube experiments with HTML5 have used H.264 becuase that was what YouTube has, but this is only an experiment. A trial run. Google have said a number of times that this experiment does not mean that they will necessarily use h.264 with HTML5 ongoing, or even that they will use HTML5 at all.
What makes you think web video “content providers” are one and the same as “big media”?
The majority of web video is contributed by individuals, who have no interest at all in DRM. A lot of this video is taken by digital cameras or smartphones belonging to said individuals. Individuals cannot afford h.264 licenses, for what amounts to a hobby.
http://videoonwikipedia.org/
http://openvideoalliance.org/
Edited 2010-04-15 03:15 UTC
You seem to have missed my point.
Flash doesn’t “do H.264”, it does H.263, VP6 & H.264. It could very easily start doing VP8, either because Google asked (or paid) them to do so, or just because it suddenly becomes popular and customers demand it.
So all the benefits of Flash that you outline could be combined with the benefits of a “pure” video codec like VP8.
I think this would mostly be a good thing for Adobe, but big business decision making is weird. Maybe they think they need to “focus” and bet the farm on H.264. Maybe they’ll consider it a way to hit back at Apple. Either way I guess we’ll find out in due time.
(And if they do support VP8 it will be “game over” in regards to the question: what is the best codec for the web?)
Edited 2010-04-15 10:44 UTC
Also, funny that you should mention Hulu, as they currently use On2 VP6 delivered via Flash. From their FAQ:
http://www.hulu.com/about/media_faq
What is the quality at which videos will be streamed on Hulu?
Hulu videos are streamed as Flash video files (FLV files). These files are encoded using the On2 Flash VP6 codec that is supported on Flash Player 8.0 and above (which is installed on more than 98% of computers in the U.S.).
Hulu currently supports four different streams including 480kbps, 700kbps, 1,000kbps (an H.264 encode that is not on On2 VP6) and 2.5Mbps.
Edited 2010-04-15 15:15 UTC
chrome has ogg and theora support already… what the issue is, is that theora isn’t good enough for youtube, and VP8 is one of the best codecs out there.
Seems like a logical step for google to do,
with all the discussion about which standard html5 should have this could be a great option. I hope this is true, internet should be open and accesible for everyone and this codec would help alot.
Here’s a summary of the pitfalls.
I’m paraphrasing my earlier post a bit, but oh well.
1) I’ve never even heard of these NewTeeVee guys and they appear to be the only source. It’s already way too much coverage for such feeble sources.
2) They talk about “open sourcing”, but that doesn’t mean much when talking about video formats. It might mean they’re open sourcing the VP8 encoder, but still keep licenses on the format. x264 is open source too, you know.
3) Then there’s the patent ambush. Let me quote a conversation with a certain x264 developer:
Me: “I hope companies don’t patent ambush VP8”
Him: “hahahahahahahah”
Since VP8 is (apparently) much more modern than Theora, it’s also even more likely there are patents on it. In this case Google could try to get some kind of cross-license thing going on, but as a counter-example, Microsoft has one of the world’s biggest patent portfolios and they still got VC-1’d.
4) Then the quality… This is of course full of maybes and buts, this is what I can say from the available material, such as:
http://www.on2.com/index.php?599
Want to know why On2 says it’s much better than H.264? They apparently use PSNR as the only measurement. If you look at the VP8 video, you can see how blurry it is. PSNR isn’t a very good metric, SSIM is already a lot better. Look at this for example:
http://www.ece.uwaterloo.ca/~z70wang/research/ssim/
Note, when MSE is constant, so is PSNR. Check the Einstein pictures. They all have the same PSNR. Yes, really. As you can see from the lover mid one, PSNR absolutely loves blur. And in fact, from what I hear, there have been studies that would suggest most people prefer video artifacts such as blocking to blur, because they perceive it as “detail”. This is one of the basic ideas of psycho-visual optimizations. (Which is what x264 does very well.)
Not to mention they used an ancient x264 from July 2008. (Sure, it was probably recent when they did the test.) I don’t know the source for the only video that is shown, though, so I can’t run my own tests.
Of course this doesn’t yet say anything about the FORMAT itself, or what they have done to the encoder since 2008. But if the current encoder sucks, it certainly might delay the adoption of VP8. It took years for H.264 encoders to get to the current level.
——-
All in all, I hope that the rumor is true. I hope companies don’t patent ambush VP8. If the quality and speed are decent, I’d very much accept VP8 as the only standard for HTML5, but I certainly wouldn’t start making any long term plans based on these rumors right now.
I don’t know… I prefer the ON2 blurry version, personally. Encoding artifacts look cheap, to me they look like stretched bitmaps, low-res images pretending they got high-res just because they were scaled up. Blur has a somewhat more honest feeling : it removes the incoherent and poor information, only the real information remains.
It’s the same as MP3 : low bitrate sounds fine until I hear that horrible garbled background noise or some cymbals looking like they went through a blender. In noisy environments, I simply can’t make a difference between mp3 64k and MP3 128k using modern encoders, because environment noise won’t allow me to perceive that audio horror, and the rest is fine.
But as you said, it’s a matter of perception. Maybe some people prefer not to have the background noise cut in MP3s… I prefer having the audio/video equivalent of a sketch : keep the useful info, throw the rest out through the windows. Isn’t it the whole point of audio/video compression ?
Edited 2010-04-14 16:47 UTC
In fact, I prefer blur myself too, but it could be because I have seen so much video artifacts they immediately shout “LOW QUALITY!” at me.
People who really matter, the end-users, might be different. Not to mention loads of video encoding people who have said they prefer the non-blurred one.
But I wouldn’t go as far as saying only displaying real information matters. For example, take movie grain. It’s just noise and if the encoder is smart enough to “remix” that noise by making something that looks very similar, but is a lot easier to compress, it’s all good, even though the “real” information is lost.
Same goes for lots of noisy textures that are seen on high resolution videos. It’s a lot better to make a high-frequency texture into something that kind of looks similar than to blur it out altogether even if it would give better PSNR, this is why psy opts are turned off for metrics tests.
For example, look at the trees in the On2 video. (And btw, I don’t think x264 should keyframe-pulsate like that normally…)
Speaking of MP3, psy opts are the reason Vorbis beat MP3.
Edited 2010-04-14 17:10 UTC
That’s right. Remixing artifacts into grain-like noise would certainly lead to much better-looking videos that blurring them along with part of the underlying details that somehow managed to survive the low-quality encoding.
Another option I’d like to see is improving level of detail in regions of high interest at the expense of completely destroying regions of low interest that I don’t care about. I think that modern codecs already try to do this to some extent, but I’m a codec customer, not a codec specialist, so I can’t tell
. Is it what you call psy opts ?
Actually, even DivX doesn’t do that anymore at usual bitrates, last time I down… err… checked some divx movies that I encoded myself from the original DVD.
Well, don’t remember ever managing to make poor-quality vorbis files, but I’ve been using FLAC for too much time to tell. Why use lossy compression in portable music players when you have a small collection of music like me and an insanely large storage space in modern music players ?
Edited 2010-04-14 20:21 UTC
I’m surprised no one has mentioned the prospect of Adobe building this into Flash. After all, there must be some reason that Google made the deal with them to bundle Flash into Chrome…
I fully expect the next version of Flash (if not 10.1, then 10.2) to support VP8, which will not only encourage a lot of Flash developers to get on the VP8 bandwagon, but also allow Google to do a 100% migration of YouTube to VP8 without having to worry about IE & Safari support.
Edited 2010-04-14 18:19 UTC
That may very well be the case. Adoption of alternative video formats (like VP8/Theora) won’t increase until they are supported by Flash.
Edited 2010-04-14 22:23 UTC
I can just imagine the look on Steve Jobs’ face when he realizes that his precious pet technology (MPEG-4/H.264) is about to get steamrolled by Google and its newly-open-sourced acquisition. While everyone else jumps on the VP8 bandwagon, he will undoubtedly stubbornly hang on, leaving the iPhone and its kin the only devices unable to view the “full” internet.
Would be somehow ironic…
And wouldn’t that be a nice reward when you think about their relation with Google and Adobe?