Slashdot Mirror
Google Rolls Out VP9 Encoding For YouTube
An anonymous reader writes: The YouTube engineering blog announced that they've begun encoding videos with Google's open VP9 codec. Their goal is to use the efficiency of VP9 to bring better quality video to people in low-bandwidth areas, and to spur uptake of 4K video in more developed areas. "[I]f your Internet connection used to only play up to 480p without buffering on YouTube, it can now play silky smooth 720p with VP9."
Er... VP9 is BSD license. I'd hardly call that proprietary. Sure, they may be the only ones using it yet. But I don't see that staying the case for long if it's actually a better format.
GENERATION 667: The first time you see this, copy it into your sig on any forum and add 1 to the generation
Compared to h.264, VP9 is MORE efficient. Remember, VP9 was actually a contender for "next gen" codecs - i.e., it was a contender for h.265 which is required to get 4K content without taking 4 times as much space.
VP8 was the competitor to h.264, and it wasn't that great at it - in practically all metrics, h.264 beat VP8 handily.
VP9 compared to h.265 was far more mixed, and it's possible that VP9 might actually make it as the next-gen codec given the troubles h.265 is having right now w.r.t. patent licensing.
VP9 compared to h.264 is no contest - it is far more efficient - it's just like comparing h.265 with h.264 - h.265 is far more efficient and will get lower bitrates for the same quality.
Of course, the primary problem is no one can hardware accelerate VP9 right now, so it's all CPU decoded. (h.265 decoders are *just* starting to emerge). So 720p decoding in CPU is probably achievable, but 1080p or 4K... not so much.
I'm not a codec expert. I'm just a dilettante, reading blog posts from time to time. I trust that if I screw anything up, someone will correct me.
VP9 is superior to H.264. It's based on VP8, which is not as good as H.264, but it's roughly in the ballpark (meaning it's much better than H.262 used in MPEG-2). My guess is that VP9 probably isn't quite as good as H.265, but it is definitely in the ballpark.
Google got VP8 by buying a company called On2. On2 claimed that their video coder was the best thing ever, better even than H.264, but now that people have seen the source code it's clear that was just puffery. (I guess VP8 is better than the "baseline profile" of H.264, but hardly anyone uses that; they use the more advanced features of H.264 which are better than the best VP8 can do.)
Google paid over 100 million dollars for On2. I believe they did this mostly to get insurance for their YouTube business. YouTube really needs a good video coder: if the videos are terribly high in bandwidth, Google spends too much on the bandwidth and the customers have a bad experience (videos take forever to buffer on phones and/or look bad). But if H.264 is the only game in town, Google would be totally at the mercy of the patent owners. It was worth 100 million dollars to Google to hedge their bets and have a Plan B if the MPEG licensing guys ever tried to take advantage of Google's critical need for a really good video coder.
After buying On2, Google was silent for almost a year. I believe that during that time, Google lawyers were poring over the VP6 code and making sure that nobody would win a patent infringement suit when Google released the code. Then they released the source code to VP8, and forever gave up any patent rights. VP8 is completely open source and unencumbered by patents.
The general strategy of On2 seems to have been to read all the patents from coders like H.264, and then implement something similar, but different enough not to infringe. When VP8 was released, several people here on Slashdot opined that VP8 simply had to infringe on some patents, being as similar as it is to H.264. Well, it's years later now and the lawyers haven't gotten rich by suing Google yet. I think Google is in the clear.
In fact, the MPEG Licensing Authority tried to put together a patent pool, with all the patents VP8 infringes. Over a year later, there were still no patents in the pool. Google made a one-time payment to MPEG-LA, and MPEG-LA gave Google a lifetime promise to not sue. Some here on Slashdot opined that this meant Google was admitting they had infringed on H.264 patents, but no; this was unconditional defeat for MPEG-LA, who got a little money but are not able to charge royalties or in any way control what anyone does with VP8.
Now, here's the thing: VP8 was too late to win the war with H.264. All modern phones contain hardware acceleration for H.264, but likely not for VP8. But VP9 is not too late for the war with H.265; and I'm personally cheering for the BSD-licensed technology to win over the patent-encrusted technology.
I'll still count it as a win if every phone ships with H.265 and VP9. I don't need H.265 to lose to be happy.
The one thing that worries me a little bit was the recent story that someone is putting together a new patent pool, outside of MPEG-LA. The only sane reason I can imagine for this: MPEG-LA has agreed never to sue Google; maybe someone wants to sue Google and this is the first step.
My guess is that Google lawyers didn't screw anything up, and Google would eventually win the court battle; but perhaps the FUD caused by a lawsuit would make the hardware manufacturers pass on VP9. By the time the court battle was over, H.265 would be the hardware standard the same way H.264 is now.
I hope I'm just wrong about this last part. It could simply be that a few companies want to get more money from H.265.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The Snapdragon 805 and newer has hardware accelerated VP9 decode.
4 years old i7-2620M: VP9 1080p takes at most 40% core (=20% CPU), 2160p takes at most 150% core (=75% CPU).
https://www.youtube.com/watch?... formats 248 and 313 respectively.
Have they bothered to come up with a decent easy to use encoder/decoder?
Well, here's a list. Some are free, some (like Sorenson Squeeze) cost money. VLC can also transcode to WebM. Handbrake does support VP8, but to a Matroska container (WebM is a subset of Matroska).