Google VP9 "Next Generation Open Video" information posted

[Nintendo Maniac 64]

Yes, rather interesting, funny (sad?) how vp9 isn't better than AVC.

To me it would seem that, via the Sintel2 test (slide 16), VP9 is very competitive at low bitrates, particularly those that are below 2Mbps. It's once you start to go above that and approach 5Mbps that it ends up only being around AVC level.

This focus on low bitrates makes sense considering the internet focus of VP9. While you cannot typically use such a low bitrate for 4k content, contrary to popular belief, 4k was never actually the focus of VP9 - rather, much like AVC, there's just no inherent limitation preventing it from being used for 4k content.

Therefore I think it's safe to say that VP9 is clearly not optimized for high bitrates.

[benwaggoner]

Yes, rather interesting, funny (sad?) how vp9 isn't better than AVC. HEVC (HM15) is doing pretty well but I wonder how well x265 would do considering it has problem with beating x264...
I note that they're using only a 64 pixel motion search range with HEVC, and a 128 with H.264. That might have some impact.

Also, I'm a little confused about the apparent differentiation they're making between intra period and GOP size. They list an 8-frame GOP for both H.264 and HEVC, but then say they're using a 1 second intra period for all three codecs. Anyone know what I'm missing there?

If VP9 is having to use fewer I-frames in Sintel, which has a lot of frame-to-frame consistency, that could explain its relatively strong performance on that clip.

[xooyoozoo]

They list an 8-frame GOP for both H.264 and HEVC, but then say they're using a 1 second intra period for all three codecs. Anyone know what I'm missing there?

They use it to describe how the biprediction hierarchy is structured. In their parlance, an IbBbP cadence would be '4-frame GOP'.

[benwaggoner]

They use it to describe how the biprediction hierarchy is structured. In their parlance, an IbBbP cadence would be '4-frame GOP'.


So IbBbPbBbPbBbPbBbPbBbPbI would be a 1second IDR interval with 4 frame GOP?

A weird nomenclature, but makes sense I guess. And it wouldn't apply to VP9 as it lacks B-frames.


-Ben Waggoner

[fumoffu]

To me it would seem that, via the Sintel2 test (slide 16), VP9 is very competitive at low bitrates, particularly those that are below 2Mbps. It's once you start to go above that and approach 5Mbps that it ends up only being around AVC level.
...


But Sintel2 is only 1 of 4 tests and it's pretty particular being 3D animation. And they tested this one with such a low bitrates only because it was already close enough to transparent at those bitrates so there was no point in testing in higher bitrates. All the test were done at low bitrates (considering the resolution) so you can not say that VP9 is optimized for low bitrates. If anything you can say that VP9 does better than AVC in low complexity video.

[Nintendo Maniac 64]

All the test were done at low bitrates (considering the resolution) so you can not say that VP9 is optimized for low bitrates.
Well it's hard to determine this when they only tested at a single resolution for everything and Sintel2 was the only test that even had those kinds of low bitrates.

Also, my 3Mbps/768Kbps internet takes offense at you calling 5-10Mbps "low bitrates". :p

If anything you can say that VP9 does better than AVC in low complexity video.

Or heck for all we know it could be both.

[fumoffu]

Well it's hard to determine this when they only tested at a single resolution for everything and Sintel2 was the only test that even had those kinds of low bitrates.

Also, my 3Mbps/768Kbps internet takes offense at you calling 5-10Mbps "low bitrates". :p



It's not hard to determine if you study and understand the graphs.
And while 5Mbps can be high bitrate for maybe 720p it's definitely low for 4K video. The only reason they tested Sintel 2 even lower is it must have been very compressible (probably because it was mostly blurry while color and not much movement).

[Nintendo Maniac 64]

But it was my impression that quality does not always scale equally with a linear increase of bitrate and resolution of the same video material.

[fumoffu]

But it was my impression that quality does not always scale equally with a linear increase of bitrate and resolution of the same video material.

I don't even know what you are talking about now. Do you have a point?

[benwaggoner]

But it was my impression that quality does not always scale equally with a linear increase of bitrate and resolution of the same video material.
If you can come up with a linear scale for perceptual quality with an automated way to measure it, period, you would be very rich very quickly :).

Even if you had, it still wouldn't be linear to other parameters. Once you have enough bits to hit perceptual transparency, more bits just makes it look exactly the same. Sometimes doubling bitrate makes a huge quality difference, sometimes it makes a small one. Sometimes doubling resolution makes a huge difference, sometimes it isn't even noticeable.

[Nintendo Maniac 64]

Sometimes doubling bitrate makes a huge quality difference, sometimes it makes a small one. Sometimes doubling resolution makes a huge difference, sometimes it isn't even noticeable.

That's my point; many (if not all) of those variables do not linearly change relative to one-another, so one cannot assume that the same content at 1/4 the resolution and 1/4 the bitrate will result in the same quality.

[benwaggoner]

That's my point; many (if not all) of those variables do not linearly change relative to one-another, so one cannot assume that the same content at 1/4 the resolution and 1/4 the bitrate will result in the same quality.
It would be startling if they did.

We can expect an ordinal relationship, and probably an polynomial one, but definitely not linear. Even with VC-1 we expected bitrate to change relative to frame size to only the power of 0.75, Thus going from 640x480 to 1280x960 would be around a 2.6x increase, not 4x. Newer codecs would likely have a somewhat lower exponent as they get more efficient at coding large smooth regions.

[xooyoozoo]

"Google's Web-video ambitions bump into hard reality" (http://www.cnet.com/news/googles-web-video-ambitions-run-into-industry-reality/) :



VP10 development has begun, and Google aims to release new versions of its codec every year and a half.
The gap between VP8 and VP9 was 24 months, but he hopes Google can get iteration cycles down to 18 months.



wat

Yea, making yourself a fast-moving target ruins all chances of achieving broad consumer hardware support (or even just plain support).

"We have yet to look at VP10," Encoding.com's Heil said, "and will probably not do so unless VP9 shows some more traction."

[zerowalker]

This kinds sucks.

Development sure is good. But a Standard should (sadly) be slow in order for it to be widely spread.
When VP10 comes, not all videos will be in VP9, making it worthless, and then just repeat that cycle.

Though i do hope this somehow brings pressure to the Codec industry, as it's not going fast enough;P

[Nintendo Maniac 64]

Yea, making yourself a fast-moving target ruins all chances of achieving broad consumer hardware support (or even just plain support).

I'd like to point out 2 things...

1. Nobody is using anything but h.264 on mobile devices anyway due to the proliferation of h.264 hardware decoding. Non-mobile can get along with software decoding just fine - we did it for years with h.264.

2. Chrome auto-update. Even if YouTube and Chrome end up being the only actual use-cases of VP9 and VP10, the bandwidth savings will still be worth it to Google.

[zerowalker]

True indeed.

Still wondering about how they are aiming to implement the Codecs. As VP9 is currently only in Popular Videos (or Channels it seems).
And i got 2k of videos, and only like 4 of them are VP9, so for a "normal user" that should say something;P

[dapperdan]

At their dev thing in the Summer Google claimed that 60% of Youtube videos delivered to the Chrome browser were VP9.

I'd assume, as it seems the most sensible way to do it, that they'll be starting with the most popular videos and working their way down, since that gives the best return on investment. Since Youtube probably has a "fat head/long tail" distribution, I'd imagine that they could achieve that number with relatively few videos. I say 'relatively' since every number I read about the scale of Youtube boggles my mind. When I randomly check the "stats for nerds" it's invariably VP9 when I'm using Chrome, though my browser of choice is Firefox which doesn't yet support the VP9 and Youtube in combination.

Google are also supposed to be targetting this coming quarter for starting to use VP9 with WebRTC in realtime video communications. Apple just announced their new phones would use HEVC for Facetime video (though with the interesting caveat that it specifies cellular: "FaceTime over cellular uses H.264/H.265"). That seems the next most interesting battle ground for the codec wars.

[zerowalker]

Well i guess that's true.

probably like 99% of the videos are H264, but the popular ones may be much higher, as there is so many more watching those.
Still, quite weird.

They are making VP9, using a random bitrate, which can either be higher or lower. And VP9 will also take more space (as an additional Codec to store).
Then with VP10 it's all over again.

Storage must really be much cheaper than bandwidth. Understandable, but still when you think about all the videos, quite hard to grasp the space just 1 video will take (as they also include the original).


WebRTC with VP9 is something i look forward to. Not really using it, but VP8 isn't the latest and greatest, even though it's viable.
Interested if it's really feasible by then, as currently it's extremely slow last i checked.

[kidjan]

I'm surprised that article doesn't mention WebRTC at all. Although there's still some question of codec support, in practice people are overwhelmingly using VP8.

Nobody is using anything but h.264 on mobile devices anyway due to the proliferation of h.264 hardware decoding. Non-mobile can get along with software decoding just fine - we did it for years with h.264.

This is becoming less true with WebRTC. In theory WebRTC supports both codecs. In practice, nobody really cares about H.264 because the number of clients that support it is a subset of the clients that support VP8. We use VP8 on all of our mobile apps that leverage WebRTC; we wouldn't change this so long as Chrome and FF have common support for VP8. The only way we'd even consider H.264 would be if MSFT were to provide WebRTC support in IE. Even then, their market share would still be dramatically smaller, so they really don't have much leverage.

Even more frustrating is Apple not allowing any sort of access to H.264 hardware encode/decode, so you're all on the ARM core anyway for *any* codec. The situation isn't much better on Android, where it's a bit of a crapshoot how well the hardware encoder/decoder are going to work. Due to both of these reasons....it's just way easier to use libvpx built-in to webrtc than try to mix stuff up.

[dapperdan]

Have you been able to measure an impact from using libvpx rather than hardware? When making the case for VP8 as a mandatory to implement codec for WebRTC Google argued that since WebRTC required the screen to be on, and two way traffic on the device's radios, that the "hardware" vs "software" advantage would be minimized as part of the overall power budget.

(They also argued that most hardware codec support lacked support for WebRTC features e.g. decoding multiple small images in a multi-person chat rather than one big video. I think the only mobile video chat service the could find that actually used hardware was Apple's Face time, presumably because they can control the entire chain from start to finish)

[Selur]

Wondering: Is VP9 development now dead since VP10 development started?

I mean last time I checked:
a. 2pass encoding really was bad (never hitting any bit rate restriction even closely)
b. encoding was really slow (which they know http://wiki.webmproject.org/vp9/known-issues)
c. VP8 documentation is not the best and VP9 documentation barely exists
-> I personally kind of gave up on VPX, since Google clearly should have the money to fix these issues, but they choose not to. Instead they start the next codec which I fear will also be kind of abandoned and more a Google intern thing than really useful.

Cu Selur

[dapperdan]

You can follow what they're doing online via git commit:

http://git.chromium.org/gitweb/?p=webm/libvpx.git

They seem to be keeping themselves busy, but don't seem to talk about their progress as much as they used to. The Youtube switchover to VP9 means they've got solid economic reasons to continue to improve VP9 even as they begin planning for VP10.

edit:

commits mentioning "VP8":

http://git.chromium.org/gitweb/?p=webm/libvpx.git&a=search&h=HEAD&st=commit&s=vp8

commits mentioning "VP9":

http://git.chromium.org/gitweb/?p=webm/libvpx.git&a=search&h=HEAD&st=commit&s=vp9

commits mentioning "VP10": (currently none)

http://git.chromium.org/gitweb/?p=webm/libvpx.git&a=search&h=HEAD&st=commit&s=vp10

[Selur]

-> unless I missed something, it seems like Google is not interested in multithreading

[Kurtnoise]

vp9 multithreading is supported in the decoding part though...

[Selur]

Yes, makes sense that they would want fast decoding. Multithreading for encoding probably isn't that interesting for them since they simply run multiple encodes in parallel. (unlike the normal private user, they have 'enough' content they want to convert)

[dapperdan]

I would guess multithreading encoding may become more important as they push VP9 usage in WebRTC. Since that use case is realtime encoding and often on mobile devices with 8 relatively-weak cores.

[mandarinka]

Have you been able to measure an impact from using libvpx rather than hardware? When making the case for VP8 as a mandatory to implement codec for WebRTC Google argued that since WebRTC required the screen to be on, and two way traffic on the device's radios, that the "hardware" vs "software" advantage would be minimized as part of the overall power budget.

(They also argued that most hardware codec support lacked support for WebRTC features e.g. decoding multiple small images in a multi-person chat rather than one big video. I think the only mobile video chat service the could find that actually used hardware was Apple's Face time, presumably because they can control the entire chain from start to finish)

Question is if those are really true or just propaganda to get their way over the opposing camp's arguments.

[Nintendo Maniac 64]

Well I know from experience that VP8 at 720p/30fps is light enough on the CPU that even a 2GHz single core Northwood Pentium 4 without hyperthreading can do it (though it almost completely maxes out the CPU).

If you aren't aware, the per-GHz performance of the Pentium 4 was really quite poor (the following image shows Prescott 2M rather than Northwood, but they still had similar performance-per-clock):
http://www.tomshardware.com/reviews/processor-architecture-benchmark,2974-15.html[/url]"]http://media.bestofmicro.com/I/O/298752/original/overall.png

[mandarinka]

Did you check really hard scenes though?
Usually you can play most of scenes in videos on weak CPUs, but then in some spikes the cpu usage can go to a double of the average load, and that is where the playback breaks.

Example: You can play 720p HEVC with current libavcodec on Atom Z3740 mostly at about 60 % cpu mostly, but in some scenes, the complexity raises and you fail to get realtime at 100 % cpu usage (judging by the slowdown, the cpu usage in those hard scenes is at least 2x the one in the simpler ones).

[Nintendo Maniac 64]

I used a video of F-Zero GX. In case you aren't aware, that game is known to stress YouTube's compressor to the point that using YouTube to demonstrate the game in HD via Dolphin is (or at least was) commonly a practice in futility.

I used either this video:
http://www.youtube.com/watch?v=8Z6A7rCF8P0

Or this video:
https://www.youtube.com/watch?v=vnc-c2SCz_0


Take note however that YouTube's 720p VP8 encodings no longer exist, only the 360p VP8 encodings are still present - all other current WebM formats use VP9.


EDIT: Relevant 2-year-old post:
http://forum.doom9.org/showthread.php?p=1565270#post1565270

[dapperdan]

A video recording of a talk mentioned previously, talking about rolling out VP9 at Youtube:

http://vimeo.com/109102513

The start is a brief into to video codecs, the Youtube specific stuff starts about 10 minutes in.

Some interesting bits:

Youtube splits up videos and encodes pieces of them in parallel across clusters of machines.
The fact that their most popular videos are so much more popular allowed them to put a ridiculously slow encoder into production and then iterate.
They thought VP9 was doing much better (in terms of user metrics) than H.264, then realised that they were comparing the most popular videos in VP9 againts all videos in H.264. Once they compared like with like VP9 had some big issues, mostly due to decoder speed so they pulled it back out of production.
They came up with hueristics to indentify slow machines, basically "if it runs XP", and don't serve VP9 to them.
Currently serving a billion VP9 videos a day.

[Selur]

Youtube splits up videos and encodes pieces of them in parallel across clusters of machines.
that explains why multi-threading isn't that interesting to them.

[BadFrame]

Interesting talk, thanks for the link DapperDan.

that explains why multi-threading isn't that interesting to them.

Well I'm sure it's interesting to them, and to be implemented (vp8 is multithreaded), however with this method it's not a 'burning issue' in order for them to test it in production (Youtube), which in turn allows the VP9 development to remain easier as they don't have to take multi-treading in to account as of yet.

Looking at the VP9 commits, it's still in heavy development/tuning/optimization, and I assume that any effort in adding multi-treading support will wait until that calms down (perhaps coinciding with a focus shift on to the upcoming VP10).

[Kurtnoise]

VP9 decoding support in iOS (http://t.co/1xpPksn02q)...

[Reel.Deel]

Anyone know of any recent VP9 binaries?

[Selur]

I use https://github.com/jb-alvarado/media-autobuild_suite to build up-to-date vpxenc binaries whenever I need a new version or I release a new Hybrid version.

[Kurtnoise]

Anyone know of any recent VP9 binaries?
x86 (http://www.mediafire.com/download/iqr945djdc5h7jl/vpx_x86_20141101.7z) & x64 (http://www.mediafire.com/download/3aieuvqlgkvgap9/vpx_x64_20141101.7z) binaries from today...

[dapperdan]

VP9 now available for use with WebRTC in dev builds of Chrome:

https://plus.google.com/u/0/+JustinUberti/posts/3FLVapCvDaG

[xooyoozoo]

Several companies (including Google) made presentations (http://mpeg.chiariglione.org/standards/exploration/internet-video-coding-internet-video-coding/presentations-brainstorming) on their codec needs and expectations for future, hypothetical standards.

Google reiterated their desires for faster codec development cycles and will release something new/better every 2 years.

It's obvious that hardware-decoding support won't be a big part of Google's future plans, but that's only a downside in practice if VP9 was going to attain a major hardware support base in the first place (let's be real here...). My guess is that Google hopes rapid mobile silicon improvements and rapid mobile upgrade cycles will bring enough CPU performance to enough people for software Youtube decoding.

Something of note in the other participant's presentations is that Netflix and telecom Orange believe a hypothetical 25% compression improvement is not enough for them to migrate to any new codec. I wonder why Youtube/Google has different needs here.

[mzso]

Yeah. That's not a valid link.

Anyway I read that that ARM was/is working on OpenCL HEVC/VP9 decoders. Which worked rather well.

[xooyoozoo]

Whoops fixed.

[Selur]

I wonder why Youtube/Google has different needs here.
probably the sheer amount of video data they handle is more and thus 25% improvement means enough in absolute numbers to be worth the effort.

[xooyoozoo]

I mentioned Netflix previously because "Netflix is using a whopping 20% more bandwidth than the nearest downstream competitor, YouTube (http://thenextweb.com/apps/2014/11/21/netflix-now-accounts-35-overall-us-internet-traffic/)".

[Selur]

isn't that U.S. only?

[xooyoozoo]

isn't that U.S. only?

Hmm you're right. Without hard numbers, though, I'm still unconvinced Youtube's worldwide bandwidth would put it in a special position in this context, especially when 50% of Youtube's traffic (http://recode.net/2014/10/27/youtube-code-mobile-1/) is on hardware-decode-dependent mobile.

VP9 now available for use with WebRTC in dev builds of Chrome:

https://plus.google.com/u/0/+JustinUberti/posts/3FLVapCvDaG

It seems like they set the VP9's speed-quality preset to 6 (http://git.chromium.org/gitweb/?p=external/webrtc/trunk/webrtc.git;a=blob;f=modules/video_coding/codecs/vp9/vp9_impl.cc#l193) (0 is slowest/best, >0 faster/worse).

I wonder how RD efficiency compares to Quicksync, NVENC, or the average built-in encoder on an ARM SoC.

[mandarinka]

I find it funny that they think that they need a new format every 2 years beause progress is not fast enough. But in practice, 2 years are too little to implement a good encoder, hence they will be leaving the benefits of each of those new formats on the table, basically, compared to standard competition with tuned encoders...

OTOH, not like On2 encoders were ever good, so maybe they are just giving up on that front and this is how they want to overcome the difficulty? Silly if true.

[mzso]

I mentioned Netflix previously because "Netflix is using a whopping 20% more bandwidth than the nearest downstream competitor, YouTube (http://thenextweb.com/apps/2014/11/21/netflix-now-accounts-35-overall-us-internet-traffic/)".

Yeah that's because of super wastefulness. If YT and Netflix would work on a P2P basis the traffic would be much smaller.

[dapperdan]

I would guess what sets Youtube apart is being able to control Chrome and Android, whereas Netflix is a lot more dependant on 3rd party browsers, set-top-boxes etc. so they need to play it safe and go with the slower refresh rate e.g. they say that in terms of royalty free it makes no direct difference to them except that it affects them if it slows uptake of the new codecs in devices, and that 25% improvement wouldn't be enough for them due to not everyone switching over immediately.

If the codec is 25% better and you can deliver it to 10% of your customers then you only get 2.5% benefit, 50% of your customers gets you a 12.5% benefit, 100% of your customers gets you the full 25%. I'd guess Youtube is better able to deliver newer codecs to customers than Netflix and so needs smaller efficiency gains to make the transition worthwhile e.g. they apparently have 60% of desktop views (which makes it about 30% of all views) on VP9 despite only having one browser that supports Youtube's VP9 delivery system (Firefox is working on it, no-one else seems interested. Note that I'm not sure that Chrome being better for Youtube than rival browsers actually hurts Google if it causes people to switch).

Combine that with the point from the VP9 at Youtube talk, that Youtube content is heavily skewed with popular videos being really popular and viral which pays them back if they can spot them and put extra CPU time into encoding those, which again reduces the absolute efficiency gain required before it pays back.

It's not all plain sailing though, I just bought an Android phone from Google that does VP8, AVC and HEVC encode/decode in hardware but not VP9. The continued success of Android and the mandate to support Vp9 though seems like it'll prompt competition between chipmakers on that front and break down the patent bogeyman eventually.

[benwaggoner]

Yeah that's because of super wastefulness. If YT and Netflix would work on a P2P basis the traffic would be much smaller.
Given the asymmetry of consumer broadband (much faster downloads than uploads), and that using a given amount of upload typically knocks out a lot more download capacity, P2P isn't that great for streaming. It seems like if you have a 50/10 connection, using 5 Mbps of upload "uses" 25 Mbps of download. So P2P can really cap the actual deliverable bandwidth by a lot.

Plus it's really impolite on mobile devices.

Anyway, as to WebM, I doubt Google does it because it pencils out in a cost/benefit spreadsheet, unless it's a really long term one.

[Nintendo Maniac 64]

I wonder why Youtube/Google has different needs here.

They're pretty much limited only by bandwidth costs - all they need to do is roll out support for a "VP10" in both Chrome and YouTube and that alone would give quite a few bandwidth savings.