Google VP9 "Next Generation Open Video" information posted

[mandarinka]

Hmm, using Chromium sadly isn't ideal for decoding/viewing the encode... The author of the build didn't compile vpxdec too, by any chance?

[Kurtnoise]

Here is a new build including the VP9 compressor & decompressor.

I'll try to add avisynth support today.

[mandarinka]

Thanks, I'll have a look. BTW, if anybody else is going to, you need to have Visual C++ Redistributable for Visual Studio 2012 installed (this)

Edit: Dunno why but it didn't want to decode VP9 encoded with --ivf /I assumed that is raw output/, but webm works.

[Leeloo Minaï]

Originally Posted by Kurtnoise

Here is a new build including the VP9 compressor & decompressor.

I'll try to add avisynth support today.

Thanks for this build, it is interesting to notice we can encode VP8 and VP9 videos with the same program.

[Sagittaire]

Originally Posted by Kurtnoise

Here is a new build including the VP9 compressor & decompressor.

I'll try to add avisynth support today.

well at this time VP9 in unable to obtain higher psnr than x264 ... and by far

[IgorC]

psnr, ssim and other for kids.

Can anybody post some screenshots for VP9 vs x264 or streams?

[Sagittaire]

Originally Posted by IgorC

psnr, ssim and other for kids.

Can anybody post some screenshots for VP9 vs x264 or streams?

Perhaps at 0.1 dB ... but not at 1.0 dB.

And to finish screenshots are more for kids than metric because screenshoot are unable to compare video for these reasons:
- Frame quality flicking: modern codec have really different frame type (Iframe, Pframe, Bframe, bFrame). With same image N you can compare Iframe for codec A and bframe for codec B.
- Rate Control: with the same codec you can configure really different RC or ratio between Frame type.
- Temporal artefact: Screenshots are unable to detect quality flick between frame (like metric for block flicking anyway)
- ... etc etc

With screenshot (and "good" screen choice) it's easy for me to make the demonstration than old DivX3 codec is better than x264. It will be hard to make that with metric ... ;-)

[mandarinka]

Originally Posted by Sagittaire

- Rate Control: with the same codec you can configure really different RC or ratio between Frame type.

Well, VP9 only has pframes still, afaik, so no problem.

I deleted my samples, sadly, but VP9 was easily beaten by x264 visually (I tested a DVD source at 3 megabits to see if it will still have quality issues with that generous bitrate).

The ratecontrol is probably faulty, select frames were even noticeably worse than VP8 with same settings.
Looking at the encoder parameters, I didn't find any mentions of adaptive quantization. A year or so back I heard that libvpx actually has some sort of AQ, but god knows how to enable it. (Any tips?)

--codec=vp9 --width=704 --height=480 --fps=24000/1001 --i420 --target-bitrate=3000 --auto-alt-ref --threads=1 --kf-max-dist=480 --passes=2 --end-usage=vbr --good --cpu-used=0 --min-q=0 --max-q=60 --drop-frame=0

--preset veryslow --pass 2 --bitrate 3000

[Sagittaire]

Well, VP9 only has pframes still, afaik, so no problem.

but x264 have I,P,B,b ... so screenshoot will always fails to make comparison.

I deleted my samples, sadly, but VP9 was easily beaten by x264 visually (I tested a DVD source at 3 megabits to see if it will still have quality issues with that generous bitrate).

Like say psnr or ssim ... ;-)

The ratecontrol is probably faulty, select frames were even noticeably worse than VP8 with same settings.

No problem with constant quantizer. Anyway the RC for VP9 seem not so bad (OPSNR higher in two pass mode than constant quantizer mode mean generaly good RC).

[benwaggoner]

Originally Posted by Sagittaire

Perhaps at 0.1 dB ... but not at 1.0 dB.

Also, On2 codecs have historically been extremely tuned for PSNR.

So if they were going to do well on one metric, that may well be it.

Of course, this is pretty early in the codec's development, so we shouldn't prejudge how good it will be in the end.

[mandarinka]

Constant quantizer is inefficient in x264, why would it be more efficient than 2-pass in VP8/9? Even the official breakdown of parameters for VP8 states that 2pass is better.

I said lack of bframes is no problem, because comparing VP8's pframe with x264's bframe is only going to hurt x264. When VP8/9 still looks bad there, the bias clearly wasn't enough to skew the result
BTW VP8/9 doesn'T seem to have more stable quality in the individual frames, despite no bframes. It has this crap-soso-okay-soso-crap-soso-crap frame cycling, so for all practical purposes, I don'T care if it has bframes under the hood or not.

In any case, the results were fairly conclusive over a series of frames. I didn't check just one pair, naturally.
I would love if it was possible to use some psychovisual model in the encoder, but its --tune parameter has only two options: PSNR and SSIM. So not much hope there.

[Sagittaire]

Finally after command line optimisation I obtain that:

|--------------|---------|---------|---------|---------|---------|
| Codec        |  PProc  | Bitrate |   Size  |  OPSNR  |  SSIM 2 |
|--------------|---------|---------|---------|---------|---------|
| DivX6 ASP    |   PP4   |   896   |  13493  |  42.78  |  77.99  |
| XviD ASP     |   PP4   |   896   |  13489  |  42.66  |  77.96  |
| LAVC ASP     |   PP4   |   897   |  13528  |  42.83  |  77.93  |
| Ateme AVC    |   PP0   |   896   |  13495  |  43.75  |  81.59  |
| x264 AVC     |   PP0   |   896   |  13509  |  44.30  |  82.44  |
| Elecard AVC  |   PP0   |   896   |  13481  |  43.71  |  81.13  |
| VP7          |   PP2   |   897   |  13534  |  43.34  |  80.02  |
| VP8          |   PP0   |   897   |  13549  |  43.27  |         |
| VP9          |   PP0   |   897   |  13510  |  43.98  |         |
| VC1          |   PP1   |   896   |  13510  |  43.06  |  78.75  |
| RV10         |   HF2   |   896   |  13493  |  42.77  |  77.72  |
| DivX3        |   PP4   |   896   |  13508  |  41.84  |  74.40  |
|--------------|---------|---------|---------|---------|---------|

VP9 is in "H264 codec group" for OPSNR, it's not so bad.

Constant quantizer is inefficient in x264

it's not true ... and by far. More quality level you have and more constant quantizer you must have. For exemple for Blu-Ray encoding, the best RC profil is near constant quantizer (better visual result are for high qpcomp and low P,B ratio). OPSNR for constant quantizer is near default RC for x264.

[mandarinka]

Well, (g/o/a)psnr can be wherever it wants to be. If the look of the video is godawful, it's meaningless. I don't want a codec to put numbers in a table, I need it to encode those obnoxious pictures

As for CQP, I'll just say that I doubt that a with the force of thousand suns and that's it o/. If nothing else, you definitely don't want all the macroblocks in a frame to have a common fixed QP.

[Sagittaire]

Originally Posted by mandarinka

Well, (g/o/a)psnr can be wherever it wants to be. If the look of the video is godawful, it's meaningless. I don't want a codec to put numbers in a table, I need it to encode those obnoxious pictures

"I don't want a codec to put numbers in a table?" Anyway it's by definition the work of codec video. For codec pictures are just number in a table ... ;-)

As for CQP, I'll just say that I doubt that a with the force of thousand suns and that's it o/. If nothing else, you definitely don't want all the macroblocks in a frame to have a common fixed QP.

IMO AQ don't make miracle for HVS with H264. There are many other function more powerfull for psy in x264.

[iwod]

Now slightly offtopic, What ever happened to xvp8? May be xvp9 will come before even xvp8?

[Kurtnoise]

Originally Posted by iwod

Now slightly offtopic, What ever happened to xvp8? May be xvp9 will come before even xvp8?

Still in development : https://github.com/DarkShikari/xvp8

Originally Posted by Sagittaire

Finally after command line optimisation

Could you share your command line please ?

[oibaf]

It looks libvpx 1.2.0 was tagged, altough still not announced on the web site. It also includes vp9, but it's not reported in the changelog, probably it still needs more work before being finalized and usable.

[easyfab]

could someone build avplay from lu-zero github : https://github.com/lu-zero/libav/tree/exp

Avconv is ok for me but i can't build avpaly (problem with my sdl lib)

[iwod]

Originally Posted by Kurtnoise

Still in development : https://github.com/DarkShikari/xvp8


Could you share your command line please ?

But havn't been touched since august.

It was also interesting that DS is doing it. I thought someone else was.

[Sagittaire]

Originally Posted by Kurtnoise

Could you share your command line please ?

yes ....

vpxenc hp.yuv -o outfile.webm --end-usage="vbr" --passes=2 --pass=1 --fpf="test.log" --target-bitrate=900 --min-q=1 --max-q=60 --best -v -t 4 -w 720 -h 304 --cpu-used=0 --fps=25000/1000 --lag-in-frames=25 --codec=vp9 --auto-alt-ref=1 --kf-max-dist=250 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=75 --minsection-pct=0 --maxsection-pct=800 --auto-alt-ref=1 --sharpness=0 --noise-sensitivity=0 --tune="psnr" --psnr

vpxenc hp.yuv -o outfile.webm --end-usage="vbr" --passes=2 --pass=2 --fpf="test.log" --target-bitrate=900 --min-q=1 --max-q=60 --best -v -t 4 -w 720 -h 304 --cpu-used=0 --fps=25000/1000 --lag-in-frames=25 --codec=vp9 --auto-alt-ref=1 --kf-max-dist=250 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=75 --minsection-pct=0 --maxsection-pct=800 --auto-alt-ref=1 --sharpness=0 --noise-sensitivity=0 --tune="psnr" --psnr --undershoot-pct=75 --overshoot-pct=125