Google VP9 "Next Generation Open Video" information posted

[benwaggoner]

I attended Google's "Next Generation Open Video" summit back in July. They've now posted links to the presentations from that.

• NGOV Product Requirements (M. Frost / J. Luther, 68kB PDF)
• WebM Product Updates

•WebM Update (J. Bankoski, HTML5-format)
• WebM Adoption (J. Luther, 137kB PDF)

• NGOV Project Update (P. Wilkins, 1.2MB PDF)

•Comparative Visualizations (P. Wilkins, HTML5-format)

• WebM Contribution Process (J. Koleszar, 1.2MB 1.2MB PDF)
• NGOV in Hardware (A. Kuusela, 180kB PDF)
• Further Video Use Cases (H. Finnan, 601kB PDF)
• WebP Still Image (P. Massimino, 697kB PDF)

The two HTML5 links aren't working correctly for me.

There's plenty of interesting ideas in there. I do think that they need to clearly define Levels, which wasn't then on their roadmap.

[mandarinka]

In VP8 temporal layers use the Golden and Alt-Ref frames so that they cannot be used for boosting compression efficiency. An easy solution would be to add more alt-refs.

I like how they see that it needs b-frames and h.264-style multiple references, but seem to not be permitted to say that. :3

[hajj_3]

"Reduce video bitrate by 50% with image quality comparable to VP8 (SSIM, PSNR)."

This to me says they aren't looking to increase the video quality just reduce the bandwidth? 50% lower bandwidth than webm isn't as good as hevc is in quality terms.

Google should just joing forces with mozilla and xiph and help with Daala video codec development. It says that NGOV must work on core i5 processors that are out in Q3 2013, so presumably NGOV won't be out atleast until then.

[sneaker_ger]

Originally Posted by hajj_3

This to me says they aren't looking to increase the video quality just reduce the bandwidth?

"Increasing video quality" and "reducing bandwidth" are the same thing.

[benwaggoner]

Originally Posted by sneaker_ger

"Increasing video quality" and "reducing bandwidth" are the same thing.

And, relevant to veterans of VPx, they are also working to increase maximum quality of the NGOV codec to support visually lossless encoding, which wasn't always possible with earlier versions. So they should be able to support higher quality than was possible before.

I had the odd realization that I'd been working with the TrueMotion/VPx codecs and their developers for years longer than anyone currently working on the project! The last guy who was at Duck when I had my first business meeting with them left four years ago...

[iwod]

I stopped reading when they said VP8 was better then H264. Obviously they didn't use x264 encoder. And yes, if they should join force with the Daala codec development.

Apparently when On2 was bought, Google made sure to bring along their marketeers as well. It is laughable that they still try to claim VP8 is superior to H.264. As was noted when VP8 first came out, they basically gimped the output to make VP8 look better and then threw in a bunch of fancy looking graphs to "prove" how great it was.

[benwaggoner]

Originally Posted by iwod

I stopped reading when they said VP8 was better then H264. Obviously they didn't use x264 encoder. And yes, if they should join force with the Daala codec development.

I asked about that. This is actually a comparison with x264 and VP8 when encoding for YouTube. However, I believe they were comparing PSNR. x264 by default, and when used appropriately, rather pointedly doesn't tune for PSNR, but for perceptual quality.

The current VP8 encoders are very much tuned for PSNR; althogh I think they have implemented an SSIM tuning mode recently.

I wouldn't at all be surprised if when looking for the bitrate that gives the same PSNR between a typical x264 setting and a typical VP8 setting, VP8 would need a somewhat lower bitrate. However, I don't find that a particularly interesting comparison.

The Google people certainly spoke about the importance of tuning for perceptual quality, not just PSNR and SSIM. But at that point in NGOV codec work, it didn't sound like they'd done that much perceptual tuning yet. Which isn't unreasonable at an early stage of codec development; I doubt that much percuptual tuning has been done for HEVC implementations yet either.

[smok3]

some suggestions:
0 - make it easy for a user to actually use it properly (One-fits-all approach will not help here), "nvob -good and film file.mov -o file.gov" should be my default
0 - make it not suck like vp8

Originally Posted by benwaggoner

I asked about that. This is actually a comparison with x264 and VP8 when encoding for YouTube.

So basically just another gimped comparison. The fact that they could get x264 output to look so poorly on Youtube seems to be quite a feat unto itself.

[benwaggoner]

Originally Posted by SassBot

So basically just another gimped comparison. The fact that they could get x264 output to look so poorly on Youtube seems to be quite a feat unto itself.

Oh, the people who make the x264 settings for YouTube know and care about what they're doing, and certainly aren't gimping anything. I think most YouTube quality issues are due to source issues. When I've tested with difficult content in pristine quality, they've produced reasonably good quality for those bitrates and encoding times.

Not what I could have hand-tuned on my own with a lot more CPU cycles, but their business is going to care a lot about picojoules per pixel!

While they may not have intentionally done so, the output still looked worse, yes even with high quality source, than anything I was able to do locally. This wasn't using some command string where I turned every knob thinking I was doing something magical, but simply just using the --preset and --tune system. Google could also easily afford to use more CPU cycles than I can.

[Asmodian]

Ah but how would Google decide which --tune to use? Also while they could afford it each CPU cycle costs money which they could be keeping, and remember they are encoding really a lot of video.

Originally Posted by Asmodian

Ah but how would Google decide which --tune to use?

They don't need to. Just use the fast decode tune like I was.

Originally Posted by Asmodian

Also while they could afford it each CPU cycle costs money which they could be keeping, and remember they are encoding really a lot of video.

Sure, but I was using the faster presets. If I was comparing their output versus using veryslow then sure that would be an absurd comparison. Considering the immense amount of capacity they have they could easily afford to use slower presets than I did especially with the clip length limits of 15 minutes and the fact that most clips are far shorter than that.

[vivan]

Looks like they messed up some graphs.
E.g. youtube doesn't use WebM for 480p. Also checked 10 random popular videos - for 360p resoultion youtube used 16-18% higher bitrate for WebM in all of them. And from 2 to hilarious 121% for 720p. Lol.

Originally Posted by benwaggoner

I think most YouTube quality issues are due to source issues.

And what about vimeo? What magic are they using, so their encoding is so much better?

[Bloax]

Well too bad they absolutely insist on recoding every single x264 video so that it looks absolutely stunning.

Or well, You go compare the youtube version to the Original video.

Of course I was very generous with bitrate on this one, but it's not like I can't get a fine looking video at half the size.
(Merely, it's because I actually wanted to try and avoid argh quality on Youtube.)

[oibaf]

There is an updated (2012-11-04) document about VP-Next: Overview of VP-Next - Objectives & Progress. This is the Google presentation for the first video-codec IETF working group (2012-11-05).

Also, on the libvpx experimental git branch, VP-Next was definitively renamed to VP9.

The last slide of the PDF has current status:

[iwod]

I mean why compare a Company Backed Resources Heavy Tuned Encoder to a Video Standard Codec's Reference Encoder? I bet x264 would have beaten the HEVC reference encoder as well.

Heck, when H.264 first came out it didn't even touch xvid in terms of quality.

This whole thing is still very On2. Very unlike Google. Not that i like Google at all but i would have thought there will be less BS and more Engineering.

[oibaf]

There are two new branches on libvpx git: vp9-preview and pcs-2013 (this last one seems a showcase for Picture Coding Symposium 2013?).

[Kurtnoise]

Wanna test VP9 compressor ?

In addition, Chromium has added VP9 support few days ago, including Opus as Audio Codec...