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
They're able to deliver a better product to their users at a lower cost.
Wow what a bunch of monsters.
bandwidth costs Google money
Bandwidth costs everybody money. The worse your options are, the more large bitrates cost, and those costs rise rapidly.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
umm, you just affirmed capitalism as the greatest growth engine in the history of man. though i doubt you meant to.
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...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
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.
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?...
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.
Have they bothered to come up with a decent easy to use encoder/decoder? You look at every format that has taken off, from MPG 2 to DivX, MP3 to H.264 you have plenty of easy to use decoders that anybody can use to convert their files to the new format. WebM? Sorry but the tools suuuuuck, the few GUI encoders that support WebM make lousy conversions, hell even Handbrake has H.264 support, WebM? Nada.
So if they want this format to take off? Then it has to be as easy or easier to use than the other formats. Lets hope they don't do like MSFT did with WMA/WMV and spend all their time only pushing it for their devices/services as they'll find out like MSFT that shit just won't fly.
ACs don't waste your time replying, your posts are never seen by me.
The Snapdragon 805 and newer has hardware accelerated VP9 decode.
That doesn't prove anything. It could have had all those ringing and mosquito noise artifacts when it was uploaded, and the vp9 could be completely transparent. Since we can't see the original file uploaded there's no telling how good or bad VP9 actually is. For all we know, that file could've been encoded in MJPEG then uploaded. Those ringing artifacts are pretty common with JPEG DCT type compression.
Hectice, baby, Mercator says hello to you
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).
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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 on pages 26, 27 and 28 in the NetVC presentation. The first codec on page 27 has a better PSNR score than Daala 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 will probably end up being Daala merged with other contributions.
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 supports WebM and works.
Yahoo Screen supports WebM and works.
Yahoo Music supports WebM and works.
Revision 3 supports WebM and works.
Wikipedia supports WebM and works.
Name any hardware OEMs supporting WebM acceleration?
Well, here's a list. It features names like Intel, Broadcom, Qualcomm, Rockchip, Nvidia, Samsung and so on.