As more people watch more high-quality videos across more screens, we need video formats that provide better resolution without increasing bandwidth usage. That’s why we started encoding YouTube videos in VP9, the open-source codec that brings HD and even 4K (2160p) quality at half the bandwidth used by other known codecs.
VP9 is the most efficient video compression codec in widespread use today. In the last year alone, YouTube users have already watched more than 25 billion hours of VP9 video, billions of which would not have been played in HD without VP9’s bandwidth benefits. And with more of our device partners adopting VP9, we wanted to give you a primer on the technology.
Good. We don’t want yet another closed, user-hostile codec.
Google really do confuse me sometimes. I would have expected them to have tossed this project a long time ago.
Why? It’s beneficial to them in multiple ways.
Both VP9 and HEVC have a potential of becoming really important to people who want to stream live-video to the Internet or who wish to upload videos; with datacaps smaller filesizes for videos could possibly mean you won’t go over the cap so easily or you could upload more videos before doing so, and Steam – broadcasting, Twitch and the likes could allow you to stream higher-quality video to your viewers if only those services supported the codecs. (I am personally quite fond of Steam’s broadcasting-feature, it’s pretty great in so many ways.)
What needs to happen, though, is that hardware-vendors start to support those codecs. And the H/W-based encoders need to produce better quality than they do now; I have tried both NVIDIA’s NVENC and Intel’s QuickSync and they both need ~5 times higher bitrate to achieve similar quality as to what e.g. the software-encoder ffmpeg with –preset medium produces. That’s just awful. Both HEVC and VP9 being a whole effing lot heavier codecs to encode than H.264 doing the encoding in software in real-time simply isn’t feasible unless you’ve got a dedicated monster-setup just for the encoding and a separate machine for source-material.
I find that so weird. I have 90mbit or maybe it is 120mbit now because they keep upgrading it. For 65 euros including tv/radio/telephone. No data limit as far as I know of. 9ms ping.
I would like better codecs so we can finally get rid of those stupid artifacts and ludicrous 100GB high res movies.
You are talking about download-bandwidth. Uploading videos, streaming to Twitch etc. are all dependant on upload-bandwidth. High download-bandwidths are irrelevant in relation to what I was talking about.
I have suspicion though that media hardware/software industry will pick h265 as it’s made by the same “industry”, manufacturers still having contracts with MPEG, pricing known and so on. MPEG can also offer discounts for a manufacturer if it doesn’t make any device with VP9 and so on. So for a realistic thinking, these open source projects, even backed by Google are to fresh for the slow changing industries.
Well, they should not, as it is illegal on most countries do so, as it is easily identified as an anticompetitive practice.
Another HEVC patent pool formed (HEVC Advance) – so this might not be true anymore or at least complicates the situation around HEVC. It is now a good opportunity for google to push VP9 more.
Fortunately we all know what happens to industries that are slow on the uptake and can’t adapt….
as more and more of those hardware devices run Android, they also find VP9 support is already there for free. they don’t have to make any effort to have it supported.
but not hw decoding
There are already SoCs with VP9 hardware support: http://wiki.webmproject.org/hardware/socs Expect it soon to be supported by all new chips.
Last time I looked into it VP9 was basically on par with h264, only slightly outperforming it in some situations. I wait for Daala, which is more interesting and seemingly closer to h265 potential performance.
At least currently, the vp9 encoder is really slow. May not be a problem for Google and their encoding farms, but it is for home use. And it does not convince me quality-wise. It is better than vp8, but not by much, especially when considering the difference in encoding speed.
With the libvpx-1.4.0 release, I repeated my test of encoding chapter 3 of the Serenity DVD. It’s a dark video, which provides a difficult challenge for encoders. Encoding was done on a Haswell i5-4570S processor.
Here’s the script I used, where you can see the settings for each encoder: http://pastebin.ca/2968939
The output of that script, where you can see encoding times: http://pastebin.ca/2968940
And the most important part, example pictures from the encoded video – for each of the three pics, the order is original, theora, vp8, vp9, x264, x265, xvid: http://www.imagebam.com/gallery/mi8nde2rfmk17itz72n185tsk6uhcsoy/
My take: x264 is still king, it’s both fast and produces the highest quality – in the third pic, it’s the only one that preserves both the bolts around the door and the belt on Mal’s back.
x265 still needs tuning, it has more tech than x264 at its disposal, but for now, without the years of tuning x264 has had, can’t use the new tech to produce a better picture.
vp8 and vp9 are just not there quality-wise, but vp8 is at least very fast.
I expect criticism of my settings and choice of video, so let me say this: An encoder should do well on all videos, including dark scenes such as this one. And it should be reasonably fast – if you advocate using stronger settings, well, that would slow down the encode even more, while not sufficiently increasing the quality.
So no need to point out that I used weaker settings for vp9 compared to vp8, it was deliberate to further highlight the speed difference. Even so, vp9 did better, and even if I matched the settings, it would not reach x264 quality.