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
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.
They're able to deliver a better product to their users at a lower cost.
Wow what a bunch of monsters.
Youtube Center works perfectly fine to download off youtube.
How about using an add-on that's actually being worked on?
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 got confused by almost well written post and and I clicked on this shit. fuck you!
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 ]
Typically web players do not provide hardware acceleration for any codecs. Usually only the framebuffer is hardware accelerated.
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.)
Proof?
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.qut.edu.au/81842/
"The BjÃntegaard metric is used to calculate the bitrate saving achieved by the test
encoders, based on the PSNR scores. As five bitrates were implemented in this study, a five-
point BjÃntegaard calculation was carried out. The results of the BjÃntegaard metric, shown in
Table 14, revealed the average bitrate saving that the VP9 and H.265/AVC encoders achieved,
relative to H.264/AVC encoder. Depending on the types of video contents, the H.265/AVC
and VP9 encoders are up to 63.8% and 73.1% more effective than the H.264/AVC encoder for
720p and 1080p resolutions respectively. When spatial resolution increases, the performance
edge of the H.265/AVC and VP9 encoders against H.264/AVC encoder will further increase.
Regardless of the spatial resolutions, both the 4th generation video encoders, H.265/AVC
and VP9, outperformed H.264/AVC by a wide visible margin. Table 15 provides the bitrate
saving of the H.265/AVC encoder over the VP9 encoder. The H.265/AVC encoder achieved
up to about 26% of bitrate saving relative to VP9. The bitrate saving achieved by the
H.265/AVC encoder is about 5% to 6% higher than the VP9 encoder under 720p resolution,
and 3% higher under 1080p resolution. However, the H.265/AVC encoder achieved a
significantly higher bitrate saving than that of VP9 for content 1 and content 6, which both
contain extreme motions as well as image details for both spatial resolutions."
Nah. Polysynthesis Filterbank is the way to go.
"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.
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.
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...
If VP9 also has any similar features it should do fine on a multicore desktop, even if it lacks GPU support.
Live today, because you never know what tomorrow brings
On my Haswell quad, I'm seeing about 10%-15%(12% typical) for 1080p and 35%-55%(45% typical) for 4k, 0 dropped frames.
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.
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?
On my 16-core (32 HT) Haswell the CPU usage is also negligible. But the goal of my past was to show it plays fine even on an ancient hardware.
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.
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.
Get free satoshi (Bitcoin) and Dogecoins
> 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 outperformed HVEC on a single data point, for all the other 269 data points HVEC was varyingly degrees of better.
A quote says it all:
"Substantial quality improvements of HEVC coding algorithm in relation to AVC and VP9 are visible especially for lower bit-rates."
> which, if you believe it, would imply that a whole bunch of very smart people at Google have spent several years wasting their time.
Or that a whole bunch of very smart people *over the entire planet Earth* collectively outperformed a smaller number of very smart people at Google.
Nothing new to see here people. Just a repeat of an earlier discussion.
they're able to deliver _the same_ product to their users at lower cost (to them).
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.
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.
Might be possible. I CPU decode pretty danged near everything at the moment in order to take advantage of custom DShow filters in ffdshow.