Google Rolls Out VP9 Encoding For YouTube 109
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."
Re:Proprietary formats suck. (Score:5, Informative)
Re:Proprietary formats suck. (Score:5, Informative)
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.
Re: Proprietary formats suck. (Score:1)
The published data on this is all over the map. I've seen one paper that seems to claim that vp9 is, on balance, *worse* than h.264 - which, if you believe it, would imply that a whole bunch of very smart people at Google have spent several years wasting their time.
On the other hand, there are a couple studies showing that vp9 and H.265 are roughly on par, with vp9 roughly 10% behind, which is thoroughly believable, and consistent with what Google themselves have been saying. For instance: http://eprints.q
Re: (Score:2)
The BjÃntegaard metric is used to calculate the bitrate saving achieved by the test
encoders, based on the PSNR scores.
The problem with a lot of these studies is that the metrics don't always work that well. For example, look at the image comparison [ietf.org] on pages 26, 27 and 28 in the NetVC presentation. The first codec on page 27 has a better PSNR score than Daala [xiph.org] on page 28, yet to me the image compressed by Daala looks better and has more detail.
Daala's not ready yet but it's been proposed as the basis for the NetVC implementation. NetVC [tomshardware.com] will probably end up being Daala merged with other contributions.
Re: (Score:2)
> Any citations on this?
There's lots. I think the most trustworthy would be this one:
http://infoscience.epfl.ch/record/200925/files/article-vp9-submited-v2.pdf
It used some pretty clever techniques to measure perceived differences, rather than theoretical. H.265/HVEC won very slightly at very high definition, and increasingly won as the bandwidth was reduced. VP9 was "competitive" only at the highest quality settings. At lower settings, VP9 did increasingly poorly, until it was worse than H.264/AVC. VP9 o
Re:Proprietary formats suck. (Score:5, Informative)
The Snapdragon 805 and newer has hardware accelerated VP9 decode.
Re:Proprietary formats suck. (Score:5, Informative)
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?... [youtube.com] formats 248 and 313 respectively.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
I'm still using a 2.4GHz Core 2 Duo. Your 4-year-old CPU may be "ancient" to you but it's still way more powerful than what the average user has.
Re: (Score:2)
interesting. 24 inch monitor I cant tell the difference between 1440p and 2160p in that video. I do notice an ever slight small difference between 1080p and 1440p but so minor if you had 2 images side by side I probably wouldnt be able to tell you which was which. Ill have to try it on my higher res 27" screen at home.
Which CPU are you talkin about ? (Score:5, Interesting)
So 720p decoding in CPU is probably achievable, but 1080p or 4K... not so much.
Which CPU are you talking about?
The huge power hungry multi-core x86_64, optionally assisted by massively parallel GPUs (running opencl) that sits on your desk ?
well decoding high res video is a walk in the park.
The small diminutive ARM designed to be as power efficient as possible that is in your pocket?
much more problematic. it won't pack enough power for higher resolutions, and in the cases were it *DOES* manage to code the video real time, it's going to kill the batter really fast.
The situation of VP9 isn't that different than H.265
- desktops work well enough even without dedicated acceleration
- smartphone are limited by the current lack of acceleration (well except the few latest phone which slowly start to get H265 hardware) due to CPU limits and battery life.
Re: (Score:2)
If you want to group them, then:
VP9 competes with (and loses to) h.264.
VP10 will compete with (and lose to) h.265.
h.265 is "current gen". h.264 is "last gen".
Wedge in VP9 and 10 wherever you want.
You can easily play 4K h.264 files via CPU decoding if they're encoded sanely.
You can fail to play 1080p h.264 files via CPU or GPU decoding if they're encoded crazily.
Re: (Score:2)
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.
For H.264, multithreading was an afterthought, I know HEVC has wavefront parallel processing that you can find a good illustration of here:
http://www.parabolaresearch.co... [parabolaresearch.com]
If VP9 also has any similar features it should do fine on a multicore desktop, even if it lacks GPU support.
Re: (Score:2)
You know if all youtube vids are being delivered in this encoding already? In my desktop I would want the new encoding, but on my phone while on wifi I would rather have the old one. Is there any flag to send so I can request one encoding or the other?
Re: (Score:2)
Might be possible. I CPU decode pretty danged near everything at the moment in order to take advantage of custom DShow filters in ffdshow.
Re: (Score:3)
In this field, patents are possibly more important. There are just so many of them, h264 needed a consortium to make cross-licensing deals possible.
Re: (Score:3)
Re: (Score:2, Informative)
Have they bothered to come up with a decent easy to use encoder/decoder?
Well, here's a list [webmproject.org]. Some are free, some (like Sorenson Squeeze) cost money. VLC [videolan.org] can also transcode to WebM. Handbrake does support VP8, but to a Matroska [matroska.org] container (WebM is a subset of Matroska).
Re: (Score:1)
gimmie a break, the command line encoder is fine. just cut and paste from the example in the VPx wiki page and you're in business.
Should Handbrake have VPx + Opus support in additional containers out of the box? Hell yes. But until then the command line version works just fine.
Fear of the CLI is just plain Gump-level stupid.
Re: (Score:2, Interesting)
refusal to compete has made Lunix (which is a fitting title as its run by loonies) so low on every metric other than servers
Linux is probably the most installed and most widely used operating system in the world. It's in servers, routers, smart TVs, mobile phones, tablets, etc. It's massively successful.
name any major sites OTHER than Google that supports WebM?
Okay, I've disabled H.264 support in Firefox 38 beta. Let's try some sites and see what works!
Microsoft's Channel 9 [msdn.com] supports WebM and works.
Yahoo Screen [yahoo.com] supports WebM and works.
Yahoo Music [yahoo.com] supports WebM and works.
Revision 3 [revision3.com] supports WebM and works.
Wikipedia [wikipedia.org] supports WebM and works.
Name any hardware OEMs supporting WebM acceleration?
Well, here's a list [webmproject.org]. It features names like Inte
Re: (Score:2)
Nothing new to see here people. Just a repeat of an earlier discussion. [slashdot.org]
Re: (Score:1)
Youtube Center works perfectly fine to download off youtube.
How about using an add-on that's actually being worked on?
Re: (Score:1)
A complete failure. If all you wanted was a first post, you would have been better off just randomly typing keys, instead of revealing your complete ignorance.
Re:Horrible artifacts (Score:5, Insightful)
Re: (Score:1)
Re:Money (Score:5, Insightful)
Wow what a bunch of monsters.
Re: (Score:2)
they're able to deliver _the same_ product to their users at lower cost (to them).
Re:Money (Score:4, Interesting)
bandwidth costs Google money
Bandwidth costs everybody money. The worse your options are, the more large bitrates cost, and those costs rise rapidly.
Re: (Score:3, Interesting)
umm, you just affirmed capitalism as the greatest growth engine in the history of man. though i doubt you meant to.
How Many Features? (Score:4, Interesting)
I was dismayed to click on the YouTube video editor today to be told I need a modern version of Flash to use it. I remember back to 2010 when YouTube was going to go all html5 within a year or two. It's amazing how the YouTube division can't afford to hire people to work on these things...
VP9's place in the landscape (Score:5, Informative)
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 [slashdot.org], 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.
Re: (Score:1)
It could simply be that a few companies want to get more money from H.265.
I think it's this. The companies involved weren't satisfied with the licensing terms the MPEG LA had decided on so they formed a competing pool.
Whatever their motivations, it's exactly these licensing complications that make it clear that the best way forward for video on the Web is to develop a high quality, royalty-free codec that everyone will implement. A video codec that gets standardized through the Internet Engineering Task Force [ietf.org] is more likely to the implemented by the likes of Apple and Microsoft t
Re:VP9's place in the landscape (Score:4, Interesting)
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.
I don't think even Google's lawyers could with certainty say they don't violate any obscure video patent somewhere. The GIF standard was torpedoed by a single patent, I'd be most surprised if there wasn't at least one shark in the water with a patent that VP9 violates, just waiting for it to get popular and to sue in East Texas for billions rather than play MPEG LAs game. Why be one of hundreds of sharks getting a nibble of the H.264 patents when you can be the one raking in all the VP9 patent royalties with a cut from every Android device sold?
You don't need to be an evil mastermind to come up with that plan, just your average corporate scum which is why Google doesn't really want to commit. They want to use the VPx codecs to force reasonable H.264/H.265 license terms, but much like people waving around the threat to migrate to Linux they don't really want to jump into the unknown waters unless they have to. Is it FUD? Well, that depends on whether you believe there's a real chance of shark attack or not. Not every warning of danger is FUD.
Laches defense (Score:2)
I'd be most surprised if there wasn't at least one shark in the water with a patent that VP9 violates, just waiting for it to get popular
Last time I checked, intentionally waiting for a patented process to become popular before suing was a good way to get your cause of action estopped by laches [wikipedia.org].
Re: (Score:2)
Not really, the doctrine of latches has two catches:
1. It involves an unreasonable delay in filing a lawsuit, not in discovering infringement. If you hear a 50 year old song on the radio and go "Hey... my dad wrote that 51 years ago" you can sue today, unless there's a statue of limitations. On the other hand if it was because of the band breaking up and you disagree with the way the copyrights were divided, the doctrine of latches would apply because your dad should have filed suit 50 years ago. It might a
Re: (Score:2)
If you hear a 50 year old song on the radio and go "Hey... my dad wrote that 51 years ago" you can sue today
In a case like that, what steps should a songwriter reasonably have taken to avoid infringing copyright, or at least to avoid being bankrupted by an award of damages?
there's no law against sticking your head in the sand for a few years before discovering your patent is being infringed
But there's a big difference between that and "just waiting for it to get popular". The latter sort of implies that the patent holder has discovered the alleged infringement.
The other big limitation is that it only applies to damages from before the filing of the lawsuit
Once alleged infringers are made aware of alleged widespread infringement, expect a design-around to become adopted. PNG was a design-around for still GIF and turned out to
Re: (Score:2, Interesting)
I don't know of any neutral parties who have really tested this who consider VP9 to be "superior" to H.264. The two codecs have different strengths and weaknesses, but VP9 is definitely not a generation ahead of H.264 in performance. And nowhere near H.265 (which is why Google is busy developing VP10).
VP8 being open source and not having any specific patent challenges yet is in now way a guarantee for VPx use not infringing on p
Re:VP9's place in the landscape (Score:5, Interesting)
You'd be wrong about that actually. Monty's given it his usual expert and honest analysis, see one of his blog posts from late last year. Caveat: If you compare VP9 today vs. some tuned H.265 of the future the roles may reverse. Or not. Who knows that's just pure speculation and it's not like VP9 won't tune up either.
In fact VP9 spec was finalized quarters before H.265, and Google has the ear and other anatomical bits of all the hardware manufactures in the Android world, so VP9 hardware support from the start is in very good shape.
And what is never mentioned in the press releases is that VP9 and H.265 make their impressive bandwidth (or filesize) improvements at the cost of double the CPU needs. You do not want to be running these codecs without hardware support.
The exciting stuff is Daala [xiph.org].
Re: (Score:2)
All of the hardware manufacturers in the Android world? Google has no control over half of the Android phones in the world -- those selling in China and India running AOSP.
Ask Adobe how far anything on the web gets without Apple's support.
Re: (Score:2)
I'll still count it as a win if every phone ships with H.265 and VP9.
Samsung Galaxy S6 has built-in hardware support for VP9, AFAIK. It is the first phone to have this.
Hasn't Google been doing that for a while now? (Score:4, Interesting)
I use youtube-dl to download presentations from Youtube. I have been getting VP9 webms for months from Youtube. If you type youtube -F , you can see all the DASH webm streams, which are encoded by VP9. The non-DASH webms are VP8 videos. With youtube-dl, you can select the DASH video and audio streams and combine them with ffmpeg. The file sizes are indeed much better.
Short Test Video:
youtube-dl --prefer-ffmpeg -f 247+171 https://www.youtube.com/watch?... [youtube.com]
39 secs of this 720p clip comes out to 5.6 MB. With H264, it would 10.8 MB.
The only problem I have is that I have to play them by dropping them in Firefox. I have not managed to get any of my desktop media players to get the codecs (Ubuntu 14.04). If any of you solved this, let me know.
Re: (Score:2)
I can't answer your question but the html5 player is much more efficient than the Flash player and I've set it as the default in Firefox. I find that a video would buffer more often using the Flash player compared to the html5 player.
Does it mean the video has been encoded in VP9 if the nerd stats say DASH in Flash? The html5 stats say explicitly VP9.
Re: (Score:2)
> Does it mean the video has been encoded in VP9 if the nerd stats say DASH in Flash?
Not all DASH streams are VP9. From what I have seen: The mp4 streams (DASH and non-DASH) are h264. webm DASH streams are VP9. webm non-DASH is VP8.
Re: (Score:2, Interesting)
You could try VLC 3.0 nightly (http://nightlies.videolan.org/)
Re: (Score:2)
That worked. Thanks.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Yes, worked for me too. Thanks.
"intergrate video in interface" isn't working though. Had the same problem with nightlies too.
Re: (Score:2)
I do indeed prefer mplayer over VLC since the CPU utilization is better. However, my mplayer does not do VP9. VLC nightly was suggested and it worked. But I would like to switch back to mplayer as soon as I can.
I did update my ffmpeg. The one that comes with Trusty did not work with youtube-dl.
Re: (Score:2)
Re: (Score:2)
Darn you, Google! (Score:2)
Dangit. Just when I get YouTube working well on my Amiga using HTML5 and H.264. But it pushes the CPU right to the edge. I haven't got a snowball's chance with VP9.
Not on an 800 MHz 603e equivalent, anyway.
*shakes tiny fist*
(My especially weird hobby hardware aside, the CPU requirement increase does kinda suck.)
Flogging that horse (Score:2)
"it can now play silky smooth 720p with VP9.""
Really? This is their selling point.
It's dead, Jim. Time to join Buzz, Gears and the others.
Re: (Score:2)