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 (http://downloads.webmproject.org/ngov2012/pdf/02-ngov-product-requirements.pdf)(M. Frost / J. Luther, 68kB PDF)
• WebM Product Updates
•WebM Update (http://downloads.webmproject.org/ngov2012/bankoski/vpnextsummit.html)(J. Bankoski, HTML5-format)
• WebM Adoption (http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-update.pdf)(J. Luther, 137kB PDF)• NGOV Project Update (http://downloads.webmproject.org/ngov2012/pdf/04-ngov-project-update.pdf)(P. Wilkins, 1.2MB PDF)
•Comparative Visualizations (http://downloads.webmproject.org/ngov2012/wilkins/vpnext-results.html)(P. Wilkins, HTML5-format)• WebM Contribution Process (http://downloads.webmproject.org/ngov2012/pdf/05-ngov-contribution-process.pdf)(J. Koleszar, 1.2MB 1.2MB PDF)
• NGOV in Hardware (http://downloads.webmproject.org/ngov2012/pdf/07-ngov-hardware.pdf)(A. Kuusela, 180kB PDF)
• Further Video Use Cases (http://downloads.webmproject.org/ngov2012/pdf/08-ngov-further-video-use-cases.pdf)(H. Finnan, 601kB PDF)
• WebP Still Image (http://downloads.webmproject.org/ngov2012/pdf/09-ngov-webp-still-image.pdf)(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]

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]

"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.

[SassBot]

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]

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

[SassBot]

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]

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!

[SassBot]

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.

[SassBot]

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

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

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.

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 (http://www.youtube.com/watch?v=LMVp0dvR5Dc) to the Original video (http://www.mediafire.com/?zs147rg4uguz62d).

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 (http://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf). This is the Google presentation for the first video-codec IETF working group (2012-11-05) (https://datatracker.ietf.org/meeting/85/materials.html#wg-videocodec).

Also, on the libvpx experimental git branch (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/experimental), 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 (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/vp9-preview) and pcs-2013 (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/pcs-2013) (this last one seems a showcase for Picture Coding Symposium 2013 (http://www.pcs2013.org/)?).

[Kurtnoise]

Wanna test VP9 compressor (http://www.4everload.com/index.php/download/0db3d3f18b7f/vpxenc-vp9_20121221.zip.html) ?

In addition, Chromium has added VP9 support few days ago (http://peter.sh/2012/12/vp9-and-opus-background-position-offset-and-ruby-positioning/), including Opus as Audio Codec...:)

[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 (http://www.mediafire.com/?vyq5bqh2ct915iv) 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 (http://www.microsoft.com/en-us/download/details.aspx?id=30679))

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ï]

Here is a new build (http://www.mediafire.com/?vyq5bqh2ct915iv) 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]

Here is a new build (http://www.mediafire.com/?vyq5bqh2ct915iv) 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]

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]

- 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]

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 :D
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]

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]

Now slightly offtopic, What ever happened to xvp8? May be xvp9 will come before even xvp8?
Still in development : https://github.com/DarkShikari/xvp8

Finally after command line optimisation
Could you share your command line please ?

[oibaf]

It looks libvpx 1.2.0 was tagged (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commitdiff;h=b9ce43029298182668d4dcb0e0814189e4a63c2a), 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]

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]

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

[xooyoozoo]

Played around with a checkout from master branch on Sat, and the decoder fails with --tune=ssim and --best during scene changes. I then just did a build with their current code, which merged in some goodies from their experimental branch. Now --tune=ssim breaks the encoder instead with "segmentation fault 11" during the first 16 frames of pass 2. Maybe it's auto-alt-ref related, but either way, looks like they definitely aren't developing for SSIM... :confused:

With the older build, I did quick 2pass runs of a dark, slightly grainy source and no tunings on either encoders. VP9 had a lot higher PSNR (maybe it defaults to this tuning) and slightly higher SSIM than x264 placebo (forgot to match keyint though whoops), but x264 fared better visually, especially in scenes of grain against a flat background. VP9 also had this weird thing where grain suddenly reappeared for 1 frame and then goes away again, and the contrast is extreme enough to be noticeable in normal playback.

I think there's definitely still some qp and rc tunings to be done. In terms of objective metrics, however, things are at least very promising.

vpxenc -p 2 -t 1 --codec=vp9 --best --cpu-used=0 \
--target-bitrate=1500 --end-usage=vbr \
--auto-alt-ref=1 -v \
--minsection-pct=5 --maxsection-pct=800 \
--lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 \
--token-parts=2 --static-thresh=0 --drop-frame=0 \
--min-q=0 --max-q=60 \
-o .webm .y4m

No hard numbers because I only wanted tune-ssim results and deleted everything after visual inspection. :o

[xooyoozoo]

Got around to actually testing the most recent build of libvpx, and it's quite something. Here's a chart of my results (http://i.imgur.com/BtuBM.png). If you're wondering about the abundance of metrics, it's because I was trying to see if anything could approximate x264's psy tweaks (nope).

There's no need to mince words: VP9 is impressive. Besides its apparent proficiency in objective metrics, it also *looks* good. I went through the 760-765 kbits clips and in terms of "pleasantness" I'd rank them as xs < xn < hevc =< vp9. The latter two are difficult to choose between because though HEVC makes the image look more 'clean', I think VP9 has some subtle psy tunings that gave more eye-pleasing bit allocations. Of course, this is only one sample, not representative, and so and so on, but we've certainly come a looonnng way since VP8's painfully underwhelming introduction.

Also, a confounding factor in the HEVC's test might be the changed intra period (normally 24 frames) and the 3 adaptive/psy QP switches I turned on. The changed intra period is to match with x264 and VP9, and I double checked the JCT-VC docs the adaptive-qp switches were based off of. The docs all showed increased obj+subj performance, but I guess you never can be sure.

Edit: Oh yea, VPX built on code from late Monday, HM from the weekend, and x264 from November.

Edit (2/2): should have done this little tidbit in the first place:
http://i.imgur.com/ThenIfE.png

[mandarinka]

I went back and made a sample encode with the decemberish build that Kurtnoise posted, since last time I deleted the samples/pictures.
This time I used a DVD source and encoded at 2500kbps. Basically, as you can see from the pictures, the problem is lack of texture/grain preservation, that leads to nasty banding/blocking in flat areas. At the same time, edges are kept dirty, which leaves the image sorta weird.
I didn't do a x264 sample, because with the utter lack of texture preservation in VP9, it would be meaningless to compare differences IMHO.

Here's a comparison with select pics, for illustration: http://check2pic.ru/compare/25338/

<BBB-work> we actually improved a lot since then, so if you want to play around, using a recent snapshot may be a good idea
I'm hoping that the final version of the encoder won't be so smooth-happy...

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

[xooyoozoo]

I'm hoping that the final version of the encoder won't be so smooth-happy...

I did a test a while back and apparently tune=psnr is the default. As in, both encodes (no tunings and psnr tuned) produce exactly the same filesize/metrics, the doc website (http://www.webmproject.org/docs/encoder-parameters/) states something similarly, tune=ssim has been broken for several weeks (http://code.google.com/p/webm/issues/detail?id=518&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary), and oh, they don't even appear to be testing with ssim (http://code.google.com/p/webm/issues/detail?id=518#c7).

That said, at low bitrates where things get desperate, graceful quantization (a la x264) doesn't mean as much as simply having a larger mathematical buffer and getting as much into one bit as possible.

[Kurtnoise]

See post #49

[mandarinka]

Oh, nice! I'll go and have a look later then.

[Selur]

thanks Kurtnoise :)

[m3sh]

Thanks Kurtnoise, been meaning to test this against HEVC.

[Kurtnoise]

Any interests to play with lossless mode ?

new builds uploaded - added Lossless Mode to VP9 + WinXP compatibility + x86 (http://www.mediafire.com/?xyt4vxoy4ylv29d)/x64 (http://www.mediafire.com/?b68m9m855ia19m2) targets

[xooyoozoo]

I came across this discussion (https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/codec-devel/dsr56_2Nj3E) in vpx development google group. It produced this quote concerning GOP lengths: We used default for each (so 250 for x264, and 9999 for vpxenc).
We'll try to correct this for future comparisons. which was troubling because, while they didn't specifically mention HEVC, it implies that in most of the tests encodes shown in VP9 slides, HEVC would have had 10+ intra frames while VP9 got away with 1! So I then decided to do my own tests with a few clips while matching GOP lengths. I used HEVC's official bitstream files and results (ftp://ftp.kw.bbc.co.uk/hevc/hm-9.0-anchors/), and matched VP9's GOP length to that. As all of VPx's promotional material emphasizes that it's meant to be a "Web codec", it (hopefully) shouldn't have any problems with 1 intraframe a second (Youtube uses 2 a sec).

Additionally, I wanted to see how VP9 performs with its bleeding edge code. I used the latest Jan-31 commit (c94e55...) and switched on all experiments except for CSM (broken?), 6tap and abovesprefmv; the latter two appear to exist mostly for simplification. A couple of sanity checks showed almost equal PSNR versus vanilla VP9.

VP9 encode paramaters were copied from WebM guide for best quality (http://www.webmproject.org/docs/encoder-parameters/#2-pass-best-quality-vbr-encoding), but kf-max-dist was changed to match GOP and tune=psnr was added. The latter doesn't seem to do anything, but I might as well cover my bases. x264 tests were encoded with veryslow, psnr|ssim, matched keyint, open-gop, and crf.

Base spreadsheet and visual basic bd-rate/interpolation code copy-pasted from JCT-VC L0322 (http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7109).

http://i.imgur.com/F7CJEK7.png

(The data (http://i.imgur.com/jjj0AdS.png))

PSNR-HVS-M is included because I wanted something besides PSNR and single-scale SSIM. The downfalls of the first is obvious, and the second is getting deprecated as a perceptual metric. Some interesting tidbits pertaining to the second point: examples of relative ranking (http://i.imgur.com/1iNt6VE.png) of subjectively vs objectively measured distortion (paper (http://foulard.ece.cornell.edu/dmc27/vsnr/vsnr_a57.pdf)), SSIM's mediocre performance (http://i.imgur.com/GkvZHIU.png) on MPEG distortion (paper (https://etd.lib.metu.edu.tr/upload/12613733/index.pdf)), and statistical ranking of metrics (http://i.imgur.com/ZclTTNu.png) on certain video distortion types (first value of each cell is for compression results, paper (http://live.ece.utexas.edu/publications/2012/moorthy_vqpm2012.pdf)). I was going to include some other metrics (MSSSIM, NQM) but Matlab got the better of me, so next time. ;)

As for subjective results? Well, it's what you'd expect. It's difficult to swing a 40+ percent bitrate disadvantage in VP9's favor.

Edit: (2/6: MOAR PIX) Well, here are some comparison pics for the 3 lower tiers of bitrates. A separate 2pass veryslow no tunings x264 was ran just for this to match bitrates.
Kimono (http://i.minus.com/i0s0XpzE1uH7j.png) (1920x1080p24)
0540: HEVC (http://i.minus.com/ibvRAkKNC0Zwzm.png), VP9 (http://i.minus.com/ikMAcJfbJz6LI.png), x264 (http://i.minus.com/iYK2YZYTEiwbZ.png)
1050: HEVC (http://i.minus.com/iLA0yWRPgJ9aT.png), VP9 (http://i.minus.com/itHPoQOO0qYbo.png), x264 (http://i.minus.com/iml0gqU1WYs2M.png)
2150: HEVC (http://i.minus.com/ibh1E95jdTuz7f.png), VP9 (http://i.minus.com/i88E4YQiBDo4b.png), x264 (http://i.minus.com/if7V4ehbGcqWZ.png)
ParkScene (http://i.minus.com/iQQpAVByNF31G.png) (1920x1080p24)
0710: HEVC (http://i.minus.com/il688wxvxChO9.png), VP9 (http://i.minus.com/iM01lInBtPYHj.png), x264 (http://i.minus.com/igSYhPRTi7pad.png)
1520: HEVC (http://i.minus.com/iXhRzdWaJ25WT.png), VP9 (http://i.minus.com/i8PqfkIQL7t6q.png), x264 (http://i.minus.com/iSy68hwoj0UcX.png)
3275: HEVC (http://i.minus.com/ibdptHz962T8Nd.png), VP9 (http://i.minus.com/ibxR4PHnOcSXEb.png), x264 (http://i.minus.com/ibkzw4uG9lZI72.png)
BasketballDrill (http://i.minus.com/irtQ0Vdd1yX6T.png) (832x480p50)
0430: HEVC (http://i.minus.com/iSYw1KP28huuQ.png), VP9 (http://i.minus.com/ieAMQDdrGoXSW.png), x264 (http://i.minus.com/is1RfuWLrviPh.png)
0815: HEVC (http://i.minus.com/i5CCZ4AQCoTw1.png), VP9 (http://i.minus.com/i7M4F7CTXAH4f.png), x264 (http://i.minus.com/ioZNlsoKdDPBQ.png)
1660: HEVC (http://i.minus.com/iDa0a52zWgkr.png), VP9 (http://i.minus.com/igJH4xcoi1XdI.png), x264 (http://i.minus.com/iblikKTpcGbjJd.png)

[IgorC]

Thank You for interesting information, xooyoozoo. And for screenshots.

Can I ask You to re-do the same test but on real scenario conditions? Like 1-2 Mbits 720p, 3-4 Mbits 1080p and 500-600 kbps for SD, 480-576p.

It's unlikely that someone encodes 1920x1080 at 535 kbps here. :)

:thanks:

P.S. The original.png will be good too.

[xooyoozoo]

It's unlikely that someone encodes 1920x1080 at 535 kbps here.

I wanted to see how and how much each encoder breaks under pressure, but I guess you make a pretty good point. ;)

My post above is updated with two higher tiers of bitrates (which were all originally set by HEVC's constant quantization of 27, 32, and 37). I added reference shots too. Based off those, I think Netflix/iTunes/Hulu-level streaming bitrates are gonna produce significantly higher quality in the coming years.

VP9 and HEVC seem to be on par at about QP=27, with VP9 doing consistently better on the Basketball clip. Maybe VP9 does really well in areas with motion (some of this can be seen on the bicyclers* in the Park clip). I'd like to find out more, but some speed optimization commits are starting to come in the libvpx git, and for my sanity, I think I'll wait some weeks for more to land. :D

* Hmm after looking at the clips some more, I think that VP9 gives more bitrate than necessary to motion, as the bicyclers get attention even though the entire background suffers.

[pieter3d]

* Hmm after looking at the clips some more, I think that VP9 gives more bitrate than necessary to motion, as the bicyclers get attention even though the entire background suffers.

That isn't really something you can attribute to VP9 being VP9, just this particular reference encoder.

[pieter3d]

By the way, where is the source code for VP9 ?

[xooyoozoo]

Here's their git (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=summary). As VP9's bitstream is undergoing rapid change and is experimental in and of itself, one might as well hop on the experimental branch too. :)

If anyone's curious, here are the clips for 1660kbps BasketballDrill: HEVC (https://mega.co.nz/#!PNFxkbJB!OI3DkRldPIB0Q6fUszvWpyaCITovAimrcizMb7v-QR4), VP9 (https://mega.co.nz/#!rYcjWLrY!XM3HtANOZNvT_BsNTncNeHKYT5AnItdH6-gT8AfHs-I), x264 (https://mega.co.nz/#!nVsjwACb!IcFPMnoSp0RH8x-9pOiMhnmw7d9KWowALgnqzv1swNo).

The first two are lossless mkvs at 60 MB each. The third is in its native 2MB (lol).

[Kurtnoise]

There is something wrong with your samples..these are all AVC streams.

http://uppix.net/1/1/2/99fd5e4029a17fd03ea0a66f78cc7.png

[xooyoozoo]

They were reencoded losslessly (qp = 0) from decoded YUV files. "High 444 Predictive" shown above is the Predictive Lossless profile. (Edit: the snapshots taken above were taken via ffmpeg at time -ss 00:00:09.38 which I think makes it the 469th frame)

[MasterNobody]

My small H.265/HEVC vs VP9 vs x264 codec comparison (http://forum.doom9.org/showthread.php?p=1615159#post1615159)

[MasterNobody]

Comparison pictures for you:
...
Without encoded samples and used encoding params for both encoders that is only two blurry images nothing more. Also 1000 kbps is insane for 720p 50fps (if you really encoded it as 50fps) even if you take into account marketing 50% less bitrate than H.264 (except if we talk about anime or flash-animation).

Here is two more blurry images for you: x264_nopsy (http://i.minus.com/iLtqfL8x0EMor.png), x264_psy (http://i.minus.com/iSpn1t4NLkeJu.png)
Samples: x264_nopsy.mkv (http://www.sendspace.com/file/b0vxen), x264_psy.mkv (http://www.sendspace.com/file/tvhdp3)
Params:
x264 park_joy_420_720p50.y4m -o x264_nopsy.mkv --preset veryslow --keyint infinite --crf 36.2 --psy-rd 0 --threads 1
x264 park_joy_420_720p50.y4m -o x264_psy.mkv --preset veryslow --keyint infinite --crf 38.8 --threads 1

P.S. x264's psy at such bitrates looks psychedelic when watching video (not screenshots)

[xooyoozoo]

Not sure if this was posted elsewhere, but Google published a draft overview (http://tools.ietf.org/html/draft-grange-vp9-bitstream-00) of VP9 on the IETF website last month.

This morning, they also made a blog post (http://blog.webmproject.org/2013/03/onward.html) promising more details about VP9 over the next few weeks. In all likelihood, VP9 will be 'released' at Google I/O in May just like VP8 was back in 2010.

There's been a lot of code cleanups and speed improvements on libvpx's exp. branch over the past couple of weeks too. The encoder is a lot faster now and seems about as fast as the old JM, which sounds like a terrible endorsement, but it's certainly better than before :). Half of the test batch I just made failed to decode though, so win some, lose some.

[xooyoozoo]

Guess which is which? :D

VP8, VP9, x264 or HEVC (https://mega.co.nz/#!GN0TBJZK!M4BW1hrLnA_HcRHdReKjelKGOp094n2w2YL1RwEbnww). Bitstream size set by HEVC QP32.

Theora*, Dirac*, MPEG2 or Xvid (https://mega.co.nz/#!iEkGVBoB!H5Z_1iwFMFplkG8wHT6fAil82jIsBDjVM9WCXkipLSs). Sizes at doubled the above.

Snapshot (http://i3.minus.com/i5vzrESbfwCmX.png) of what you'll be looking at. The two clips are 50-70MB in size. They were reencoded from each encoder's YUV dumps using x264 CRF 10 and is entirely transparent to the main encode.

I didn't like how some of the encoders in the first clip were barely flustered, so I redid that scenario but with HEVC's QP35. This one uses a scene from Big Buck Bunny and has sound: (Edit: on YouTube now (http://www.youtube.com/watch?v=Ctjm1kxw-BM). Realized its recompression doesn't change much in this situation). QP 0 lossless variant (https://mega.co.nz/#!LQ0wTKST!RHJqPC1oilk8aTIZp4T1gVO01chnoTo_JSX6zqNemfg).

Settings (http://pastie.org/6585432) and clip order.
-----
* It's strange to think that these two came out so late (2008) and won over so many on faith alone.

[dapperdan]

* It's strange to think that these two came out so late (2008) and won over so many on faith alone.

2008 seems late for Theora. Wikipedia claims 2004 for initial release. Though it did lie dormant for a while till the search for a codec compatible with the W3C royalty-free standard for HTML5 made it more relevant.

Wikipedia seems to peg 2008 for various firsts for dirac, like publishing the final spec and a 1.0 version of a high-performance non-research implementation. I'm not sure how long it had been floating around before that.

And while hypnotic and fun to look at, isn't this form of testing a bit misleading? Like testing the brakes of 4 cars by driving them right up to a cliff? Yes, you can conclude that the two that aren't flaming fireballs at the foot of the cliff have better brakes than the other two, but you're going to subconsciously group both sets of two closer together (and further from the other group) than is perhaps warranted.

E.g. for me this made me mentally group VP9 and HEVC together, and VP8 and x264, whereas before I may have assumed more of a linear progression: VP8, x264, VP9, HEVC.

I'm also curious about what the red jumper guy is actually supposed to look like in the original Mall scene, is the slightly psychedelic pulsing an artifact of the encoding?.

[dngnta]

Well, they weren't kidding when they said that HEVC is visually even better than what quantitative metrics like PSNR tell you. While examination of individual frames reveals that an incredible amount of detail is thrown away, the temporal stability of hard edges and textures makes the end result much more pleasant to watch in motion than that of any other codec.

HEVC is amazing. Let's hope an open source encoder/decoder comes along soon.

[xooyoozoo]

2008 seems late for Theora. Wikipedia claims 2004 for initial release

I believe the first public 'stable' version came out in 2008? I certainly remember a lot of fanfare when it reached 1.0 (or something) then.

And while hypnotic and fun to look at, isn't this form of testing a bit misleading? Like testing the brakes of 4 cars by driving them right up to a cliff? Yes, you can conclude that the two that aren't flaming fireballs at the foot of the cliff have better brakes than the other two, but you're going to subconsciously group both sets of two closer together (and further from the other group) than is perhaps warranted.

Considering the generational gaps present here, I dont' think there's any sort of visual test holding bitrate constant that won't either park all cars at a Walmart or throw most of them into the ocean.

You're right though, in that a multi-way comparison creates mental groupings that aren't really needed. Despite the pitfalls of objective measurements, an overview of several encoders would probably work better with some hard numbers, of which I certainly have lots and on which I will likely do a post once VP9 is released.

I'm also curious about what the red jumper guy is actually supposed to look like in the original Mall scene, is the slightly psychedelic pulsing an artifact of the encoding?.

In the original raw clip, that pattern looks normal if the image is viewed 1:1. Any sort of resizing in VLC and it's psychedelic again. I think it's just a very difficult pattern.

[Dark Shikari]

"You are not allowed to post or reply until you have been registered for at least 5 days." .. anyone have a doom9 account and can go tell them at http://forum.doom9.org/showpost.php?p=1620374&postcount=65 that the theora format was finalized in 2004. See e.g. http://developers.slashdot.org/story/04/06/15/2250214/theora-i-bistream-format-frozen and that it was largely just a formal specification for and a few minor fixes/enhancements of a format first released to the public in 1999?

5chars

[GTPVHD]

http://blog.webmproject.org/2013/05/vp9-codec-nears-completion.html

[mzso]

Will they make a new "WebP" version too based on VP9?

[hajj_3]

No chance. WebP has taken a long time to be created, for an image format to become a standard it needs to stay the standard for several years or no-one would adopt it. Hence why we don't have h.266 coming out in 2 years. WebP will be good enough for many years to come.

[mzso]

No chance. WebP has taken a long time to be created, for an image format to become a standard it needs to stay the standard for several years or no-one would adopt it. Hence why we don't have h.266 coming out in 2 years. WebP will be good enough for many years to come.

It's not even good now. Last time I checked a few weeks ago due to the facebook using webp news it was still inferior to jpg.

[tuqueque]

@mzso... Boy, WebP is not only superior to JPEG in 95% of cases, but in Lossless mode is superior to PNG in 99% of cases... I'm already switching all of my "raw" lossless data to WebP and have saved around half the space. And considering that I work with PNG sequence animations, that's GBs of information I've saved!

And I reiterate, I also have converted a lot of my lossy data (casual JPEGs like parties and social gatherings taken with my camera) to WebP, again, saving around 40% of data with the same visual quality.

[hajj_3]

@mzso... Boy, WebP is not only superior to JPEG in 95% of cases, but in Lossless mode is superior to PNG in 99% of cases... I'm already switching all of my "raw" lossless data to WebP and have saved around half the space. And considering that I work with PNG sequence animations, that's GBs of information I've saved!

And I reiterate, I also have converted a lot of my lossy data (casual JPEGs like parties and social gatherings taken with my camera) to WebP, again, saving around 40% of data with the same visual quality.

Exactly, the quality of WebP is great, there are a few bugs on their bugtracker left but once those are fixed it will be a great image format: https://code.google.com/p/webp/issues/list

I'll be glad when people stop using .gif animations on reddit and other sites and start using .webp, gif looks terrible, webp looks wonderful for animated images.

[Keiyakusha]

I'll be glad when people stop using .gif animations on reddit and other sites and start using .webp, gif looks terrible, webp looks wonderful for animated images.
How it looks or what it capable of is not an issue here. I can create .gif with Photoshop or thousands of other tools. WebP is around for quite some time already. Is there any convenient tools for working with WebP? Is there native support for it in operating systems and other software? While WebP support remains to be close to zero, people won't start using it.
There was already good formats for lossy/lossless compression like jpeg2000 and apng/mng for animated images. And while they are good (and I believe they are official standards, except apng), hardly anyone uses them. Unfortunately WebP is not any better than those formats.

[tuqueque]

I can start saying (repeating) that WebP is better than PNG in 95% of cases, ergo, is better than APNG and of course, GIF; second, in most cases WebP is better than JPEG... Is just one file format that offers better features/compression/quality than what the other three offer separately... And, oh, yes; is created, developed, maintained and promoted by a dude like Google!... Let's complain less about WebP/WebM not being supported and let's do more promoting them!

In this forums there are like 5 redundant but active threads about H265 stuff and just one about WebM... That's just sad!

Google is implementing WebP in services like Google+, Picasa, Gmail... WebP in Google Maps is not yet supported, but they're getting there... Google is already supporting WebP and WebM in Chrome. I don't use Chrome, but I use Firefox and Mozilla guys a month or so ago said that they were finally considering WebP support... Google is already working in VP9 (in a daily basis with lots of commits: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=log;h=refs/heads/experimental) which will probably be about twice the quality of VP8... VP8 is inferior than H.264, but it's still a dang good video codec and is an open standart! (which I already use frequently)... I'm confident that VP9 will be equal or even slightly better than x264... So, Google is definitely doing its job (an awesome job, BTW) promoting them... Is now our job to give it a real try.

I've suggested the support for WebP in several programs and thanks to that, my favorite image viewer, JPEGView (http://sourceforge.net/projects/jpegview/), now supports loading and saving WebP!

So, when people like us, the users... Stop complaining and start using and promoting demonstrated new (and OPEN) standarts, those standarts will establish!

[Keiyakusha]

Wikipedia says that WebP only supports 8-bit YUV 4:2:0 Is it true? This is unacceptable if it is and format can be thrown into trash can instantly.
Jpeg with maximum quality looks visually lossless while size is like half of the optimized PNG. And this is 4:4:4, Photoshop doesn't even lets you to save jpeg with subsampling.

I just discovered some WebP plugin for photoshop based on libwebp/libvpx. Tried to save photoshop-generated tri-color gradient with it (1024x576, dithered).
With maximum quality (100%) settings I got 20kb file that looks so bad that I'm not even going to post it. Jpeg of the same size created in photoshop looks the same (if not to say better!)
No mentions of any lossless mode or something. And what about metadata or custom ICC profiles? WebP supports that? Not through this plugin at least. But even if that supported in theory, from (non-web)designers and artist's point of view, saving in some intermediate format and then properly converting it to WebP using some commandline tools is not an option.
Also I need a tool that can not only save file, but allows me to specify target filesize instead of desired quality.


I can start saying (repeating) that WebP is better than PNG in 95% of cases, ergo, is better than APNG and of course, GIF; second, in most cases WebP is better than JPEG...
Where is any tools that will allow me and other users to see it? I'd like to test them. Please no commandline stuff. Something with GUI that is easy to use, as we're talking about simple users here. Available tools is what matters for wide adoption, not how good the format is. "open standard" is not something normal users care about.

Edit: To be clear, I don't deny that such tools may exist. I just want information on where they are. But if there is no such tools, even if format many times better than jpeg - it doesn't matter.
Tried plugin for GIMP. the only option is quality. with 100% quality I got 30kb image - a bit more than with Photoshop plugin but looks just as crappy. No mentions of lossless mode, no ways to save real high quality but still lossy image, no mentions about animation, no mentions about ICC profiles, no alpha support. And this is plugin that I need previously find and then install. As a simple user I demand out of the box support. Otherwise this is an image format for geeks.

Edit2: simple example. Below I tried to embed WebP image using tag. It works? Not in firefox at least. As simple user, before I'll even think about using this format, someone have to make sure it does work in all browsers. Even on official WebP presentation page all images converted to png for display. What joke is that?
[IMG]http://www.gstatic.com/webp/gallery3/2_webp_ll.webp

[tuqueque]

@Keiyakusha:
I'm doing some "research" and investigation and I'll get back in a couple of days with more tangible information (and possibly comparisons and tools to create good WebPs)...

simple example. Below I tried to embed WebP image using [img] tag. It works? Not in firefox at least. As simple user, before I'll even think about using this format, someone have to make sure it does work in all browsers. Even on official WebP presentation page all images converted to png for display. What joke is that?

Also, try to embed a Jpeg2000 (which has been out 3 or 4 times as long as WebP)... Good luck with that!

Firefox said it won't support (ever) natively Jpeg2000... OTOH, hopefully, this year we could see support for WebP (which is already supported in Chrome and Opera)... 3 of the 5 major browsers supporting natively WebP this year? that's not a joke, my friend :), WebP guys are trying to improve the format constantly and you can see the improvements with each release.

You described yourself as a simple user (I'm not pointing it out in a bad way; don't take me wrong)... So is natural that while this format is still in adoption process (as it is today), most tools are a bit "unfriendly" and just targeted for advanced users, early adopters, developers and enthusiasts in general. General users will come later (hopefully soon enough)... Anyway, if you feel a little adventurous, in my next post I'll try to talk about a couple of tools that are not entirely friendly, but will meet you half-way.

Greets!

[Keiyakusha]

I'm doing some "research" and investigation and I'll get back in a couple of days with more tangible information (and possibly comparisons and tools to create good WebPs).Don't bother with comparison if you don't feel like it. I have no doubts that lossless WebP is smaller than PNG, or that lossy WebP can perform better than JPEG. I just say that available tools are so bad that they can't show this effectively, most of the features are not available at all.

Also, try to embed a Jpeg2000 (which has been out 3 or 4 times as long as WebP)... Good luck with that!Of course it won't work. But noone here says that I should use jpeg2000 because it's so awesome and I have no plans on using it myself. Otherwise I would make the same example with jpeg2000.

3 of the 5 major browsers supporting natively WebP this year? that's not a joke, my friend :)When I said about joke, I meant that WebP presentation page is a joke because what it really shows is a webp-converted-to-png. Nothing more. They should be forcing mozilla to add WebP support before even creating that page. Or write patch themselves if they have to, firefox is opensource after all.
If something becomes widely supported, it can become a standard (official or de facto). If they want to make standard, they should also make it widely supported. Look at matroska. If there was no mkvtoolnix and haali splitter, everyone would still use avi and occasionally mp4. And even with these epic tools mkv is not as supported as everyone wanted it to.

You described yourself as a simple user (I'm not pointing it out in a bad way; don't take me wrong)... So is natural that while this format is still in adoption process (as it is today), most tools are a bit "unfriendly" and just targeted for advanced users, early adopters, developers and enthusiasts in general. General users will come later (hopefully soon enough)... Anyway, if you feel a little adventurous, in my next post I'll try to talk about a couple of tools that are not entirely friendly, but will meet you half-way.

I don't see any reason to talk about not user-friendly tools, because for me advantages of using WebP is not big enough to make it worth using it instead of good old jpeg/png. Even as advanced user, if lossless WebP can compress 2 times better, it is still not enough for me to switch my production pipeline to it from PNG, because of how much more operations I can already perform on PNG material. And professional tools not getting support for WebP because they also think that improvements are not big enough to make users pay for it, that the format is mature enough to make it high priority. If it will be able to compress 4 times better and decompression wont take any longer than jpeg - then it will be really useful, then it will be instantly supported everywhere.

Edit: BTW, PNG supports bitdepth up to 16bits per channel +alpha. jpeg2000 supports 32bit float +alpha. How about webp? Am I really limited to 8-bit 4:2:0?

[vivan]

IrfanView has webp plugin for opening and saving webp images. It has lossless mode too, I've got ~20% better compression than png with it (and checked that it bit-identical to it). But it slow as hell (like 1 min for compressing 720p image o_O).
As for lossy - it has some presets (text, photo), but the only rate control is «quality». Also it's fast.

Google is already working in VP9 (in a daily basis with lots of commits: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=log;h=refs/heads/experimental) which will probably be about twice the quality of VP8... VP8 is inferior than H.264, but it's still a dang good video codec and is an open standart!H.264 and H.265 are "open standart". VP8 is kinda open, since it specification is available, but it's awful. And have you seen VP9 specs? Me neither.

I'm confident that VP9 will be equal or even slightly better than x264...
So, Google is definitely doing its job (an awesome job, BTW) promoting them... Is now our job to give it a real try.Yeah, awesome job: lying, cheating, making absurd claims, removing H.264 from Chrome...

[dapperdan]

And have you seen VP9 specs? Me neither.

Yeah, awesome job: lying, cheating, making absurd claims, removing H.264 from Chrome...

They published an "overview" of VP9 here:

http://tools.ietf.org/html/draft-grange-vp9-bitstream-00

I assume they'll similarly publish the spec once it's done, like they did for VP8:

http://tools.ietf.org/html/draft-bankoski-vp8-bitstream-06

Also, they never removed H.264 from Chrome and it seems unlikely they will now, though they did announce they were going to a couple of years ago.

[mandarinka]

@mzso... Boy, WebP is not only superior to JPEG in 95% of cases, but in Lossless mode is superior to PNG in 99% of cases... I'm already switching all of my "raw" lossless data to WebP and have saved around half the space. And considering that I work with PNG sequence animations, that's GBs of information I've saved!

My results were much more modest (webp lossless filesizes were pretty unimpressive). Try if you don't get better compression with lossless jpeg 2000 or jpeg-XR (the former achieves better ratios). Make sure though that your software uses the reversible transform and yuv conversions. Jasper (also used in imagemagick) apparently fails to.

[Rumbah]

And this is 4:4:4, Photoshop doesn't even lets you to save jpeg with subsampling.[/IMG]
Photoshop saves jpegs automatically with subsampling depending on the quality you choose (if I remember it correctly 4:2:0 with quality <=6 or 50% with save for web, 4:4:4 above).

[Keiyakusha]

Photoshop saves jpegs automatically with subsampling depending on the quality you choose (if I remember it correctly 4:2:0 with quality <=6 or 50% with save for web, 4:4:4 above).
this is true. but at this point you don't care much about quality so you won't benefit from having no subsampling anyway. I don't remember the case when had so save jpeg with something other than high quality. In fact most of the time I use 10-12. Most of the images I save have gradients of some sort.
The point is that after I saved gradient in webp with max quality, cause of subsampling or some other thing it looks bad compared to jpeg.

This is exactly my thoughts too:
don't believe a niche image format like this will ever be widely-adopted. I hope it isn't, because adoption of a niche format designed solely to save bandwidth will slow the creation and adoption of the *real* successor to JPEG.

[dapperdan]

My results were much more modest (webp lossless filesizes were pretty unimpressive). Try if you don't get better compression with lossless jpeg 2000 or jpeg-XR (the former achieves better ratios). Make sure though that your software uses the reversible transform and yuv conversions. Jasper (also used in imagemagick) apparently fails to.

WebP lossless is basically a different file format from WebP. It's much more PNG-like rather than a lossless version of JPEG.

So you'd expect it to do better on typical web icon type images rather than photos (and it does: http://extrememoderate.wordpress.com/2011/11/28/a-web-centric-image-compression-benchmark/ (http://extrememoderate.wordpress.com/2011/11/28/a-web-centric-image-compression-benchmark)).

This is a fairly direct consequence of WebP in general being designed around making web images smaller and faster. If you've got a photorealistic image then the fastest, most efficient way to deliver it in a webpage is using lossy compression.

[IgorC]

Even on official WebP presentation page all images converted to png for display. What joke is that?

Provide a link where only .png were posted.

[Keiyakusha]

Provide a link where only .png were posted.
I never said that "only png were posted". webm is there too, one of them even embedded in one of my posts. Here (https://developers.google.com/speed/webp/gallery2) is a link for you, but I suggest to re-read what I said about png and browsers support.

[filler56789]

^

Hummm, I use Opera 11.64, and it supports only "normal" WebP. Lossless and lossy-with-alpha-channel get replaced with a placeholder : - /

And no, "full WebP support" is not a good reason for switching to Chrome/Chromium.

[vivan]

Hummm, I use Opera 11.64The lastest Opera is 12.15. And it supports both webp lossless and lossy with alpha.

[filler56789]

Opera 12.xx dropped the "Windows Native Skin" :(

[benwaggoner]

@mzso... Boy, WebP is not only superior to JPEG in 95% of cases, but in Lossless mode is superior to PNG in 99% of cases... I'm already switching all of my "raw" lossless data to WebP and have saved around half the space. And considering that I work with PNG sequence animations, that's GBs of information I've saved!
I think there's a lost opportunity to use H.264 High Profile IDR frames as a still image format. Efficiency is better than WebP, and we'd get hardware decode support on most devices.

HEVC promises to be a very good still image format, particularly at high resolutions.

Getting support for arbitrary bit depths and channels would be great for all these formats, of course, so they could be used for RAW Bayer pattern and that sort of thing. I wish JPEG XR had taken off...

[pieter3d]

HEVC promises to be a very good still image format, particularly at high resolutions.


HEVC even has a special profile just for still images.

[pieter3d]

Here's what I know about VP9 coding tools.

64x64 "superblocks". Each divisible vertically, horzontally or quad. Quad divisions are recursive, so you can have any shape NxM, where N and M are 2^(2..6), and never more than 1 power apart (e.g. 4x4, 16x32, 8x4, 64x64 ... etc).
128x128 support is on the table, but undecided.

4 supported transforms: 4x4, 8x8, 16x16, 32x32. Yes this is the same as HEVC.

10 intra modes at any square size. 6 of these are directional.

1/8th pel motion comp, 8-tap filters. 3 filters (normal, blur, sharpen), selectable per prediction unit or frame.

3 ref pics per pic, but up to 8 pics to hold on to.

Discrete sine transform for intra blocks.

A second loop filter (analogous to SAO in HEVC) is under experimentation.

Bitstreams are still "data paritioned" like vp8, which is a pain for HW designs.

Entropy coding is similar to vp8.

Support for tiles, like HEVC, for parallel decode. Mandated above 2k resolution.

Support for lossless coding, as well as 4:4:4 with alpha.

The picture is still single-loop decodable to make HW implementations simpler.

[tuqueque]

http://www.androidauthority.com/webm-vp9-youtube-209088/ (Let's try to keep this thread WebM-wise and not another H.26x one.)

[GTPVHD]

http://i.imgur.com/cqIQh6y.jpg

From Google I/O 2013.

[kypec]

http://i.imgur.com/cqIQh6y.jpg
From Google I/O 2013.

Awesome comparison! (Not!):mad: If only they published what settings were used for H.264: Profile, Level, CABAC/CAVLC, ref-frames, B-frames, frame resolution, rate etc. etc.
Otherwise it's plain marketing rubbish, nothing more. ;)

[nevcairiel]

It was a quick video show in a keynote, of course its marketing. There is no time in such an event for technical details.

[Keiyakusha]

Awesome comparison! (Not!):mad
They won't benefit from showing something like this (http://i.imgur.com/Zyg5U8r.jpg) Looks like On2 guys taught them how to do the marketing.

[dapperdan]

The had a VP9-focused session directly after the keynote:

https://developers.google.com/events/io/sessions/325741299

But it's not one of the sessions being broadcast/recorded.

I assume they'll post the slides though.

edit: a news story based on the presentation

http://news.cnet.com/8301-1023_3-57584706-93/google-urges-fast-adoption-of-vp9-video-compression/

Best bits:

They claim VP9 saves ~50% bandwith compared with H.264 and is ~1% worse than H.265

There's a VP9 test channel:

http://www.youtube.com/user/WebMVP9/videos

And apparently you can turn on VP9 in Chrome today to view them.

[dapperdan]

The actual bit of the keynote when they talk about VP9 vs H.264

http://youtu.be/9pmPa_KxsAM?t=1h11m47s

They repeat the ~50% figure given above, the slightly larger figure is only for that particular video.

[cogman]

The had a VP9-focused session directly after the keynote:

https://developers.google.com/events/io/sessions/325741299

But it's not one of the sessions being broadcast/recorded.

I assume they'll post the slides though.

edit: a news story based on the presentation

http://news.cnet.com/8301-1023_3-57584706-93/google-urges-fast-adoption-of-vp9-video-compression/

Best bits:

They claim VP9 saves ~50% bandwith compared with H.264 and is ~1% worse than H.265

There's a VP9 test channel:

http://www.youtube.com/user/WebMVP9/videos

And apparently you can turn on VP9 in Chrome today to view them.

http://www.youtube.com/watch?v=thtvQi6fEug&list=PLElsSrqQYMoHPY5k1l-X49OkW6Gz-9_zP&index=1

Ummm... wow, that is pretty terrible quality.

Grass is just one giant blob. Everything is VERY blocky, reminds me of the old xVid days. It is just really, well, terrible.

IDK, maybe the source video was this bad, but man, if they were trying to sell VP9 this video does them no favors.

[mk.2]

Wikipedia says that WebP only supports 8-bit YUV 4:2:0 Is it true?

I think it's true.

I just tried converting Dark Shikari's avatar (http://forum.doom9.org/image.php?u=83421) to WebP with XnView.

Here is the result: http://i.imgur.com/3QP5EZo.png   This is original: http://i.imgur.com/zTTG7XI.png

And that was converted with the best quality setting (http://i.imgur.com/IqeKHAR.png) which suppose to be lossless. I also tried converting with WebP plugin for Photoshop (https://developers.google.com/speed/webp/docs/using). It produced the same result with slightly smaller filesize.

[vivan]

That just means that plugin doesn't support 4:4:4...
https://dl.dropboxusercontent.com/u/16254258/test/d9/DS.webp

[JEEB]

Someone asked me to build vpxenc and vpxdec from the current VP9 experimental branch with just VP9, so here we go (http://x264.fushizen.eu/builds/vpx/vpx_enc_dec_experimental_g18e0742.7z).

Enjoy, and feel free to test.

Edit: Dear BBB said he'd like it if I'd publish the settings I compiled with as well ;) I later also learned that just --disable-vp8 would would have worked the same way for disabling VP8 functionality.
./configure --enable-vp9 --disable-vp8-encoder --disable-vp8-decoder

[hajj_3]

Frost also said that the VP9 bitstream will be frozen on 17 June, with Google's Chrome web browser and Chrome OS to implement VP9 by default.

Source: http://www.theinquirer.net/inquirer/news/2267629/webm-project-says-vp9-video-codec-is-nearing-completion



Mozilla was asked this today:

user: Google said VP9's bitstream will be frozen on 17th june, are you guys still making Daala?
mozilla ceo (brendan eich): Yes, we are. Daala aims to be more forward looking & different. VP9 given the schedule is more incremental.

http://www.youtube.com/watch?v=thtvQi6fEug&list=PLElsSrqQYMoHPY5k1l-X49OkW6Gz-9_zP&index=1

Ummm... wow, that is pretty terrible quality.

Grass is just one giant blob. Everything is VERY blocky, reminds me of the old xVid days. It is just really, well, terrible.

IDK, maybe the source video was this bad, but man, if they were trying to sell VP9 this video does them no favors.

Skip later into the video, the source was bad for the beginning it seems.

[dapperdan]

That just means that plugin doesn't support 4:4:4...
https://dl.dropboxusercontent.com/u/16254258/test/d9/DS.webp

No, it's not supported in lossy webp at all (yet). They're still thinking about how to add it:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webp-discuss/mCWm8IjAYJc


On the other hand he could have saved it as a lossless webp file.

[foxyshadis]

Mozilla was asked this today:

user: Google said VP9's bitstream will be frozen on 17th june, are you guys still making Daala?
mozilla ceo (brendan eich): Yes, we are. Daala aims to be more forward looking & different. VP9 given the schedule is more incremental.

This has serious whiffs of vaporware. Hopefully they're close to having a working prototype that they can add ideas to, instead of pie in the sky ideas and nothing to attach to them.

[foxyshadis]

No, it's not supported in lossy webp at all (yet). They're still thinking about how to add it:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webp-discuss/mCWm8IjAYJc


On the other hand he could have saved it as a lossless webp file.

I've noticed most WebP plugins only support lossy mode, not lossless.

[hajj_3]

This has serious whiffs of vaporware. Hopefully they're close to having a working prototype that they can add ideas to, instead of pie in the sky ideas and nothing to attach to them.

http://git.xiph.org/?p=daala.git;a=shortlog

Here is the VP9 google i/o talk:

http://www.youtube.com/watch?v=K6JshvblIcM

[mzso]

The had a VP9-focused session directly after the keynote:

https://developers.google.com/events/io/sessions/325741299

But it's not one of the sessions being broadcast/recorded.

I assume they'll post the slides though.

edit: a news story based on the presentation

http://news.cnet.com/8301-1023_3-57584706-93/google-urges-fast-adoption-of-vp9-video-compression/

Best bits:

They claim VP9 saves ~50% bandwith compared with H.264 and is ~1% worse than H.265

There's a VP9 test channel:

http://www.youtube.com/user/WebMVP9/videos

And apparently you can turn on VP9 in Chrome today to view them.

How do I play in vp9 mode? For me the video is played by flash so it can't be vp9.

[dapperdan]

How do I play in vp9 mode? For me the video is played by flash so it can't be vp9.

There's a few steps:

* have a recent enough Chrome (28+)
* visit chrome://flags/ and turn VP9 on
* restart chrome
* Join Youtube HTML5 demo here http://www.youtube.com/html5
* View items on those VP9 playlists

You can test what codec you're getting by right clicking and choosing show video info.

[mzso]

There's a few steps:

* have a recent enough Chrome (28+)
* visit chrome://flags/ and turn VP9 on
* restart chrome
* Join Youtube HTML5 demo here http://www.youtube.com/html5
* View items on those VP9 playlists

You can test what codec you're getting by right clicking and choosing show video info.

Huh, I have 27 with vp9 enabled, but I get vp8/vorbis. I guess I'll have to upgrade

[xooyoozoo]

Quick visual comparison using default Main HM 10 configs and "suggested" VP9 settings (http://goo.gl/fQ8BT) on latest experimental libvpx (5f3612c) compiled without any special switches.

Key interval at 32. 2pass VP9 bitrate matched against QP34 HEVC on a Sintel clip.

Here are the bitstreams and a convenient side-by-side cropping+recomposition in predictive lossless. (https://mega.co.nz/#F!yJMEUTCB!Imi4mxhpI3NVf1Z_QNPUFQ)

And this is an extra convenient, if slightly (edit: much) less accurate, version on Youtube (http://youtu.be/yNo9qVQ9Q84). I've learned my lesson and turned off comments. :)

I don't think there's anything new to see here, but it's good to touch base occasionally. The only think left to do is quantify bd-rate differences once the bitstream is finalized and perhaps revisit the codec once or twice a year to determine perceptual encoding improvements. At least the folks at MSU (http://www.compression.ru/video/codec_comparison/index_en.html) will be on top of the last bit.

There's also an in-progress encode using a Tears of Steel clip that I might edit in later if it finishes in a timely manner.

Here's what I know about VP9 coding tools [...]

Thank you for the quick rundown. Do you have a general sense of "inherent" computational complexity vs HEVC?

It occurred to me that VP9's speed advantage over the HM is perplexingly minor despite the former's assembly optimizations. On my system, normal VP9 is "only" 1.3x-1.5x as fast as reference HEVC, which is great for now, but the HM isn't a 'real' encoder. If VP9 is forced to go C-only (--disable-mmx/sse#), theoretically putting it on the same level as HEVC, it slows down by a magnitude.

[IgorC]

xooyoozoo,

Can I ask You what speed do you get with HEVC or VP9 to encode 720/1080p and what is your CPU?

Thank You.

[xooyoozoo]

The encoding machine has a quad-core Nehalem i7 @ 3.5GHz, and the encoders were compiled with gcc-4.8 -O3 -flto -funroll-loops.

I don't have exact numbers, but the clip above took ~3-3.5 hours for HEVC and ~2.5 hours for VP9. Both were single-threaded.

This is pure conjecture, but I'd predict that in the medium term, clever optimizations would increase speed by about a magnitude over reference C-code, and assembly optimizations would then speed things by another magnitude.

[GTPVHD]

http://www.youtube.com/watch?v=K6JshvblIcM

[Beelzebubu]

Bitstreams are still "data paritioned" like vp8, which is a pain for HW designs.

What does this mean? It sounds like you're saying that (like in vp8), modes/mvs and coefficients are in separate data partitions - that's not true in vp9 (it was removed about a year ago). They are interleaved per block. See here (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/encoder/vp9_bitstream.c;h=bcec13c4bedcafe87ad40e0026169bfe362a9207;hb=refs/heads/experimental#l834).

Support for tiles, like HEVC, for parallel decode. Mandated above 2k resolution.

Max. tile size is 4k, not 2k. See here (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/common/vp9_tile_common.c;h=ea26289b76ec1dff6589244c683fcc1cc575c210;hb=refs/heads/experimental#l14).

Other than that, nice rundown, thanks for writing it up.

[vivan]

http://www.youtube.com/watch?v=K6JshvblIcMOmg, he said that "We're using the very best [H.264] encoder with very best settings" and that vp9 is 50% better than that http://5.firepic.org/5/images/2013-05/19/osejf096mh6i.gif

[mzso]

Here are the bitstreams and a convenient side-by-side cropping+recomposition in predictive lossless. (https://mega.co.nz/#F!yJMEUTCB!Imi4mxhpI3NVf1Z_QNPUFQ)

Ugh. This Mega is messed up. It downloads the whole file into some mystical location and then then browser download window pops up to ask where to "download" (copy) the file. Any way to make it download where I want it from the start?

[nevcairiel]

Any way to make it download where I want it from the start?

No. thats how that weird site works.

[vivan]

What's the problem with that?They lie too much.

Can you explain this?
This is screenshot from their presentation (stated as 250 kbps encodes), cropped and downscaled to 720p: http://4.firepic.org/4/images/2013-05/19/6l3zi87aj0uy.png
This is screenshot of the same frame of encoded video (https://dl.dropboxusercontent.com/u/16254258/test/d9/enc.mp4): http://4.firepic.org/4/images/2013-05/19/s184t5fzelr7.png
(Source is 720p mp4 from http://www.youtube.com/watch?v=gF58loLxjRk, downscaled to 360p and encoded at 250 kbps bitrate (2-pass, veryslow preset). Screenshot is upscaled to 720p.)

Why does it look better than both right (supposed to be x264) and left (vp9) sides?

[vivan]

Why did you downscale it to 360p?Because encoding 720p at such bitrate is madness. Even on 240p youtube uses higher bitrate.

The video is available as 720p on YouTube. So, what led you to believe that they did not encode it at 720p for the comparison?I thought that they don't have autism. Looks like I was wrong.

Also, your source is the already compressed YouTube encoded file, whereas their source probably is the original source file that was uploaded to YouTube because them being Google they probably have access to the original uploaded file?Probably. But that makes their encode better, not mine. And that's why I can't compare PSNRs (using PSNR in 2013, lol) too.

[vivan]

Maybe it's madness to use such bitrates with x264, but maybe it's not with VP9?Okay, VP9 is better at producing blurry mess at insane low bitrates.
Sane person would just downscale an get better result with x264, insane would use vp9.

Why would anyone use a proprietary H.265 (HEVC) if there would be an open-source VP9 available being roughly as good (according to what they say in the video (http://www.youtube.com/watch?v=K6JshvblIcM)) :confused:?Proprietary? Open source? Do you even now what these words mean?
x264 is open source. vpxenc is open source.
H.264 and H.265 are open - anybody can get specification and write decoder/encoder.
VP8 is kinda open, since specification is mess. VP9 is closed, since no specification is avaivable.
Also read this (http://www.infoworld.com/d/open-source-software/googles-open-video-proposal-closes-door-software-freedom-218765).

[Beelzebubu]

Why does it look better than both right (supposed to be x264) and left (vp9) sides?

Youtube has re-compressed the I/O presentation, so naturally any image shown will have additional compression artifacts in addition to the ones already present in the encoding results shown on-screen in the room.

Source is 720p mp4 from http://www.youtube.com/watch?v=gF58loLxjRk

We didn't use the .mp4 you're referring to as source (that is actually a re-compressed version from Youtube) - we used the originally uploaded file as source for this test. Different inputs - different outputs, and thus different artifacts.

downscaled to 360p

All encodes were 720p, not 360p. Obviously, if you're using a quarter resolution at the same bitrate, it'll look 4x as good.

[Beelzebubu]

Because encoding 720p at such bitrate is madness. Even on 240p youtube uses higher bitrate.

Accomplishing amazing quality (nearly 40dB in PSNR, or equivalent gains in SSIM or whatever other metric you look at) at 250kbps is not acceptable just because you're used to it stuttering and buffering and clogging up your network?

That is the whole point of VP9! Yes, we want to half (or really: the less, the better) our bitrates. That's the whole point!

[vivan]

Youtube has re-compressed the I/O presentation, so naturally any image shown will have additional compression artifacts in addition to the ones already present in the encoding results shown on-screen in the room.That was 1080p stream. Of course youtube kills quality - but not that much.

All encodes were 720p, not 360p. Obviously, if you're using a quarter resolution at the same bitrate, it'll look 4x as good.It was upscaled back to 720p so comparison is fair.
Read How to cheat on video encoder comparisons (http://x264dev.multimedia.cx/archives/472), part about picking too low bitrate.

[mzso]

Okay, VP9 is better at producing blurry mess at insane low bitrates.
Sane person would just downscale an get better result with x264, insane would use vp9.

A sane person wouldn't complain about low bitrate when the purpose is to compare encoding artifacts.
The comparison wouldn't show much if they would choose a bitrate where both encoders are way past visual transparency.

[mandarinka]

A sane person wouldn't complain about low bitrate when the purpose is to compare encoding artifacts.
The comparison wouldn't show much if they would choose a bitrate where both encoders are way past visual transparency.

That's equally silly. But what would tell us most would be a test of both encoders at a bitrate where one already achieves acceptable quality but the second doesn't. Then you can tell which one is compressing better (with higher quality).

If you compare two streams that are completely ruined by two different sorts of artifacting, you have no idea how well the encoding scheme actually does under sane conditions (you see crap, but you don't know if that crap is necessary due to the low bitrate, or if the encoder decission and/or format just blows).

Maybe the codec that looks less bad will still have major quality issues at serious bitrates, while the second will get acceptable much faster and clearly outperform it? Or maybe vice versa...

[benwaggoner]

We didn't use the .mp4 you're referring to as source (that is actually a re-compressed version from Youtube) - we used the originally uploaded file as source for this test. Different inputs - different outputs, and thus different artifacts.
It would be great if you could make the actual files themselves available for the community to take a look at, including the command lines used to encode them.

That could help short-circuit a lot of the speculation on this thread.

All encodes were 720p, not 360p. Obviously, if you're using a quarter resolution at the same bitrate, it'll look 4x as good.
That is not accurate. Video codecs need fewer bits per pixels as the pixel count goes up, and more advanced codecs should have a stronger effect. Like HEVC, I'd think VP9 would do well in this regard with larger block sizes available.

Also, at "reasonable" bitrates adding more bits to the same pixels should help quality less than adding more bits and more pixels at the same time. Although that is a somewhat circular definition of reasonable :).

Alex Zambelli had a good discussion about this in a blog post about this I just saw. Check out the second half.
http://alexzambelli.com/blog/2013/01/28/h-265hevc-ratification-and-4k-video-streaming/

[dapperdan]

If you compare two streams that are completely ruined by two different sorts of artifacting, you have no idea how well the encoding scheme actually does under sane conditions (you see crap, but you don't know if that crap is necessary due to the low bitrate, or if the encoder decission and/or format just blows).

Maybe the codec that looks less bad will still have major quality issues at serious bitrates, while the second will get acceptable much faster and clearly outperform it? Or maybe vice versa...

They did show a PSNR graph right after the video:

http://www.youtube.com/watch?v=K6JshvblIcM&t=16m32s

[dapperdan]

Okay, VP9 is better at producing blurry mess at insane low bitrates.
Sane person would just downscale an get better result with x264, insane would use vp9.


Isn't one of VP9's features that it can do this automatically within a stream, for realtime streaming? Though if it's hanging together at the point that x264 falls apart then you'd need to go even lower before VP9 needs to downscale.

[pieter3d]

What does this mean? It sounds like you're saying that (like in vp8), modes/mvs and coefficients are in separate data partitions - that's not true in vp9 (it was removed about a year ago). They are interleaved per block. See here (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/encoder/vp9_bitstream.c;h=bcec13c4bedcafe87ad40e0026169bfe362a9207;hb=refs/heads/experimental#l834).



Max. tile size is 4k, not 2k. See here (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/common/vp9_tile_common.c;h=ea26289b76ec1dff6589244c683fcc1cc575c210;hb=refs/heads/experimental#l14).

Other than that, nice rundown, thanks for writing it up.

I meant that tiles are required to be used at pictures sizes above 2k (aka, anything bigger than 1080p). Is that not right?


Regarding the block-level interleaving, that is great news to hear.

[Beelzebubu]

It would be great if you could make the actual files themselves available for the community to take a look at, including the command lines used to encode them.

That could help short-circuit a lot of the speculation on this thread.

That's a great point, and we're happy to do so - see here (http://downloads.webmproject.org/rbultje/io2013/).

The given source files were converted to y4m/720p using "ffmpeg -i $file -an -y -vf scale=-1:720 -vframes 1000 -pix_fmt yuv420p in.y4m", then encoded with x264 using "--preset veryslow --profile high --keyint infinite --pass 1/2 --stats $statsfile --bitrate X -o out.264 in.y4m", and encoded with vpxenc using "--good --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --target-bitrate=X --codec=vp9 -o out.webm in.y4m".

[benwaggoner]

That's a great point, and we're happy to do so - see here (http://downloads.webmproject.org/rbultje/io2013/).

The given source files were converted to...
Thanks for the information. But those links are to the source files? These are already highly compressed with plenty of artifacts and weirdly lit to boot. MPEG-4pt2 ASP at 5.7 Mbps and H.264 Baseline at 8.4 Mbps? Using sources with lots of compression artifacts makes it very hard to analyze the output video quality in a meaningful way. Differences between codecs will make much less impact in the resulting quality than differences in source postprocessing. And metrics like PSNR are going to be even more useless than normal in estimating perceived quality after reencoding.

More representative samples using high-quality sources would make for a much more compelling and relevant comparison. Any source used for codec testing should have no visible artifacts.

There are a number of useful clips (many already in y4m format) at VQEG. Individually they are quite short, but multiple clips may be concatenated together: http://media.xiph.org/video/derf/

The Tears of Steel project also has nice sources (although the PNG sequence is Studio RGB and should be properly corrected to Y'16-240 range prior to compression): http://mango.blender.org/download/

Other blender.org productions are often used in codec testing, but their use of CGI leaves them rather easier to encode than most content.

Also, it would be helpful to provide the encoded files for comparison as well.

[Beelzebubu]

Thanks for the information. But those links are to the source files? These are already highly compressed with plenty of artifacts and weirdly lit to boot. MPEG-4pt2 ASP at 5.7 Mbps and H.264 Baseline at 8.4 Mbps? Using sources with lots of compression artifacts makes it very hard to analyze the output video quality in a meaningful way. Differences between codecs will make much less impact in the resulting quality than differences in source postprocessing. And metrics like PSNR are going to be even more useless than normal in estimating perceived quality after reencoding.

More representative samples using high-quality sources would make for a much more compelling and relevant comparison. Any source used for codec testing should have no visible artifacts.

We have certainly done tests against original sources also, and the results are basically the same - VP9 files are 50% smaller than x264 files of the same quality. This isn't hard to reproduce - you already pointed out yourself where to get samples, and the settings for vpxenc/x264 are identical.

However, our talk at I/O was in the context of Youtube, and Youtube uploads are typically already compressed. Therefore, the results shown in the I/O talk covered these already-compressed sources. Again - we found that this didn't change the results: VP9 files are 50% smaller than x264 files of the same quality.

[schweinsz]

We have certainly done tests against original sources also, and the results are basically the same - VP9 files are 50% smaller than x264 files of the same quality. This isn't hard to reproduce - you already pointed out yourself where to get samples, and the settings for vpxenc/x264 are identical.

However, our talk at I/O was in the context of Youtube, and Youtube uploads are typically already compressed. Therefore, the results shown in the I/O talk covered these already-compressed sources. Again - we found that this didn't change the results: VP9 files are 50% smaller than x264 files of the same quality.
Could you provide the detailed comparison results using all of the JCT-VC test sequences with the HEVC HM10.0 hierarchical B configuration?

[benwaggoner]

We have certainly done tests against original sources also, and the results are basically the same - VP9 files are 50% smaller than x264 files of the same quality. This isn't hard to reproduce - you already pointed out yourself where to get samples, and the settings for vpxenc/x264 are identical.
Sure, one of the goals of this kind of discussion is to allow independent verification of results.

However, it would be helpful in getting everyone on the same page if you could provide the source and encoded samples demonstrating your claim.

Also, a precise definition of "same quality" would be helpful. I would interpret you claim as saying "H.264 will require twice the bitrate to achieve the same subjective quality as a VP9 encode." Is that the sense that you mean it?

If you're measuring "quality" via PSNR or SSIM, your x264 should use --tune PSNR or --tune SSIM as appropriate.

However, our talk at I/O was in the context of Youtube, and Youtube uploads are typically already compressed. Therefore, the results shown in the I/O talk covered these already-compressed sources. Again - we found that this didn't change the results: VP9 files are 50% smaller than x264 files of the same quality.
Yes, providing the files you believe exhibits that behavior would be delightful.

[vivan]

For example park_joy_420_720p50.y4m:

x264 settings: --preset placebo --tune psnr --pass 1/2 --stats 1 --bitrate $BITRATE
vp9 settings: --codec=vp9 --passes=2 --good --cpu-used=0 --target-bitrate=$BITRATE --auto-alt-ref=1 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --lag-in-frames=25 --kf-min-dist=0 --kf-max-dist=250 --static-thresh=0 --min-q=0 --max-q=63 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3
PSNR measured by avisynth Compare.

http://5.firepic.org/5/images/2013-05/23/gyfba2x1ph9d.png
files (https://www.dropbox.com/sh/m2r0p83l4qj3b6r/rxatd1b-Bf)

@8000 kbps: vp9 (http://5.firepic.org/5/images/2013-05/23/tu9i27ran7t5.png), x264_psnr (http://5.firepic.org/5/images/2013-05/23/n6545v6og4x8.png), x264 (http://5.firepic.org/5/images/2013-05/23/ria4qkbvmynv.png)
(x264 is just --preset veryslow)

is not acceptable just because you're used to it stuttering and buffering and clogging up your network?I'm used to perfect video playback, thanks to Flash, h/w acceleration and 100 Mbit/s connection.

Is there any way to disable psnr tuning in VP9? Because this blurring looks awful.

[dapperdan]

A VP9 developer talked about this exact clip a couple of months ago:

https://groups.google.com/a/webmproject.org/d/msg/codec-devel/19wxAVyC_X8/BC_FSe4X_x8J

"Just to clarify, the --tune=ssim option in VP8 and VP9 does not currently result in adaptive quantization.

There is clearly scope in the bit-streams for such (e.g. using segmentation) but we have not yet addressed this in the encoder. I suspect that this clip is one that would benefit quite a bit in terms of psycho-visual quality (and metrics like ssim) from adaptive quantization, as do clips like park-run and park-joy (which are particularly good test cases for adaptive quant). For most clips (in a large test corpus such as YouTube), we have found that the benefit is much less significant, but there are a number of categories of content and use cases where it does seem to make a big difference, so we will certainly be addressing this."

The other clip mentioned (park-run) is also specifically called out in point 2d of Dark Shikari's "How to cheat at video codec comparisons", but I believe it applies to park joy too, though perhaps to a lesser degree.

http://x264dev.multimedia.cx/archives/472
" I’ve also used the standard test clip “parkrun” as a demonstration of adaptive quantization. But claiming that either is representative of most real content — and thus can be used as a general determinant of how good encoders are — is of course insane."

[Beelzebubu]

Is there any way to disable psnr tuning in VP9? Because this blurring looks awful.

What version (git hash)?

[vivan]

What version (git hash)?This one - http://forum.doom9.org/showthread.php?p=1628695#post1628695.
v1.2.0-2727-g18e0742

[tuqueque]

@vivan, you are using the --placebo preset in your x264 encoding... But just using the --good command in the VP9 encoding... How convenient!

use the --best command for VP9 if you want a fair comparison!

[vivan]

@vivan, you are using the --placebo preset in your x264 encoding... But just using the --good command in the VP9 encoding... How convenient!

use the --best command for VP9 if you want a fair comparison!1) I'm using proposed settings.
2) vpxenc is already slow as hell (30-40s for 1 frame, doing 8 encodes simultaneously).
3) Have you actually tested this? Even doc on website says thatSetting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best

[paradoxical]

@vivan, you are using the --placebo preset in your x264 encoding... But just using the --good command in the VP9 encoding... How convenient!

use the --best command for VP9 if you want a fair comparison!

The difference in compression efficiency between veryslow and placebo is not even remotely as big as you seem to think it is.

From Dark Shikari here (http://doom10.org/index.php?topic=141.msg1020#msg1020):

Based on your experience, what is the percentage of benefit gained (quality, size or others) that I get when I use "placebo" preset over "very slow" preset. Thank you in advance.

Probably less than 1%.


There's a reason it's called "placebo". It's the preset you use if you want your machine to burn energy as a space heater.

[phate89]

The difference in compression efficiency between veryslow and placebo is not even remotely as big as you seem to think it is.

From Dark Shikari here (http://doom10.org/index.php?topic=141.msg1020#msg1020):



There's a reason it's called "placebo". It's the preset you use if you want your machine to burn energy as a space heater.

another reason to use best instead of good..

[paradoxical]

another reason to use best instead of good..

Why? Is the difference somehow going to make VP9 magically better? The difference for x264 is negligible visually with a compression efficiency gain of less than 1% between the two. Also did you read the part that vivian quoted from Google's own docs?

Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best

[benwaggoner]

1) I'm using proposed settings.
2) vpxenc is already slow as hell (30-40s for 1 frame, doing 8 encodes simultaneously).
I see four basic comparisons that are useful for incorporating encode time in a codec comparison:

Use settings that provide similar encoding times, comparing the quality each provides.
Use settings that provide similar quality, comparing the encoding time required for each.
Use settings that provide the optimal quality for non-placebo encoding levels, comparing both quality and encoding time.
Use the settings that provide the utterly best quality irrespective of encoding time, to set a max bound

Encoding time can vary a lot with the same encoder on different hardware and sources, so this is rarely an area where specific claims can be made that aren't scenario-specific. But that's pretty much true of everything in codec testing :).

Given the relative maturity of H.264 and VP9 implementations, I don't think we should sweat big performance differences at this point. Making codecs faster is a lot more straightforward than making them provide better looking video! What I'm most curious at this point is to see the quality the best H.264 encoder and the best VP9 encoder with good challenging content with real-world scenarios.

The only prediction I'd make myself at this point is that each codec would be "best" for some scenarios. Codecs are generally very good at what they are designed to do, and what they are designed to do can be quite different.

[phate89]

Why? Is the difference somehow going to make VP9 magically better? The difference for x264 is negligible visually with a compression efficiency gain of less than 1% between the two. Also did you read the part that vivian quoted from Google's own docs?
If you want to compare the top quality for both you have to use both at comparable setting. It's almost sure it won't change anything but it's still not a fair test if you use the best possible in x264 because it doesn't change much with veryslow and you do the opposite with vp9 for the same exact reason

[paradoxical]

If you want to compare the top quality for both you have to use both at comparable setting. Probably it won't change anything but is still not a fair test if you use the best possible in x264 even if it doesn't change much with veryslow but you do the opposite with vp9 for the same exact reason

Placebo does not much more than make your encodes take way longer. Sure, veryslow would be more close of a comparison, but the difference is going to be so tiny as to make little difference especially visually.

[phate89]

Placebo does not much more than make your encodes take way longer. Sure, veryslow would be more close of a comparison, but the difference is going to be so tiny as to make little difference especially visually.
I know that but for the same principle (the maximum settings didn't give too much improvements with a lot slower encoding) you do for x264 a choice (slower but a little bit better) and for vp9 the opposite (faster but a little bit worse).
99% it won't change the result? Ok but it's still not a fair test.

[benwaggoner]

I know that but for the same principle (the maximum settings didn't give too much improvements with a lot slower encoding) you do for x264 a choice (slower but a little bit better) and for vp9 the opposite (faster but a little bit worse).
99% it won't change the result? Ok but it's still not a fair test.
What's fair or not fair depends on what's being tested. If the question is "what's the quality comparison between the best that VP9 and H.264 can do?" than speed doesn't matter. As a production codec, speed is a critical factor, but at this point I'm most interested in just figuring out what the current potential for both is.

I'm sure VP9 will get a lot faster and meaningfully better looking it if catches on. The lack of AQuant alone suggests significant headroom. And almost certainly there's more room for quality optimization in VP9 than x264 given the enormous amount of quality tuning has been applied to x264 over many years.

For a useful discussion today, I think we're fine looking at good representative sources encoded to scenario-appropriate bitrates using the best available encoders for each. If we see an apples-to-apples test demonstrating VP9 matching H.264 quality at half the bitrate, that would be huge. Heck, even matching quality at 80% bitrate would be quite significant at this point.

[paradoxical]

I know that but for the same principle (the maximum settings didn't give too much improvements with a lot slower encoding) you do for x264 a choice (slower but a little bit better) and for vp9 the opposite (faster but a little bit worse).

"good" is supposed to be pretty much the same and sometimes better than "best" as the quote I mentioned above says as well.

99% it won't change the result? Ok but it's still not a fair test.

It might not be "fair" but is going from "good" to "best" going to make much of any noticeable difference? Probably not. Which is what my point is. The person I responded to originally was making it out to seem that placebo was going to add some huge difference over veryslow when that just really isn't the case.

[benwaggoner]

"good" is supposed to be pretty much the same and sometimes better than "best" as the quote I mentioned above says as well.
These sorts of things are exactly why I'd like Google to provide encoded samples using the settings they select as optimal. As long as the process can be reproduced, we want to see the best VP9 can do.

[tuqueque]

All I see here are assumptions from x264 fanboys... I tend to be very patient and friendly, but this is ridiculous...

It might not be "fair" but is going from "good" to "best" going to make much of any noticeable difference? Probably not.

You won't KNOW it if you don't do the test!... And again, how convenient is to set --preset placebo instead of --preset veryslow (knowing that -- preset veryslow is the proposed setting in these comparison test!).

Is also ridiculous to compare speed at this point. VP9 is still under heavy sort-of-alpha/beta development and x264 is a quite mature project... Give VP9 a couple of years at least so you can speak properly about speeds.

[paradoxical]

All I see here are assumptions from x264 fanboys... I tend to be very patient and friendly, but this is ridiculous...

Assumptions? More like the words straight from the developers? And calling me a fanboy? That's classic.

You won't KNOW it if you don't do the test!... And again, how convenient is to set --preset placebo instead of --preset veryslow (knowing that -- preset veryslow is the proposed setting in these comparison test!).

I have done tests between the presets. In my tests, the compression difference is usually less than .5% and visually there is no difference. So there is no "convenience" to it, the fact that they used placebo did nothing more than make the encode take many times longer. Again, there's a reason it's called "placebo". You do know what a placebo is, right?

And again:

Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best


So by Google's own documentation this supposed unfairness is probably next to nothing for VP9. So unless you have any data showing that going from good to best has something more than 1% or less difference then your whining is really overblown.


Is also ridiculous to compare speed at this point. VP9 is still under heavy sort-of-alpha/beta development and x264 is a quite mature project... Give VP9 a couple of years at least so you can speak properly about speeds.

Why is it ridiculous? Speed for quality is a very important metric.

[vivan]

I've asked you: 3) Have you actually tested this?And you still haven't answered.
I did not want to spend 6 hours encoding and then hearing something like "--best is broken, you should have used --good".
And, for example, --tune=ssim is broken and leads to crash.
Optimisation is not just making everything faster. It's also about using faster algorithms that are less accurate. So, at best, making vp9 faster would be the same as going from placebo to veryslow.

Anyway, moving to http://downloads.webmproject.org/rbultje/io2013/gF58loLxjRk.vid.mp4
encoded with vpxenc using "--good --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --target-bitrate=X --codec=vp9 -o out.webm in.y4m".@250, 500, 1000 and 2000 kbps.
x264 - preset veryslow and keyint infinity. And --tune psnr for psnr chart below:
http://4.firepic.org/4/images/2013-05/23/yar5wrd2m1us.png

source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_vp9_1000.png).
source (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_source.png), x264_0750 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_0750.png), x264_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_1000.png), x264_2000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_2000.png), vp9_0500 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_vp9_500.png), vp9_1000 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_vp9_1000.png).
encodes (https://www.dropbox.com/sh/xu7tkht1jpvu32h/NZvWOP1l03)

x264 fails completely at 500 kbps, vp9 at 250 kbps.
At 1000 kbps vp9 and x264 are on par with a different artifacts: vp9 filters out everything, source artifacts, noise, details... x264 tries to encode source artifacts.
At 500 kbps downscaled to 360p and then upscaled back x264 is on par with vp9: 1 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/1_x264_0500.png) 2 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/2_x264_0500.png) 3 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/3_x264_0500.png) 4 (https://dl.dropboxusercontent.com/u/16254258/test/vp9/mb/scr/4_x264_0500.png).

So, well, vp9 is less bad for low quality sources at really low bitrates. Probably proper filtering before encoding using x264 will change things.
If you never seen source vp9 could look a bit better... But for video creators it coud be pain. Nobody cares about quality on youtube, but, vimeo, please no :D

Oh, btw, source is BT.601, so all other files too.

[Beelzebubu]

This one -
http://forum.doom9.org/showthread.php?p=1628695#post1628695.
v1.2.0-2727-g18e0742

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).

Now, more to the point, we've definitely seen parkjoy being one of the clips that we do poorly on. Other clips in this same bucket are crowdrun and parkrun, they're all basically very similar clips, and we tend to be worse than x264 on some datapoints for these clips, similar to your graph (all around the 30dB point). This is probably due to a mix of AQ, mbtree and possibly other things.

VP9 is currently not optimized for extreme test footage like parkrun, parkjoy, etc. - those edge cases will be covered later this year. Right now, we are focused on real-world videos that people watch every day and represent the vast majority of real-world content. Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.

[benwaggoner]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).
Are you using PNSR as your primary measure for quality at this point? Have you done any double-blind subjective testing yet?

Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.
By that, are you indicating you plan to implement similar features in the reference VP9 encoder? Those features are huge for improving perceptual quality, and I imagine would help VP9 as much as H.264.

To some degree this thread is conflating two related but distinct questions:

What is the potential compression efficiency of VP9 compared to H.264 and HEVC?
How does the current VP9 encoder compare to the best encoders for H.264 and HEVC?


It would be unreasonable to extrapolate VP9's relative potential based on the current encoder, as it clearly is not nearly as refined as available H.264 encoders.

It would be reasonable to extrapolate how useful VP9 is at this moment in time based on the current encoder, since that's all there is.

HEVC and VP9 are a lot easier to compare at this point since they both have encoders at early stages of refinement.

There's also a lack of clarity about what we mean by "quality." I only talk about quality in terms of subjective quality myself. When I'm talking about PSNR I call it "PSNR" - my customers never watch rate-distortion curves :). But codec developers tend to talk about PSNR a lot more than codec operators; it's a time-honored and easy to measure objective value.

[paradoxical]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable. We do indeed lose around the 30dB mark, but we consistently beat x264 again from 35dB and up (same settings).

Beat in what manner? Subjective quality or just PSNR? Because purely on PSNR is meaningless. Most of us here are not impressed by a codec that can win in PSNR by blurring details out. Which is why the original VP8 vs x264 comparison that On2 did (http://web.archive.org/web/20100208115706/http://www.on2.com/index.php?599) was a complete joke. It's because of comparisons like that that you will see many people here very skeptical of claims when it comes to new codecs (and, no, it's not because we are fanboys).

Note also that if you disable aq and mbtree (--aq-mode=0 --no-mtree), you'll see we consistently beat x264 at all datapoints for these clips.

Isn't that sort of a tautological statement? Yes, if you purposefully disable optimizations that are there specifically to increase subjective quality you can make x264 look worse. Alert the press!

[mandarinka]

VP9 indeed smooths everything heavily. Not just temporally, it will wipe grain-like texture that is static, too. The lack of psy makes it very hard to establish that it is really better than x264 in compression... because all that removed detail and noise must save tons of bits, yet the results of VP9 aren't so great. I suspect its rate-control is still very poor which together with lack of AQ and psychovisually tuned RDO means the visual quality is way behind x264.

However, VP8 (last release from year ago, dunno if there are newer betas) is also quite bad - compared to VP9, much worse - as far as I can tell, after 2 years of being in the market. So there aren't any guarantees that Google will improve their encoder quickly/substantially. I may be wrong of course.

----------------------------------------
Here are randomly picked frames (http://check2pic.ru/compare/29294/10/) from a test I made at 1350kbps, the source is ~2200 frames of scenes taken from a DVD - I would upload the streams, but since the footage isn't permissively licensed, i don't know if I can do it here.

x264 (2216, 32bit, 8bit depth from x264.nl - these are IMHO suboptimal settings, but I picked them for simplicity - lower aq would probably help this source for example):
x264-2216-32-8.exe --fps 24000/1001 --preset veryslow --pass 1 --bitrate 1350 --threads 1
x264-2216-32-8.exe --fps 24000/1001 --preset veryslow --pass 2 --bitrate 1350 --threads 1

vp9 (vp9 - WebM Project VP9 Encoder v1.2.0-2727-g18e0742, build by jeeb):
vpxenc.exe --codec=vp9 --good --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63
--cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0
--static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5
--arnr-type=3 --sharpness=0 --undershoot-pct=100 --target-bitrate=1350 --fps=24000/1001 --width=720 --height=478

Edit: Although I think it is sort of obvious - VP9 is encode b. Encode a is a reference encode with x264, with options above. BTW, the small sizes of the png images aren't accidental. If you encode teh VP9 stream into lossless h.264, the size of the file is half the size of lossless encode of the source.

[Leeloo Minaï]

[post removed]

[vivan]

First, a general comment: I'm a little suspicious of the fact that your highest PSNR point is 30, that's still unwatchable.Have you actually seen pj encoded at 8 mbps? In case not, here you are (https://dl.dropboxusercontent.com/u/16254258/test/vp9/x264_8000.mp4) (psnr is 29.8039).
It looks far better than any youtube video, making all youtube videos "unwatchable" by your definition of quality :D

[Dark Eiri]

Hmm... at least on youtube videos, I think WebM VP8 1080p videos are much higher quality than the H264 counterparts - and I compared a lot of them, the WebM versions seem a lot sharper. I don't know exactly which settings Google is using for x264, but I believe if they say VP9 is a lot better comparing with their own VP8 encodes, I'll be quite happy with it.

[hajj_3]

Hmm... at least on youtube videos, I think WebM VP8 1080p videos are much higher quality than the H264 counterparts - and I compared a lot of them, the WebM versions seem a lot sharper. I don't know exactly which settings Google is using for x264, but I believe if they say VP9 is a lot better comparing with their own VP8 encodes, I'll be quite happy with it.

The filesize is much higher for their vp8 encodes.

[mandarinka]

VP8 also smooths a lot, but it also blocks and bands a lot (way more than VP9).
Same test conditions as above, but x264 against VP8 1350 kbps (http://www.check2pic.ru/compare/29376/) (The binary used was 1.1.0 Eider, last encoder they released, a year ago; the VP8 commandline is the same as with VP9, x264 encode is the same) - some frames are the same, some which were too troublesome to find I replaced with different ones.
encode a = x264, encode b = vp8

[the_weirdo]

"encode a" = x264 or VP9?

"encode b" = x264 or VP9?

From what he describes, I can assume that "encode a" was encoded by x264, and "encode b" was encoded by VP9 (or VP8 in x264 against VP8 test).

[mandarinka]

Yeah, in both cases, A = x264. I added the explanation as an edit to the original post (I didn't want to clog the thread too much), sorry for not being clear. The VP codecs with their PSNR tuning (or you could call it utter lack of psychovisual model) result in very smoothed video with blur and possibly blocks/banding, so anybody aware of that will probably know which one is x264 right away.

[Dark Eiri]

The filesize is much higher for their vp8 encodes.

I've seen some that are quite similar and still, VP8 yeld a much sharper video. The video for Calvin Harris' I Need Your Love is practically the same filesize for both H264 and VP8 and yet, the x264 version is a little blurry.

[the_weirdo]

I've seen some that are quite similar and still, VP8 yeld a much sharper video. The video for Calvin Harris' I Need Your Love is practically the same filesize for both H264 and VP8 and yet, the x264 version is a little blurry.

Of course, this is true when applying to YouTube. Because, ahem, it is from Google.

[paradoxical]

One shouldn't use anime to compare encoders but should use artificial CGI or videogame footage? How does that make any sense? Why should anime be disqualified?

[benwaggoner]

One shouldn't use anime to compare encoders but should use artificial CGI or videogame footage? How does that make any sense? Why should anime be disqualified?
Yeah, testing anime content is really useful when evaluating an encoder's ability to encode anime :)! I've seen psychovisual optimizations that fail badly with cel animation content because of its very different properties.

Quality==Fitness for use, so judging the quality of any given encoder is only possible in the context of particular use.

[paradoxical]

IMHO, the Anime used by mandarinka doesn't seem to have much detail/texture...

That's why.

Seems completely arbitrary. Anime is a great test of preserving gradients and preventing banding.

Apart from that, it has only low resolution (i.e. not high definition).

Because no one encodes SD footage anymore, right? :rolleyes:

[paradoxical]

See above. I simply don't care about Anime. And they could implement something like --tune animation.

I would rather like to see comparisons using very detailed high definition sources showing real-life footage from digital or film camera, high quality CGI footage and modern 3D videogame footage.

Period :p.

Good for you? Then make your own tests testing the footage you care about. You seem to think that what you care or don't care about is supposed to matter to anyone else.

Unfortunately, even though we live in the year 2013, yes, we still have to deal with things like standard definition, chroma subsampling and interlacing...

Yes, which is my entire point. Saying "no SD content" is ridiculous since there is overwhelmingly plenty of content that will never be available at anything but SD resolutions.

[paradoxical]

Why should i ask for something i don't care about?

I did not say "no SD content". I simply didn't ask for it.

Then make your own comparisons rather than simply whining that you didn't like the content someone else chose to use. Nowhere in mandarinka's post did I see him asking your opinion on anything.

[benwaggoner]

--tune animation
...
And they could implement something like --tune animation.
Actually x264 does fine encoding cel animation using --tune film or no --tune at all. It can do a better job with the correct tuning, but it is not one of the pathological encoders I was referring to.

As yes, VP9 certainly can and probably should introduce an animation tuning mode. Good psychovisual tuning requires tuning for animation, even if it is an internal mode switch or a sufficiently advanced psychovisual model that has been extensively tested against cel animation.

The encoders that do badly with it are generally ones that didn't get good subjective visually tuning against animation sources. One of the big risks for codec developers is an insufficiently diverse library of sources.

[mandarinka]

I have chosen my sample for a single reason - nobody tests any clips like this. Note that this isn't particularly "anime" sample - it shakes, has noise, is cel (not used anymore today), is not digital, has grain. It might be closer to film sources (16mm in this case, I think?).

And it perfectly shows how much VP encoders suck when you are targeting transparent quality. Of course, I didn't use transparent bitrates (although a few months back I tried 2 megabits) but you can clearly see where VP9 aims to be - it is effectively tuning for PSNR and nothing else. This is no news though. I just hope the format itself isn't compromised in visual quality by development with an encoder that sorta ignores it.
IMHO this is an interesting type of footage to try (definitely more fun that Foreman and I would say less crazy than Parkrun/Parkjoy) and as benwaggoner says, it is better suited to no tuning or tune film in x264.
(And when I say interesting, I don't mean just the battle bikini...)

Here is a link with an archive (http://ulozto.net/xJcLBB6z/vp9-x264-test-dvd-sample-zip) that contains 1) vp9, vp8 and x264 encodes I posted screens from. 2) lossless reencode of the source footage 3) lossless reencode of teh VP9 encode, so that you can actually watch it (in motion, it looks worse than on stills, because there is a weird flickering of brightness in many scenes, I think it is a nasty side-effect of the altref smoothing or something?).

Unfortunately it's only a comparison of x264 vs. VP9, without showing the original source, but IMHO "encode b" (VP9) looks better than "encode a" (x264) because VP9 has noticeably less artifacts.
Now this is IMHO a fallacy. Note how VP9 used little to no bits to preserve the dirty/grainy backgrounds (or flat areas - you can see blocking on the girl's hair for example, because VP9 didn't code any residual at all there, I think). So naturally it has much more bits to throw at the outlines, but that hardly means it is more efficient at compression. Given the amount of smoothing it does, its improvements on the outlines are very meager IMHO (the cause could be primarily in sucky ratecontrol though).

You can watch the actual encodes if you download the zip. I think you would agree that x264 is more watchable.

[MasterNobody]

Here is my little (3 samples) VP9 vs x264 test. Not very representative (need more samples) but at least I didn't used parkrun / park_joy for test which were criticized as insane.
Here is archive xls-files with metrics and plots:VP9_vs_x264_metrics.zip (http://www.sendspace.com/file/7td7cs)
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip (http://www.sendspace.com/file/pznpca)

P.S. Sorry, no time to make screenshots or to make formatted post with tables so download archives.

[benwaggoner]

Here is archive xls-files with metrics and plots:VP9_vs_x264_metrics.zip (http://www.sendspace.com/file/7td7cs)
And here encoded samples with cmd-files I used for encoding: VP9_vs_x264_samples.zip (http://www.sendspace.com/file/pznpca)
I don't see any way to download anything other than an .exe from that hosting provider.

[phate89]

I don't see any way to download anything other than an .exe from that hosting provider.

Uncheck the checkbox that tells you accept to download with their download tool, click on the button download now (or something like that, i don't remember exactly) , the page reloads, click on "Click here to start download from sendspace"

[dapperdan]

I have chosen my sample for a single reason - nobody tests any clips like this. Note that this isn't particularly "anime" sample - it shakes, has noise, is cel (not used anymore today), is not digital, has grain. It might be closer to film sources (16mm in this case, I think?).

And it perfectly shows how much VP encoders suck when you are targeting transparent quality. Of course, I didn't use transparent bitrates (although a few months back I tried 2 megabits) but you can clearly see where VP9 aims to be - it is effectively tuning for PSNR and nothing else.

I understand (I think) why grain is an issue for PSNR (in short because the best way to "preserve" it is basically to fake it) but why would preserving the detail on a static painted background not give you a higher PSNR score?

[dapperdan]

The VP9 Bitstream (at least for "profile 0") is now frozen, according to the latest info posted to this thread:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webm-discuss/UzoX7owhwB0

[mandarinka]

Am I the only person that finds it very weird that changes to the format are pursued and hectically made in the last few days and even hours prior to the bitstream finalization?
IMHO there is no way there could have been enough review to really do this all properly and search for possible problems.

Compare that to the lengthy and careful process HEVC has been through... true, maybe it was too lengthy and too slow, but surely that can't hurt as much as this hurry.

[hajj_3]

interesting, their website said the bitstream would be finalised on 17th, maybe they are testing until 17th then going public saying it is finalised assuming they don't find mistakes.

[Bathrone]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm

[hajj_3]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm

This might be of use: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=summary

[Kurtnoise]

Has anyone got any links to windows builds please in preferably 64 bit or 32 bit if I have too? Im having troubles with cygwin and am after the latest compile from the git experimental tree from webm
x86 (http://tinyurl.com/mlmzm2l) / x64 (http://tinyurl.com/m93ehyu) builds from today.

[mzso]

Anyone have any ffmpeg vp9 enabled builds for windows?

[Selur]

a. I hope the official release will be multithreaded, since single threading vp9 encoding is just too slow to be really useful.
b. does someone know what are valid arguments for, the new parameters ?
--lossless=<arg> Lossless mode
--frame-parallel=<arg> Enable frame parallel decodability features
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2
c. hope will be faster with providing a usable documentation than the last time (when vp8 was released)

[Kurtnoise]

a. I hope the official release will be multithreaded, since single threading vp9 encoding is just too slow to be really useful.
Known issue (https://code.google.com/p/webm/issues/detail?id=527)...

b. does someone know what are valid arguments for, the new parameters ?
--lossless=<arg> Lossless mode

--lossless=1, dunno about the rest.

[Bathrone]

x86 (http://tinyurl.com/mlmzm2l) / x64 (http://tinyurl.com/m93ehyu) builds from today.

Legend thankyou Merci

[Selur]

Known issue...
LOL and then you read that 'Google urges (for) fast adoption of VP9',... (+ but good that they have '-t <arg>, --threads=<arg> Max number of threads to use' as an option :D *gig*)

--lossless=1, dunno about the rest.
Thanks, didn't work for my before, since I didn't set '--min-q=0 --max-q=0' since I assumed that '--lossless=1' would automatically do this.

Cu Selur

[Leeloo Minaï]

--lossless=1, dunno about the rest.

Thanks, didn't work for my before, since I didn't set '--min-q=0 --max-q=0' since I assumed that '--lossless=1' would automatically do this.

Cu Selur

vpxenc definitively needs presets like x264.

[Selur]

I think first we need to a usable way to playback it. ;)

[Bloax]

Well as of the current, my experience with VP9 is that encoding is glacial - and decoding either whines about lacking FPS settings (despite vpxenc.exe outright refusing to work if you use the --fps xx/--fps=xx switch) or just outright refuses to be output.

i must be doing something horribly wrong
except it's not told anywhere so joke's on them

[benwaggoner]

Well as of the current, my experience with VP9 is that encoding is glacial - and decoding either whines about lacking FPS settings (despite vpxenc.exe outright refusing to work if you use the --fps xx/--fps=xx switch) or just outright refuses to be output.

i must be doing something horribly wrong
except it's not told anywhere so joke's on them
I think it's just that VP9 and HEVC are really at similar development stages right now. If Google puts the productization resources into VP9 that HEVC is getting, the bitstream will get a good shake.

The risk is that, like with VP3-9, we'll see a potentially promising bitstream get hobbled by having on a single vendor focused on it with an unhealthy PSNR bias, competing with a whole lot of other companies making big bets on making the best implementation for particular scenarios of the mainstream MPEG/ITU codec.

Single-developer codecs have been successful in the past; RealVideo and Windows Media did quite well in their eras, and certainly help their own and more versus MPEG-4 Part 2. But things were different with H.264. Momentum begats momentum, and when you have 90% of the world's best encoder developers focused on a particular bitstream, implementations get better fast.

I believe that if Microsoft had a sustained, coordinated effort around improving VC-1 after 2007 it would have remained quite competitive for some time (dynamic frame resizing was a hugely effective feature and much more friendly for software decoders than H.264's expensive in-loop deblocking). But there weren't any other companies in the wings to take lead in implementation when Microsoft progressively disbanded the Digitial Media Division and its component parts until there was simply no center of excellence for digital media instead Microsoft; just a lot of little teams solving their own local problems with the staff at hand and with very little coordination.

A successful VP9 will see multiple third parties competing hard to make the best implementation for particular scenarios of note. Even if it had a bitstream with 10% more raw potential, real-world results from having 10 focused encoding companies trying to make HEVC better would easily swamp that 10%. Psychovisual and scenario-specific tuning can drive 50% efficiency improvements in a couple of years.

[mandarinka]

I'd say it isn't completely the same. They were frantically working on the bitstream itself for this whole first half of this year, whereas HEVC was virtually done since january... which means codec developers have had a head start. Ateme, MainConcept, Vanguard, Cyberlink, Elemental and some other broadcast guys already announced their stuff, and that is just software. There are probably more players preparing to announce their encoders (and working on the code)...

What I wholeheartedly agree with is that as long as the only VP9 vendor is Google, the real produced encodes won't be anything spectacular, for the reason you described. I admit that I haven't been following how much VP8 changed over the three years that it was supposed to be on market (but was it? Google pushed it for yt, but that is opt-in for users, and of course it is natural for Google to deploy it, even if it sucked completely). But what I see now is still a codec with no psychovisual tuning - how much progress has there really been on the video quality? So if I had to judge based on VP8, then no, VP9's quality isn't really going to see much progress :D

[Bathrone]

Well as of the current, my experience with VP9 is that encoding is glacial

The discussion list for the project clearly says that they are not optimizing the code right now. Up till recently the focus of the project has been the bit stream. Optimization is the next phase.

Gee you critics are needlessly harsh. No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims. x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce. Now we have a next gen codec that is totally free of patent encumberment. That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels

[dapperdan]

Google have committed to using it on Youtube and that internal usage alone should be enough to drive performance increases since they're accepting 100 hours of new video every minute (and encoding it in multiple resolutions). That's possibly enough money coming out of some department's budget to pay for the engineering time by itself. Though, having said that, I'm guessing they're relatively happy with single-threaded code, since they've got plenty of other videos they can use the spare cores for.

They've also announced their intention to push it for video chat in Chrome via WebRTC project. This also gives them motivation (from within yet another separate team within Google with it's own objectives to meet) to optimise for realtime and multithreaded encoding on various chipsets.

Same applies for decode in Chrome, (primarily at first with content from Youtube) but I don't know if anyone's complained about that being slow yet, or if it actually is or not (I seem to recall this being a relative strong point of VP8). If anyone is going to feel that pressure though it's the Chrome team, particularly on netbooks and mobile.

So I wouldn't worry about it too much, particularly based on a bitstream that's just been frozen.

[benwaggoner]

The discussion list for the project clearly says that they are not optimizing the code right now. Up till recently the focus of the project has been the bit stream. Optimization is the next phase.
Correct. The slow speed of the current encoder shouldn't be considered intrinsic to the technology itself. That said, the VPx series has typically lagged in speed @ quality performance.

Gee you critics are needlessly harsh. No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims.
It may be found to be true that VP9 doesn't infringe on any patents, but experience suggests it'll be some years and lots of patent attorney billable hours before there's a clear answer to that.

Both VP8 and VC-1 wound up with lots of patent claims being asserted that weren't anticipated during standardization.

x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce. Now we have a next gen codec that is totally free of patent encumberment. That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels
One upside to MPEG-LA licensed technologies is that all the major patent owners in the video space agree to not assert any patent claims against anyone who has licensed the technology. So while there is the cost of licensing, the potential attack surface of patent claims is much, much smaller.

Sometimes it's cheaper to pay a known amount with relative security than it is to pay nothing but have to account for a higher risk of patent claims. Even if a patent is invalidated, defending against them is expensive, time consuming, and adds business risk.

The last popular "patent free" codec was MPEG-1. Since then, the industry has repeatedly voted that "free" has the potential of being way too expensive to be worth it.

Companies hate unbound risk. And AFAIK, no company that has a MPEG-LA license for H.264 has ever had a meaningful economic hit from losing a patent suit.

That said, there's lots of stuff that Google could do to mitigate those risks, like indemnifying all VP9 licensees. Thus they'd defend all VP9 patent claims and reimburse companies for any actual damages they were required to pay. Or a patent pool could be formed. It wouldn't have to be the MPEG-LA model; Google could potentially just pay a one-time fee for indemnification from the major patent-holding companies.

The licensing side of things strikes me as too ambiguous to worry about too much right now. The real question is whether VP9 will be a competitive bitstream, and for which scenarios.

If there's important stuff that VP9 can do substantially better than HEVC, there will be a lot of momentum to take care of licensing issues one way or another.

[paradoxical]

No one seems to recognise that here we have a competitor to HEVC, but we can legally use it without patent claims.

I can legally use an HEVC, H.264, etc. codec without worrying about patent claims. So VP9 gains me nothing in that area.

x264 was always legally unclear in many countries because H.264/AVC is covered by lots of patents which some countries would enforce.

It was pretty much known from the beginning that you had to license MPEG-LA patents in order to distribute x264 binaries or that using x264 to do commercial distribution of video (such as VOD, commercial Blurays, etc.) would require royalty payments in the United States. The MPEG-LA was quite upfront about the terms with regards to H.264. There was never anything "legally unclear" unless you were willfully ignorant.

Now we have a next gen codec that is totally free of patent encumberment.

Again, irrelevant for most people here.

That alone makes it worth more interest than HEVC so we arent writing cheques out to media cartels

I've yet to write a single check to a "media cartel" to use H.264 or for the HEVC test encodes I've done. So apparently this "interest" is lost on me.

[dapperdan]

Or a patent pool could be formed. It wouldn't have to be the MPEG-LA model; Google could potentially just pay a one-time fee for indemnification from the major patent-holding companies.

This (may have) already happened. There's some vagueness about the strength, number, essential-ness and validity of the patents and that impacts on how much Google paid them but the companies that came forward for MPEG-LA's patent pool seem to have opted for the latter approach rather than the standard usage fee based pool which points to either weak patents or a big bag of cash from Google (or some combination thereof).

http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

List of the companies involved (which wasn't made available at the time the story initially broke):
http://www.webmproject.org/cross-license/primary-licensors/

Google seems to have demonstrated it's commitment to fighting/paying off anyone it needs to so I'm not sure the remaining suits from Nokia make VP8 any worse in this regard than H.264 given the Motorola suits.

(Note the pool was formed around VP8, but the agreement covered VP9. Maybe other companies outside that group will claim patents on VP9 incremental improvements over VP8, but that seems much less serious than hassle from the big players)

[nevcairiel]

Wasn't there something about Nokia refusing to join the VP8/9 patent pool, leaving Google a bit in an awkward position?

[dapperdan]

Wasn't there something about Nokia refusing to join the VP8/9 patent pool, leaving Google a bit in an awkward position?

Yeah, they're currently suing HTC over Android using a bunch of patents, some of which is VP8 related.

They also listed 12 or so patents at the IETF that they claim VP8 infringes (though there's no business reason for them to be truthful here and some other highly respected names in IP spam pretty much any related IETF disclosure since there's no downside to claiming too much)

https://datatracker.ietf.org/ipr/2035/

list with clickable links to actual patent filings:

http://mdpaste.appspot.com/p/agdtZHBhc3Rlcg0LEgVQYXN0ZRjJoxYM

And some more background info:

http://www.groklaw.net/articlebasic.php?story=20130324162902177

So Google has to work around, pay for, invalidate or win in court (and/or the court of popular opinion), or call Nokia's bluff on those patents for VP8 (and I'm assuming they apply, or not, roughly equally to VP9) and it's very possible Nokia have more "encoding video *on a phone*" type patents they could dig up if they really wanted to.

[mandarinka]

so I'm not sure the remaining suits from Nokia make VP8 any worse in this regard than H.264 given the Motorola suits.

That is sadly not true. Motorola was contractually obliged to license those patents on fair, reasonable and non-discriminatory terms to any implementer. (Their suit with MS was most likely a breach of that and the courts will beat them into submission.)

However, VP8 as a proprietary 1-vendor made codec is different. Nokia has no obligations at all with regards to 1) giving the license at all 2) asking ridiculous sums of money 3) withholding the license from select subjects (f.e. based on if they are competition to Nokia).

Basically, Nokias patent once found infringed are (can be used as) a show-stopper, Motorola's patents just mean paying a small royalty.
Naturally, there is a chance that Google will buy the needed license to those patents as it did with the MPEG-LA-related companies.

[dapperdan]

I don't believe it's been fully settled that you can't use those kind of patents to block imports. Even if it finally goes that way, that's been a long time that people have been able to throw crippling legal threats about that would be enough to sink most small players and had the big players worried enough to go running to the government for help.

There's also Microsoft vs Alcatel-lucent that's been rumbling on for years and with awards of up to 1.5 billion which was all about MPEG patents too. I believe part of the argument there is similar in that they were supposed to be signed up for MPEG-LA but thought they could do a bit better out of the deal by trolling instead.

Bottom line is, lots of patents + lots of money leads to lots of problems, and MPEG-LA isn't the panacea it's often made out to be

[mandarinka]

Well, with MPEG-LA, you have at least the promise of FRAND licensing by MPEG-LA players - and luckily, by other subjects too - because you enter into such an obligation when you license H.264 from them (and H.264 licensing is extremely wide-spread thanks to its ubiquity).

With VP*, the only one promising anything to you is Google. Google's license has similar grant-back term, so people who use VP8 can't sue you for using VP8. However, Google hasn't been able to catch as many as potentially threatening parties on that hook, compared to MPEG-LA.

I agree that MPEG-LA doesn't give you certainty either, but there is a real difference there.

[Bathrone]

Both VP8 and VC-1 wound up with lots of patent claims being asserted that weren't anticipated during standardization.

Ben you make some well founded points in your post, thanks for that

Im thankful for competition to HEVC and choice for us who want to use next gen codecs

[dapperdan]

Well, with MPEG-LA, you have at least the promise of FRAND licensing

...

With VP*, the only one promising anything to you is Google.

...

Google hasn't been able to catch as many as potentially threatening parties on that hook, compared to MPEG-LA.


Unfortunately there's no actual legal definition for FRAND (which is crazy when you think about it). They're currently beating out some kind of compromise in the courts, but that's where it's happening *in courts*, during high profile legal cases with no guarantee of how things will turn out and with all sorts of threats of import bans (which were ruled legal by at least some courts, so not a total hail mary play) based on MPEG-LA FRAND patents.

...

I posted a link to the list of the people who are promising you their patents for VP8 at no cost above:

CIF Licensing LLC

France Telecom

Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.

Fujitsu Limited

Koninklijke Philips Electronics N.V.

LG Electronics Inc.

Mitsubishi Electric Corporation

MPEG LA, LLC

NTT DOCOMO, INC.1

Panasonic Corporation

Samsung Electronics Co., Ltd.

Siemens Corporation2

...

VP8 has been a core part of Android since 2.3, and basically everyone uses android, or builds chips for android so the list of non-vp8 users is shrinking fast. (Android is of course big in phones and tablets, but it's expanding to laptops, desktops, TVs etc.)

...

The difference is subtle and complicated while it is often represented as black and white.

[xooyoozoo]

Did a quick 'spot-check' comparison of the latest 6/28 master commit. Long story short, nothing much has really changed, and I doubt much will change for months and years, as the 0.x-1% refinements take a while to add up.

This is versus an HEVC anchor clip: Kimono @ QP32. Matched bitrate and keyint as usual, and same settings as previous encodes but this time, preset was changed to Best (not sure if there's much of a difference...).

VP9 bitsream (http://dropproxy.com/f/303)

Side-by-side comparison vs HEVC. Encoded at CRF10 (http://dropproxy.com/f/304)

This is only one point of data, so I can't give an all encompassing bd-rate number, but I can say that in this single instance VP9 needs ~32% more bits for the same quality.

http://i.imgur.com/3iVMniw.png

[mandarinka]

The VP9 encoder shows quite serious issues after the scenechange, so it might be rate-control messing up the results a bit. /Still not an excuse, since they want to push this format fast for example on youtube. The videos will be screwed there for years I guess :) /

[pieter3d]

You can run the VP9 encoder in two-pass mode, probably that will fix the scene change problems

[BadFrame]

You can run the VP9 encoder in two-pass mode, probably that will fix the scene change problems

Yes, from what I gather from reading the mailing list, they (Google) run all their VP9 encodes as two-pass, also cq-level and end-use=cq seems to be silently ignored (defaulting to end-use=vbr), I guess they'll work on cq at a later stage in development.

[xooyoozoo]

You can run the VP9 encoder in two-pass mode, probably that will fix the scene change problems

I didn't realize the one-pass option is now enabled(?); it wasn't working for the longest time.

In any case, the sample above was with VP9's 2pass, as it'd be a lot more difficult to get matched bitrates otherwise.

vp9enc $input -o $output.webm --codec=vp9 --target-bitrate=$bitrate \
--kf-min-dist=0 --kf-max-dist=$kint -p 2 --best --end-usage=vbr --static-thresh=0 \
--min-q=0 --max-q=63 --auto-alt-ref=1 --lag-in-frames=25 --limit=$frms \
--minsection-pct=0 --maxsection-pct=2000 --bias-pct=50 \
--arnr-maxframes=7 --arnr-strength=5 --arnr-type=3

[schweinsz]

Did a quick 'spot-check' comparison of the latest 6/28 master commit. Long story short, nothing much has really changed, and I doubt much will change for months and years, as the 0.x-1% refinements take a while to add up.

This is versus an HEVC anchor clip: Kimono @ QP32. Matched bitrate and keyint as usual, and same settings as previous encodes but this time, preset was changed to Best (not sure if there's much of a difference...).

VP9 bitsream (http://dropproxy.com/f/303)

Side-by-side comparison vs HEVC. Encoded at CRF10 (http://dropproxy.com/f/304)

This is only one point of data, so I can't give an all encompassing bd-rate number, but I can say that in this single instance VP9 needs ~32% more bits for the same quality.

http://i.imgur.com/3iVMniw.png

Could you provide more results on more sequences such as the JCT-VC sequences, bqsquare, bqterrace, racehorses, basketballdrive, cactus.

[mzso]

Okay. So was vp9 finalized? Somebody talked about last minute additions a not long ago.

[hajj_3]

Okay. So was vp9 finalized? Somebody talked about last minute additions a not long ago.

It was finalised on the 11th june: https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/UzoX7owhwB0, here is the github for VP9: http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=summary

[dapperdan]

The latest WebM Project blog post:

http://blog.webmproject.org/2013/07/vp9-lands-in-chrome-dev-channel.html

It's not exactly long but the interesting bits are, their claims on how VP9 stacks up:

"VP9 development began eighteen months ago. In the short time since, according to our internal tests, we've produced a codec that shows video quality that is slightly better than HEVC (H.265) and is 50% better than VP8 and the best implementations of H.264 high profile."

and what the immediate project goals are now that the bitstream is final:

"We’ll now be working on optimizing libvpx for speed and performance, and working—with help from partners and the WebM community—to ensure that VP9 is positioned to integrate with the major encoding tools and consumer platforms, including mobile and embedded"

[xooyoozoo]

we've produced a codec that shows video quality that is slightly better than HEVC (H.265)

At this point, I would love to see some examples of situations and settings, however contrived, where this is true...

[dapperdan]

Well, they made very similar claims (VP9 1% behind HEVC) at Google IO so I'd guess most of the variables there hold true for this one as well (though they were less forthcoming about the HEVC details compared with the x264 ones, it was more of a passing remark at that time).

VP9/libvpx (obviously) vs the HEVC reference encoder. (I think they claimed they had access to other pre-release encoders but weren't allowed to publish benchmarks due to EULA restrictions)
Quality measured by PSNR.
Test set a broad selection of Youtube content.
They published their VP9 encoder settings on the mailing list and x264 as well, but I don't think they specified anything for HEVC.

Google are better than most at documenting/releasing their test setups for others to recreate so you might want to just ask them for more details on the areas that aren't fully specified.

[mandarinka]

It was probably some fringe case and the "lead" if true was a result of a difference in encoder decisions - since I think you could more or less think of VP9 as a weaker subset of compression tools available under HEVC...

[Keiyakusha]

"VP9 development began eighteen months ago. In the short time since, according to our internal tests, we've produced a codec that shows video quality that is slightly better than HEVC (H.265) and is 50% better than VP8 and the best implementations of H.264 high profile."
What I understand from this quote:
"best implementations of H.264 high profile" = x264
VP8 quality = x264 quality
VP9 quality = HEVC quality and 50% better than VP8/x264

So. I can believe that some HEVC implementation is 50% better than x264.
But in reality VP8 is like half the x264 quality...
Does that mean the truth behind their lies is that VP9 in fact no more than half of the HEVC quality?

[benwaggoner]

Quality measured by PSNR.
Test set a broad selection of Youtube content.
Unfortunately, PSNR is probably the worst available objective metric available. I'd like to see 3SSIM or MOVIE at least. I really don't understand why anyone focusing on a real-world codec would spend much time on PSNR.

I'd love to see some proper double-blind subjective tests comparing VP9 and other codecs. People watch a rapid succession of frames of decoded videos, not Rate/Distortion plots :)!

This is a quite interesting paper that highlights how useless PSNR can be, and how different codecs can show quite different correlations between subjective and objective measurements: https://ece.uwaterloo.ca/~z70wang/publications/vpqm13.pdf.

If Google is only tuning their VP9 implementation for PSNR, then their implementation may offer substantially lower subjective quality than the VP9 bitstream may be capable of.

[Rumbah]

If anyone is interested here is a Windows Cygwin compile of vpxenc/vpxdec to tinker with. I tried to get a MinGW compile to work but gave up after trying for some time.

x264.janhum.alfahosting.org/vpx05072013.7z

[Mangix]

If anyone is interested here is a Windows Cygwin compile of vpxenc/vpxdec to tinker with. I tried to get a MinGW compile to work but gave up after trying for some time.

x264.janhum.alfahosting.org/vpx05072013.7z

IIRC it's the same as making the cygwin compile but doing ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pc-mingw32

MinGW has to be installed of course, which is possible through cygwin's installer.

[easyfab]

If anyone is interested here is a Windows Cygwin compile of vpxenc/vpxdec to tinker with. I tried to get a MinGW compile to work but gave up after trying for some time.

x264.janhum.alfahosting.org/vpx05072013.7z

Rumbah for MinGW compile you need a patch see :

http://forum.doom9.org/showpost.php?p=1633729&postcount=6

[zerowalker]

I have done some tests on VP9 VS VP8 on youtube, meaning there own encoded material.
And from that, i can say that VP8 looks better then VP9.

Now, i don´t know what bitrate VP9 uses, as i can´t download it.

If anyone knows a way to download the VP9 encoded videos from Youtube, please tell.

[MoSal]

I have done some tests on VP9 VS VP8 on youtube, meaning there own encoded material.
And from that, i can say that VP8 looks better then VP9.

Now, i don´t know what bitrate VP9 uses, as i can´t download it.

If anyone knows a way to download the VP9 encoded videos from Youtube, please tell.

What videos?

[zerowalker]

Youtube videos.
Some are encoded in VP9, they have a user and playlist that contains them.

[MoSal]

Youtube videos.
Some are encoded in VP9, they have a user and playlist that contains them.

You mean?
https://www.youtube.com/user/WebMVP9/videos

Those videos were not encoded with the final bitstream.

You can download VP9 versions by parsing the output of:
https://www.youtube.com/get_video_info?video_id=VIDEO_ID

This is what libquvi/cclive and others do to download from yt. It's just the VP9 formats in those experimental videos are not supported.

[zerowalker]

Yes.

I see, well is it that big of difference?

I tried to use that, i got a Get_Video_Info file, that was 32kb;S

[xooyoozoo]

Could you provide more results on more sequences such as the JCT-VC sequences, bqsquare, bqterrace, racehorses, basketballdrive, cactus.

I tried a couple more, made with latest July 4 '13 master.

Instantaneous MS-SSIM bitrate gap versus QP32 HEVC is +25% filesize for basketballdrive (bitstream (https://docs.google.com/file/d/0BzAA-H5x8NKTRzNjY3BIek80UE0/edit?usp=sharing), side-by-side (https://docs.google.com/file/d/0BzAA-H5x8NKTdXk0X1BvUTR0N2c/edit?usp=sharing) download) and +30% filesize for cactus (bitstream (https://docs.google.com/file/d/0BzAA-H5x8NKTMkVMTVpLWkxza1U/edit?usp=sharing), side-by-side (https://docs.google.com/file/d/0BzAA-H5x8NKTSld0Z0FlUmdpUGc/edit?usp=sharing) download).

Personally, I think I've lost interest in the next-gen "codec war" until we can find scenarios that seem nuanced at the very least.

(By the way, the bitstreams work perfectly on Chrome dev branch, and the side-by-sides had their frame rates reduced to 24.)

[zerowalker]

Could you record some 3d game lossless, and encode it in vp9 and hevc?
I don´t mean a whole session, but you know, some secs.

As it would be nice to see some, Unencoded material being encoded and compared.

Personally, I think I've lost interest in the next-gen "codec war" until we can find scenarios that seem nuanced at the very least.


I have to agree there. I was extremely excited with VP9, i have been waiting for it with high hopes.
But i can´t say i am impressed, but i still have a bit of hope:)

[MoSal]

Yes.

I see, well is it that big of difference?

I tried to use that, i got a Get_Video_Info file, that was 32kb;S

I see you need more hand-holding.

Assuming you replaced VIDEO_ID with the video id, you will get a file with url-encoded text. You need to escape/unquote the text (you might need to do that twice depending on the method you use for this).

Now, reading the (escaped) text should be easier, search for vp9, then copy the following url (what comes after url=) until and including the signature parameter. That's the video url.

[zerowalker]

Yes indeed.

Never done this, but i actually got it to work!
Much thanks to you:)!

[zerowalker]

Okay i tested myself, so here is a picture from the same source, which was lossless, and i encoded in vp9 1 pass -good -target 1000bitrate (but it was 300bitrate in the end for some reason)
So the x264 encode was 2 pass and 300bitrate, default slower preset.

The difference is significant, it´s night and day:)
And hopefully, i did things right.

EDIT: Forgot, the x264 i encoded is 10bit, so it has a bit of advantage there, especially as this is a dark clip.

[vivan]

And hopefully, i did things right.I bet defaults are still awful and presets are still broken. Try finding recommended settings, they were somewhere in this thread... They are way better than just --good or --best.

[BadFrame]

Okay i tested myself, so here is a picture from the same source, which was lossless, and i encoded in vp9 1 pass -good -target 1000bitrate (but it was 300bitrate in the end for some reason)
So the x264 encode was 2 pass and 300bitrate, default slower preset.

Why did you do 1 pass in vp9 (particularly when you did two pass in the x264 test)? As far as I know it's very dependant on two-pass for quality.

For my vp9 tests I used settings I picked up on the webm mailing list which I recall some dev said is what they are typically using:

vpxenc --best --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --codec=vp9 --target-bitrate=BITRATE -o <output video> <input video>

[zerowalker]

I didn´t do a precise test, it was just more to check if it is noticable at all.

And with that encoding i did, x264 had alot of advantages. 2Pass and 10 Bit, and it still looked way worse than VP9.

Which means, x264 will look even worse with the same settings as vp9 right?


And if i did use 2 pass, it would have taken like 5 hours, for 2 secs, which isn´t that great;P
will have to wait till they improve it to atleast 1fps and not 0.005:)


EDIT: Also, is there a directshow filter/decoder for vp9?
As i need to watch in chrome, which is not that nice.

[benwaggoner]

Okay i tested myself, so here is a picture from the same source, which was lossless, and i encoded in vp9 1 pass -good -target 1000bitrate (but it was 300bitrate in the end for some reason)
So the x264 encode was 2 pass and 300bitrate, default slower preset.
Given the speed differences, I think --preset placebo would have been appropriate for an even faintly apples-apples comparison :).

--tune film may have also helped with that content.

Can you share the full x264 command line you used? The quality seems less than it should be for even that bitrate, unless there is a crazy lot of motion or something.

[zerowalker]

True, but i really doubt it would make a real difference.
Tune Film might though.

here: program --preset slower --pass 2 --bitrate 300 --stats ".stats" --output "output" "input"

It was a lot of movement i guess, it was a third person game, and i looked right and left about there (was scared from something and panicked;P).

I can give the original lossless clip if you want.


EDTI:

Added anyway: http://www.sendspace.com/file/embffb

VP9 file, encoded with the settings got from some posts before, though 1 pass, (don´t know how to get 2 pass working).
And also the lossless clip is there.

[BadFrame]

Which means, x264 will look even worse with the same settings as vp9 right?
I still think it's important to strive for as similar settings as possible when doing comparisons, which typically means going for the best each encoder has to offer.


And if i did use 2 pass, it would have taken like 5 hours, for 2 secs, which isn´t that great;P
The first pass in VP9 two pass encode is MUCH MUCH faster than the second one, they're not remotely comparable, first pass only gathers information on the file, it's the second pass where it encodes that gets super slow.


EDIT: Also, is there a directshow filter/decoder for vp9?
As i need to watch in chrome, which is not that nice.
I have no idea, I re-encoded the resulting webm file to a x264 file with --crf 0 (lossless) to check the end result.

[STaRGaZeR]

Okay i tested myself, so here is a picture from the same source, which was lossless, and i encoded in vp9 1 pass -good -target 1000bitrate (but it was 300bitrate in the end for some reason)
So the x264 encode was 2 pass and 300bitrate, default slower preset.

The difference is significant, it´s night and day:)
And hopefully, i did things right.

EDIT: Forgot, the x264 i encoded is 10bit, so it has a bit of advantage there, especially as this is a dark clip.

What in the world are you doing compressing 1920x1080 high detail game footage at 300kbps? This is the same kind of retarded testing Google did to prove VP9's superiority, if my memory serves me right.

[BadFrame]

I decided to re-do zerowalker's tests at higher bitrates, I also re-did the 300 bitrate test.

VP9 used the same settings I posted above (lifted from the webm mailing list) and is 2 pass.

For x264 I used --preset=placebo and --tune=film (as per benwaggoner's suggestion) and 2 pass.

I encoded at the following bitrates: 300, 1000 and 2000.

VP9 300 bits:
http://img24.imageshack.us/img24/9178/nklw.png
http://img811.imageshack.us/img811/593/exk1.png

VP9 1000 bits:
http://img441.imageshack.us/img441/2787/lhf.png
http://img19.imageshack.us/img19/3884/ysyz.png

VP9 2000 bits:
http://img28.imageshack.us/img28/406/akn8.png
http://img856.imageshack.us/img856/7550/x9i.png

x264 300 bits:
http://img841.imageshack.us/img841/4861/vi2z.png
http://img600.imageshack.us/img600/4782/qbqo.png

x264 1000 bits:
http://img7.imageshack.us/img7/9409/1n2k.png
http://img829.imageshack.us/img829/221/2v7.png

x264 2000 bits:
http://img585.imageshack.us/img585/6510/cghv.png
http://img580.imageshack.us/img580/3185/n6k.png

With this specific high definition content, and at these bitrates, VP9 certainly came out the clear winner.

I'll try uploading the resulting files to sendspace or something in a couple of minutes.

edit: here are the files http://www.sendspace.com/file/0quq36

[easyfab]

BadFrame,

It is possible to do the same for VP9 but with --good --cpu-used=4 instead of --best --cpu-used=0 . I will be normally faster ( a lot ?) and i'm interesting in the quality with that parameters vs x264.

[BadFrame]

BadFrame,

It is possible to do the same for VP9 but with --good --cpu-used=4 instead of --best --cpu-used=0 . I will be normally faster ( a lot ?) and i'm interesting in the quality with that parameters vs x264.
Hmm.. I don't quite see the point of re-doing the tests with 'good', it will only be a bit worse in quality, and as for comparisons between encoders I think the only 'fair' quality comparison is when you use the best options you know for each encoder. Unless I'm missing something here?

I'd certainly be interested in re-doing the tests if someone has better settings for either x264 or vp9 to try out.

As for --cpu-used=4, I've tried that and --threads=4 but to no avail, vpxenc only used one of my cores, of course I make sure to run 4 simultaneous encodings when doing tests so as to make use of my full cpu capacity, but I've never been able to have one encoding use more than 1 core.

Is there some configuration option necessary when compiling vpx?

[mindwin]

Share a source file, please.

Very interesting to compare with HEVC too.

[zerowalker]

BadFrame good comparasions there.

And i totally agree, i am impressed with how good VP9 looks, especially on low bitrate (under 1k).

But above 1k bitrate, it really polishes the picture compared to X264, which can barely show the picture correctly more or less.

[BadFrame]

Share a source file, please.

Very interesting to compare with HEVC too.

I used the source file posted by zerowalker right here in this thread just a few posts up (which is why I didn't include it with my test files) :

http://www.sendspace.com/file/embffb

And yes, I was thinking about doing tests using the hm reference encoder, but if you do it instead then that's just fine by me :D

[hajj_3]

Would be better to see how it handles 1080p bluray source rather than a video game.

[mindwin]

BadFrame
thx.
I am not familiar with reference HEVC encoder.
I want to try Strongene HEVC latest beta version (http://xhevc.com/en/downloads/downloadCenter.jsp).

[zerowalker]

Videogame is probably alot more complex with movement in terms of small details compared to Bluray.
At least in that source ( a dark scene with some effects from shooting etc).

And it´s very good to see how it performs in Dark Scenes, as that is where every encoder "Fails" to put it simple.

[BadFrame]

And i totally agree, i am impressed with how good VP9 looks, especially on low bitrate (under 1k).

But above 1k bitrate, it really polishes the picture compared to X264, which can barely show the picture correctly more or less.
Yes I was surprised at how good quality VP9 could muster out of such a low bitrate, I guess it has to do with it being developed with real time video in mind?

At 2000 bits the difference wasn't that profound though, in my opinon, although I think VP9 still clearly won.

I'd like to do some high definition animation tests on my Akira bluray, I just gotta figure out how to decrypt it.

[mindwin]

zerowalker
You may try this video sample (https://mega.co.nz/#!SEIhACSD!dRSlwkSofL-hfYPmZzN54zhaATdsJQXa6XxTb3be1Jo). (660mb)


Have dark, static, dynamic scenes, some film grain, and very high quality.

Format : AVC
Format profile : High@L4.0
Duration : 2mn 7s
Bit rate : 43.4 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Stream size : 660 MiB (99%)

[BadFrame]

BadFrame
thx.
I am not familiar with reference HEVC encoder.
I want to try Strongene HEVC latest beta version (http://xhevc.com/en/downloads/downloadCenter.jsp).
Ok, I've only tried the fraunhofer reference encoder, that commercial encoder you linked looks interesting but I'm on Linux, perhaps it runs under wine though.

[zerowalker]

Yes indeed, at high bitrates, the only Real difference was that x264 wasn´t able to keep the image "accurate", it tried it best to keep the bits at the right places, but you can clearly see that it doesn´t do to well.
While VP9 have alot more balance, and is able to produce a much more detailed and accurate image.

Though, the difference isn´t Day and Night, but it´s still there.
And thinking that VP9 will be better and better makes this very interesting!

[mindwin]

BadFrame
but I'm on Linux, perhaps it runs under wine though.
I think it will not work, becouse it is a DirectShow filter.
I am using it with GraphStudioNext utility.

[zerowalker]

mindwin, will maybe try it later, currently VP9 is so slow, that it takes like 1-2 hours for 2-3 secs, which isn´t that fun;P

[schweinsz]

Is there any configuration to use the vp9 to get the max PSNR using the fixed QP coding? I want to do a comparison between the HEVC HM and the vp9 reference software.

[guada2]

Hello midwin,
The installation went well. But i have a small problem:
VFW_E_CANNOT_ CONNECT (0x80040217)


how can i do to solve it.

Thanks

[zerowalker]

Well let´s try to keep it towards VP9. Comparing VP9 with HEVC is a good thing though, they should be compared as they are combating about the "throne".

But i would like to know, why can´t i make a .webm file with VP9?

mkvtoolnix doesn´t allow this for some reason, i thought the VP9 in Webm was a standard for a while now, or has it been changing alot, making them wait?

[Guest]

OT posts have been removed. This thread is about VP9. Start a new thread for HEVC. Thank you.

[mzso]

Well let´s try to keep it towards VP9. Comparing VP9 with HEVC is a good thing though, they should be compared as they are combating about the "throne".

But i would like to know, why can´t i make a .webm file with VP9?

mkvtoolnix doesn´t allow this for some reason, i thought the VP9 in Webm was a standard for a while now, or has it been changing alot, making them wait?

I'm assuming it wasn't updated to do so with vp9.

Did vp9 made it into the main ffmpeg branch?

[zerowalker]

Probably, would like to see it though, but as there is no decoder to play the videos, it doesn´t really matter at this time.

From when i last checked, No.

ffmpeg seems to go after the git version 1.2.0 instead of Master for some reason.

[Nintendo Maniac 64]

Probably, would like to see it though, but as there is no decoder to play the videos, it doesn´t really matter at this time.

Chrome doesn't count? :P

[zerowalker]

What´s Chrome?

Just kidding, well sure it works, but i wouldn´t actually call it a player;P

[benwaggoner]

Is there any configuration to use the vp9 to get the max PSNR using the fixed QP coding? I want to do a comparison between the HEVC HM and the vp9 reference software.
I think an unconstrained VBR encode at the same bitrate as a HEVC encode would be a fine initial comparison. Unless you're trying to compare the relative strengths of the codecs without any rate control.

I seem to recall that VP9 defaults to tuning for PSNR.

[Rumbah]

First of all thanks for the compiling help, I just got vpxenc compiled with an up to date MSYS 64 and Yasm.
Unfortunately, PSNR is probably the worst available objective metric available. I'd like to see 3SSIM or MOVIE at least. I really don't understand why anyone focusing on a real-world codec would spend much time on PSNR.Are 3SSIM and MOVIE freely available anywhere for HD resolutions?I seem to recall that VP9 defaults to tuning for PSNR.Well, according to the vpxenc command line help you have --tune=psnr,ssim to choose from. If it defaults to any of this I do not know.

[zerowalker]

Okay need to ask these, how do you get 2 Passes to work?

If i set passes 2, it will just do the fast first pass.
How can i make it do the second pass?

[Rumbah]

You need --passes=2 --pass=1 for first pass and --passes=2 --pass=2 for second pass.

[zerowalker]

ah, that make sense, thanks.

Okay, well it doesn´t work for me.

ffmpeg -i "Z:\Dead Space 2\deadspace2.avs" -f yuv4mpegpipe -| vpxenc --best --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 --passes=2 --pass=1 --kf-

max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --

codec=vp9 --target-bitrate=1000 -o dead.webm -

ffmpeg -i "Z:\Dead Space 2\deadspace2.avs" -f yuv4mpegpipe -| vpxenc --best --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --end-usage=vbr --auto-alt-ref=1 --passes=2 --pass=2 --kf-

max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --

codec=vp9 --target-bitrate=1000 -o dead.webm -

[easyfab]

And with --fpf=name.ext -> first pass statistics file name ?

and pehraps also -w and -h for the resolution ?

[Rumbah]

I always used --fpf=filename
to give a filename for the first pass statistics file, i don't know if the encoder creates it automatically if you omit it (for both passes, the only difference is pass=1 and pass=2)

[zerowalker]

Just read about that command, and that solved it.
Or well, i also skipped the pipeline by just adding the yuv file in the same folder as i encode.

But got it working at last:)

It´s still super slow though, would like them to do some optimization to speed it up a bit atleast XD

[Rumbah]

Well, if you look at the git it changes very fast. If you need a new version compile just say so ;)

[zerowalker]

Yeah, i am following it:)

And am encoding now, using the latest, and it´s still super slow XD

But, when you compile, do you get the an error in the "make" command?
I get it everytime, and i have to rename Libvpx_g.a to Libvpx.a (or well i have to copy it and have both those files). then rerun make to make it work.

It´s just irritating:S

[Rumbah]

I use the patch form here:

http://forum.doom9.org/showpost.php?p=1633729&postcount=6

So after the ./configure I use the patch with
patch Makefile libvpx-makefile.diff
in the libvpx main directory. Then the following make works without a problem.

This is the script I use with libvpx-makefile.diff in the main libvpx directory:
cd libvpx
git pull
./configure
patch Makefile libvpx-makefile.diff
make

[zerowalker]

Ah, think i read about that before, didn´t know how to use it though.

Where can i put the script and use it?
I always write everything from scratch in Mingw?

Also, i use standard mingw, should i use mingw64 or something like that?

EDIT:

Got the script and patch to work, Thanks:)

[Rumbah]

well, I have used git clone http://git.chromium.org/webm/libvpx.git
in my home folder so it created the libvpx sub folder.

To get a new version of the source just switch in the libvpx main folder with cd libvpx and use git pull to get the latest version.

I copied the libvpx-makefile.diff in that main folder and patch it after the configure with patch Makefile libvpx-makefile.diff.

So just copy the libvpx-makefile.diff into the main libvpx folder.

Then you can create a text file example.sh and if you put it in the main libvpx folder just inset in the text file:
git pull
./configure
patch Makefile libvpx-makefile.diff
make

Or if you place it anywhere else just insert a "cd to libvpx folder" at the beginning.

[zerowalker]

Yeah got it to work, had a bit different folder setup, but it all went well.
Needed to experiment to get Patch working, but now all is well!

Thanks, saves time and frustration:)

[zerowalker]

Does the latest encoder work for you?
For me, it produces like 1 frame that looks good (the first frame, maybe some more), then it´s just artifacts and messed up:S

[easyfab]

Zerowalker, Rumbah,

Here an example of my little script if it can help you to build vp9 more easily .
In my example, first create a folder build in home and src in build, put libvpx-makefile.diff in the build folder and create a vp9.sh like this :

MY_BUILD=${HOME}/build
cd ${MY_BUILD}/src/
git clone http://git.chromium.org/webm/libvpx.git
cd ${MY_BUILD}/src/libvpx
git pull
patch -p1 < ../../libvpx-makefile.diff
./configure --disable-vp8
make clean && make -j4 && make install

[zerowalker]

what does the -j4 command do?

[easyfab]

It use multithread, a lot faster if you have a multi-core processor, I use -j4 but you can also use more like -j8 but it could be more unstable.

[zerowalker]

Alright, well tried it, with some modifications, and well went pretty much the same as before.
Took along time to compile though.

And well, it became less in size, guess thanks to no vp8.

But damn, i still get the artifact problem.

4 frames work, then the rest is just blended colors in a mess:S

[easyfab]

Problably a latest commit broke something.

If you want to build an old version you can do a :
git checkout <HASH>
for <HASH> you need to know the commit hash look here http://git.chromium.org/gitweb/?p=webm/libvpx.git under commit (h=XXX)
or git checkout HEAD~<number>
for example HEAD~20 gives you an old version of 20 commits back

[BadFrame]

You need --passes=2 --pass=1 for first pass and --passes=2 --pass=2 for second pass.
Hmm... all I do is set --passes=2 and the encoder does two passes automatically without me having to do anything (no --pass x needed), the first pass is fast and the second pass (where it does the actual encoding) is very slow.

You can see which pass it's on when it's encoding as it is displayed with the current frame:

Pass 1/2 frame x
...
Pass 2/2 frame x

[zerowalker]

Probably, if someone could test the latest commit, just encode like 10 frames, and watch it with chrome (you can watch while encoding, though it´s FPS isn´t correct so it plays to fast, but you see the artifacts anyway).

Hmm... all I do is set --passes=2 and the encoder does two passes automatically without me having to do anything (no --pass x needed), the first pass is fast and the second pass (where it does the actual encoding) is very slow.

I think i have seen that as well, not actually sure though. However i haven´t seen any "stats" file being created.

[BadFrame]

I think i have seen that as well, not actually sure though. However i haven´t seen any "stats" file being created.
Well here is how I understand it, when you use '--passes 2' without specifying a '--pass X', there is no need for a 'statistics' file as the whole 2 pass encode is done in 'one go' (in other words, the encoder doesn't exit after a pass).

And in this 'mode' the statistics which would normally be stored in a file (-fpf=<file>) during the first pass is instead stored in allocated memory and from there used in the automatically started second pass.

If you specify a pass using '--pass N' however, it will exit after each pass and store the statistics in the file you specify using '--fpf=<file>', just the way it works in x264 for example.

I also verified this by encoding a clip using only '--passes=2' and then the same clip using '--pass=1' followed by '--pass=2' and the webm files created where bit identical (confirmed by md5sum).

So in other words, if you have no interest/use of the statistical data generated, you can supply only '--passes=2' (without --pass N) and it will automatically do the two passes after eachother with no manual intervention.

[zerowalker]

It seems like what you are saying is true.
Saves a line of code;P

But is anyone able to encode with vp9?
I still get the artifacts.

It seems weird that it still hasn´t been solved, i am starting to suspect something on my side.

[BadFrame]

But is anyone able to encode with vp9?
I still get the artifacts.

It seems weird that it still hasn´t been solved, i am starting to suspect something on my side.
I did some tests just yesterday with no problems at all.

Given that I have no problems and I am using vpxdec to losslessly decode the vp9 video to watch it rather than use Chrome which you've stated you are using, I dare say that the problem lies with your version of Chrome not being compatible with the vp9 stream generated by the latest vpxenc builds and that this is what is causing problems for you during playback.

[zerowalker]

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?

[BadFrame]

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?
Yes I suppose it should, however are you sure that the version of Chrome you have includes a version of vp9 that is after the bitstream freeze?

[zerowalker]

Pretty sure, it´s the latest Chrome Canary (Test build).

http://www.sendspace.com/file/96oly0

there is a file, see if you can play it

[BadFrame]

Pretty sure, it´s the latest Chrome Canary (Test build).
Hmm... maybe they aren't that gung-ho about keeping the bitstream compability in the middle of development and will instead fix it in time for a final release?

I don't use Chrome so I don't have it installed and thus haven't tried it with VP9, but decoding the vp9 streams with vpxdec works perfectly fine for me.

edit: missed that you added a vp9 file, it decoded just fine and I then encoded it using x264 and it played fine aswell when I watched it.

steps I took if you are interested:

vpxdec --i420 -o i420.mkv dead.webm
x264 --crf 0 --input-res 1920x1080 i420.mkv -output h264.mkv

[zerowalker]

That worked great for me aswell.

Weird that they aren´t keeping the decoding of chrome the same, i was sure they had frozen the bitstream last month.

[hajj_3]

chrome 29 beta is out now btw, vp9 decoding is enabled by default.

[iwod]

Do VP9 Encoder or the spec adds some pre filter to video and default post filter when playback.

I seems to get a sense of Rmvb 'work in there.

[Monarc]

http://www.sendspace.com/file/96oly0

Plays fine ... tested with self compiled mpv (linux)

[Nintendo Maniac 64]

I don't use Chrome so I don't have it installed and thus haven't tried it with VP9
I don't have Chrome installed either but you can use this instead which doesn't require installation (the "installer" is just a fancy archive unpacker):
http://portableapps.com/apps/internet/google_chrome_portable

Scroll down for the beta versions.

The only thing missing is the auto-updater service, which depending on the person may actually be a good thing.

[IgorC]

BTW, some news from Opus codec.
Opus 1.1 beta. A new WebM audio codec (Opus+VP9) (http://forum.doom9.org/showthread.php?t=168270)

[foxyshadis]

Do VP9 Encoder or the spec adds some pre filter to video and default post filter when playback.

I seems to get a sense of Rmvb 'work in there.

RMVB, H.264, and VP6 to 9 all have inloop filtering. It's much better than pre or post filtering, but it becomes much more obvious the lower the bitrates go. RMVB and the VP family will more aggressively soften and smooth the video than H.264, but I see a great deal of promise in VP9 despite not having been a fan of previous generations (and the exaggerated claims that went with them).

If vendors don't move quickly on HEVC, VP9 may well steal their thunder for a few years.

[mandarinka]

I doubt that. It's Google who will be moving slowly (as with VP8), because they will probably again be the sole provider of VP9 encoders.

On the other hand, handful companies already announced or even offer H.265 encoders, and the competition is bound to push quality and speed of them up. Basically, it's open environment (somebody might find it paradoxical, but the MPEG stuff really is open in all ways but the royalty requirement).

[BadFrame]

Basically, it's open environment (somebody might find it paradoxical, but the MPEG stuff really is open in all ways but the royalty requirement).
Not following the 'open environment' argument, there's a HEVC specification and to implement the specification and sell the implementation you need to pay royalites to cover the patent licencing, VP9 afaik is entirely royalty free and also licenced permissively so in terms of 'open environment' it wins hands down there.

I still think you are right as far as the actual result though, given that Google gives away a free fully open source codec which is the 'standard', I think there's very little commercial opportunity to compete.

Compare that to HEVC where it's unlikely to be any quality open source and free offering until the x264 devs get a mature h265 encoder out (go guys go! :D), that situation leaves a lot of room for commercial closed source h265 encoders.

[mzso]

Not following the 'open environment' argument, there's a HEVC specification and to implement the specification and sell the implementation you need to pay royalites to cover the patent licencing, VP9 afaik is entirely royalty free and also licenced permissively so in terms of 'open environment' it wins hands down there.

I still think you are right as far as the actual result though, given that Google gives away a free fully open source codec which is the 'standard', I think there's very little commercial opportunity to compete.

Compare that to HEVC where it's unlikely to be any quality open source and free offering until the x264 devs get a mature h265 encoder out (go guys go! :D), that situation leaves a lot of room for commercial closed source h265 encoders.

Since when does quality matter? You can see some ugly encodes on Blu-Rays...

[XaLBa]

I see, probably true.
But i find it weird, doesn´t a bitstream freeze mean that decoders will be compatible forever with the codec?

There was a bugfix (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=31a68bcdfffdefbfea28c3cf9678363d4fec4bc3) recently, which affected the bitstream.

Possibly this is the cause of the decoding problem.

[pieter3d]

That looks like it is part of comp (composite?) prediction, which I haven't been able to get the vp9 encoder to utilize. So, likely it isn't a factor.

[XaLBa]

Agree. But possibly I missed another fix changing bitstream.
Regarding compound prediction, developers restricted its usage not long before bitstream freeze: now it is available only in case when one reference frame is from the past and another is from the future. Not sure that encoder currently has such tools.

[dapperdan]

VP9 Status update from Google

https://groups.google.com/a/webmproject.org/forum/m/?fromgroups#!topic/webm-discuss/bbMo00Gvops


Progress so far is 7 times faster with no quality impact, 20x faster with 5% quality penalty and 50x faster with 12% quality drop.

[BadFrame]

Progress so far is 7 times faster with no quality impact, 20x faster with 5% quality penalty and 50x faster with 12% quality drop.
Looks very promising, have you seen anything regarding them enabling multithreaded encoding again?

I read somewhere that they disabled it to make development easier, now that the bitstream is finalized and optimizations are taking place it should be something of a priority methinks?

Being able to utilize more than one core for a single encode would make quite a difference.

[Kurtnoise]

Here are some recent (yesterday) windows builds for those are interested :

- x86 (http://tinyurl.com/lztn3ku)
- x64 (http://tinyurl.com/kbmexrz)

[Selur]

Thanks Kurtnoise for this new builds! :)

[XaLBa]

Looks very promising, have you seen anything regarding them enabling multithreaded encoding again?

I read somewhere that they disabled it to make development easier, now that the bitstream is finalized and optimizations are taking place it should be something of a priority methinks?

Being able to utilize more than one core for a single encode would make quite a difference.

As I can see, they didn't disable multithreading. They just haven't implemented it yet in VP9 encoder. VP9 format have tiles, which will allow easy threading implementation. But if VP9 is proposed as encoder for wide range of application (including video calls and screen capture), it should provide acceptable single-core performance.

Also what was confusing for me, they use “cpu-used” option, which implies multithreading, but actually it is something similar to “preset” option of x264.

[dapperdan]

Being able to utilize more than one core for a single encode would make quite a difference.

It'll happen eventually as part of the codec design was to plan for the multi-core future, this part of the preview spec (although headlined "Parallel Decodability") talks about tools for multi-threaded encoding:

http://tools.ietf.org/id/draft-grange-vp9-bitstream-00.html#rfc.section.3.2

On the other hand, they might want to wait until they start to hit diminishing returns on a single CPU, most heavy users can spin up mutiple encodes at the same time to use up idle CPUs and at the other end of the scale some people won't be able to spare more than one core so it may or may not be top of their agenda, it really depends on where they think the low hanging fruit are and what use-cases they are prioritising.

[mzso]

Aren't there any ffmpeg builds out there with vp9 support for windows?

It should be in ffmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=libvpx) for a long while now, but the builds linked from the main site are stubbornly without vp9.

[mzso]

Well, I found this (http://oss.netfarm.it/mplayer-win32.php). but it fails every time I try to encode.
[libvpx-vp9 @ 04ec2ba0] Failed to set VP8E_SET_TOKEN_PARTITIONS codec control: Unspecified internal error

[Kurtnoise]

Why you need it ? Just use the pipe line...

[Selur]

@Kurtnoise: when trying to start the x86 build on Windows XP, I get: "vpxenc.exe is not a valid Win32 application" (works fine on Win7)
-> What compiler did you use?

[Kurtnoise]

Visual Studio 2012 - XP compatible (http://msdn.microsoft.com/en-us/library/vstudio/jj851139.aspx)...

I'll check it out when I'll get back to home.

[nevcairiel]

This XP compat is broken in Update 2 for VS2012, it only works with Update 1 or the new Update 3, which would result in exactly such a message.
An alternative could be SSE2 optimizations which are enabled in VS2012 by default, and Selur runs an ancient CPU. :)

[Rumbah]

Here are 32 and 64 bit MinGW compiles, perhaps they work with XP:

http://x264.janhum.alfahosting.org/vpx27072013.7z

[Selur]

@Rumbah: the MinGW compile works on XP :)
Would be nice if you could make a build which includes VP8 and VP9.
Thanks! :)

[Rumbah]

sure, here you go:

http://x264.janhum.alfahosting.org/vp8vp927072013.7z

[Selur]

Nice! Thanks a lot!

[mindwin]

I am trying to encode(VP9 vpxenc) foreman.y4m, first pass works fine, but the second pass encoder all the time crashes.
What problem could be?
(AMD Phenom II X3, Windows 7 x64

The problem was in options.
Works well with
-p 2 --min-q=0 --drop-frame=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --end-usage=vbr --target-bitrate=100 --codec=vp9 --good --profile=0 --auto-alt-ref=1 --lag-in-frames=25 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --kf-min-dist=0 --kf-max-dist=9999 -v --psnr --tune=psnr --test-decode=warn

[Selur]

vp9: tile limits were off source: http://forum.selur.de/topic22-infos-about-fixed-bugs-etc-in-the-next-release.html

Will be fixed in the release I plan to make this evening,..

[easyfab]

I try to compile ffplay with libvp9 and it seems to work for me, if someone want to play with this ffplay vp9 version : https://mega.co.nz/#!1VE3XBJS!PeLmHlEMp_anouHgdhwuiWBramsYPL0I6aAqYwQ7cG4
As libvp9 support is experimental in ffmpeg please add -strict -2
command line example : ffplay.exe video.webm -strict -2

[xooyoozoo]

VP9 development seems to have stabilized, as there's been few speed/quality commits in the past several weeks. This is then likely a good time to finally assess fps-size tradeoffs as well as compare VP9 to both VP8 and x264.

Using four 300 frames 704x576 test sequences (ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/), I measured normalized size for the same quality (via ratios of logMSSSIM (http://mmspg.epfl.ch/vqmt)-based bdrate (http://webcache.googleusercontent.com/search?q=cache:okESKHI6xzQJ:www-ee.uta.edu/dip/courses/ee5356/BDPSNR.doc+&cd=1&hl=en&ct=clnk&gl=us)) and normalized encoding speed (via ratios of geometric means) and took the mean of all clips. The 2pass encoders had bitrate scaling (based on previous tests) to prevent bdrate calculations from chopping off large regions of extremities. The versions and settings tested are shown here (http://pastebin.com/QnhBhhH4).

Everything was normalized to be a ratio of x264-veryslow's results:

http://i.imgur.com/Ng7MY3s.png

The three dashed lines are power law trend lines respectively based on speed-size scalings between x264's superfast-faster, faster-slower, and slower-veryslow. The logic here is that some compromises are reasonable, and the trends demonstrate the tradeoffs x264 makes and thus the regions where next-gen encoders must be in order to be "acceptable" for current x264 users.

I included VP8's best mode, but it's obvious the mode is VP8's equivalent of a placebo preset. The same is even more true (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=0d8723f8d5372eaaadfb5373a3b9d35e2c78c42d) for VP9, though I didn't bother with actually testing that.

The lone cross in the graph's bottom left corner is a result for a week old x265 build. x265's development is currently too rapid for reliable testing, so I didn't want to focus on it but still wanted to include a single (admittedly non-useful) data point.

Lastly, I included x264-veryslow with --aq-mode 0 (effectively --tune psnr) to demonstrate how well psychovisually-revelant metrics favor adaptive quantization. Both x265 and VP9 currently have no AQ. Commits in x265 indicate that AQ's on-track/definite, and VP9/WebM's mailing lists indicate that the developers will look into it.

Note that everything was tested on a dualcore Penryn left untouched during runs for accurate speed results. Having (only) 2 cores means that on other machines, single-threaded VP9 may have much lower normalized speeds. Also, I believe x264 is well optimized for newer instruction sets and should be relatively faster on AVX2/FMA/etc chips.

Edit:

If we play around with the numbers established in the graph above, an idealized next-gen "equivalent" (i.e. half the size at similar speed scaling) for x264-medium would have a point at [0.5914, 0.0204] on the graph. The same for x264-veryslow would be at [0.5, 1.375E-6], so someone who chooses 'veryslow' over 'slower' may find it reasonable to halve the filesize even if a 1hr encode now takes 83 years. ;)

[mandarinka]

An interesting development: https://gerrit.chromium.org/gerrit/#/c/65426/

A variance-based adaptive quantization patch for VP9 - it is based on x264's approach AFAIK, although according to the developer, it turned out to be less effective in VP9 (so far).

[Nintendo Maniac 64]

GStreamer 1.2 supposedly includes experimental VP9 encode & decode via the vpx plugin:
Major changes:
　• New plugins:
　 　∘ vpx plugin has experimental VP9 decoding and encoding support

Source: http://gstreamer.freedesktop.org/

Direct link to release notes: http://lists.freedesktop.org/archives/gstreamer-devel/2013-September/043124.html

[zerowalker]

Is there still no Decoder for Media Players for VP9?
It´s been around for half a year now, and while it has improved in terms of speed from my tests, it isn´t exactly adopting to well, though then again VP8 never did either.

EDIT:

How do you make 64 bit builds?

[Nintendo Maniac 64]

According to this article:
http://www.myce.com/news/vlc-2-1-released-new-audio-core-4k-ready-new-mobile-ports-68904/

The VideoLAN guys supposedly said that VLC would get VP9 support in about two weeks. However, I cannot find any source on where they got the "two weeks" thing from, so who knows?

On the other hand, the following forum thread is very relevant and contains a direct comment from one of the VideoLAN forum admins regarding VP9 not actually having a proper release yet:
https://forum.videolan.org/viewtopic.php?f=7&t=111668

[zerowalker]

Oh, thought everything was public and ready, except that it´s not 100% completed.
By that explains the standstill.

Hope things starts moving when it´s released, cause VP9 is pretty worthless now for use as you can´t even play it,
small steps like usability is a good thing that hopefully will bring more eyes to it.

[BadFrame]

Oh, thought everything was public and ready, except that it´s not 100% completed.

According to the webm git history the developers tagged a 'stable vp9 decoder' branch 36 hours ago, so I guess from here on the decoder is ready to go and we'll likely see quick uptake in atleast the open source ecosystem.

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

[zerowalker]

Ah great, will be holding hopes on this, Open Source Codecs like this are really interesting.

[Kurtnoise]

There is also a patch review for a native vp9 decoder (http://ffmpeg.org/pipermail/ffmpeg-devel/2013-September/148634.html) from the FFmpeg crew...

[Nintendo Maniac 64]

Once we have actual VP9 encoders and decoders, shouldn't we make separate threads instead of bunching up in this topic that doesn't even mention VP9 in the title? I mean, by then VP9 will be current-gen, not next-gen. :P

EDIT: For reference I just counted 9 separate h.265-related threads on the first page of the "New and alternative video codecs" forum.

[dapperdan]

Another VP9 status update from Google:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webm-discuss/EO3fF_1Wry4

Some highlights:

[encode] x7.5 speedup for --cpu-used=0 up to approximately a x80 speed up for --cpu-used=2.

[decode] Arm / Neon ~ x4 speedup (We can now decode 720p a Nexus 10). Intel ~ x1.5 speedup.

have added a command line constant quality option (--end-usage=3, --cq-level=<value>, where value is the Qp level).

[zerowalker]

So multi core works now?
Or am i misreading it?

Nintendo: I agree, this thread is more suited for (What news does this unknown new Google codec bring?).

[mzso]

Once we have actual VP9 encoders and decoders, shouldn't we make separate threads instead of bunching up in this topic that doesn't even mention VP9 in the title? I mean, by then VP9 will be current-gen, not next-gen. :P

EDIT: For reference I just counted 9 separate h.265-related threads on the first page of the "New and alternative video codecs" forum.

When will that be... Last time I checked the builds on the webmproject site didn't include VP9.

[Nintendo Maniac 64]

When they say "Intel", I wonder if they mean x86 or if they actually mean 'Intel'. Previously when I tried to play a VP9 video in Chrome it fully pegged a core on a 2.8GHz Phenom II 920. For reference I can do 720p VP8 in VLC on a 1.6GHz Intel Atom N270 (1 core, 2 threads), on a 2GHz Pentium 4 (Northwood), and on an underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x512KB L2).

[Rumbah]

The last time I checked the decoder and encoder were not multithreaded.

And VP9 is more complex than VP8 so it's more ressource hungry when decoding.

[BadFrame]

So multi core works now?
Or am i misreading it?

You are misreading it, the '--cpu-used' parameter (atleast as I understand it) is there to offer more fine-grained quality/resource demand settings beyond that of --good and --rt .

For example, '--good' used with '--cpu=0' should be very close to the quality of '--best', and then as you increase '--cpu=n' the quality will drop as certain performance demanding features are disabled, leading to increased encoding/decoding speed (again at the cost of quality).

It certainly has nothing to do with multithreading the encoder, which is not yet implemented although I'm certain it's currently being worked on in a non-public branch as it's kind of disruptive.

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

[BadFrame]

When will that be... Last time I checked the builds on the webmproject site didn't include VP9.
The builds there are based upon official releases, the last one was 1.1 (eider), the next one is 1.2 (yet unnamed) which supports VP9. I guess it will be out once multi-threading is in place (together with yet more fine-tuning).

Meanwhile if you go to 'downloads' they do offer snapshots of the current branch for you to build, or you can of course just build directly against the git master branch (that's what I do).

[easyfab]

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

I think he did the native VP9 decoder in ffmpeg recently but I hope mutithreading in under way.

[mandarinka]

I don't recall the source (must have been somebody from libav), but IIRC he left or is going to leave Google.

[Kurtnoise]

Only the loop filter is multithreaded in the vp9 library for the moment...

[Nintendo Maniac 64]

And VP9 is more complex than VP8 so it's more ressource hungry when decoding.

The 2GHz Northwood Pentium 4 is a single core and single thread processor, and a Phenom II is nearly twice as fast per-GHz (SOURCE (http://www.tomshardware.com/reviews/processor-architecture-benchmark,2974-15.html)). Doing some math*, that would make a 2.8GHz Phenom II be about 2.7x faster in single-threaded operations than a 2GHz Northwood.

So you're telling me that VP9 is almost 2.7 times slower to decode than VP8? Doesn't that seem a bit...much? Even h.264 high profile isn't that much more CPU demanding than VP8 is; I can decode either 1280x720 30fps VP8 or high-profile 1280x720 30fps h.264 on a mere underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x 512KB L2) - and yes that's without h.264 GPU acceleration.


* Here's the math I did.
3 (Reference Pentium 4 clockrate) / 2 (My Pentium 4 clockrate) = 1.5
240 (Reference Pentium 4 score) x 1.5 = 360 (estimated 2GHz Pentium 4 score)
3 (Reference Phenom II clockrate) / 2.8 (My Phenom II clockrate) = 1.07
124 (Refrence Phenom II score) x 1.07 = 133 (estimated 2.8GHz Phenom II score)
360 / 133 = 2.7

[fumoffu]

I would say this sounds about right - yes it's that much slower. VP8 has similar complexity to h264 so there isn't much difference. But VP9 and HEVC are 2-3 times more hardware demanding than previous generation. (and yes I'm talking about decoding, because encoding speeds are 5-10times slower...)

[phate89]

The 2GHz Northwood Pentium 4 is a single core and single thread processor, and a Phenom II is nearly twice as fast per-GHz (SOURCE (http://www.tomshardware.com/reviews/processor-architecture-benchmark,2974-15.html)). Doing some math*, that would make a 2.8GHz Phenom II be about 2.7x faster in single-threaded operations than a 2GHz Northwood.

So you're telling me that VP9 is almost 2.7 times slower to decode than VP8? Doesn't that seem a bit...much? Even h.264 high profile isn't that much more CPU demanding than VP8 is; I can decode either 1280x720 30fps VP8 or high-profile 1280x720 30fps h.264 on a mere underclocked-to-1GHz Athlon 64 x2 (Brisbane with 2x 512KB L2) - and yes that's without h.264 GPU acceleration.


* Here's the math I did.
3 (Reference Pentium 4 clockrate) / 2 (My Pentium 4 clockrate) = 1.5
240 (Reference Pentium 4 score) x 1.5 = 360 (estimated 2GHz Pentium 4 score)
3 (Reference Phenom II clockrate) / 2.8 (My Phenom II clockrate) = 1.07
124 (Refrence Phenom II score) x 1.07 = 133 (estimated 2.8GHz Phenom II score)
360 / 133 = 2.7

I think that twice the decoding complexity was planned for both h265 and vp9, the missing 0.7 is all better optimization

[Nintendo Maniac 64]

I think that twice the decoding complexity was planned for both h265 and vp9, the missing 0.7 is all better optimization

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

[phate89]

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

vp8 is similar to h264...

[benwaggoner]

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)
If you are CPU-bound than H.264 is definitely your friend on older hardware, as long as you have a GPU good enough to enable hardware decode in Flash or HTML5. VP9 and HEVC are going to be software (or software + GPU) on existing and near-future PC platforms.

It is an interesting and evolving question for when using >H.264 codecs delivers more benefit from better compression than the downside from increase decoder requirements. Particularly for battery-powered devices.

HEVC is promising for multi-core machines as it is highly parallelizable with Wavefront Parallel Processing; you can easily get a parallel decoder thread per 64 pixels of frame height. Finally something to do on those quad-core ARM phones :).

Also, there really aren't any practical VP9 or HEVC encoders available today. We can do apples-to-apples comparisons to some degree, but x264 generally gets used to make oranges. Common scenarios like capped VBR with adaptive GOP length and B-frame patterns with reasonable encode times are months away for the next gen codecs.

[Nintendo Maniac 64]

If you are CPU-bound
I'm largely bandwidth-bound. 720p YouTube requires about 330KB/s and I can only achieve that with multi-chunk downloads (~360KB/s). With video streaming and/or single-chunk downloads, I can only achieve around 310 KB/s.

than H.264 is definitely your friend on older hardware, as long as you have a GPU good enough to enable hardware decode in Flash or HTML5.
I'm talking about purely software decoding. You definition of "older hardware" is newer than the 'older hardware' that I'm currently using. :p

Integrated GPU hardware that was compatible with the Athlon 64 x2 or the Core 2 Duo largely predates the concept of h.264 decoding on the GPU. Only the Radeon HD 3200 and 4200 series of iGPs were new enough to have h.264 decoding and yet were still compatible with the both older (AM2) Athlon 64 x2 and the newer Phenom II x6.

For reference, my desktop is the Athlon 64 x2 Brisbane previously mentioned, and luckily for me I happen to have a Radeon HD 4200 iGP. My Core 2 Duo laptop is not so lucky however...

[borring]

I heard/read that decoding performance for VP9 was to be similar to h.264...

Nevertheless, I just hope that a 2.5GHz Brisbane and/or a 2GHz Conroe will be able decode 720p VP9! Otherwise I'm SOL, especially since I was hoping for VP9 in order to actually stream YouTube 720p. (My connection is just a bit too slow for it, unless the video has very minimal movement)

I don't think you need to worry with that hardware. I was having just a little trouble decoding youtube vp9 videos at 480p with my 1.9Ghz apu in chrome. Fortunately, the libvpx in git is way faster than the one currently shipped with Chrome. After compiling Chromium using the latest libvpx code, I can play 1080p.

[Nintendo Maniac 64]

I don't think you need to worry with that hardware. I was having just a little trouble decoding youtube vp9 videos at 480p with my 1.9Ghz apu in chrome. Fortunately, the libvpx in git is way faster than the one currently shipped with Chrome. After compiling Chromium using the latest libvpx code, I can play 1080p.

But all of the APUs that run at 1.9GHz have a turbo up to at least 2.4GHz. My Brisbane completely predates the concept of Turbo.

Also if that's a Llano rather than a Trinity, then it'll be even faster at 1.9GHz. (Llano is slower per GHz than Trinity, but Trinity clocks considerably higher per watt)

[borring]

Just found out my turbo core was actually working (2.35 Ghz). Just requires special tools to report the right frequencies.

It still has a harder time decoding than my Core 2 Duo though. It's a shame though that my APU isn't new enough to have all the popular instruction sets.

[Nintendo Maniac 64]

Here's something interesting, apparently new uploads to YouTube have at least their 480p and 1080p resolutions have the video stream seperate from the audio stream. This is relevent because, AFAIK, Opus isn't (yet) compatible with MKV (which WebM is a subset of). This woud mean that using Opus audio in an OGG container (which is all .opus is) and using VP9 in a WebM like usual, you could essentually have VP9 + Opus.

Source: https://github.com/YePpHa/YouTubeCenter/issues/98#issuecomment-26488263

[sneaker_ger]

This is relevent because, AFAIK, Opus isn't (yet) compatible with MKV

Opus in mkv has been finalized and is supported by mkvtoolnix.

[Nintendo Maniac 64]

Opus in mkv has been finalized and is supported by mkvtoolnix.

Well shoot, I need to update my version of mkvtoolnix then! I've been waiting on that functionality.

And just to clarify, ffdshow doesn't decode vp9 yet, correct? I'm also waiting to update for that functionality.

[vivan]

And just to clarify, ffdshow doesn't decode vp9 yet, correct? I'm also waiting to update for that functionality.ffdshow is dead

[zerowalker]

fddshow tryout is pretty dead too, atleast it´s been 4 months.

Not sure who will add it, only thing i can think of is MPC, and i sadly don´t use that as a Player.

[Rumbah]

MPC doesn't use ffdshow anymore, either. It is distributed with LAV filters.

[Keiyakusha]

MPC doesn't use ffdshow anymore, either. It is distributed with LAV filters.

MPC never used ffdshow... unless you installed both and made ffdshow preferred decoder.
Also not every MPC out there uses LAV. There is the one that does, there is the one that doesn't. Both of them will have vp9 support. (Plus there were lite builds that don't use anything, but not sure if they are still supported)

----
Anyway. When people here say "ffdshow is dead" they mean tryouts one. Original ffdshow is dead for sooo long, hardly anyone remembers it existed. And its not 4 months, its more than a year. If there were some small maintenance commits, it doesn't counts.

[sneaker_ger]

(Plus there were lite builds that don't use anything, but not sure if they are still supported)

The current official builds are basically MPC-HC lite, i.e. the filters are not integrated in the executable. They just ship with an extra folder that includes the LAV Filters.

[Nintendo Maniac 64]

I meant tryouts.

But uh, ok, perhaps I should reword the question then; both ffdshow tryouts and LAV filters do not support VP9 decoding currently, correct?

[nevcairiel]

LAV Filters will support VP9 soon, but not right now, thats correct.

[the_weirdo]

No, they don't support VP9 decoding yet. However, I suppose nevcairiel will update his filters to support VP9 soon after he's back from his vacation. Not sure about ffdshow-tryouts though.

[mandarinka]

Well, VP9 isn't exactly a "yesterday was too late" feature, is it. Encoding into the format is alpha, there is no content, etc.

[dapperdan]

you could essentually have VP9 + Opus.


I was under the impression that this was going to be the default on Youtube and for VP9 in WebM generally.

Two minor things though.

1) The WebM team proposed allowing mix-n-match so you could have VP8 and Opus and VP9 and Vorbis in WebM. Some of the Xiph team suggested that WebM should stick to VP8+Vorbis and have WebM2 defined for anything else.

2) There was an obscure comment on one of Xiph's meeting logs for Daala that said "- jm: i keep getitng interrupted with issues like google dropping opus for complexity reasons." but I don't know the context of that.

[Beelzebubu]

I'd also guess that it is being primarily done by Ronald Bultje as I haven't seen any public commits from him in a long time and as far as I know he is one of the current lead developers of VP9.

Was, unfortunately. I no longer work at Google. I did write FFmpeg's native VP9 decoder (and am still working on optimizing it) together with Clement Boesch, though.

[BadFrame]

Was, unfortunately. I no longer work at Google. I did write FFmpeg's native VP9 decoder (and am still working on optimizing it) together with Clement Boesch, though.

Ah what a shame, you've certainly left a void with all the great commits you kept pumping out.

Good luck on whatever venture you are currently engaging!

[Kurtnoise]

The 1.3.0 release is under way...

2013-11-15 v1.3.0 "Forest"
This release introduces the VP9 codec in a backward-compatible way.
All existing users of VP8 can continue to use the library without
modification. However, some VP8 options do not map to VP9 in the same manner.

The VP9 encoder in this release is not feature complete. Users interested in
the encoder are advised to use the git master branch and discuss issues on
libvpx mailing lists.

- Upgrading:
This release is ABI and API compatible with Duclair (v1.0.0). Users
of older releases should refer to the Upgrading notes in this document
for that release.

- Enhancements:
Get rid of bashisms in the main build scripts
Added usage info on command line options
Add lossless compression mode
Dll build of libvpx
Add additional Mac OS X targets: 10.7, 10.8 and 10.9 (darwin11-13)
Add option to disable documentation
configure: add --enable-external-build support
make: support V=1 as short form of verbose=yes
configure: support mingw-w64
configure: support hardfloat armv7 CHOSTS
configure: add support for android x86
Add estimated completion time to vpxenc
Don't exit on decode errors in vpxenc
vpxenc: support scaling prior to encoding
vpxdec: support scaling output
vpxenc: improve progress indicators with --skip
msvs: Don't link to winmm.lib
Add a new script for producing vcxproj files
Produce Visual Studio 10 and 11 project files
Produce Windows Phone project files
msvs-build: use msbuild for vs >= 2005
configure: default configure log to config.log
Add encoding option --static-thresh

- Speed:
Miscellaneous speed optimizations for VP8 and VP9.

- Quality:
In general, quality is consistent with the Eider release.

- Bug Fixes:
This release represents approximately a year of engineering effort,
and contains multiple bug fixes. Please refer to git history for details.

[zerowalker]

Hope it will finally start to be used more, like in Youtube, as i don´t think it´s used there yet, except for some experiments.

[mzso]

Hope it will finally start to be used more, like in Youtube, as i don´t think it´s used there yet, except for some experiments.

Only chrome supports it so far. Converting all videos to VP9 feels premature to me.

[Nintendo Maniac 64]

VLC 2.1.1 now has experimental support for VP9 (and HEVC) decoding:
http://news.cnet.com/8301-11386_3-57612525-76/vlc-steps-into-next-gen-video-wars-with-vp9-hevc-support/

I tried it with the video on here, but it would only show a single frame before ending the video:
http://base-n.de/webm/VP9%20Sample.html

[BadFrame]

VLC 2.1.1 now has experimental support for VP9 (and HEVC) decoding:
http://news.cnet.com/8301-11386_3-57612525-76/vlc-steps-into-next-gen-video-wars-with-vp9-hevc-support/

I tried it with the video on here, but it would only show a single frame before ending the video:
http://base-n.de/webm/VP9%20Sample.html

Yes VLC 2.1.1 has been available on the Arch Linux repos for a couple of weeks, and while I haven't tried the sample you linked, it has played all the vp9 encodes I've made myself (using vpxenc built from git main branch).

Navigating (seeking) through the file during playback doesn't work for me though, it just keeps on playing from where it was.

Also I saw that they added a 'aq-mode' setting recently called 'variance', I should do some new tests to see what impact it has.

[nakTT]

Yes VLC 2.1.1 has been available on the Arch Linux repos for a couple of weeks, and while I haven't tried the sample you linked, it has played all the vp9 encodes I've made myself (using vpxenc built from git main branch).

Navigating (seeking) through the file during playback doesn't work for me though, it just keeps on playing from where it was.

Also I saw that they added a 'aq-mode' setting recently called 'variance', I should do some new tests to see what impact it has.
I have exactly the same issue as you, but that I encounter while using the latest MPC-HC. With the latest VLC Player, I can do the seeking but once I did, the video will turn ugly with broken video image.

[dapperdan]

Another update on VP9 progress from the mailing list:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/webm-discuss/alfjBJLIA3g

Notable stuff: faster en/decode, initial implementation of a 1-pass encoding mode that currently produces valid but not very nice to look at output, VP9 decode ships with Android KitKat, hardware decoder RTL (which I believe is like source-code for hardware manufacturers) about to be released.

[Selur]

Small question: How to use VP9s lossless mode?
I though using:
for decoding:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
and for encoding:
vpxenc --codec=vp9 --lossless=1 --good --threads=16 --width=640 --height=352 -o "H:\Output\test_07_56_58_0010_01.vp9" -
but that ended with:
Error: Tried to set control 27 = 1
Failed to control codec: Invalid parameter
rc_max_quantizer out of range [..0]
using:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --threads=16 --width=640 --height=352 -o "H:\Output\test_07_56_58_0010_01.vp9" -
aborts with:
Warning: Bad quantizer values. Quantizer values should not be equal, and should
differ by at least 8.
1 encoder configuration warning(s). Continue? (y to continue) (it also only writes 'Continue? (y to continue)', but doesn't wait for an answer, it simply aborts)

-> Can someone post an vpxenc-example of a VP9 lossless encoding call?
(sadly the webm documentation is lacking in so many regards,..)

Cu Selur

[Kurtnoise]

You have to use a recent build (at least a build using the latest commits from the master branch).

Then,

--passes=1 --pass=1 --fpf=logfile.log --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=640 --height=352 -o output.webm -

[Selur]

vpxenc I used is: (build on 4th of december)
vp8 - WebM Project VP8 Encoder v1.2.0-5319-g584c729
vp9 - WebM Project VP9 Encoder v1.2.0-5319-g584c729

and calling:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --passes=1 --pass=1 --fpf=logfile.log --codec=vp9 --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=640 --height=352 -o output.wem -
still gives me:
Warning: Bad quantizer values. Quantizer values should not be equal, and should differ by at least 8.
1 encoder configuration warning(s). Continue? (y to continue)

Will make a clean rebuild a bit later and test again.

[Kurtnoise]

Like I told you, you have to use a more recent build (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=2341747805d1a829cb9140a4f391bdf2534cdf70)...

[Selur]

Ah, okay didn't know it had to be that recent. :)

[oibaf]

1.3.0 was tagged (http://git.chromium.org/gitweb/?p=webm/libvpx.git). :)

But is there an official announcement somewhere other than the git tag? Download section still only has 1.2.0 (http://code.google.com/p/webm/downloads/list). :confused:

[Kurtnoise]

From the changelog (http://forum.doom9.org/showthread.php?p=1653611#post1653611) file...

[Selur]

Compiled vpxenc&vpxdec using https://github.com/jb-alvarado/media-autobuild_suite
but either something is wrong with that build script or vpx is simply broken.

lossless creates a 1byte file
normal vp9 and vp9 encoding produces an output where it looks like that the color space got totally mixed up.

-> Can someone compile and upload current vpxenc so I can check with that and contact jb-alvarado or the vpxenc devs depending on where the problem is.

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | vpxenc --codec=vp9 --passes=1 --pass=1 --target-bitrate=1500 --end-usage=vbr --profile=0 --good --cpu-used=3 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o "H:\Temp\test_16_23_09_2810_01.vp9" -
works fine with the old 1.2 release, but produces 'broken' output with this release. :(

Cu Selur

[Nintendo Maniac 64]

Firefox apparently now supports VP9 playback in its development branches:
http://www.phoronix.com/scan.php?page=news_item&px=MTUzODA

[Selur]

attached my broken vpxenc versions I build with media-autobuild_suite to a post over at videohelp (http://forum.videohelp.com/threads/360831-Looking-for-up-to-date-working-and-static-vpxenc-version?p=2287227#post2287227)


Cu Selur

[Selur]

LoadCPlugin("G:\avsiynth\avisynthPlugins\ffms2.dll")
# loading source
FFVideoSource("H:\TESTCL~1\test.avi",cachefile="H:\Output\21437943319_16_52_0110.ffindex",fpsnum=25000,fpsden=1000)avs2yuv "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Output\test_19_16_52_0110_03.stats" --profile=0 --good --cpu-used=3 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --min-q=0 --max-q=63 --lag-in-frames=25 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -

avs2yuv "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --good --cpu-used=2 --psnr --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --pass=2 --fpf=file.fpf --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --aq-mode=2 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --psnr --target-bitrate=275 --width=640 --height=352 - -o "h:\Output\try1.webm"WORKS!!
avs2yuv -raw "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Output\test_19_16_52_0110_03.stats" --profile=0 --good --cpu-used=3 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --min-q=0 --max-q=63 --lag-in-frames=25 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -

avs2yuv -raw "H:\Output\encodingTempAvisynthSkript_19_16_52_0110.avs" - | vpxenc --codec=vp9 --good --cpu-used=2 --psnr --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --cq-level=20 --end-usage=0 --auto-alt-ref=1 --passes=2 --pass=2 --fpf=file.fpf --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --aq-mode=2 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --sharpness=0 --undershoot-pct=100 --psnr --target-bitrate=275 --width=640 --height=352 - -o "h:\Output\try1.webm"doesn't.

-> seems like vpxenc now only supports y4m input, despite the fact that the help only states:

--yv12 Input file is YV12
--i420 Input file is I420 (default)-> WTF?!?
(didn't consider testing y4m since the help doesn't mention it)

btw. ffmpeg as decoder works fine too as long as yuv4mpegpipe is used. (using raw i420 or yv12 produces the above problems.)
-> filed a bug report: http://code.google.com/p/webm/issues/detail?id=678

[Selur]

using:
vp8 - WebM Project VP8 Encoder v1.3.0-290-ge18eb77
vp9 - WebM Project VP9 Encoder v1.3.0-290-ge18eb77
and
ffmpeg -v -10 -i "H:\TestClips&Co\test.avi" -an -sn -threads 8 -vsync 0 -r 25 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --lossless=1 --end-usage=q --min-q=0 --max-q=0 --width=640 --height=352 -o "H:\Output\test.webm" -
lossless encoding still doesn't work. :( (only creates a 1kByte file)

Cu Selur

[Leeloo Minaï]

I got valid 2-pass encoding but also lossless with this command line and your "broken" 32-bit vpxenc from your videohelp post :

ffmpeg -i input.avi -an -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=1 --pass=1 --fpf="test.stats" --lossless=1 --min-q=0 --max-q=0 --end-usage=q --width=224 --height=384 - -o test.webm


Note : your 64-bit "broken" build is really... broken, it does 1st pass but encounters an error at start of 2nd pass.

[Selur]

Compiled a new version (v1.3.0-290-ge18eb77) (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing) which works fine with 2pass here.
Seems like the missing '--passes=1 --pass=1' was the problem. :D
(I even got dvd->vpxenc working by doing a double-pipe: mencoder ... | ffmpeg ... | vpxenc ... )

[o-l-a-v]

When will they make WebP with VP9, does anyone know? So far I haven't found much on that topic

[Hyral]

Here's something interesting, apparently new uploads to YouTube have at least their 480p and 1080p resolutions have the video stream seperate from the audio stream.

This might be related to Youtube now using MPEG-DASH, which separates resources down to the streams.

[Nintendo Maniac 64]

This might be related to Youtube now using MPEG-DASH, which separates resources down to the streams.

It is. That post was made before I knew about DASH. :P

[xooyoozoo]

Two semi-recent papers on VP9 efficiency.

VP9 intra performance vs HM/JM/VP8 (http://m-hikari.com/ams/ams-2013/ams-137-140-2013/sharabaykoAMS137-140-2013.pdf). TLDR: VP9 needs 20% less bitrate than VP8. HEVC needs 30% less than JM, 15% less than VP9. Authors suggest 2/3 of HEVC's gains over VP9 due to having more prediction angles + SAO, the rest due to slightly better entropy coding.

VP9 vs HM vs x264 in playback/random-access config (http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf). TLDR: The paper found that VP9 needs 80% more bitrate than HEVC, 8% more than x264. Unfortunately, VP9 was ran with min-q=max-q=$QP. If that's what that sounds like, their results for VP9 are almost certainly invalid.

For both papers, I wouldn't expect VP9's results to change more than 1-2% with a recent build. I recall almost all quality commits being for the higher speed presets.

VP9 also now has adaptive quant. Aq-mode 1 seems to improve MS-SSIM bdrate by several percent on a couple 1080p clips I've tried. I'm not particularly sure what aq-mode 2 does, and on testing with crowdrun seq, both subjective viewing and MS-SSIM bdrate showed worse performance compared to aq1.

It'd be nice to do a subjective comparison against x265+AQ, but VP9's wildly off its 2pass target bitrates when AQ is on. That along with how encoding is single-threaded and how cpu-used=0 is roughly as fast as the HM mean I'm not too keen on trial-and-error encodes. ;)

[mzso]

Looks like now VP9 works in the main ffmpeg builds (except with x64 where it just crashes). Anyone knows a good guide for VP9 options?
Rather liked x264's profile preset features.

[dapperdan]

Quote from the mailing list (in the context of encoding):

"Right now VP9 is a lot slower than VP8. We are working hard to correct that. Watch for big speed increases in the couple of months."

Obviously easier said than done, but thought I'd note it anyway.

[Selur]

hopefully, after that they fix 2pass encoding in a way that it actually hits (near) a specified bitrate.

[BadFrame]

Anyone knows a good guide for VP9 options?
Rather liked x264's profile preset features.

I don't have a guide but the best settings (quality wise) I've gotten from my own tests are as follows:

VBR:

vpxenc --good --end-usage=vbr --target-bitrate=X --cq-level=0 --aq-mode=1 --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=15 --arnr-strength=6 --arnr-type=3 --sharpness=0 --codec=vp9

I noted in VBR that it's best to set the cq-level to 0, else the encoder will be eager to try to save a lot bits in flat areas leading to macro-blocks, of course you may want this and if so increase the cq-level value accordingly.

CQ:

vpxenc --good --end-usage=3 --cq-level=X --aq-mode=1 --cpu-used=0 --threads=0 --profile=0 --lag-in-frames=25 --min-q=0 --max-q=63 --auto-alt-ref=1 --passes=2 --kf-max-dist=9999 --kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --arnr-maxframes=15 --arnr-strength=6 --arnr-type=3 --sharpness=0 --codec=vp9

The only change in the CQ encode is the -end-usage parameter, you could also experiment with aq-mode=2 which I haven't yet examined. Also I'm using --good here, for the best quality you should use --best but it is REALLY slow so unless you have a lot of time or are doing a comparison between encoders I would use --good

It's been a bunch of weeks since I last did some tests so I hope these settings are still valid.

[xooyoozoo]

Some months ago, VP9 defaults in libvpx were changed to match the high-quality suggestions. In the same commit, the developers also recommended against using --best over --good.

IIRC, the only thing you'd need to worry about now is cpu-used, end-usage, aq-mode, kf-max-dist.

[x265_Project]

MulticoreWare, the company behind the x265 project, is working with Google and semiconductor companies to accelerate VP9.

http://www.prweb.com/releases/2014/02/prweb11612574.htm

[dapperdan]

There was also a similar project from ittiam for the ARM MALI GPU.

http://malideveloper.arm.com/demo-showroom/computer-vision/ittiam-vp9-decoder-using-opencl/

Both seem to have involved collaboration with Google and the use of OpenCL, but I don't know if that means we should expect other chips to have similar solutions.

Also, ffmpeg's VP9 decoder had a blog post from one of the authors, which has some stuff about decoder speed, decoder threading and encoder quality:

http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

[Procrastinating]

Given that the GPU was only able to leverage motion prediction in X264(and in cases worse motion prediction at that), what areas of VP9/265 are able to better take advantage of GPGPU?

[Selur]

looks like they are only improving the decoder, not the encoder

[mzso]

Hmm. Fffmpeg for vp9 is garbage. Only encodes -b (cbr) everything else results in 200k bitrate.
I still can't a place for recent vpxenc builds with vp9. (Does anyone have a recent build?) Looks like people are pretty indifferent to this format.

[Selur]

uploaded vpx_v1.3.0-1742 to my google drive (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing)

[Monarc]

Hmm. Fffmpeg for vp9 is garbage. Only encodes -b (cbr) everything else results in 200k bitrate.

Try:

... -vcodec libvpx-vp9 -crf 10 -b:v 5M ...

-b = max Bitrate, if -crf is used.

[mzso]

Thanks guys.


Ouch. Can't default to using the same resolution as the input... :)

[mzso]

Is this wrong?

E:\Videó Felvételek>vpxenc --codec=vp9 --good --aq-mode=2 --kf-max-dist=30 --cq-level=20 -w 1920 -h 1200 -o vpx.mkv "input.mkv"
Pass 1/2 frame 82/83 12616B 1230b/f 36924b/s 21279 ms (3.85 fps)←[K
Pass 2/2 frame 34/9 794197B 1023652 ms 1.99 fpm [ETA 2:11: 47] ←[K 40FF

I just noticed that the ETA might not be 2 minutes 11 second, but two hours eleven minutes. Feels a bit exorbitant for a less than 10 second sample even on my dated computer.

[Selur]

vp9 is slow (lack of multi-threading), not knowing what cpu you have that might be right :)

[mzso]

vp9 is slow (lack of multi-threading), not knowing what cpu you have that might be right :)

Well, I encode that very same file with x264 in like two minutes. (I have an e6750 BTW) But cinse the couple frames that were encoded turned out to be total garbage. I'm assuming the input is not supported even though the encoder didn't complain.

[mzso]

Okay so I have to decode and pipe first. :)
Now I get an empty file. :)
ffmpeg -i "E:\Videó Felvételek\motor2.avi" -an -vcodec rawvideo -pix_fmt yuv420p -f rawvideo - | vpxenc --codec=vp9 --good --aq-mode=2 --kf-max-dist=30 --cq-level=20 --i420 -o -w 1920 -h 1200 vpx-teszt.mkv -

I get "av_interleaved_write_frame(): Invalid argument".

[Selur]

a. I normally feed vpxenc through a pipe, where I do the decoding&filtering.
b. yes, your system is probably too slow to fast encode vp9 faster atm. (hoping that there will be some optimizations in the future)

just for perspective on a i7-4770k using:
ffmpeg -y -v -10 -r 25000/1000 -analyzeduration 100M -probesize 100M -i "F:\TestClips&Co\MPEG-4 H.264\1080p25.ts" -an -sn -threads 8 -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=1 --pass=1 --end-usage=cq --cq-level=18 --target-bitrate=15000 --profile=0 --good --cpu-used=3 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=1920 --height=1080 -o "H:\Temp\test_23_38_28_8910_01.vp9" -
it takes 20:45.096min (1245 seconds) to encode 3178 frames -> ~2.55 fps (had no 1920x1200 source available so I went with 1080p)
side note: Encoding the same source with x265 and preset slow I get ~2.6fps, x264 with preset placebo runs at~3.57fps.

Could this get faster? Sure if more than one cpu core was in use during the encoding,... so still hoping for multi-threading support.
Main drawbacks, from my perspective with VP9 atm. are:
1. it's too slow to be useful (x265 encodes faster)
2. 2pass encoding only hits a target bitrate once a year

[mandarinka]

IIRC the author of the AQ patch thinks that the useless 2-pass rate-control is due to the use of adaptive quantization.

[Selur]

Main reason for using 2pass is to hit a specific average bit rate (end-size) and archive the 'best' possible quality under that restriction.
So if I have to disable adaptive quantization for 2pass encoding to work, I would say that sounds like either the adaptive quantization or the 2pass implementation is rubbish.

[Kurtnoise]

For your information, a new branch has been created few days ago in the source tree. It concerns High Bits Depth Feature...

So, I made some fresh windows compile in order to play with :

-> vpx tools for x86 plateform (https://www.mediafire.com/?qbrqt41412af72y)
-> vpx tools for x64 plateform (http://www.mediafire.com/download/t4itk2dgscuvwr1/vpx_hbdepth-x64_1.3.0-6956f43a9.zip)

[Selur]

hmm,... high bit depth sounds nice (probably it will slow things down even more)

[zerowalker]

Hope does VP9 Decoding fare for you compared to x265?

Cause x265 takes some serious CPU from me, haven't checked, but i think it's heavier than VP9, and i am guessing that x265 is better optimized (at least Encoding is, so probably Decoding as well).
And if so, that leaves hope for reduced workload in the future.

[Nintendo Maniac 64]

Honestly they were really similar; h.265 only averaged about 10% more CPU utilization than VP9 on my Brisbane (Core 2 Duo testing will have to wait).

However, there are some distinct differences. VP9 was more dynamic in its CPU usage with a range of like 40%; h.265 by comparison only had a range of maybe 25% CPU usage.

Most importantly though, VP9 spead the load between my two cores much more equally; h.265 on the other had had one core getting very close to being maxed out while the ovher core ran at below half usage.

[zerowalker]

Anyone technical, is there a reason why VP9 isn't multi-threaded yet?

I find it very hard to understand that a Codec made in the "Threads/Cores Era" not utilizing it at all.

[Selur]

Only reasons that pop into my mind (with Google behind it) are:
a. Google doesn't want to add multi-threading (since Google seems to be the only one really using VP9 it seems kind of in there interest to support multi-threading) or simply they don't want to share it and only added it in some non-public repository
b. There really is some enormous design flaw which prevents the encoder from using multi-threading, but reading https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/IFFSy2xlKV0 it sounded like nobody got around to implement it. (and that conversation is from nearly one year ago)
c. Google can't find anyone who knows enough about VP9 who could spend the time to implement multi-threading (unlikely, but you never know)
d. Google gave up on VP9 and there is no man-power planned in to support it development wise any further

[mzso]

"d." is extremely unlikely. VP9 youtube videos just started to appear.

[zerowalker]

I supposed the closest is that Google don't care about Threading, as Youtube Videos are done in a way that whre threads doesn't matter.
It's faster to do 4 videos on a 4 core CPU, than 1 using 4 cores.

Which would mean Google themselves improves anything with Quality first (Bandwidth), then performance (not threading part).

Which would leave Threading to be done by others, as it's open source it can surely be the case.

I guess that's the theory of things at least.

I certainly hope it will be added, but i would say that improving the overall performance goes first,
If you get 3fps, 4 threads won't quadruple it as things are Never linear, you would probably get 6-9fps at best.
So better improve the 3fps first (Just a figure, as it's so extremely slow right now).

"d." is extremely unlikely. VP9 youtube videos just started to appear.

Right indeed, and google works on it everyday, or well it get's worked on by people at least, and i doubt many of them aren't connected to Google, as VP9 isn't really x265 famous.

[Kurtnoise]

a. Google doesn't want to add multi-threading (since Google seems to be the only one really using VP9 it seems kind of in there interest to support multi-threading) or simply they don't want to share it and only added it in some non-public repository
Since when ? I'd say that Google doesn't care coz they have plenty of datacenters all over the world...and can schedule stuff in parallel.

b. There really is some enormous design flaw which prevents the encoder from using multi-threading, but reading https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/IFFSy2xlKV0 it sounded like nobody got around to implement it. (and that conversation is from nearly one year ago)
Well...multi-threading is available for VP8. So, we just need some time to get this also for VP9.

c. Google can't find anyone who knows enough about VP9 who could spend the time to implement multi-threading (unlikely, but you never know)
d. Google gave up on VP9 and there is no man-power planned in to support it development wise any further
I doubt that...there are plenty of commits every days (except the weekend) in their source tree.

[BadFrame]

Only reasons that pop into my mind (with Google behind it) are:
a. Google doesn't want to add multi-threading (since Google seems to be the only one really using VP9 it seems kind of in there interest to support multi-threading) or simply they don't want to share it and only added it in some non-public repository
b. There really is some enormous design flaw which prevents the encoder from using multi-threading, but reading https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/IFFSy2xlKV0 it sounded like nobody got around to implement it. (and that conversation is from nearly one year ago)
c. Google can't find anyone who knows enough about VP9 who could spend the time to implement multi-threading (unlikely, but you never know)
d. Google gave up on VP9 and there is no man-power planned in to support it development wise any further

I can't recall if it was from the webm mailing list or IRC, but they've stated (VP9 devs) that the reason they haven't incorporated parallel encoding yet is because VP9 is still in very active development / tuning, and adding parallel encoding at this point would only complicate development and make it slower to make changes. They will add parallel encoding to VP9.

If you want to follow the (quite active) development of VP9 you can do so here:

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

[Monarc]

Only reasons that pop into my mind (with Google behind it) are:
a. Google doesn't want to add multi-threading (since Google seems to be the only one really using VP9 it seems kind of in there interest to support multi-threading) or simply they don't want to share it and only added it in some non-public repository
b. There really is some enormous design flaw which prevents the encoder from using multi-threading, but reading https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/IFFSy2xlKV0 it sounded like nobody got around to implement it. (and that conversation is from nearly one year ago)
c. Google can't find anyone who knows enough about VP9 who could spend the time to implement multi-threading (unlikely, but you never know)
d. Google gave up on VP9 and there is no man-power planned in to support it development wise any further

e. hardware encoder?

[benwaggoner]

I can't recall if it was from the webm mailing list or IRC, but they've stated (VP9 devs) that the reason they haven't incorporated parallel encoding yet is because VP9 is still in very active development / tuning, and adding parallel encoding at this point would only complicate development and make it slower to make changes. They will add parallel encoding to VP9.
I suspect it's a lot harder to parallelize VP9 since the lack of B-frames makes frame-level parallelism somewhat harder, and the way that entropy coding and prediction are tied together makes intraframe parallelism harder. I'm sure there are ways to crack those nuts. After all, x254 can do frame level parallelism to some degree with Baseline profile which lacks B-frames.

I'd think getting parallel encoding going to some degree would be very helpful, though, because:

It proves it is possible, to address the "I'm not going to look at VP9 until I see a fast enough encoder" position. When you're use to 12-16 physical cores for encoding, a single-threaded encoder is maddeningly slow, and sometimes you want to get one file done fast, not a bunch of files done in parallel slowly.
It's allow the developers to iterate more quickly on testing particular changes. Having to wait 1 hour instead of 8 hours to see the results of a change is pretty massive.


If you want to follow the (quite active) development of VP9 you can do so here:

http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=summary
Yeah, that is a very impressive cadence. More than x264+x265 put together. Although it's hard to tell how material each change is; the notes in the full log aren't very informative. A lot of it sounds like code cleanup to make future work easier, and removing a lot of unused cruft. I always like it when a checkin indicates that it will have a speed or output quality impact, and at least a quick description of what that would be.

[BadFrame]

I suspect it's a lot harder to parallelize VP9 since the lack of B-frames makes frame-level parallelism somewhat harder, and the way that entropy coding and prediction are tied together makes intraframe parallelism harder. I'm sure there are ways to crack those nuts. After all, x254 can do frame level parallelism to some degree with Baseline profile which lacks B-frames.

I recall reading something about how golden frames and alt-ref frames would mitigate the lack of b-frames to a large extent, but that is a bit above my head.


I'd think getting parallel encoding going to some degree would be very helpful, though, because: ...

I fully agree with your reasons, and I personally find VP9 pretty much unusable for anything but small encoding tests until it offers multi-core encoding per clip.

I always like it when a checkin indicates that it will have a speed or output quality impact, and at least a quick description of what that would be.

Well I think that depends on if you look at the 'merge' or the original commit, for example, take the recent merge of 'Add static-threshold skipping in non-rd mode', it's not very descriptive, however if you look at the parent commit, it says the following:


Add static-threshold skipping in non-rd mode

Added a skipping test in non-rd inter-mode. After interpolation
prediction step, the residuals are tested to see if they will be
quantized to 0 based on modeling between spatial domain and
frequency domain.

Set static-thresh to 800 for >=720p and 300 for <720p, rtc set
tests showed
1. Speed 5, psnr: -0.514%; ssim: -1.748%;
speedup on related clips: 5% -11%
2. Speed 6, psbr: -0.628%; ssim: -1.637%;
speedup on related clips: 4% - 9%


Which is a lot more descriptive

[Nintendo Maniac 64]

Here's something interesting I just discovered today - on a CPU with SSSE3 support, VP9 requires less than half the CPU utilaztion that h.265 needs.

Since my HTPC hooked up to my HDTV (1080p) runs on a Core 2 Duo, this means that I can do 1080p VP9 with room to spare while I won't be able to do 1080p h.265 at all. Heck I could probably even do 1440p VP9 on my HTPC.

[zerowalker]

You are comparing them at similar bitrates and settings (as i am sure that has quite the impact on the decoding)?

If you are, or at least fairly close as they are quite different, then that is very impressive, very good indeed when you think of the aim of this codec where decoding needs to be highly optimize to be able to dominate..

[Nintendo Maniac 64]

Actually, I'm comparing the CPU utilization between my Brisbane and my Core 2 Duo. VP9 uses like half the CPU on my Core 2 Duo vs my Brisbane, but h.265 uses only a bit less (~10%) on my Core 2 Duo than my Brisbane.

Considering that VP9 already used about 10% CPU utilization on my Brisbane vs h.265, this results h.265 only breaking even with non-SSS3-optimized VP9.

Here's the tl;dr version:

Brisbane
VP9 ~60%
h.265 ~70%

Core 2 Duo
VP9 ~25%
h.265 ~60

While the VP9 and h.265 footage was not the same, I was sure to use the exact same VP9 clip and the same h.265 clip with both CPUs.

[xooyoozoo]

If your decoding stacked is built on libav/ffmpeg, and you need faster HEVC decode, you can always use the OpenHEVC fork (https://github.com/OpenHEVC/FFmpeg). Optimizations there eventually percolate outwards, but for whatever reasons, progress is intermittent and OpenHEVC is (still) 2x faster than ffmpeg-master.

On Sandy Bridge, both single and auto threaded software decode seem to be roughly 2/3 the speed of high profile AVC. I didn't compare directly against VP9, but the numbers here look competitive.

[Guest]

Audio is off topic in a video thread. Make a new thread about it and stop discussing it here.

[benwaggoner]

I recall reading something about how golden frames and alt-ref frames would mitigate the lack of b-frames to a large extent, but that is a bit above my head.
Yes, I think they could. But it'd require new encoder and decoder features to take advantage of this. One of VP9's big challenges is that it's having to compete as an ecosystem, not a bitstream, and there's a whole lot more companies competing and investing in H.264 and HEVC encoders and decoders than are for VP9. So one thing Google needs to demonstrate is that VP9 will actually have a competitive encoder implementation in the market. Possible in theory doesn't do anything for viewer experience.

I think the last marginally competitive VPx encoder was probably VP3, and even then only as a progressive download codec (lousy rate control) in the pre-standards market of 14 years ago. VP6 only mattered because On2 got really lucky with Flash, but even with the gift of that huge market they still struggled to make an encoder with good performance and rate control. VP6's main innovations were in post-processing, where they did a lot of postprocessing block removal and noise synthesis to mask loss of detail. Interesting stuff, but orthogonal to encoding.

Well I think that depends on if you look at the 'merge' or the original commit, for example, take the recent merge of 'Add static-threshold skipping in non-rd mode', it's not very descriptive, however if you look at the parent commit, it says the following:

Which is a lot more descriptive
Ah, thanks. That's a good feature to have. Although it is somewhat worrisome that basic stuff like that is still getting implemented (although "non-rd mode" doesn't sound like something that would get used that much). On the other hand it suggests that there could still be a lot of future improvement in VP9 visual quality.

From my perspective, I'm waiting to see the first platform for which VP9 provides the overall best customer experience inclusive of battery life, performance, playback smoothness, speed of random access, and of course quality at a given bitrate.

[BadFrame]

One of VP9's big challenges is that it's having to compete as an ecosystem, not a bitstream, and there's a whole lot more companies competing and investing in H.264 and HEVC encoders and decoders than are for VP9. So one thing Google needs to demonstrate is that VP9 will actually have a competitive encoder implementation in the market. Possible in theory doesn't do anything for viewer experience.

Well I don't think market share really matters to Google when it comes to VP9, it's not as if they are making money from it as they have released it under a perpetually royalty free licence.

As I see it (as in me speculating) Google wants their own codec which they can develop according to their needs (realtime is probably big here) as well as saving money long term on royalties, it's not as if their use of video on the web will decrease, then we have devices like Google Glass, and whatever else they've got cooking which will likely make use of video in some form.

This likely means that it's not important to them how well or not VP9 is received in the 'video market', meanwhile chipmakers targeting Android will most likely implement it in hardware as it doesn't cost them any royalties (hardware implementation is also royalty free) to do so while making their chips more 'attractive', particularly given Android's market dominance.

[foxyshadis]

OK, guys, I've split off the YouTube discussion that ate the thread (https://forum.doom9.org/showthread.php?t=170682).

[Kurtnoise]

For your information, a new branch has been created few days ago in the source tree. It concerns High Bits Depth Feature...

So, I made some fresh windows compile in order to play with :

-> vpx tools for x86 plateform (https://www.mediafire.com/?qbrqt41412af72y)
-> vpx tools for x64 plateform (http://www.mediafire.com/download/t4itk2dgscuvwr1/vpx_hbdepth-x64_1.3.0-6956f43a9.zip)
New builds uploaded concerning this branch :

http://kurtnoise.free.fr/vpx/vpx-x86_1.3.0-51790ab22.zip
http://kurtnoise.free.fr/vpx/vpx-x64_1.3.0-51790ab22.zip

>> The log (https://chromium.googlesource.com/webm/libvpx/+log/highbitdepth)

[hajj_3]

1080p vp9 youtube videos use about 20% cpu on my intel core i5 430m laptop processor, not too bad i guess. I wondered why my laptop was getting warm playing youtube videos. They seem to be using it for quite a lot of videos now.

[Nintendo Maniac 64]

Here are two short videos from Google I/O that are relevant to this thread:

Update on WebM/VP9: https://www.youtube.com/watch?v=xo_R40C7RTo

Demystifying encodes and decodes of WebM: https://www.youtube.com/watch?v=o-TAyIQBOuA

The first video is mainly about the functions and features of the codec itself along with upcoming developments; the second video is more about actually using it.

[zerowalker]

They say they have increased the speed about 40x if i remember right.
But it's still super slow, and no multi core support (Encoding wise).

And i am not into the way they say that it looks 50% better, it just doesn't, sad but true (At least when i tried it some time ago).

Other than those things, i am very happy that things are going forward, High Bit Depth, Hardware Decoding. This can really bring VP9 into the market place.

(Can't imagine the Realtime Encoding though, must be low resolution;P)

[Nintendo Maniac 64]

And i am not into the way they say that it looks 50% better, it just doesn't, sad but true.

Part of the issue is that general statements like "50% better" are really, well, general.

Different codecs respond differently at different bitrates, for example h.264 really starts to break down at the lower bitrates that YouTube focuses on. I mean, once you get into the high bitrates then even MPEG-2 will look quite good (as evident by OTA HDTV broadcasts).

[dapperdan]

http://youtu.be/GBAEG_RuqeE?t=33m28s

Another VP9 update given in the context of WebRTC. Looks like realtime encoding for video chat and screen casting is currently a focus for improvement.

Interesting stat that 60% of YouTube plays in Chrome are now VP9.

[kidjan]

Part of the issue is that general statements like "50% better" are really, well, general.

Different codecs respond differently at different bitrates, for example h.264 really starts to break down at the lower bitrates that YouTube focuses on. I mean, once you get into the high bitrates then even MPEG-2 will look quite good (as evident by OTA HDTV broadcasts).

Also, a lot of the comparisons I've seen are comparing VP9 to H.264/HEVC with main/high profile, which likely means B-frames. B-frames are a cool feature for playback and content encoding, but for low latency situations (e.g. live streaming) they're not an option. The more honest comparison would be VP9 to baseline H.264, with the caveat that H.264 could have better quality at the expense of live and/or low-latency situations. For example, this study (http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf) is comparing VP9 to H.264 high profile with B-frames, which is totally legit for content encoding and completely bogus for live encoding. It also doesn't look at any performance below the ~1 mbps range, which is a particularly interesting range for live video streaming given most user's limited upload bandwidth.

For live streaming, my personal opinion is low-quality performance is a lot more important than high-quality performance to accommodate for adverse network conditions.

[sneaker_ger]

"Live streaming" is not really a low-latency application per se. It only needs low-latency if you require the other side to react fast, e.g. a video phone call where both sides interact or when you are remote controlling a robot.

[dapperdan]

For example, this study (http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf) is comparing VP9 to H.264 high profile with B-frames, which is totally legit for content encoding and completely bogus for live encoding.

Isn't that the study that was consider ridiculously flawed? I remember it specifically because it claims that the VP9 encoder was released on the day they finalised the bitstream, which is a bit silly since it was equally available the day before, i.e. a public work in progress in git.

But someone else, with more knowledge, wrote it off due to one of the encoder settings for VP9 being silly if I remember correctly.

[kidjan]

Sorry, I should have been more clear: by live streaming I mean video conferencing, video calling, etc. I'm aware that "live streaming" isn't necessary low-latency.

[kidjan]

Isn't that the study that was consider ridiculously flawed? I remember it specifically because it claims that the VP9 encoder was released on the day they finalised the bitstream, which is a bit silly since it was equally available the day before, i.e. a public work in progress in git.

But someone else, with more knowledge, wrote it off due to one of the encoder settings for VP9 being silly if I remember correctly.

That's entirely possible; it's just the first thing I found when I went to look for comparisons this morning. Even if VP9 were mature at the time, it's silly in a few other regards: VP9 has no B-frames, no low-bitrate performance measurement, etc.

[sneaker_ger]

IIRC VP9 does have B frames, they just call it differently and employ a trick in an attempt to not break any patents.

[benwaggoner]

IIRC VP9 does have B frames, they just call it differently and employ a trick in an attempt to not break any patents.
Correct, although I don't know how heavily used that feature is in the current implementation.

As for "fair"comparisons, low latency live encoding is a different scenario than on-demand content. Those really should be separate tests.

[kidjan]

As for "fair"comparisons, low latency live encoding is a different scenario than on-demand content. Those really should be separate tests.

No arguments from me, it should be a separate test. And that's my point: comparing H.264 with B-frames to VP8 is a bit of a red-herring. I find that nearly all video encoding comparisons I see ignore this point, and as a "real time" guy (most of my work has a significant emphasis on latency), it's a little frustrating.

I also think in the video encoding world, people tend to see a codec that lacks a feature like bidirectional prediction as "inferior" to a codec that has such a feature, and I think that's a bit disingenuous when you take into consideration the real-world implications of that feature.

[x265_Project]

I think you'll be interested in this...
http://www.slideshare.net/touradj_ebrahimi/spie2014-hev-cvsvp9

[fumoffu]

I think you'll be interested in this...
http://www.slideshare.net/touradj_ebrahimi/spie2014-hev-cvsvp9

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...

[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.

[mandarinka]

Maybe one could look at it this way: they want to lower the effective bandwidth, quality be damned. But if they do it with the existing formats, people could whine. However, if you use a new codec, you can spin it that the picture quality is still the same because "VP9 is better". Which might or might not be true (libvpx being bad, but yt's H.264 too), but you were able to achieve the real objective - bitrates were reduced. HEVC could really work too, of course.

[mzso]

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.

What? How did you come up wit this nonsense?

And they're more like VOD than streaming, even Youtube. (Except for live streams)

[zerowalker]

Fun thing is that the don't really reduce bandwidth cost anyway, as they pretty much use same bitrate. Sometimes lower and higher. Doesn't make any sense.

[Nintendo Maniac 64]

However, if you use a new codec, you can spin it that the picture quality is still the same because "VP9 is better". Which might or might not be true (libvpx being bad, but yt's H.264 too), but you were able to achieve the real objective - bitrates were reduced. HEVC could really work too, of course.

Actually it's more complicated than that. VP9 is about equal quality to non-DASH h.264 720p (fmt22) but VP9 is higher quality than all the other h.264 formats; the thing about fmt22 is that it has a considerably higher bitrate as you can see from my screenshot below.

Fun thing is that the don't really reduce bandwidth cost anyway, as they pretty much use same bitrate. Sometimes lower and higher. Doesn't make any sense.

Uhh, the VP9 versions are consistantly of smaller size than the h.264 videos, the only exceptions being a couple small resolutions.

Video in question:
https://www.youtube.com/watch?v=FIc4Uj9RL2Y

Browser extension in question:
http://cys-audiovideodownloader.com/

http://i.minus.com/izF95htkdU5Iv.png

[zerowalker]

Damn they have fixed it now then..
When VP9 came, it was extremely random in my tests, some VP9 was much lower, but some were also higher than the h264 counter part, which i of course enjoyed.
Well, there broke that good part of it all;(

[Nintendo Maniac 64]

Well, there broke that good part of it all;(

As someone with only 3Mbps down, I'm glad they fixed it.

[zerowalker]

Well you were one of those that noticed it i think, when you and i did some tests back then;P

And damn you, it's cause of your internet i can't be satisfied! I demand more and more bitrates:(
Well, i hope VP9 looks better than H264 still, as in my old tests when the bitrate was about half in some cases, H264 looked better overall, which wasn't a good turn.

[Nintendo Maniac 64]

Well, i hope VP9 looks better than H264 still, as in my old tests when the bitrate was about half in some cases, H264 looked better overall, which wasn't a good turn.

In high-motion videos, such as that one I linked to 2 posts back, VP9 totally looks better.

Here's the link again if you need it:
https://www.youtube.com/watch?v=FIc4Uj9RL2Y

(note: I cannot test the VP9 formats above 720p30fps because my current CPU is way too weak - an AMD E-350; its replacement, a Pentium G3258, isn't ready for use yet - the E-350 was only a stop-gap solution from when the motherboard died to my Brisbane 4800+)

[zerowalker]

Well motion is the hardest, and dark parts. I take your word for it, did a little check on the VP9 60FPS and i can't complain. Though there is not much detail to be lost anyway.
But still VP9 was "bad" when it was released, my guess is they have made major updates sense release, even if Youtube itself probably get those releases a bit slower than the actual codec.

Still skeptical to how VP10 will go, if they keep releasing codecs without improving the encoder, it will just come to a standstill. HEVC is crap compared to x264, and if HEVC V2 would come next year, it would look even worse most likely:S
(Crap is an overstatement of course).

[Nintendo Maniac 64]

Regarding VP10, my only concern would be the unnecessary competition between it and Daala...

Though there is not much detail to be lost anyway.

That's likely due to the fact that the game is only being rendered at 480p with 4xAF and I think no AA.

EDIT: Maybe a better video? Same game, different track, but rendered at a much higher resolution:
https://www.youtube.com/watch?v=5I-nQtsJuhE

[zerowalker]

Can't speak for Daala, but i am hopeful about that codec, as Opus and Vorbis did just nicely. Not sure about Theora though, kinda missed that part, but remember Ogg (not sure what the codec was called, maybe it was Theora), and it did nicely compete with DivX.

Most likely. This video looked much clearer, Not sure how the original video looked. But i can see the usual VP9 Artifacts that i dislike (the weird square boxes, kinda similar to no-deblocking on x264 or older codecs).
But still, it's very acceptable when i know it's Youtube.

If VP10 etc goes as Google plans (and i hope it does) and everything will be less in size and same (hopefully a bit better) in quality. Then i can't really complain, even if i wish to have 10mbps+:P

[tuqueque]

VPx and Daala are fundamentally different technologies... The only similarities are their goals (free, open and unencumbered video codecs), but the internals are completely different. VPx will always (?) be DCT based; Daala is exploring Lapped Transform encoding, among other new, experimental techniques.

At the end, they are not competing, they are exploring different approaches; VPx with the more "traditional" one, and Daala goes on testing some new stuff to see if it's really viable as a video codec.

[zerowalker]

Well competition with new techniques is always good. It might be bothersome as it brings back the "Divx,Xvid,Vorbis,MP3," Wars that was going on before, now it's all x264/AAC pretty much as those are pretty much the best (As no one uses Opus yet).
But eventually it will lead somewhere when the best of the best is at the end of the horizon;)!

[Nintendo Maniac 64]

And because I can, here's another high-motion video; make sure there's no kiddies around for the giant on-screen f-bomb text that's at the end:
https://www.youtube.com/watch?v=CEo1D2Y57_U

OK then, I'm done. :p

Interesting note: Even though it's not available for playback via YouTube's own video player, the 1440p30 version of this video is actually available using a YouTube downloader, including VP9 1440p30.

EDIT: It turns out that VP9 actually is smaller at 144p as well, it's just the vorbis audio has a higher bitrate than the aac audio. Also you can actually kind of see what's going on with VP9 @ 144p; meanwhile h.264 @ 144p is pretty bad (though Baseline@1.2L probably isn't helping).

[foxyshadis]

I've yet to see a VP9 that was worse than the AVC version; even if it's a hash, at least it's smaller. Back when they had zero rate control and VP9 vids could be huge, I was pretty ecstatic by all the extra quality, though. Guess I'm spoiled like zerowalker. VP9 is a great format, it just feels mismanaged.

I typically download both formats for vids I want to archive, then combine and re-encode them. Sure I'd love to have all those bits in one perfect copy, but two vids damaged in different ways gives you some interesting ways of reconstructing a better one.

As for HEVC, at Youtube-ish bitrates it easily exceeds AVC and VP9 at this point. It's mainly for videophile encodes that x264 still beats HEVC, though x265 is slowly narrowing that gap.

[zerowalker]

Really?
Seen some that's worse, at least in the beginning. Though i think in some cases the VP9 won, like certain parts. And if i remember right it was like, AVC = 2mpbs, VP9 = 3mbps. Or something, which explained it.

And yeah welcome to the club, let's wish for a future with high bandwidth all over so bitrates don't have to suffer;P!

Interesting about HEVC, thought it still was "crap", you sure it beats x264 for like 3mbps 1080p? (Or whatever the bitrates is for 1080p)

[Tommy Carrot]

Interesting about HEVC, thought it still was "crap", you sure it beats x264 for like 3mbps 1080p? (Or whatever the bitrates is for 1080p)

I wouldn't generalize about HEVC, because as a format i believe it has the potential to be superior at all ranges, but currently x265 only has advantage at low bitrates. I mean above the crf 24-25 range of x264. Below that, they are usually similar, or even x264 has the quality advantage (not to mention the computation complexity advantage).

The bitrate depends on the compressibility, so for more complex videos 3 mbps at 1080p often would go above crf 25, so in those cases, x265 would beat x264, In other cases, not so much.

[zerowalker]

Yeah that's my view at it, the Codec itself has advantage, but the encoder doesn't (yet).
And crf 24-25 isn't something i even consider for next to anything myself. For me i need it to look at least like 16-18.
So i am really skeptical to how BD 4K will turnout cause of this, they high bitrates which i am guessing is above the 24-25 for 4K, but if that's the case then they should uxe x264.

Then again that's a year ahead, i hope the Encoder will be much better till then (guessing they don't use x265, so to whatever they use).

Ah miss when i thought DVD looked transparent and i couldn't complain as i didn't know anything else:(

[Bloax]

Well yes, it's not very fair comparing an encoder that has gone through many years of tuning, improvement, innovation and optimization to a rather recent encoder for a different standard. (^:

[Nintendo Maniac 64]

And if i remember right it was like, AVC = 2mpbs, VP9 = 3mbps. Or something, which explained it.

This isn't the case anymore, refer to the posts on the previous page.

[zerowalker]

Yeah that's what i mean, it Was something like that in my tests way back (it was at least more bitrate, that's for sure in those cases). But as you say, it's not like that any more.
Not sure if old files have been replaced by new VP9 encodings, highly doubt that happens, but it would be nice if they did that to "fix" those mistakes. If it increases quality:P!

[Nintendo Maniac 64]

Here's something interesting - it would seem the very last video I just linked to has the 1440p VP9 version use considerably more bitrate than the 1440p h.264 version...

It doesn't seem to be consistant though, the following videos have pretty much the same bitrate for both 1440p formats:
https://www.youtube.com/watch?v=_wEOK6Hf4h8
https://www.youtube.com/watch?v=5jO1ju4CFoE

And yet here's a video with the VP9 1440p having somewhat less bitrate than the h.264 1440p (again, only available though a downloader):
https://www.youtube.com/watch?v=THmD3BiLpuk

Maybe at 1440p the bitrate for VP9 is set to be more variable or something depending on the video? Like I've stated before, F-Zero GX has always been tough on video encoders, so maybe YouTube automatically determines that it needs more bitrate?

----------------------------------------------------------------

I typically download both formats for vids I want to archive, then combine and re-encode them.

Combine? How the heck does one do that for video? I only know how to do that for individual images, and not automatically either (so I can't just do it to a sequence of frames without it taking forever).

[zerowalker]

Hmm interesting about 1440p. Perhaps it's as you say, just have a bit less limit to it's bitrate, and if it has much motion it will just use what it can as any codec/encoder.
That would be the case for pretty much all recordings though, except simple 2D, as any kind of 3D movement eats bitrate to the max most of the time (as long as there is much movement).
Everything that matters is just that the pixels change colors and doesn't stay the same for long.

Good for for me though;), sadly my CPU hates 1440p+, so don't think i can see 1440p60 if/when that is supported:P

[Nintendo Maniac 64]

Good for for me though;), sadly my CPU hates 1440p+, so don't think i can see 1440p60 if/when that is supported:P

Even my HTPC's good ol' 2.4GHz Penryn handles 1080p 60fps VP9 just fine in MPC-HC 64bit with D3D Fullsceen (though at like 90% CPU utilization :p). Is your CPU really that weak, or are you one of the unfortunate people with a CPU that lacks SSSE3? (like I was before my AM2+ mobo died on me a few months back)

[zerowalker]

1080p is fine, it's above that. 4k VP9 lags for me for example. So guessing 1440p at 60fps would lag as well.

I got i5 760 @4Ghz, so i don't lack SSE features and speed in that sense.

[Nintendo Maniac 64]

Huh, that's interesting... on my new fancy Pentium G3258 I can decode 2160p VP9 in 64bit MPC-HC with around ~80% CPU utilization, and that's only at stock clocks. I didn't think Haswell's IPC was that much better in things other than emulation (where it does really well).

One thing I do know is that disabling Accurate VSync and using D3D Fullscreen can reduce the CPU utilization a teeny bit, which can be useful if you're at almost playable speeds.

[zerowalker]

Talking Chrome here, but i think i actually tried downloading one before. Though i think it was much higher quality then youtube, so can't compare to that.
Chrome is locked at 50% as far as i know, so perhaps 80% i can do it as well, or perhaps it's a better decoder, or my CPU is just not good enough;P

[Nintendo Maniac 64]

Well for one thing MPC-HC uses ffvp9 which is much more optimized than the Google reference VP9 decoder, especially with SSSE3 and 64bit.

Case in point: 1280x720 30fps VP9 is actually playable on a measly 1.6GHz AMD E-350 in MPC-HC 64bit, but the very same video is a stutter-fest in MPC-HC 32bit.

(Chrome has similar performance to MPC-HC 32bit)


And FYI, MPC-HC can totally play back a still-downloading WebM file along with its according external audio file.

[zerowalker]

Interesting, guess i will try next time:)

[Nintendo Maniac 64]

Forget that, I found something even better - SVPtube. It's a small program that just runs in the background and keeps an eye on your copy/paste clipboard at all times, and then when you copy a YouTube link it will automatically launch your preferred program of choice along with your preferred format and resolution (all of which can be configured).

Now normally it's used in conjunction with SVP, but it's not actually required, so you can use it for launching your 4k VP9/WebM videos in 64bit MPC-HC.

Link to program:
http://svp-team.com/wiki/SVPtube


Just an FYI though, the "Autoplay" function may be a bit finicky at times (I think it's caused by changing a specific setting in SVPtube, but I don't know what...); in such situations, you can just left-click the SVPtube icon on the taskbar to start the video manually.

[pandy]

Huh, that's interesting... on my new fancy Pentium G3258 I can decode 2160p VP9 in 64bit MPC-HC with around ~80% CPU utilization, and that's only at stock clocks. I didn't think Haswell's IPC was that much better in things other than emulation (where it does really well).

One thing I do know is that disabling Accurate VSync and using D3D Fullscreen can reduce the CPU utilization a teeny bit, which can be useful if you're at almost playable speeds.


With or without DXVA (or similar solution)?

[zerowalker]

VP9 has no hardware acceleration yet. Or well perhaps Mobile.

[mzso]

Forget that, I found something even better - SVPtube. It's a small program that just runs in the background and keeps an eye on your copy/paste clipboard at all times, and then when you copy a YouTube link it will automatically launch your preferred program of choice along with your preferred format and resolution (all of which can be configured).

Now normally it's used in conjunction with SVP, but it's not actually required, so you can use it for launching your 4k VP9/WebM videos in 64bit MPC-HC.

Link to program:
http://svp-team.com/wiki/SVPtube


Just an FYI though, the "Autoplay" function may be a bit finicky at times (I think it's caused by changing a specific setting in SVPtube, but I don't know what...); in such situations, you can just left-click the SVPtube icon on the taskbar to start the video manually.
I tried it before. Didn't find it too reliable. Opening videos often failed or took a long time. Plus it runs as a separate program which watches the clipboard for yt links which is annoying.

Just gave it a try again. It fails to open any videos.

[mandarinka]

Well for one thing MPC-HC uses ffvp9 which is much more optimized than the Google reference VP9 decoder, especially with SSSE3 and 64bit.

Case in point: 1280x720 30fps VP9 is actually playable on a measly 1.6GHz AMD E-350 in MPC-HC 64bit, but the very same video is a stutter-fest in MPC-HC 32bit.

(Chrome has similar performance to MPC-HC 32bit)


The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

Some users may find that ffvp9 is a lot slower than advertised on 32bit; this is correct, most of our SIMD only works on 64bit machines. If you have 32bit software, port it to 64bit. Can’t port it? Ditch it. Nobody owns 32bit x86 hardware anymore these days. (see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

[Nintendo Maniac 64]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

(see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

Already well aware of this - I'm arguably the first guy that found out that their optimizations are actually not just 64bit but also SSSE3 - if you have one but not the other, you'll essentually get the same performance as 32bit.

[Kurtnoise]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode.
ffvp9 is the decoder not the encoder...

[mandarinka]

Yeah, of course. I know but made a mistake when writing that.

Already well aware of this - I'm arguably the first guy that found out that their optimizations are actually not just 64bit but also SSSE3 - if you have one but not the other, you'll essentually get the same performance as 32bit.

Yeah, the cause is probably the same - the developers didn't feel like supporting SSE2-only CPUs like K10 derivatives. I guess the reason is unwillingness, time and having less code to maintain.

I'm in the same boat here (2011 AMD chip) but luckily I don't experience need for VP9 decoding as such, so slowness is not an issue, hehe (yet, maybe that will change in time). ffmpeg/libav guys aren't the only people like this anyway, x265 is the same. I guess we are quite lucky that x264 was quite consistently developed with serious targeting of SSE2 as well as newer CPUs <3

[Nintendo Maniac 64]

I'm in the same boat here (2011 AMD chip)

You're on a Llano APU? That's the only 2011 AMD CPU without SSSE3 - even Bobcat supported SSSE3.

And FYI, I'm no longer in the same boat since my AM2+ mobo died back in July. The only SSSE3-less system that's actively used now is my file server (Pentium 3) and my father's PC (1.9GHz Brisbane G1).

[mzso]

I'm in the same boat here (2011 AMD chip) but luckily I don't experience need for VP9 decoding as such, so slowness is not an issue, hehe (yet, maybe that will change in time). ffmpeg/libav guys aren't the only people like this anyway, x265 is the same. I guess we are quite lucky that x264 was quite consistently developed with serious targeting of SSE2 as well as newer CPUs <3

I don't think luck has anything to do with it. x264 is a much older project which predates SSSE3.

[mandarinka]

I don't think luck has anything to do with it. x264 is a much older project which predates SSSE3.

In the relevant time (say 2006-2010), SSSE3 was available or even mainstream on Intel processors, so the "predating" isn't that important. The point is that they almost always implemented assembly for SSE2 (or even MMX in the past) path as well as the higher sets and didn't drop it later for sake of simplicity or like that. Same for 32bit mode, their assembly is always made for both, with only little exceptions with actual technical reasons. I'd call it luck that they cared so much even though 90 % of users usually had ~Core 2 chips that did not need it.

x264 doesn't even require SSE2 yet, although it wouldn't be unreasonable - you can run the encoder on Athlon XPs and it won't be significantly crippled in comparison to K8 cores with SSE2, actually.

Edit: But I'm getting fairly far form the thread's topic...

[foxyshadis]

Here's something interesting - it would seem the very last video I just linked to has the 1440p VP9 version use considerably more bitrate than the 1440p h.264 version...

It doesn't seem to be consistant though, the following videos have pretty much the same bitrate for both 1440p formats:
https://www.youtube.com/watch?v=_wEOK6Hf4h8
https://www.youtube.com/watch?v=5jO1ju4CFoE

And yet here's a video with the VP9 1440p having somewhat less bitrate than the h.264 1440p (again, only available though a downloader):
https://www.youtube.com/watch?v=THmD3BiLpuk

Maybe at 1440p the bitrate for VP9 is set to be more variable or something depending on the video? Like I've stated before, F-Zero GX has always been tough on video encoders, so maybe YouTube automatically determines that it needs more bitrate?

I'm pretty sure the explanation is more that VP9's rate control is mostly worthless, which at least is a step up from how it was it completely worthless a year ago. Instead of being anything from 50% less to 100% more, it's now within 25% either way.

Combine? How the heck does one do that for video? I only know how to do that for individual images, and not automatically either (so I can't just do it to a sequence of frames without it taking forever).

It's not that much different from images. Mask off anything that looks like blocking or flat detail-free parts, where only one is masked off mostly or only use the other there, where both or neither are just merge them. Detail can be good or bad, but it generally looks better. The masktools scripts are kind of a pain though.

[Nintendo Maniac 64]

Uhh, I just realized - shouldn't the whole VP9 on YouTube discussion have been in the other thread?

http://forum.doom9.org/showthread.php?t=170682

[easyfab]

New commit :" vp9_ethread: the tile-based multi-threaded encoder"

Vp9 should be a little faster now ( 2x ?) . I'll make some tests later .

[Selur]

that sounds nice, please report, may be this will make VP9 usable :)

[easyfab]

vpxenc v1.3.0-4967-ga3a4a34 x64
park_joy_1080p50.y4m
intel I2600k

--good --cpu-used=3
1.59fps
cpu usage 12%

--good --cpu-used=3 --tile-columns=2 --threads=4
3.4fps
cpu usage between 30 and 40%

so better but still progress possible to saturate the cpu usage, x3 with 100% ?

Still to slow for real encoding

[BadFrame]

--good --cpu-used=3 --tile-columns=2 --threads=4
3.4fps
cpu usage between 30 and 40%

so better but still progress possible to saturate the cpu usage, x3 with 100% ?


I just tried it myself, I got ~80% cpu utilization on a 2.67ghz core i5 using the following:

vpxenc --good --cpu-used=1 --codec=vp9 --end-usage=q --cq-level=10 --aq-mode=3 --lag-in-frames=25 -o clip.webm clip.y4m --tile-columns=2 --threads=4

using '--tile-columns=2 --threads=4' cut the encoding time down from 23 minutes and 12 seconds, to 7 minutes and 59 seconds on a 50 second 720p clip, so something like a ~65% faster.

[Tommy Carrot]

What's the difference between --end-usage q and cq modes? I can't find any real description about them. I'd guess one of them is similar to constant quantizer mode, but which one? Is the other similar to the crf mode in x264, or is it something different?

[Selur]

What's the difference between --end-usage q and cq modes?
Which cq modes?
Afaik there's "--end-usage=<arg> (vbr, cbr, cq)"
vbr = variable bitrate
cbr = constant bitrate
cq = constant quantizer
and "--cq-level=<arg> (valid values 0-63, default 10)" which defines the quantizer that is used with "--end-usage=cq",
but no "cq modes".

And no, at least atm. there is no such thing as similar to crf in x264.

[Tommy Carrot]

In the latest build from Kurtnoise, there are: --end-usage=<arg> vbr, cbr, cq, q
"cq" is supposed to be constrained quality, not constant quantizer, and i haven't found any description about "q" mode, but many people use it in their command lines.

[Selur]

You are right there is totally missed that,... sorry.
---
looking at http://wiki.webmproject.org/vp9/vp9-tips
it seems like:
--end-usage=q --cq-level=<desired quality in quant scale 0-63>
is constant quantizer
--end-usage=cq --cq-level=<desired quality in quant scale 0-63> --target-bitrate=<max_bitrate_constraint_in_kbps>
is some sort of constant quantizer, but restricted to a max bitrate (so the quantizer will be lowered if the choosen quantizer would violate the bitrate restriction)

[Tommy Carrot]

Ah, i see, thanks. I know vp9 is mostly developed for youtube, it's not really intended for end-users, but i hope they'll improve the documentation a bit. It's kinda hard to find info about basic stuffs.

[Selur]

I know vp9 is mostly developed for youtube,...
didn't know that :), but yes their way to document&share stuff really is lacking

[Tommy Carrot]

I played around with the vp9 encoder a bit, and i've never thought i would say this, but i'm actually quite impressed with the quality of it. I've tried almost all available vpx codec since vp3, and they were always overhyped, but ultimately lackluster, so i thought this is the case with vp9 as well. In my opinion currently it beats x265 quality-wise in most cases, even though hevc should be a more advanced format with more powerful tools for compression.

[Selur]

Problem is, that it simply is too slow for normal usage. The single threading really is a pain.

[Tommy Carrot]

Yep, it's too slow, but at least it has the quality advantage we'd expect from a "next gen" codec (unlike x265), and it just got multi-threading support, and i'm sure the encoding speed will be improved a lot in the future.

[Selur]

.. and i'm sure the encoding speed will be improved a lot in the future.
it's slow since the beginning and even http://wiki.webmproject.org/vp9/known-issues (which hasn't been updated for ages notes "Expect slow performance.")
-> the hope that vp9 will be faster any time soon was abandoned by my 1+ year ago :/

[Tommy Carrot]

That's too bad. I'd like to have a more efficient codec than x264, but the only real contender, x265 just doesn't seem to go anywhere. They are trying to improve speed, but often with shortcuts at the cost of quality. In fact the coding efficiency seems to be getting worse and worse instead of improving, as the development progresses. What's the point of improving the encoding speed, if it's still many times slower than x264, while the quality is not really any better in most cases?

[mzso]

it's slow since the beginning and even http://wiki.webmproject.org/vp9/known-issues (which hasn't been updated for ages notes "Expect slow performance.")
-> the hope that vp9 will be faster any time soon was abandoned by my 1+ year ago :/

It's a funny thing to say right after multithreading was implemented...

[easyfab]

It's funny thing to say right after multithreading was implemented...

yes between 2x and 2.5 X for me.
But I hope it's only a first step in multithreading because i'm only at 30% of CPU usage .

[Selur]

It's a funny thing to say right after multithreading was implemented...
Hopefully only for a small fraction of the code,...

Using a fresh compiled vpxenc (64bit) with:
vp8 - WebM Project VP8 Encoder v1.3.0-5001-g547cb14
vp9 - WebM Project VP9 Encoder v1.3.0-5001-g547cb14

Settings I used:
1st pass:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_09_50_38_5810_02.stats" --best --cpu-used=0 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
2nd pass:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=2 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_09_50_38_5810_02.stats" --best --cpu-used=0 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=2 --tile-rows=1 --threads=16 --width=640 --height=352 -o "H:\Temp\test_09_50_38_5810_03.vp9" -
I get 25% cpu usage which is better than the previous 12%, but still if that's what the speed of VP9 will stay at for again a year or more it's not really worth my time.

I'm using VP9 since spring of 2013 and this is the first time the speed got better and it's nice to see that something is happening in the multi-threading department, but still not enough to make it usable and pardon me, that after a year of knowing that vp9 is really slow and comparing how other codecs evolve in 1+ year (without a 'small' company like Google behind it) I'm still disappointed.
When I then read that Google plans to throw out another codec every 2 years, I'm not really confidant that VP9 will be usable till VP10 get's released.

[dapperdan]

When I then read that Google plans to throw out another codec every 2 years, I'm not really confidant that VP9 will be usable till VP10 get's released.

A quote on their mailing list suggested that's not the actual plan and they'd been misquoted.

Apparently VP10 work has started and there's a couple of branches available that have various experiments in them, details here:

https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/codec-devel/cp4E8q3TjEo

And in a reply later in that thread someone says:

"The 2015 timeline for VP10 was misquoted.
A more realistic timeline is ~3 years, but also subject to the technical uncertainty of being able to achieve a substantial compression gain over VP9 at reasonable complexity."

[BadFrame]

I would suggest not using --best and --cpu-used=0 for anything other than to do an extreme test to see the absolute maximum the codec can produce (like more extreme than placebo on x264/x265), for something practical in terms of speed, use --good and --cpu-used=1, and I must say they do very well against --preset=slower on x264/x265 quality-wise in my tests.

I don't know if it is because I use --good and --cpu-used=1, but I get between 75-90% cpu utilization on my 2.67ghz core i5 using the following:

vpxenc --good --cpu-used=1 --codec=vp9 --end-usage=q --cq-level=15 --lag-in-frames=25 -o clip.webm clip.y4m --tile-columns=2 --threads=4

other things to try out are the different aq-modes, --aq-mode=2 (complexity) seems to give me the best results in terms of size/quality, also setting --arnr-maxframes=15 --arnr-strength=6 helps with better compression ration with no visible loss of quality as far as I can tell.

looking at the commandline you posted, you are manually setting a lot of parameters, like tile rows etc, why not cut down on parameters to make sure that they are not interfering with the possibility to do multithreading encoding ? try the settings I posted, (two pass is default so I don't set that), and also if you don't get good results through ffmpeg, try using vpxenc directly ?

[dapperdan]

Also, am I missing something, or would you expect tile-based multithreading with two tiles to only double CPU usage? Several people seem to report that result as if they expected something different to happen?

About a year ago Youtube suggested they were using 4 tiles for 1080p, though I think it was multithreaded decode they were talking about at that time.

[Selur]

@dapperdan:
Also, am I missing something, or would you expect tile-based multithreading with two tiles to only double CPU usage? Several people seem to report that result as if they expected something different to happen?
Using a higher tile count doesn't change the cpu usage.
About a year ago Youtube suggested they were using 4 tiles for 1080p, though I think it was multithreaded decode they were talking about at that time.
at least I used SD content (--width=640 --height=352)

looking at the commandline you posted, you are manually setting a lot of parameters, like tile rows etc, why not cut down on parameters to make sure that they are not interfering with the possibility to do multithreading encoding ?
I'm not manually setting the parameters and most of them should be at their default values. :)

I don't know if it is because I use --good and --cpu-used=1, but I get between 75-90% cpu utilization on my 2.67ghz core i5 using the following
I'm using a i7 quad core, so my 25% might be similar to you 75%, but still if far away from using the available cpu power. ;)

Using:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_11_15_49_0510_02.stats" --good --cpu-used=1 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=4 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
and
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\test.avi" -map 0:0 -an -sn -vsync 0 -r 25000/1000 -pix_fmt yuv420p -f yuv4mpegpipe - | vpxenc --codec=vp9 --passes=2 --pass=1 --target-bitrate=1500 --end-usage=vbr --fpf="H:\Temp\test_11_15_49_0510_02.stats" --good --cpu-used=1 --min-q=0 --max-q=63 --bias-pct=70 --minsection-pct=15 --maxsection-pct=10000 --lag-in-frames=25 --drop-frame=0 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=0 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --tile-columns=4 --tile-rows=1 --threads=16 --width=640 --height=352 -o NUL -
encoding is slower, but the cpu usage is lower (< 23%).

.. try using vpxenc directly ?
Since I always decode through ffmpeg or mencoder and then pipe the output of those to the encoder of my choosing. Creating humongous intermediate files isn't really an option for me.

--arnr-maxframes=15 --arnr-strength=6 helps with better compression ration with no visible loss of quality as far as I can tell.
I normally prefer to do the noise reduction before the encoding. :)

Cu Selur

[BadFrame]

I'm using a i7 quad core, so my 25% might be similar to you 75%, but still if far away from using the available cpu power. ;)

Using:
...
encoding is slower, but the cpu usage is lower (< 23%).

Are you saying you get slower encoding with --good and --cpu-used=1 than --best and --cpu-used=0 ???? That makes no sense at all.


Since I always decode through ffmpeg or mencoder and then pipe the output of those to the encoder of my choosing. Creating humongous intermediate files isn't really an option for me.

But in order to easily see if there is something in using ffmpeg to encode which gives you such poor results, how about just testing with a 'humongous intermediate file' just this once ? You realise you don't have to encode an entire movie, right ?


I normally prefer to do the noise reduction before the encoding. :)
Cu Selur

It's an alternate method of creating a reference frame, by temporally filtering a specific frame against a set of other frames, I don't see how it has anything to do with noise reduction ?


When --auto-alt-ref is enabled the default mode of operation is to either populate the buffer with a copy of the previous golden frame when this frame is updated, or with a copy of a frame derived from some point of time in the future (the choice is made automatically by the encoder). The --lag-in-frames parameter defines an upper limit on the number of frames into the future that the encoder can look.

However, many other options are possible and one alternative that has been implemented uses a temporally filtered image derived from a group of future frames. The extra control parameters for this are:

--arnr-maxframes=<arg> (number of frames to filter over 0-25)
--arnr-strength=<arg> (strength of the temporal filter 0-6)
--arnr-type=<arg> (not currently supported)

[Kurtnoise]

There is a fork on github using openCL (https://github.com/ittiamvpx/libvpx)...That should be faster.

[Selur]

Are you saying you get slower encoding with --good and --cpu-used=1 than --best and --cpu-used=0 ???? That makes no sense at all.
No I'm saying I get lower cpu usage. (speed is, as expected, faster)

[qutoe] I don't see how it has anything to do with noise reduction ?[/quote]
You are right haven't used vp9 for so long that I mixed up some stuff. :)

how about just testing with a 'humongous intermediate file' just this once ?
will to later, but I don't expect it to change anything (I'm using SD here so, decoder should be really fast and not really need much resources)

There is a fork on github using openCL...That should be faster.
didn't know that, will try it if someone can make a win 64bit build of it.

[dapperdan]

@dapperdan:

Using a higher tile count doesn't change the cpu usage.



I'm confused then. I assumed it was breaking the video up into independant tiles and using a thread to encode each one individually. So 2 tiles, 2 cpus used, 4 tiles 4 cpus used to their full extent.

Can someone explain what it's actually doing?

[Selur]

That is what I assumed too, but since the cpu usage didn't change that doesn't seem to be what the option (or the multithreading support) is doing

[mandarinka]

Yep, it's too slow, but at least it has the quality advantage we'd expect from a "next gen" codec (unlike x265), and it just got multi-threading support, and i'm sure the encoding speed will be improved a lot in the future.

If it is tile-based multithreding, then that is a fairly cheap-to-write but very bad-for-quality method. Basically it splits the frame into parts (vertical slices iirc) and encodes them separately. Really blows compared to WPP or frame-threads.

And are you sure VP9 is better than x265? AFAIK it was the other way around, and x265 keeps improving actually.

-------------------------------------
https://groups.google.com/a/webmproject.org/forum/?fromgroups#!topic/codec-devel/cp4E8q3TjEo

From the linked thread:
Currently for the playground branch, you can try configuring with any combination of these options in bold:
--enable-experimental --enable-supertx --enable-copy-coding --enable-ext-tx --enable-filterintra --enable-interintra --enable-masked_interintra --enable-masked_interinter
You will get about 4% gain over baseline VP9. There was an ICIP talk recently which talks briefly about these tools, which should be available online sometime.

Currently for the nextgen branch the available tools are:
--enable-experimental --enable-ext-tx --enable-tx64x64 --enable-filterintra --enable-txskip
where ext-tx is a better version of the tool in the playground branch, and txskip is only used in lossless mode. The stable tools from the playground branch are in the process of being promoted to nextgen currently.

Does anybody have a link/pointer to the mentioned ICIP talk information? It would be nice to get an idea of the experimental compression tools that they evaluate.

[Tommy Carrot]

And are you sure VP9 is better than x265? AFAIK it was the other way around, and x265 keeps improving actually.

Yep, x265 tends to blur out the fine details. Maybe some extreme psy-rd settings can negate that, but that causes other issues. Vp9 retains more detail without causing any really perceptible artifacts. X265 only has advantage at ridiculously low bitrates (above crf 40 or so).

And yes, in my opinion the older versions produced better quality. The newer versions tend to produce less detailed, smoother output. Hell, an ancient 0.3 build, which i use as a comparison standard, often beats the latest build quality-wise without having any adaptive quantization, cutree and psy-rd (which should improve the perceptual quality quite a bit).

[mandarinka]

To me it seemed that VP9 blurs even more, while having no psy-rd at all, so you can't prevent that at all, unlike with x265.

[Kurtnoise]

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...
x86 (http://www.mediafire.com/download/fwdmfhna2ala97a/vpx_x86_20141214.7z) & x64 (http://www.mediafire.com/download/6lmjqi1dnk2uau9/vpx_x64_20141214.7z) binaries from today...

[benwaggoner]

x86 (http://www.mediafire.com/download/fwdmfhna2ala97a/vpx_x86_20141214.7z) & x64 (http://www.mediafire.com/download/6lmjqi1dnk2uau9/vpx_x64_20141214.7z) binaries from today...


Any notable new features or changes?

I keep hoping VP9 will get something to start closing the gap with x265, which is improving quite rapidly in speed and quality, as are other HEVC encoders.

I don't think I've seen a compelling real-world example of VP9 beating x264 yet for a practical scenario. I believe the bitstream itself to be capable of better than H.264 quality, but encoder refinement is a HUGE factor.


-Ben Waggoner (via TapaTalk)

[mandarinka]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

(see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

Just a quick note since this was discussed earlier.
Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.
https://github.com/rbultje/ffmpeg/commits/vp9-32bit
I think that some parts at least already hit the official tree of FFmpeg.

[Kurtnoise]

Any notable new features or changes?

Mainly bugfixes but devs are also starting multithreading support for the vp9 encoder...

[easyfab]

I see a Multiframe Quality Enhancement (MFQE) commit but I don't know what it is ? for encoding or decoding ?

[Kurtnoise]

It's for decoding...

The aim for MFQE is to replace pixel blocks in the current frame with the correlated pixel blocks (with higher quality) in the last frame. The replacement can only be taken in stationary blocks by checking the motion of the blocks and other conditions such as the SAD of the current block and correlated block, the variance of the block difference, etc.

From the commit message :
* Multiframe Quality Enhancement(MFQE) in VP9.

It is the first version of MFQE in VP9. There are a few TODOs included
in this version.
Usage: Add flag --enable-vp9-postproc to config the project.
In decoder, use flag --mfqe in the command line to enable
MFQE in postproc.
Note: Need to have key frame with low quality to see the effect of this
new patch. In my experiment, I fixed the qindex to 200 in key frame.

I'm rebuilding binaries w/ the post-proc flag...

x86 (http://www.mediafire.com/download/qn0nb19bwb2rpuv/vpx_x86_20141215.7z) & x64 (http://www.mediafire.com/download/lqrns8hbtgq0agt/vpx_x64_20141215.7z) binaries from today...

[Nintendo Maniac 64]

I wonder if the last several performance improvements are related to why there haven't been any VP9/WebM encodes on YouTube for a week now...? Like, maybe they're tweaking their encoding setup or something.

Just a quick note since this was discussed earlier.
Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.
https://github.com/rbultje/ffmpeg/commits/vp9-32bit
I think that some parts at least already hit the official tree of FFmpeg.

Now the real question is, when will this hit LAV and when will it hit MPC-HC?

[easyfab]

Now the real question is, when will this hit LAV and when will it hit MPC-HC?

The best chance is when nevcairiel make an update of his ffmpeg tree for LAV filters.
Peharps a little faster if you ask him nicely in the LAV filters thread :p

[nevcairiel]

Building those new optimizations on Windows is currently broken in some configurations, certainly not before that is fixed.

[Selur]

Probably fixed now, at least the problem I had (and reported the last days) was fixed yesterday. :)

[Nintendo Maniac 64]

Seems that the things are changing, VP9 is getting some SSE2 level assembly also for 32bit mode.

It just hit me - that's SSE2. AFAIK, all optiimizations for SSE2 and below are coded for both 32bit and 64bit; it's only optimizations using SSSE3 and above that are 64bit only.

[nevcairiel]

It just hit me - that's SSE2. AFAIK, all optiimizations for SSE2 and below are coded for both 32bit and 64bit; it's only optimizations using SSSE3 and above that are 64bit only.

There is not really any relation between which SSE version is used and 32-bit or 64-bit.

Truth is that many newer optimizations are written to take advantage of the newer instructions for even more speed, and at the same time are written for 64-bit only because thats much easier to deal with, which may give someone this impression.
However, there is no rule that says I couldn't write 64-bit only SSE2 code, or SSSE3 32-bit code (or AVX2 32-bit code for that matter).

[Nintendo Maniac 64]

I didn't mean for code in general, I meant specifically for what is being developed for ffvp9:

http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2014-July/002201.html[/url]"]<nevcairiel> both ssse3 and avx optimizations, and most of those are only available on 64-bit on top, so if you run on 32-bit or on a CPU without ssse3, it'll be quite a bit slower

<jamrial> the optimizations up to sse2 are all for both x86 and x64. it's only ssse3 and above that (most) require x64

The point was that, because the new optimization being implemented for 32bit was SSE2, their policy of focusing on 64bit has not changed since SSE2 optimizations were already stated to be implemented for both 32bit and 64bit.

[benwaggoner]

It's for decoding...

I'm rebuilding binaries w/ the post-proc flag...
Wow. The "standardized but optional post-processing filter" was NOT the feature from VC-1 I expected to see in modern codecs.

Unless it's really fast, software decoders tend to leave out the optional post-processing in my experience. Even HW as well. That certainly happened in lots of VC-1 ports. Even Silverlight, although that was more a case of lameness than thoughtful design.

The way they should work is to turn off with the codec is under decoder performance stress, but that can be surprisingly hard to measure and tune in real-time.

[mandarinka]

[03:16] <BBB> https://raw.githubusercontent.com/rbultje/public/master/vp9-32bit.png

It seems I'll have to find a different thing to bash VP9 about ;) , 32bit and/or SSE2 decoding performance in FFVP9 seems to have closed the gap with 64bit / SSSE3+. Solidly trounces libvpx, too (lol @ libpx essentially being single-threaded...).

Edit: Thanks to the devs (mainly Ronald S. Bultje, I think)! This will come handy on those 32bit Wintel tablets or on Athlon/Phenom machines. Also when one is forced to 32bit playback components by MadVR.

[Nintendo Maniac 64]

Also when one is forced to 32bit playback components by MadVR.

And SVP which also requires 32bit - the extra performance will really come in handy considering that SVP can pretty much take advantage of as much CPU performance as you can throw at it.

[Kurtnoise]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

[Nintendo Maniac 64]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

Needs more info whether this means VP8 or VP9, because for all we know this could just be an integration of the previously-existing VP8/WebM IE plugin... it also needs more info whether this includes actual vorbis support or if they're kind of cheating and only supporting Opus for audio (I mean, it is partially built off Skype's SILK codec)

However, if it does mean actual VP9 support along with actual vorbis audio, then that would definitely pretty big news and may very well mean that VP9 will beat HEVC to the punch for browser-based streaming purposes.


(though Opus is better than vorbis anyway, which begs the question, "Why is YouTube still using vorbis audio for its VP9 WebM encodes?")

[dapperdan]

I thought I'd seen Opus on Youtube? There's some discussion here: http://www.hydrogenaud.io/forums/index.php?showtopic=107481

Also, is this actually confirmed? When I read it on Anandtech earlier and googled for more info, the only thing that came back was Anandtech, and a whole bunch of scummy sites that republish Anandech's articles in full without their permission.

Assuming it is actually true, confirmation of whether this is just for WebRTC or not would be good, as well as the points made above about VP8 and/or VP9 and what audio codecs supported alongside which video codecs etc.

[Nintendo Maniac 64]

I thought I'd seen Opus on Youtube? There's some discussion here: http://www.hydrogenaud.io/forums/index.php?showtopic=107481

Oh, that's a new development! That's great to see since it means YouTube also now officially support 48KHz audio. I'll have to contact the developer of CompleteYoutubeSaver so he can add them in...

[zerowalker]

Well this is indeed nice.
Always hated that Youtube uses 44.1khz for everything as my favorite is 48khz (it looks nicer, but primarily it's what pretty much every standard use except CD).
And Opus instead of super fast AAC encoding is most certainly going to be a quality gain:)

Weird how old that Topic is though, thought i would notice if Opus and 48khz was added:S

[NikosD]

Spartan Project supports WebM (http://www.anandtech.com/show/8932/internet-explorer-project-spartan-shows-large-performance-gains)...awesome !!!

Needs more info whether this means VP8 or VP9, because for all we know this could just be an integration of the previously-existing VP8/WebM IE plugin...


I tried latest Windows 10 Preview Build 9926 and IE11 with Spartan project enabled, already supports VP8 but not VP9 yet.

I think Microsoft's browser (IE12 ?) is going to support VP9 within the final Windows 10 product.

[xooyoozoo]

I tried latest Windows 10 Preview Build 9926 and IE11 with Spartan project enabled, already supports VP8 but not VP9 yet.

Does this also apply to Opus?

Was this through drag-n-drop into a window? If so, can you check whether FLAC, HEVC, and/or MKVs can play?


I think Microsoft's browser (IE12 ?) is going to support VP9 within the final Windows 10 product.

Whatever's stopping Spartan from including VP9, it's probably a holdup at the decision level rather than the implementation level. VP9 is activated by default in libvpx (I doubt they handrolled their own decoder or used LGPL libav), so they must have manually disabled library support for it.

Microsoft has already committed to incorporating a future version of WebRTC (ORTC/WebRTC 1.1), where both VP8 and Opus are mandatary codecs for full support. In that sense, including VP8 isn't entirely unexpected, but I assumed Microsoft would just ignore the VP8 requirement and glibly go for "webrtc-compatible", so this is a nice surprise.

[Nintendo Maniac 64]

Always hated that Youtube uses 44.1khz for everything as my favorite is 48khz (it looks nicer, but primarily it's what pretty much every standard use except CD)

48KHz is particularly nice for my uses since 99.99% of music and audio in games on Nintendo platforms are 32KHz.

(yes I know it's 32006Hz on the N64, but that can be losslessly slowed down to 32000Hz flat via Audacity)

[mandarinka]

Inb4 they still convert everything to 44.1khz, then Opus internally resamples it to 48khz when encoding and then during playback, the player resamples to 44.1khz again.

[NikosD]

Does this also apply to Opus?

Was this through drag-n-drop into a window? If so, can you check whether FLAC, HEVC, and/or MKVs can play?


IE doesn't look to work that way, with drag&drop.

Whenever I do that with any sample, a pop-up message asks me if I want to save it or open it and it opens that with the default program set by Windows default programs.

I tested IE11 (Spartan) by hitting this page:
https://www.youtube.com/html5

[xooyoozoo]

I tested IE11 (Spartan) by hitting this page:
https://www.youtube.com/html5

Oh hmmmm.

That page assumes compatibility whenever a certain API call returns either 'probably' or 'maybe'. You can see how that's troublesome in a pre-beta browser (relevant (http://gph.is/Z5SBTA) ;)).

Edit: This page (http://www.quirksmode.org/html5/tests/video.html) has videos to explicitly determine support.

Edit 2: Microsoft will not include VP8/VP9 support in the foreseeable future (https://twitter.com/jacobrossi/status/560918042821918720).

[Nintendo Maniac 64]

Inb4 they still convert everything to 44.1khz, then Opus internally resamples it to 48khz when encoding and then during playback, the player resamples to 44.1khz again.

I had thought of that...but I didn't want to suggest it until I actually tested it myself.

[zerowalker]

Same thought occurred to me, was hoping that wasn't true -_-.
Talk about a mess, you get better audio quality, but playback breaks it. Why do they want to force 44.1 on playback?
Is Hardware limited to playing that or what?
Cause all Hardware i know that has any access to Youtube should be able to play 48khz, as either it's a TV (DVD = 48khz) or it's a Phone/Media player thing which can often play up to 96khz.

[Nintendo Maniac 64]

Same thought occurred to me, was hoping that wasn't true -_-.
Talk about a mess, you get better audio quality, but playback breaks it. Why do they want to force 44.1 on playback?

You're jumping to conclusions, nobody actually said that they actually do that; we're just theorizing that it is technically possible.

BTW, turns out that YouTube livestreams are 48KHz AAC.

[zerowalker]

You're jumping to conclusions, nobody actually said that they actually do that; we're just theorizing that it is technically possible.

BTW, turns out that YouTube livestreams are 48KHz AAC.

Oh, nice. It's good to be wrong (hopefully) ;)

Ah, that's at least a bonus, Good Job Youtube!

[sneaker_ger]

At least Chromium should always use 48 kHz for Opus decoding, a patch was applied last year for that.

[NikosD]

Oh hmmmm.

That page assumes compatibility whenever a certain API call returns either 'probably' or 'maybe'. You can see how that's troublesome in a pre-beta browser (relevant (http://gph.is/Z5SBTA) ;)).

Edit: This page (http://www.quirksmode.org/html5/tests/video.html) has videos to explicitly determine support.

Edit 2: Microsoft will not include VP8/VP9 support in the foreseeable future (https://twitter.com/jacobrossi/status/560918042821918720).

The page you posted is similar to an older one I used to test which is from Microsoft and it's here:
http://ie.microsoft.com/testdrive/Graphics/VideoFormatSupport/Default.html

Well, using IE11 of Win 10, it couldn't play the WebM videos of both pages, so it's a bug of Win 10 reporting "probably" for VP8/VP9 support as you posted above.

Let's hope that Microsoft will at least support a DXVA device decoder for VP8/VP9, for HW decoding acceleration.

[xooyoozoo]

libvpx just added (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=9a1ce7be7d4a3056b9da1df64cb7d5115a513dd9) the foundation for a psyrd-like feature. So far it's only activated in very specific situations and seems conservatively tuned even when it's on.

[benwaggoner]

It's great to see some psychivisual optimizations coming. Hopefully this will migrate to VP9 proper with interframe support.

[soresu]

They also just prepped a release candidate for libvpx 1.4.0, "Indian Runner Duck" http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=bb5a39c1a7ff4544c55a29c2ad34c5d391acb713

Seems to have multi threaded VP9 decode and encode, 10 and 12 bit support in VP9, aswell as enhanced ARMv8 support.
All round good update, if a bit late coming.

[Fantasy]

hello,
I try to build vpxenc.exe for windows 64 bit but it is too complicated for me.
Can some one build the latest version and then upload it pls?
Thank you!

[Kurtnoise]

http://www.mediafire.com/download/rs1j8hzhesouskl/vpx_x64_20150329.7z

I enabled high bitdepth in this build...

[Fantasy]

Thank you again, it works.
I try out 10 bit but no player can play it.

I have question about speed vs quality.

I read this: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

but -speed 4 is not a command used in vpxenc.exe.
I think it is a combination of -deadline and -cpu-used.
-deadline: best, good and rl are easy to understand.
But I don't understand what -cpu-used values mean?

[vivan]

http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
Those are for VP8, but for VP9 it should be the same:
--best is like placebo (why does it even need a special option?)
--good --cpu-used 0 is like veryslow
...
--good --cpu-used 5 is like ultrafast

And https://www.ffmpeg.org/ffmpeg-codecs.html#Options-17
-speed sets VP8E_SET_CPUUSED

[Kurtnoise]

I try out 10 bit but no player can play it.
It depends on which players, which filters used, libraries used etc...and how the players and the filters/libraries have been compiled.


I have question about speed vs quality.

I read this: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

but -speed 4 is not a command used in vpxenc.exe.
I think it is a combination of -deadline and -cpu-used.
-deadline: best, good and rl are easy to understand.
But I don't understand what -cpu-used values mean?
You have some explanations from here (http://www.webmproject.org/docs/encoder-parameters/)...it's for vp8 but it's the same idea.

[Fantasy]

wow I readed so much!
I have a question about -crf
"crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0."

I find out about -crf: VPX_CQ, VP8E_SET_CQ_LEVEL

VPX_CQ can be used as: --end-usage=qc
VP8E_SET_CQ_LEVEL can be used as: --cq-level=<arg>

I think -crf 10 is similar to --cq-level=10

I find out about -b:v: -b:v can be used as --target-bitrate=<arg>
But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

[Fantasy]

hello, I try --end-usage=q but it doesn't work.
The ffmpeg-version I found in internet is compiled with libvpx-1.3.0, so the new features are not in and multi threads works not pefectly.
I hope they will release vpx-1.4.0 / libvpx-1.4.0 soon.

[Fantasy]

hello, I try --end-usage=q but it doesn't work.
The ffmpeg-version I found is compiled with libvpx-1.3.0, so the new features are not in and multi threads works not pefectly.
I hope they will release vpx-1.4.0 / libvpx-1.4.0 soon.

[dapperdan]

Latest version of libvpx, 1.4 "Indian Runner Duck" is out. Announcement email:

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/2zYWenmdUM8

[Motenai Yoda]

wow I readed so much!
I have a question about -crf
"crf is the quality value (0-63 for VP9). To trigger this mode, you must use a combination of crf <q-value> and b:v 0. bv MUST be 0."

I find out about -crf: VPX_CQ, VP8E_SET_CQ_LEVEL

VPX_CQ can be used as: --end-usage=qc
VP8E_SET_CQ_LEVEL can be used as: --cq-level=<arg>

I think -crf 10 is similar to --cq-level=10

I find out about -b:v: -b:v can be used as --target-bitrate=<arg>
But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

I think u should use -b:v as max average bitrate

[Kurtnoise]

Latest version of libvpx, 1.4 "Indian Runner Duck" is out. Announcement email:

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/2zYWenmdUM8
x86 Windows build available here (http://www.mediafire.com/download/3sd9rr33x3e1hwu/vpx-1.4_x86_20150404.7z) and x64 available there (http://www.mediafire.com/download/wj9czojjc9jfmcb/vpx-1.4_x64_20150404.7z).

2015-04-03 v1.4.0 "Indian Runner Duck"
This release includes significant improvements to the VP9 codec.

- Upgrading:
This release is ABI incompatible with 1.3.0. It drops the compatibility
layer, requiring VPX_IMG_FMT_* instead of IMG_FMT_*, and adds several codec
controls for VP9.

- Enhancements:
Faster VP9 encoding and decoding
Multithreaded VP9 decoding (tile and frame-based)
Multithreaded VP9 encoding - on by default
YUV 4:2:2 and 4:4:4 support in VP9
10 and 12bit support in VP9
64bit ARM support by replacing ARM assembly with intrinsics

- Bug Fixes:
Fixes a VP9 bitstream issue in Profile 1. This only affected non-YUV 4:2:0
files.

- Known Issues:
Frame Parallel decoding fails for segmented and non-420 files.

[mzso]

x86 Windows build available here (http://www.mediafire.com/download/3sd9rr33x3e1hwu/vpx-1.4_x86_20150404.7z) and x64 available there (http://www.mediafire.com/download/wj9czojjc9jfmcb/vpx-1.4_x64_20150404.7z).

2015-04-03 v1.4.0 "Indian Runner Duck"
This release includes significant improvements to the VP9 codec.

- Upgrading:
This release is ABI incompatible with 1.3.0. It drops the compatibility
layer, requiring VPX_IMG_FMT_* instead of IMG_FMT_*, and adds several codec
controls for VP9.

- Enhancements:
Faster VP9 encoding and decoding
Multithreaded VP9 decoding (tile and frame-based)
Multithreaded VP9 encoding - on by default
YUV 4:2:2 and 4:4:4 support in VP9
10 and 12bit support in VP9
64bit ARM support by replacing ARM assembly with intrinsics

- Bug Fixes:
Fixes a VP9 bitstream issue in Profile 1. This only affected non-YUV 4:2:0
files.

- Known Issues:
Frame Parallel decoding fails for segmented and non-420 files.


Interesting. So now you can encode 444. Can it encode in full range too too?
How does it fare compared to x264 these days efficiency wise. Decoding was a fair bit slower when I last messed with it for similar quality, judging by youtube (I guess even worse at equal bitrates). Encoding was painfully slow.

[Motenai Yoda]

Interesting. So now you can encode 444. Can it encode in full range too too?
Seems no, there aren't any switch to set full or limited range.

[BadFrame]

But what is "b:v 0", they said "bv MUST be 0", does it means --target-bitrate=0?
I think it is not bacause if i set I set:
--end-usage=qc --cq-level=10 --target-bitrate=0
quality is very bad.
What can i do to get -crf (is to achieve a constant (perceptual) quality level without regard to bitrate)?

Hmm, what is --end-usage=qc ? And why are you setting --target-bitrate at all ? And to zero ?

If I want crf style encoding when testing vp9 I use the following:

'vpxenc --end-usage=q'

that is 'q', not 'qc' for 'end-usage', here's a full parameter example:

vpxenc --good --cpu-used=0 --codec=vp9 --end-usage=q --cq-level=10 --lag-in-frames=25 -o clip.webm clip.y4m

[vivan]

And why are you setting --target-bitrate at all ? And to zero ?
Because that's what official VP9 encoding guide told him to do. It even highlights it in all caps.

[Nintendo Maniac 64]

Decoding was a fair bit slower when I last messed with it for similar quality, judging by youtube

Be wary of using YouTube as a test since, by default, h.264 in the web browser will use your GPU's hardware accelerated decoder if it's available, which is present on pretty much any GPU made since 2009.

[mzso]

Be wary of using YouTube as a test since, by default, h.264 in the web browser will use your GPU's hardware accelerated decoder if it's available, which is present on pretty much any GPU made since 2009.

I'm comparing videos from youtube, not how it's played on youtube.
Actually the difference was quite little now when I tested it with latest mpc-hc. Though for some reason VP9 playback wasn't completely smooth. (Not because of cpu usage because it didn't get near max.)

[Selur]

Small question, does VP9 (or VP8) nowadays hit a specified average bitrate when using 2pass? (last time I did some testing it was still totally off target)

[Nintendo Maniac 64]

I'm comparing videos from youtube, not how it's played on youtube.
Actually the difference was quite little now when I tested it with latest mpc-hc.

Well the same issue still can apply - MPC-HC can take advantage of LAVfilter's DXVA decoding, so you'd want to make sure LAV's "Hadware decoder" is set to "None".

[BadFrame]

Because that's what official VP9 encoding guide told him to do. It even highlights it in all caps.

Could you point me to the official VP9 encoding guide ?

[vivan]

http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide#TOC-Constant-Quality-Recommended-Settings

[dapperdan]

Actually the difference was quite little now when I tested it with latest mpc-hc.

The measurements done for the ffmpeg vp9 decoder seemed to suggest that vp9 and h264 were roughly tied when it came to decoder complexity (they gave a slight lead to vp9 if comparing at same-quality rather than same-bitrate).

https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

At that point the libvpx decoder was trailing both ffmpeg decoders by a fair margin, I believe they've been focussing on speed since then, though ffmpeg probably haven't been sitting still either (notably extending support for 32 bit processors).

Be interesting to see how things stand now.

[BadFrame]

http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide#TOC-Constant-Quality-Recommended-Settings

What you point me to are ffmpeg mappings which in turn have pretty much nothing in common with parameters of the official encoder, which is vpxenc.

And since 'fantasy' used vpxenc specific parameters as '--cq-level', '--target-bitrate', '--end-usage', I can only assume he was using vpxenc.

Now when using constant quality (--end-usage=q) in vpxenc, --target-bitrate has no effect (unless you set it to zero which gave me a floating point exception.

And since there is no 'qc' option in vpxenc I can only assume that 'fantasy' meant 'cq' which stands for 'constrained quality' which is using --target-bitrate as an upper bound (which explains very poor quality when set to 0), but that is obviously the wrong option for him if he wants --crf style encoding with vpxenc, which again is '--end-usage=q', '--cq-level=X' .

[sneaker_ger]

If I do vpxenc.exe --end-usage=q --cq-level=X -o output.vp9 - (y4m input via pipe) it does not matter what I choose for X. It's always the same bitrate and same crappy quality.

[BadFrame]

If I do vpxenc.exe --end-usage=q --cq-level=X -o output.vp9 - (y4m input via pipe) it does not matter what I choose for X. It's always the same bitrate and same crappy quality.

That's weird, '--cq-level=X' gives me a corresponding quality (and of course file size) variation relating to 'X'.

vpxenc --good --cpu-used=0 --codec=vp9 --end-usage=q --cq-level=X --lag-in-frames=25 -o clip.webm clip.y4m

I build vpxenc from the development branch, perhaps you are using an old version ?

[sneaker_ger]

It seems it was encoding to vp8 because I missed the --codec parameter. But if I add it it tries to do 2pass encoding. Looks like it also needs --passes=1.

What a shame the documentation is as bad as the ffmpeg one.

[BadFrame]

It seems it was encoding to vp8 because I missed the --codec parameter. But if I add it it tries to do 2pass encoding. Looks like it also needs --passes=1.

What a shame the documentation is as bad as the ffmpeg one.

I agree it's poorly documented, I'm guessing this is because parameters are still very much in flux, basically I just look at the parameters vpxenc lists as any web documentation is likely very outdated.

[stax76]

Is anybody else using piping? No matter what I try, it's crashing at the last frame, my command line is:

ffmpeg.exe -i test.avs -f yuv4mpegpipe - | vpxenc.exe --codec=vp9 -w 1120 -h 688 --limit=300 --good --cpu-used=0 -o test_out.webm -

I also tried avs2yuv.

[sneaker_ger]

I think it's because it's trying automatic multi-pass encoding. It cannot rewind the pipe like it could re-read a file so it crashes after the first pass.

[stax76]

Problem solved, thanks!

[Nintendo Maniac 64]

Here's an intesting article that tested the quality and encoder performance testing between VP9 and HEVC:
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Great-UHD-Codec-Debate-Googles-VP9-Vs.-HEVC-H.265-103577.aspx

However, these tests were supposedly ran back in December.

They also did playback performance testing, but the choice of software wasn't the greatest (no MPC-HC?)...though admittedly the web browser is very likely to be the most common "player" for VP9 content. I tried to leave a comment mentioning the lack of a player like MPC-HC which can play both formats out-of-the-box, but it seems their commenting system's support for Microsoft accounts is broken, and I don't have an AOL of Facebook account (I have an old Yahoo account though, but I've no idea what it even is).

[dapperdan]

He uses the University of Moscow tool to measure objective quality, which reminds me that they're doing an HEVC evaluation this year and including VP9. Results are due in a month or so.

Tangentially related, I noticed libvpx pulled in code to output some other objective metric from daala, I think they only outputted PSNR before.

[leonccyiu]

Here's an intesting article that tested the quality and encoder performance testing between VP9 and HEVC:
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Great-UHD-Codec-Debate-Googles-VP9-Vs.-HEVC-H.265-103577.aspx

However, these tests were supposedly ran back in December.

They also did playback performance testing, but the choice of software wasn't the greatest (no MPC-HC?)...though admittedly the web browser is very likely to be the most common "player" for VP9 content. I tried to leave a comment mentioning the lack of a player like MPC-HC which can play both formats out-of-the-box, but it seems their commenting system's support for Microsoft accounts is broken, and I don't have an AOL of Facebook account (I have an old Yahoo account though, but I've no idea what it even is).

Thank you for the link, this is something I have been looking at. I would like to take screenshots at 1080p of encodes in 4k between h264 and vp9 on youtube, unfortunately this would be downscaled. I would like to do the comparison at 4k as for most 4k videos, the vp9 bit-rate is higher, some as high as 60 for time-lapses whereas the h264 versions are around 22. For older vp9 4k encoders (circa sep 2014) I have seen bit-rates as low as 8 which was lower than 16 for the same video.

By comparison to 1080p, I have only seen one video where the vp9 bitrate was higher. The bit-rates on many 1080p vp9 videos are only around 2.5mbps and imo should not qualify as 1080p, I have no qualms about streaming the 4k versions wherever available despite the wastefulness as the difference is night and day even on just a 1080p monitor

[Nintendo Maniac 64]

Thank you for the link, this is something I have been looking at. I would like to take screenshots at 1080p of encodes in 4k between h264 and vp9 on youtube, unfortunately this would be downscaled.

I'm not quite understanding what it is exactly you're trying to achieve, but never-the-less any YouTube-specific discussion relating to VP9 or the like would be better off discussed in the other VP9 thread that is located in this subforum:
http://forum.doom9.org/showthread.php?t=170682

[Kurtnoise]

VP10 code has been merged to the main branch (https://github.com/webmproject/libvpx/commits/master) few days ago...

Here are some fresh windows builds for testing : x86 (http://www.mediafire.com/download/7z88x93rtk4tkgg/vpx-1.4-1119_x86_20150815.7z)|x64 (http://www.mediafire.com/download/cdjkpvoaa7olxko/vpx-1.4-1119_x64_20150815.7z)

[SeeMoreDigital]

VP10 code has been merged to the main branch (https://github.com/webmproject/libvpx/commits/master) few days ago...

Here are some fresh windows builds for testing : x86 (http://www.mediafire.com/download/7z88x93rtk4tkgg/vpx-1.4-1119_x86_20150815.7z)|x64 (http://www.mediafire.com/download/cdjkpvoaa7olxko/vpx-1.4-1119_x64_20150815.7z)
How about creating a new topic for these VP10 builds ;)

[zerowalker]

I am confused, VP10 is merged into VP9 or what?

[Reel.Deel]

I am confused, VP10 is merged into VP9 or what?

libvpx now includes 3 encoders/decoders, before VP10 was merged it only included VP8 and VP9.

vpxenc.exe:
Included encoders:

vp8 - WebM Project VP8 Encoder v1.4.0-1119-gd030715
vp9 - WebM Project VP9 Encoder v1.4.0-1119-gd030715
vp10 - WebM Project VP10 Encoder v1.4.0-1119-gd030715 (default)

Use --codec to switch to a non-default encoder.

[zerowalker]

oh, didn't know it was combined.

Well VP10 is very interesting.
How far has it comes, i am guessing it's like when x265 was released or something, as they just merged the code?

Anyone know what VP10 has in store though, what's the features etc?

[Jamaika]

It's nice that there is something new. I did a test and decided that it doesn't have to be now codec VP10.
Too much bitrate, change colorspace, worse quality of the X264, there are no decoder and adapt to anything. Screenshots watched in Honeyview 5.12.

Video
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x264.exe --demuxer y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --threads 4 --output-csp i420 --preset slower --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --tune stillimage --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range tv --output x264.h264 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x265.exe --y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --preset slower --output-depth 8 --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output x265.h265 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp9 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp90_420p08le.webm"
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp10 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp100_420p08le.webm"
vpxdec.exe --codec=vp10 --i420 --progress --rawvideo vp100_420p08le.webm -o 111.yuv
Screenshot
ffmpeg.exe -i "orginal.mp4" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot_original.bmp
ffmpeg.exe -i "x264.h264" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot1.bmp
ffmpeg.exe -i "x265.h265" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot2.bmp
ffmpeg.exe -i "vp90_420p08le.webm" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot3.bmp
ffmpeg.exe -s 1920x1080 -pix_fmt yuv420p -i "111.yuv" -q:v 1 -vframes 1 -f image2 -ss 00:00:00.155 -pix_fmt rgb24 -s 1920x1080 screenshot4.bmp
Examples of how someone is interested to "pass=1":
https://www.sendspace.com/file/d33dri

PS. Are there too codecs VP9/VP10 for WebP?

[easyfab]

I have the same pnsr for vp9 and vp10.
It's more like a copy-paste vp9->vp10 preparation for the moment.

To see what vp10 should be the nextgen branch is more appropiate IMO : https://github.com/webmproject/libvpx/commits/nextgen

configure with --enable-experimental --enable-supertx --enable-ext-tx ... and all the experiments you will try

the complete list : https://github.com/webmproject/libvpx/blob/nextgen/configure#L280

[Kurtnoise]

How about creating a new topic for these VP10 builds ;)
Im lazy to do that...if a moderator may split the discussion, that would be great, indeed.

It's nice that there is something new. I did a test and decided that it doesn't have to be now codec VP10.
Too much bitrate, change colorspace, worse quality of the X264, there are no decoder and adapt to anything. Screenshots watched in Honeyview 5.12.

Video
[I]ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x264.exe --demuxer y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --threads 4 --output-csp i420 --preset slower --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --tune stillimage --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range tv --output x264.h264 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
x265.exe --y4m --input-depth 8 --input-csp i420 --input-res 1920x1080 --preset slower --output-depth 8 --fps 25000/1000 --bitrate 4500 --vbv-maxrate 10000 --vbv-bufsize 10000 --keyint 25 --min-keyint 1 --open-gop --ref 1 --bframes 0 --aq-mode 1 --me dia --colorprim bt709 --transfer bt709 --colormatrix bt709 --range limited --output x265.h265 -
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp9 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp90_420p08le.webm"
ffmpeg.exe -y -loglevel warning -i "orginal.MP4" -s 1920x1080 -r 25000/1000 -an -sn -f yuv4mpegpipe -strict -1 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range mpeg - |
vpxenc.exe -v --i420 -w 1920 -h 1080 --threads=4 --passes=1 --pass=1 --profile=0 --cq-level=63 --good --codec=vp10 --fps=25000/1000 --cpu-used=3 --target-bitrate=4500 --color-space=bt709 --kf-min-dist=0 --kf-max-dist=25 --drop-frame=100 --aq-mode=1 - -o "vp100_420p08le.webm"


why such poor command lines ?


I have the same pnsr for vp9 and vp10.
It's more like a copy-paste vp9->vp10 preparation for the moment.

To see what vp10 should be the nextgen branch is more appropiate IMO : https://github.com/webmproject/libvpx/commits/nextgen

configure with --enable-experimental --enable-supertx --enable-ext-tx ... and all the experiments you will try

the complete list : https://github.com/webmproject/libvpx/blob/nextgen/configure#L280
yes, the merge is ongoing...it's not yet finished of course.

[Jamaika]

why such poor command lines ?
I don't know better command lines. I look for better records with samples. I hope that not offended someone my opinion about the codec VP10. It doesn't interest me "pass = 2" for core i8.

[hajj_3]

new interview article about VP10 with a google manager: http://www.cnet.com/news/inside-googles-master-plan-for-faster-sharper-streaming-video/

[foxyshadis]

Unfortunately it's not a technical interview, it's mostly about HEVC's patent problems. I'd like to see an overview of what they're currently putting in it, and how much it helps.

[hajj_3]

Unfortunately it's not a technical interview, it's mostly about HEVC's patent problems. I'd like to see an overview of what they're currently putting in it, and how much it helps.

i think the most interesting part is that it won't be ready until the end of 2016. Google had previously had said that they would release a new version of VP every 18 months, vp10 would therefore have been released 6 months ago, so vp10 will be 1yr and 9 months ish later than they had previously envisioned. Daala is supposed to have an alpha version available at the end of this year. It is possible that the IETF codec by mozilla/cisco could be finished before vp10. Lets hope that google joins the open IETF codec instead as having 2 codecs would be annoying.

[LigH]

... the IETF codec by mozilla/cisco ...

Do you mean Thor?

[mandarinka]

i think the most interesting part is that it won't be ready until the end of 2016. Google had previously had said that they would release a new version of VP every 18 months, vp10 would therefore have been released 6 months ago, so vp10 will be 1yr and 9 months ish later than they had previously envisioned. Daala is supposed to have an alpha version available at the end of this year. It is possible that the IETF codec by mozilla/cisco could be finished before vp10. Lets hope that google joins the open IETF codec instead as having 2 codecs would be annoying.

I doubt netVC will be here earlier than in two years. Look how long Opus standardization took. Daala was supposed to be roughly done almost by this time, according to original plans :)

The plan to make new VP codecs ever 18 months was/is not real I think, I think they later said it was just misinterpreted/misquoted.

[Jamaika]

Google’s new VP10 algorithm to cut online video data in half… again (http://www.htxt.co.za/2015/09/01/googles-new-vp10-algorithm-to-cut-online-video-data-in-half-again/)
I don't know what algorithm is described and why it will not be under the Youtube ? What sort of quality improvement is mentioned ?
Can someone explain?
There is a catch, however; VP10 is only expected to be up and running by the end of 2016, after which it will be up to non-YouTube online video platforms to integrate it into their services.
Advertising codec VP10:
http://otavafiles.fi/plaza/s/f/editor/images/20150819vp10.jpg

[dapperdan]

Do you mean Thor?

Both Mozilla's Daala and Cisco's Thor have been contributed towards the IETF's NetVC codec effort to standardize a new royalty free codec.

Presumably, depending on how the process goes, independent development of either (or both) of those codecs would be discontinued in favour of working on the resulting codec.

[dapperdan]

And relevant to that last point, it looks like Google, Microsoft, Amazon, Netflix, Intel and others have joined in on the fun:

https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/

"Things are moving fast for royalty-free video codecs. A month ago, the IETF NETVC Working Group had its first meeting and two weeks ago Cisco announced Thor. Today, we’re taking the next big step in this industry-wide effort with the formation of the Alliance for Open Media. Its founding members represent some of the biggest names in online video, such as Netflix, Amazon, and YouTube, multiple browser vendors including Mozilla, Microsoft, and Google, and key technology providers like Cisco and Intel. The Alliance has come together to share technology and run the kind of patent analysis necessary to build a next-generation royalty-free video codec."

[LigH]

[img] {more or less pretty flowers}

:rolleyes: An over-simplified and idealized schematic presentation. How dubious.

[foxyshadis]

http://otavafiles.fi/plaza/s/f/editor/images/20150819vp10.jpg

Oooh, it's the difference between QCIF, SD, and 4K (conveniently skipping HD), but I'm not sure what that has to do with the VPx family.

[dapperdan]

Possibly as a result of the new royalty-free codec alliance thing, Microsoft has just commited to adding VP9 to Internet Explorer:

http://dev.modern.ie/platform/status/vp9videocodec/

Current status: "In Development"

[benwaggoner]

So, where the heck can I get a current Windows binary for vpxenc? I see it's in Staxrip and ffmpeg, but is there an actual .exe anywhere?

[LigH]

The media-autobuild_suite by jb_alvarado will build it for you. I just don't have my development PC available right now, so not before tomorrow...

[Jamaika]

So, where the heck can I get a current Windows binary for vpxenc? I see it's in Staxrip and ffmpeg, but is there an actual .exe anywhere?
Someone upset? I didn't dare ask such questions.
Selur adds codec vpxenc v1.4.0-1171. Currently codec vp10 has been turned off. There isn't need to turn it on
Possibly as a result of the new royalty-free codec alliance thing, Microsoft has just commited to adding VP9 to Internet Explorer:
How install codec vpx to Edge?

[Nintendo Maniac 64]

And relevant to that last point, it looks like Google, Microsoft, Amazon, Netflix, Intel and others have joined in on the fun:

https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/

Seems to me like they're not happy about the whole "HEVC Advance" thing.

[VDO2015]

With MPEG-LA announcing a call for patents for MPEG-DASH, I think that AOMedia's appetite is greater than codecs.


Sent from my iPad using Tapatalk

[Reel.Deel]

So, where the heck can I get a current Windows binary for vpxenc? I see it's in Staxrip and ffmpeg, but is there an actual .exe anywhere?

Here:VP10 code has been merged to the main branch (https://github.com/webmproject/libvpx/commits/master) few days ago...

Here are some fresh windows builds for testing : x86 (http://www.mediafire.com/download/7z88x93rtk4tkgg/vpx-1.4-1119_x86_20150815.7z)|x64 (http://www.mediafire.com/download/cdjkpvoaa7olxko/vpx-1.4-1119_x64_20150815.7z)

There's also older versions (http://forum.doom9.org/showthread.php?t=165839&page=32#post1716013) earlier in the thread.

[Koti]

vpx.enc built from /libvpx/master @ e5732bc (x64) (win64-vs11)
includes vp10

https://www.mediafire.com/?mcbtahae8dmjqx4

[LigH]

A pity the media-autobuild_suite seems to be broken today, should not have updated. Maybe I can downgrade from the repo.

VP10 sources may have got merged. But we already guessed that they are not yet completely functional. Rather a preparation of required changes for structures.

[LigH]

Apparently, the VP10 codec has to be enabled before compiling. Unfortunately I don't understand how, the "configure" script keeps resetting to the default disabling VP10 when I run the media-autobuild_suite, even if I add switches enabling VP10 explicitly.

[Kurtnoise]

vp10 is not yet ready for testing...that's why this has been disabled now whatever you run in configure.

[MoSal]

Untested win64+win32 binaries with VP10 enabled.
(Built under GNU/Linux with: mingw-w64 4.0.4, GCC 5.2.0).

https://archive.org/download/Vpx-win32win642015.09.03/vpx-win32+win64(2015.09.03).zip

[leonccyiu]

If google are going to release a new codec roughly every 18 months, then what about hardware acceleration? We don't even have vp9 yet which may not arrive until pascal or kaby lake next year at the earliest, would vp10 build upon vp9 and therefore allow a hybrid decode where the vp9 hardware decoder parts which can be used are used in conjunction with the cpu?

[hajj_3]

If google are going to release a new codec roughly every 18 months, then what about hardware acceleration? We don't even have vp9 yet which may not arrive until pascal or kaby lake next year at the earliest, would vp10 build upon vp9 and therefore allow a hybrid decode where the vp9 hardware decoder parts which can be used are used in conjunction with the cpu?

there will be no VP10 codec anymore, there will be a codec created by multiple companies instead.

[foxyshadis]

there will be no VP10 codec anymore, there will be a codec created by multiple companies instead.

That's not confirmed, Google may well simultaneously develop VP10 and the Open Media codec, or whatever they end up calling it. VP10 is already in progress, while the Open Media will be a larger fusion of different efforts and take a while. In fact, as far as I can tell Google has made no public comment on the Alliance at all.

[BadFrame]

That's not confirmed, Google may well simultaneously develop VP10 and the Open Media codec, or whatever they end up calling it.

Well, before the Alliance statement the VP10 encoder/decoder was included in the master repo checkouts (I know, as I built and tested it myself), after said statement the VP10 codec was no longer included.

Not exactly a smoking gun, but I wouldn't be surprised to find the VP10 branch shortly renamed to whatever the Alliance choose as their codec name.

In fact, as far as I can tell Google has made no public comment on the Alliance at all.

The 'Alliance' (which includes Google) had a joint statement where they outlined their goals, and that did include a statement from Google's Matt Frost:

-"Google launched the WebM Project in 2010 in the belief that web video innovation was too slow and too closed, and that broad collaboration — in the open — would fix both problems. The Alliance for Open Media is a big leap forward for these core philosophies, and we’re gratified that our AOMedia partners share this vision. Our combined strength, resources and expertise will drive the next generation of web media experiences much further and faster than WebM can do alone"

[LigH]

Because VP10 is not yet "ready", LAV Filters are not yet prepared to decode it either; just tried to encode some with MoSal's build, and MPC-HC skipped it immediately.

[GTPVHD]

http://blogs.windows.com/msedgedev/2015/09/08/announcing-vp9-support-coming-to-microsoft-edge/

[dapperdan]

I assumed Opus support would already be in place thanks to their work on WebRTC. Instead they're starting with VP9 and AAC via MSE. I guess that means either (or both) of Amazon and Netflix have said that's what they're going to serve in the short term?

Actually they just announced Dolby Digital Plus support a few months ago, basically just for Netflix, so that might be why?

[Nintendo Maniac 64]

Actually Microsoft's lack of support for Opus is quite strange since it is the evolution and the SILK and CELT codecs and SILK was developed by and for Skype.

[nevcairiel]

Microsoft is strongly considering Opus, and judging from their roadmap priority, it should probably happen eventually.
http://dev.modern.ie/platform/status/opusaudiocodec/

[BadFrame]

Because VP10 is not yet "ready", LAV Filters are not yet prepared to decode it either; just tried to encode some with MoSal's build, and MPC-HC skipped it immediately.

VP9 was not yet "ready" when they included in the master branch and there wasn't any decode support in any players.

This is why you have vpxdec, which allows you to decode the stream into a lossless format so that you can see the result.

So whatever the reason VP10 was pulled from master, I'm pretty certain that's not it (as it certainly was not the case with VP9).

[Kurtnoise]

http://blogs.windows.com/msedgedev/2015/09/08/announcing-vp9-support-coming-to-microsoft-edge/

Microsoft is strongly considering Opus, and judging from their roadmap priority, it should probably happen eventually.
http://dev.modern.ie/platform/status/opusaudiocodec/

Only available through the browser ? What a shame...

[mzso]

Only available through the browser ? What a shame...

Since that website is for Edge it's not surprising they don't mention anything else. Who knows what they're planning for windows...

[Jamaika]

Since that website is for Edge it's not surprising they don't mention anything else. Who knows what they're planning for windows...
It is now lock decoders for "Films and TV" and "WMP". The security don't omit in a simple way, eg. registering in Windows decoder MPC-BE.
I don't expect too rapid implementation VP9. So, I installed the player MPC.

[dapperdan]

I noticed this page got updated recently:

http://compression.ru/video/codec_comparison/call_for_codecs_15.html

The report (which I think was originally due last month) is now due for public release in a couple of weeks time.

[Nintendo Maniac 64]

Darn, too bad it seems that the tests were confirmed before the Broadwell and Skylake launched...

[Jamaika]

Who knows functions VP9 and X264?
Is the function --tune-content screen equivalent --tune stillimage?

[foxyshadis]

Who knows functions VP9 and X264?
Is the function --tune-content screen equivalent --tune stillimage?

It's closer to --tune animation, being designed for lots of sharp edges. But I don't know how it performs relatively.

[mandarinka]

https://www.youtube.com/watch?v=gkz1ZvejmEc

Talk about stuff intended or tested/investigated for VP10 from VDD 2015. Apparently the final format is fairly remote at this point in time, the slides also mention that some "new big ideas" are needed for it in addition to conventional boosts like 64x64 transforms, better intra, and raised internal and/or real bitdepth.

[Nintendo Maniac 64]

Here's another video from the same event that compares VP9 encoding and decoding performance to AVC and HEVC:
https://www.youtube.com/watch?v=_Q6J2_nvLSI

On a similar note, here's something interesting: the 1080p VP9 YouTube encode for the VP10 presentation mandarinka linked to is 206MB while the 1080p AVC YouTube encode is 806MB! And it's not a one-time fluke either - the Daala and Thor videos at the same event all have a similar filesize discrepancy, yet for the video I just linked above the filesize difference for 1080p is "only" 273MB (VP9) vs 457MB (AVC)...

I haven't watched this video nor the Daala, Thor, or VP10 videos just yet, so at this point in time I have no idea why this considerably smaller-than-normal difference in filesize is in fact occurring.

----------------------------------------------------------------

MS Edge officially has VP9 support now (not enabled by default):
http://www.ghacks.net/2015/09/23/enable-vp9-in-microsoft-edge-for-better-html5-streaming-support/

However, the fact that the setting is located under "Media Source Extensions" makes me curious if Edge only supports VP9 via MSE...

Could someone on Windows 10 test out the VP9/WebM video from the following website in Edge and report back? For reference the WebM file only has a VP9 stream - there's no audio stream (I checked via mkvtoolnix):
http://base-n.de/webm/VP9%20Sample.html

Direct link to the video file if you need it:
http://base-n.de/webm/out9.webm

[mandarinka]

The size discrepancies might be largely unintentional. Libvpx's rate control for VP9 is very inacurate and can drastically overshoot or undershoot. Of course quality is a whole different thing, that 806MB video is going to look tons better, unless YT is totally f...ing up (which is possible of course, their encodes were never very good).

[jmartinr]

Could someone on Windows 10 test out the VP9/WebM video from the following website in Edge and report back? For reference the WebM file only has a VP9 stream - there's no audio stream (I checked via mkvtoolnix):
http://base-n.de/webm/VP9%20Sample.html
It says "Invalid Source"

[Nintendo Maniac 64]

It says "Invalid Source"

And that's with VP9 enabled in Edge, correct?

Hopefully this is just because they don't have support for the webm container yet...

[jmartinr]

And that's with VP9 enabled in Edge, correct?.
Sorry, I totally missed that.

There's no entry "Media Source Extensions" on my Edge (20.10240.16384.0). Maybe the new version is not pushed yet?

[mandarinka]

Yeah, IIRC it was only in insider builds or something like that (you don't really expect them to push it so fast, do you. I'm not sure if there has even been an Edge update on the WU at all, since the support was announced).

[Nintendo Maniac 64]

Well the article clearly states that the option is present as of Insider build 10547 in the very first sentence...

[leonccyiu]

Here's another video from the same event that compares VP9 encoding and decoding performance to AVC and HEVC:
https://www.youtube.com/watch?v=_Q6J2_nvLSI

On a similar note, here's something interesting: the 1080p VP9 YouTube encode for the VP10 presentation mandarinka linked to is 206MB while the 1080p AVC YouTube encode is 806MB! And it's not a one-time fluke either - the Daala and Thor videos at the same event all have a similar filesize discrepancy, yet for the video I just linked above the filesize difference for 1080p is "only" 273MB (VP9) vs 457MB (AVC)...

I haven't watched this video nor the Daala, Thor, or VP10 videos just yet, so at this point in time I have no idea why this considerably smaller-than-normal difference in filesize is in fact occurring.

----------------------------------------------------------------

MS Edge officially has VP9 support now (not enabled by default):
http://www.ghacks.net/2015/09/23/enable-vp9-in-microsoft-edge-for-better-html5-streaming-support/

However, the fact that the setting is located under "Media Source Extensions" makes me curious if Edge only supports VP9 via MSE...

Could someone on Windows 10 test out the VP9/WebM video from the following website in Edge and report back? For reference the WebM file only has a VP9 stream - there's no audio stream (I checked via mkvtoolnix):
http://base-n.de/webm/VP9%20Sample.html

Direct link to the video file if you need it:
http://base-n.de/webm/out9.webm

While I get Invalid source for the link you sent me, and the direct video link gets downloaded to the hard drive, I can confirm that after enabling vp9 in Microsoft Edge on Insider Build 10547, YouTube uses vp9.

I can take a screenshot and upload it if you'd like.

Microsoft Edge is quite CPU intensive, I am using a Pentium G3258, with several tabs opens, CPU usage hovers around 50%, on avc on YouTube, CPU usage doesn't vary much and I can't hear the CPU fan much, but once I switched to VP9, the CPU fan kicked in, so I definitely know it's VP9.

[leonccyiu]

The size discrepancies might be largely unintentional. Libvpx's rate control for VP9 is very inacurate and can drastically overshoot or undershoot. Of course quality is a whole different thing, that 806MB video is going to look tons better, unless YT is totally f...ing up (which is possible of course, their encodes were never very good).

Actually, I prefer the VP9 version, I used pot player to switch between the two streams, I notice less artefacts in the shadow detail of the mans face.

If anything though, YouTube's bit-rates are far too low, 1080p looks blurred, watching 4k downscaled looks like proper 1080p. I notice that for 4k, the situation is reversed, the vp9 versions are more often larger than the h264 versions.

[dapperdan]

http://x265.org/wp-content/uploads/2015/09/Figure-145-Ripping.png

Sneak peak of the MSU results, posted by x265 in another thread http://forum.doom9.org/showthread.php?t=168814&page=136

Makes me wonder how well an xvp9 encoder would do.

[MoSal]

Sneak peak of the MSU results, posted by x265 in another thread http://forum.doom9.org/showthread.php?t=168814&page=136


Are we going to pretend that those results are somehow relevant subjectively?


Makes me wonder how well an xvp9 encoder would do.

Why would this imaginary encoder be significantly better? libvpx is already tuned for SSIM.

Using different parameters in libvpx might give interesting results, if you are really keen on micro-tuning for SSIM.

This generation of codecs will probably be skipped by those of us who are looking for subjectively transparent results.

[mandarinka]

Does VP9 encoding in libvpx have any significant psyopts now? (x265 does though, so if anything, objective metrics should be helping VP9)

[MoSal]

Does VP9 encoding in libvpx have any significant psyopts now? (x265 does though, so if anything, objective metrics should be helping VP9)

IIUC, developers were asked to provide their tuning parameters for each metric. Those parameters were used as long as they didn't break speed constraints.

So, the claim that x265's results were crippled somehow by their psy opts is false, IMHO.

[mandarinka]

IIUC, developers were asked to provide their tuning parameters for each metric. Those parameters were used as long as they didn't break speed constraints.

So, the claim that x265's results were crippled somehow by their psy opts is false, IMHO.

But that is not what I meant. SSIM/PSNR is something like a base tuning of the codec that is easier to achieve quality in, because all your experimenting has easily evaluatable results. But the psyopts add quality on top of that, so when two codecs are tied on metrics but one has psy that can be enabled on top of that and the other has not, the first is going to be much better perceptually.

[MoSal]

But that is not what I meant. SSIM/PSNR is something like a base tuning of the codec that is easier to achieve quality in, because all your experimenting has easily evaluatable results. But the psyopts add quality on top of that, so when two codecs are tied on metrics but one has psy that can be enabled on top of that and the other has not, the first is going to be much better perceptually.

And we are back to square one!

The claim of added value implies the relevance of the common base. And metrics are irrelevant in the context of subjective quality.

Subjective quality should be judged visually. Preferably with double-blind tests if the lossy result is thought to be visually transparent. There is no need to promote other factors into relevance here.

[dapperdan]

Blog post that corresponds to the video talk posted a few days ago:

https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

[CruNcher]

Are we going to pretend that those results are somehow relevant subjectively?



Why would this imaginary encoder be significantly better? libvpx is already tuned for SSIM.

Using different parameters in libvpx might give interesting results, if you are really keen on micro-tuning for SSIM.

This generation of codecs will probably be skipped by those of us who are looking for subjectively transparent results.

I wouldn't say that even grain retention looks in some pretty decent for the bitrate in Motion :)

but to reach that you have to invest x orbitant of more speed/power currently, though some invested those already before in their preconstruction so now they have it more efficient in 1 step ;)

The more interesting question will be how efficient will be the upcoming Hardware Encoder/Decoder for each Codec compared to the CPU results, we are seeing now ;)

FPGA,DSP,HSA you name it ;)

[Jamaika]

I have a question. Where to download the plugin WebM VPX for quicktime?
https://github.com/webmproject/webmquicktime/commits/master

How to correctly perform the conversion yuv4mpegpipe on ffmpeg for depth 10bit? (http://forum.videohelp.com/threads/374452-The-problem-with-converting-ffmpeg)

[iwod]

I haven''t been following the codec development, But in my (gosh) old days, VP8 were suppose to be slightly better then H.263 and VP9 would rival H.264, then VP10 or VPx they are working on to compete against H.265. VP8 wasn't good enough, and VP9 never matched x.264 despite all the marketing tell you otherwise.

Now i am seeing many proclaim VP9 is better then x.264 and is competing against H.265. What ever VP10 / x?
And has VP9 really gotten that much better? Most site still uses PNSR or SSIM which to me is like benchmarks number that you cant trust without context.

Any one has done any recent Picture quality testing? I did google search and nothing new came up.

[Tommy Carrot]

I haven''t been following the codec development, But in my (gosh) old days, VP8 were suppose to be slightly better then H.263 and VP9 would rival H.264, then VP10 or VPx they are working on to compete against H.265. VP8 wasn't good enough, and VP9 never matched x.264 despite all the marketing tell you otherwise.

Now i am seeing many proclaim VP9 is better then x.264 and is competing against H.265. What ever VP10 / x?
And has VP9 really gotten that much better? Most site still uses PNSR or SSIM which to me is like benchmarks number that you cant trust without context.

Any one has done any recent Picture quality testing? I did google search and nothing new came up.

VP9 is better than x264 at low bitrates (though it still loses to x265), so for youtube, it's probably better, especially for game footages. However, x264 is still unbeatable for high quality, near transparent encodings.

[LigH]

^ A similar opinion existed years ago between MPEG-2 and MPEG-4 Part 2 (ASP as e.g. DivX). Coincidence or logical? ... Well, x265 is not yet "final". Neither is VP10. Stay curious! :)

[Nintendo Maniac 64]

Maybe iwod is confusing MPEG-4 Part 2 with h.263 due to the fact that the former used the latter as a basis? If you had a player that could only decode MPEG-4 Part 2, you would be able to play an h.263 video stream just fine, but a player that could only decode h.263 cannot decode MPEG-4 Part 2.

Anyway, it was my understanding that VP8 was more on level with VC-1 or h.264 baseline.

especially for game footages

For one thing, when VP9 doesn't have enough bitrate it becomes blurry while when AVC doesn't have enough bitrate it becomes blocky or pixelated, and for motion content the blurriness looks much more natural than the blockiness for obvious reasons.

One can kind of compare it between MP3 and Vorbis at low bitrates - MP3 will have distinctly digital-sounding artifacts while Vorbis just sounds muffled.

[leonccyiu]

Blog post that corresponds to the video talk posted a few days ago:

https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

Firstly, I can confirm on the latest windows insider build the internal video player plays back vp9, however judging from cpu usage, it's using the libvpx decoder. So is Microsoft Edge and Firefox.

This is highly frustrating as looking at Ronald's graph, it's clear to see ffvp9 is light years ahead of libvpx on fps, it makes an absolute huge difference. So many people are using older computers and while 1080p is easily decoded by my cpu, for others it can slow down their systems. 4k30 doesn't play back with libvpx, 1440p is stuttery on my pentium g3258 at 4.3ghz, but with ffvp9, 4k60 videos play back at around 35-60fps, a minor stutter here and there but such an amazing difference compared to the libvpx decoder. 4k30 plays back smoothly with the exception of scenes which reach 50mbps according to potplayer, these are more likely to be 4k videos shot on smartphones which have a very deep depth of field from their small sensors.

I reported the issue to google, but as expected got no reply. They really badly need to do something about their decoder if uptake of vp9 is to become more widespread.

[NikosD]

Latest Windows 10 Build 10565 has removed temporarily WebM and VP9 support .


WebM and VP9 have been temporarily removed from the flight builds.
We continue to develop a VP9 implementation that we intend to ship in Windows.
Expect VP9 to return soon in a future release.

[NikosD]

Meanwhile, Microsoft released 6 days ago the specifications for HW DXVA acceleration of VP8 and VP9 profile 0 (8bit , 4:2:0)

Details here:
http://www.microsoft.com/en-us/download/details.aspx?id=49188&WT.mc_id=rss_windows_allproducts

[Nintendo Maniac 64]

Compression.ru's 2015 video encoder test results were released:
http://compression.ru/video/codec_comparison/hevc_2015/

Included and most likely to be of interest are VP9, x265, and x264.

[dapperdan]

Is there not usually a download link for a free report too?

edit: the free version is there now

[LigH]

Has it not already been discussed here in the x265 thread? I remember that luminance only values were displayed with images. — There (http://forum.doom9.org/showthread.php?p=1740028#post1740028).

[Nintendo Maniac 64]

Has it not already been discussed here in the x265 thread? I remember that luminance only values were displayed with images. — There (http://forum.doom9.org/showthread.php?p=1740028#post1740028).

That was actually before the report was officially released; the x265 guys basically were given a sneek preview that they were allowed to share.

[dapperdan]

I've just read the free report, is there an explanation as to why VP9 only appeared in the "ripping" test, and not the others?

[CruNcher]

Pretty sad that Ateme is not contributing anymore their Titan Broadcast encoder seems pretty popular :D

[foxyshadis]

I've just read the free report, is there an explanation as to why VP9 only appeared in the "ripping" test, and not the others?

Because VP9 couldn't hit the 30+fps targets that the other profiles required, apparently. VP9 doesn't massively scale in an individual encode, it relies on massive scale of many encodes. Their statement: "It is definitely possible to incorporate more computing resources to significantly speedup the VP9 encoding process while achieving the same compression statistics. As an open source project, we certainly welcome contributions from the video coding community to make it happen."

Obviously, having 4-5 videos running at once on the 32-core test system probably would have been a better approximation of Youtube's workload, but that's not very applicable for many users.

[dapperdan]

I'm not sure 32-cores encoding a single video is particularly representative for many users either.

It would be nice to have some official confirmation on what exactly happened, e.g. did Google provide settings that just failed to hit the target they were set and so were disqualified, or did Google simply refuse to compete in that category because they thought the quality they would get would be embarrassing until they'd done more tuning for that use case, or ... ?

I can't quite figure out how they can have done so well in terms of speed/ssim for the ripping comparison if the number of cores was the fundamental issue.

[Motenai Yoda]

Because VP9 couldn't hit the 30+fps targets that the other profiles required, apparently.

But it does with high cpu-used or with deadline on realtime
It can be even faster than x265 on ultrafast

[Jamaika]

I wanted to ask is there any viewer to codec VP10?

[LigH]

There is not even a complete encoder yet, I believe; only source code adapted from VP9 and prepared to contain VP10 code later on, during its development and release... The last time I tried to build vpxenc, disabling the VP10 encoder was enforced by the configure scripts, one would have to manually patch configuration files in between configuring and making.

[Jamaika]

Some manufacturers add to their codec and I thought that here also find some primitive vpxview.exe.
I don't understand why the colormatrix vpxenc sRGB is equal to the BT709? At least in HEX it looks like that.
I don't understand why the vpxdec a record --rawvideo is equal to the --i420?
I understand that these features will only be created in future.

[BadFrame]

There is not even a complete encoder yet, I believe; only source code adapted from VP9 and prepared to contain VP10 code later on, during its development and release...

Actually development on VP10 is ongoing and the encoder is up and running, for example Ronald Bultje (of ffmpeg, x264 fame) is working for Google on it:

https://chromium.googlesource.com/webm/libvpx/+log/HEAD?5ce15400

Also it's in the main development branch now, but you still need to enable it with '--enable-vp10' when configuring.

[LigH]

If that's the case, then the media-autobuild_site team may try to insert a config patch when desired... I'll notify them.
__

Too late, vpxenc built with media-autobuild_site already contains VP10.

Included encoders:

vp10 - WebM Project VP10 Encoder v1.4.0-1579-gd162934
vp8 - WebM Project VP8 Encoder v1.4.0-1579-gd162934
vp9 - WebM Project VP9 Encoder v1.4.0-1579-gd162934 (default)

[Motenai Yoda]

If that's the case, then the media-autobuild_site team may try to insert a config patch when desired... I'll notify them.
http://forum.doom9.org/member.php?u=48461

[LigH]

Too late, vpxenc built with media-autobuild_site already contains VP10.

Everything is fine. :cool:

[Jamaika]

Where can I download a codec VPX v1.4.0-1579 or newer?

[LigH]

While I do so, you may as well use the media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite/) and configure it so that only VPX binaries will be built (to re-configure, delete or rename build\media-autobuild_suite.ini).
__

vpx v1.4.0-1652-gd7bbe1a (https://www.mediafire.com/download/677k1iqbaw360rc/vpx_v1.4.0-1652-gd7bbe1a.7z) (MSYS2 GCC 5.2.0, Win32+Win64)

Included encoders:

vp10 - WebM Project VP10 Encoder v1.4.0-1652-gd7bbe1a
vp8 - WebM Project VP8 Encoder v1.4.0-1652-gd7bbe1a
vp9 - WebM Project VP9 Encoder v1.4.0-1652-gd7bbe1a (default)

[Jamaika]

Thanks. Do somewhere is manual as it compile? I install media-autobuild_suite and don't know what to do next.

[LigH]

Run the batch file: media-autobuild_suite.bat; that should guide you through a first time setup (select which kind of environment to install and which tools to compile in which flavours), download and install an MSYS / MinGW environment with GCC, download sources, compile them, copy results to local32 or local64 subdirectories ... full automatic success, as long as there are no source code bugs.

[mindwin]

Javan Whistling Duck Release v1.5.0
https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/0rjNpFerYs8

What's new?
- The above codec controls
- Substantially improved VP9 encoding speed and quality
- Improvements to VP9 decode speed including algorithmic changes to the multi threaded decoder.

What's not in this release?
- VP10. The vp10/ directory has been removed from the release branch. Please explore the master and nextgenv2 branches if you are interested in VP10 development.
- While many improvements have been made for vp9 realtime encoding there are many more ongoing and so we encourage people interesting in this use-case to submit changes to the master branch.

[Jamaika]

My thoughts on the codec VP9 1.5.0 included in ffmpeg.
http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20151111-git-edd0c1d-win64-static.7z
ffmpeg.exe -loglevel verbose -i "input.mts" -s 1920x1080 -r 50000/1000 -an -sn -f webm -c:v libvpx-vp9 -vb 4700k -cpu-used 1 -aq-mode 0 -threads 4 -deadline best -quality 100 -g 25 -pix_fmt yuv420p "output_vp90_v1.5.0.webm"
I don't like the codec description for function "verbose". It isn't known which performs converter ffmpeg.
[libvpx-vp9 @ 000000750a6900a0] v1.5.0
[libvpx-vp9 @ 000000750a6900a0] --target=x86_64-win64-gcc --prefix=/home/kyle/software/ffmpeg/pkgs/libvpx/libvpx-1.5.0-win64 --enable-runtime-cpu-detect
Output #0, webm, to 'output_vp90_v1.5.0.webm':
Metadata:
encoder : Lavf57.14.100
Stream #0:0: Video: vp9 (libvpx-vp9), 1 reference frame, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 4700 kb/s, 50 fps, 1k tbn, 50 tbc
In the end can set the "-quality" using percentages:
Good = 75%
Best = 100%
The problem is that I don't see quality improvements. The converter acts as if nothing has changed.

[markanini]

Just a heads up for firefox users, you have to toggle enable for media.mediasource.webm.enabled in about:config to view youtube videos as VP9.

[foxyshadis]

My thoughts on the codec VP9 1.5.0 included in ffmpeg.

Are the speed improvements vs 1.4.0 true? Also, any improvements in rate control? I can't test right now.

[Nintendo Maniac 64]

Just a heads up for firefox users, you have to toggle enable for media.mediasource.webm.enabled in about:config to view youtube videos as VP9.

This is not new...also we have a dedicated thread regarding VP9 videos on YouTube.

[Jamaika]

In the end can set the "-quality" using percentages:
Good = 75%
Best = 100%
The problem is that I don't see quality improvements. The converter acts as if nothing has changed.
These functions aren't working. You should only use these with the specifications vpxenc.:!:
http://i64.tinypic.com/2mqmc81.jpg
-quality <int> E..V.... (from INT_MIN to INT_MAX) (default good)
best E..V....
good E..V....
realtime
I don't see changes in improving the speed for quality equal best. Computer practically stands.):

[MoSal]

I don't see changes in improving the speed for quality equal best. Computer practically stands.)

What were your expectations?

VPx developers explicitly recommend against using 'best'. All it does is slowing things down. And it's not even guaranteed to improve quality.

I can tell you with confidence that (almost) zero testing went into 'best' while developing VP9.

Increase '-speed' if you want faster encodes with less compression efficiency.

[Jamaika]

What were your expectations?
Hmm..., better sharpen the image, quick conversion and a lack the checkered in frames B.
http://i68.tinypic.com/2ypdlvt.jpg
Photo for the "good" and "cpu-used=1", fullhd, 4700kbps. Lack of intermediate option between "good" and "best".

[MoSal]

Hmm..., better sharpen the image, quick conversion and a lack the checkered in frames B.
...
Photo for the "good" and "cpu-used=1", fullhd, 4700kbps. Lack of intermediate option between "good" and "best".

For starters, why are you passing '-g 25'?
You know what that option means, right?

[Jamaika]

It's GOP (https://en.wikipedia.org/wiki/Group_of_pictures).
Why don't I use a long GOP?
I wanted to have a better opportunity to scroll 1 minute video in the player.
Intra frames, also known as "I" frames, are sometimes described as key frames because they are suitable for navigation points in the video. In order to skip forwards or backwards the user only has to decode the I frames. For inter coded frames, the user must find the most recent I frame, decode it, decode any other reference frames, then decode all the inter frames up to the desired frame. (http://www.tiliam.com/Blog/2015/07/06/effective-use-long-gop-video-codecs)

[MoSal]

It's GOP (https://en.wikipedia.org/wiki/Group_of_pictures).
Why don't I use a long GOP?
I wanted to have a better opportunity to scroll 1 minute video in the player.
Intra frames, also known as "I" frames, are sometimes described as key frames because they are suitable for navigation points in the video. In order to skip forwards or backwards the user only has to decode the I frames. For inter coded frames, the user must find the most recent I frame, decode it, decode any other reference frames, then decode all the inter frames up to the desired frame. (http://www.tiliam.com/Blog/2015/07/06/effective-use-long-gop-video-codecs)

You realize that value is in frames, not seconds, right?

[LigH]

Short GOPs will be useful for compatibility with consumer devices like Blu-ray players. But VPx has no consumer player target, and GOPs of 25 frames for 50 fps material will cause half-second GOPs, that's certainly not very efficient. The more I frames a video contains, the less bitrate can be spared by predictions (I frames need a magnitude more space than P or even B frames).

[mzso]

You realize that value is in frames, not seconds, right?

What makes you think he doesn't? Going above 30 starts to suck for seeking even for h264 here.
The typical big GOPs can be really annoying if you tend to seek a lot.

25 second would be just ridiculous and horrible. (With very little gain)

[Jamaika]

@LigH
We wrote theory. Let's get to the facts.
What can I enter minimal good GOP for movies 25, 50,100 fps now?
For me the default GOP=250 for vpx is too large.

PS. No problem with GOP=25 for X265.

[huhn]

I don't understand why the colormatrix vpxenc sRGB is equal to the BT709? At least in HEX it looks like that.

the colormatric is equal the difference is the transfer(gamma) between sRGB and BT709

[Jamaika]

This is true.
Changing the color matrix (RGB <-> YUV_bt709) in codec BPG(X265) gives a complete change in the recording compression.
For VP9 record it is almost the same in HEX. Unless that RGB is also bt709.
http://i64.tinypic.com/14juebq.png
https://www.sendspace.com/filegroup/H%2FCXE9aJ2azF0F6zVclLNEjYZbXOBNSB
vpxenc.exe --aq-mode=1 --verbose --threads=4 --i444 --profile=1 --best --codec=vp9 --fps=25000/1000 --cpu-used=1 -w 3840 -h 2160 --passes=1 --pass=1 --drop-frame=0 --end-usage=q
--color-space=bt709/sRGB - -o "vp90_1.5.0-110_bt709/sRGB.webm"
bpgenc.exe -v -q 0 -e x265 -f 444 -c ycbcr_bt709/rgb -limitedrange -b 8 -m 9 -keepmetadata "input_RGB.png" -o "x265_0.9.6_yuv444_bt709/sRGB.bpg"

[foxyshadis]

Well you're not inputting rgb into vpxenc are you? (Hard to tell, since it's piped in.) The color-space is just a tag in the file to facilitate proper decoding to rgb, assuming the decoder doesn't just ignore it. If you input yuv and tell the encoder it's rgb, or vice versa, it'll be decoded all wrong.

BPGenc is nice enough to convert to yuv if you specify bt709 when it knows you're inputting rgb, of course it would be completely different.

[benwaggoner]

@LigH


We wrote theory. Let's get to the facts.


What can I enter minimal good GOP for movies 25, 50,100 fps now?


For me the default GOP=250 for vpx is too large.





PS. No problem with GOP=25 for X265.



Well, the shorter the GOP the lower the compression efficiency, and the greater the risk of key frame strobing. H.264/H.265 have pretty rich reference list features that let a decoder skip lots of B-frames when seeking. Something like that is theoretically possible in VP9 using alt-ref frames, but I don't know if it has been implemented in the existing encoders or decoders.



If you look at a typical Long GOP encode in x264/x265, you get mainly B-frames or b-frames, which means most frames don't need to be decoded when seeking far into the GOP. Mainly just the P-frames.

[Jamaika]

The color-space is just a tag in the file to facilitate proper decoding to rgb, assuming the decoder doesn't just ignore it.
It's true but I haven't seen a decoder and viewer for VP9 sRGB.
FFplay/MPC-BE/LAVsplitter it reads as follows::(
Stream #0:0(eng): Video: vp9 (Profile 1), gbrp(pc, gbr/unknown/unknown), 3840x2160, SAR 1:1 DAR 16:9, 1k tbr, 1k tbn, 1k tbc (default)
Something like that is theoretically possible in VP9 using alt-ref frames, but I don't know if it has been implemented in the existing encoders or decoders.
I gave up and will not be inquired what was missing.

[LigH]

Something like that is theoretically possible in VP9 using alt-ref frames, but I don't know if it has been implemented in the existing encoders or decoders.

At least the CLI option is available in my last released version, v1.4.0-1652-gd7bbe1a:

VP9 Specific Options:
...
--auto-alt-ref=<arg> Enable automatic alt reference frames

But I don't know if it changes the output.

[Motenai Yoda]

IIRC --auto-alt-ref works on 2 pass only

[MoSal]

@LigH
We wrote theory. Let's get to the facts.
What can I enter minimal good GOP for movies 25, 50,100 fps now?
For me the default GOP=250 for vpx is too large.

PS. No problem with GOP=25 for X265.


kf_max_dist is not set to a default 250 in ffmpeg. That's probably why you had problems with seeking. There should be no seeking issues if you actually pass '-g 250' and force an intra frame every 5 seconds.

[Jamaika]

This isn't the cause. This effect alone in the same frame for GOP=250.
Tested on decoders MPC-BE 1.4.6.935 and LAV Video 0.66.

[MoSal]

This isn't the cause. This effect alone in the same frame for GOP=250.
Tested on decoders MPC-BE 1.4.6.935 and LAV Video 0.66.

Works for me in mpv(GNU/Linux system). Seeking between keyframes is fast. Accurate seeking is a little bit slow, but nothing drastic.

[xyzone]

I wonder about yuv422, yuv444, and 10-bit+ vp9 encodes of profile 2 and 3. It doesn't seem like anything but profile 0 yuv420 is getting much hardware support. yuv422 would suit some of my purposes better, since heavy contrast reds tend to stay sharper, but strangely enough, even chrome only supports yuv444, but not even yuv422 in profile 0. I've done some experiments with 10-bit vp9 (yuv420), and in some cases there is some efficiency advantages when encoding very flat and still content. So is there any point of encoding in the more exotic vp9 profiles and pixel formats, or they're DOA as far as potential hardware support?

[nevcairiel]

but strangely enough, even chrome only supports yuv444, but not even yuv422 in profile 0.

Anything but yuv420 is invalid in profile 0, you would need profile 1 for 422/444, and profile 2/3 for 10-12 bits

[Jamaika]

I've done some experiments with 10-bit vp9 (yuv420), and in some cases there is some efficiency advantages when encoding very flat and still content.
In my opinion, it makes sense to have a monitor 10-bit.
I hear too of the opinion that only layman makes films 10-16bit. The human eye is unable to perceive more colors than in the movies 8bit.

PS You cann't convert lossless quality of yuv420 on yuv444 or rgb!
You cann't convert lossless quality of bt709 on bt2020!

[xyzone]

Anything but yuv420 is invalid in profile 0, you would need profile 1 for 422/444, and profile 2/3 for 10-12 bits

You're right. I was talking about 422 in profile 1. Chrome can't play it, but it can 444.

[xyzone]

In my opinion, it makes sense to have a monitor 10-bit.
I hear too of the opinion that only layman makes films 10-16bit. The human eye is unable to perceive more colors than in the movies 8bit.

PS You cann't convert lossless quality of yuv420 on yuv444 or rgb!
You cann't convert lossless quality of bt709 on bt2020!

It's supposed to be about more efficient compression (of flat content), not higher baseline in quality. I have no idea if it's true, but I've seen this argument a lot coming from 10-bit h264 anime advocates.

[Nintendo Maniac 64]

It doesn't seem like anything but profile 0 yuv420 is getting much hardware support

AFAIK most h.264 hw decoders are only 8bit 4:2:0 as well...

[xyzone]

AFAIK most h.264 hw decoders are only 8bit 4:2:0 as well...

Yes, I know. But does that mean newer and better codecs should do the same?

[foxyshadis]

The human eye is unable to perceive more colors than in the movies 8bit.

That's not even remotely true anymore; that's based on crappy old TVs with a terrible gamut. Sure there are still lots of 6bit TVs and monitors out there, but the difference of a truly high-end TV is obvious to most people. Both banding reduction and wider gamut are important.

In motion it doesn't matter, of course, like many things.

[Jamaika]

Maybe, but opinion is that the gamut is only handling the recipient. 24(8x3)bit image is 16.8 million colors, 30(10x3)bit is 1 billion colors when the young man receives only ~25mln. Is reduction banding not just a matter of implementation 8bit codec?

[LigH]

VPX v1.5.0-132-g16eba81 (http://www.mediafire.com/download/vgw5x3eee7ax3xt/vpx_v1.5.0-132-g16eba81.7z) (GCC 5.2.0, VP8/VP9/VP10, Win32/Win64)

[Motenai Yoda]

Maybe, but opinion is that the gamut is only handling the recipient. 24(8x3)bit image is 16.8 million colors, 30(10x3)bit is 1 billion colors when the young man receives only ~25mln. Is reduction banding not just a matter of implementation 8bit codec?

actually for bt.709 u'll need at least 10 bit yuv to get all colors of 8 bit RGB, as yuv is intended as a space to store RGB colors in a color opponent colorspace.
maybe for a bt.709 RGB gamut 8bit will be enough, but for larger colorspaces as DCI P3 (video) or AdobeRGB (photo), at least 11bit will be needed, and for ever larger as bt.2020 (UHD BD/TV) or ProPhoto (some imaginary colors) it will take even 12 bit or more.

The reduction of banding Imho will be based on 2 primary factors,
1- some source has banding that is hided during mastering with noise/grain,deband or dither, during compression lossy codecs often remove/attenuate high frequency details, so "unhide" the banding;
2 - when case 1 or high bit depth source the codec can't process/store/reproduce high precision values for low frequencies, so those will be rounded to low precision (8bit). As this precision isn't enough to mantain the continuity between blocks and isn't even linked between planes, on a lot of gradients will generate an interference that cause banding or color banding.

[dapperdan]

The latest Chrome beta release, supports VP9 in WebRTC

http://blog.chromium.org/2015/12/chrome-48-beta-present-to-cast-devices_91.html

[Selur]

Anyone has a working vpxenc binary with high bit depth support?
The one I build with https://github.com/jb-alvarado/media-autobuild_suite always crashes. (+ they removed the "--input-bit-depth=X" and "--bit-depth=X" from the vpxenc help,..)

[Jamaika]

Cancelled input color depths for vpxenc. So in the new Hybrid 2016 will only have ffmpeg/vpxenc the 8bit BT709.

[pandy]

Maybe, but opinion is that the gamut is only handling the recipient. 24(8x3)bit image is 16.8 million colors, 30(10x3)bit is 1 billion colors when the young man receives only ~25mln. Is reduction banding not just a matter of implementation 8bit codec?

Nope - trained person is capable to perceive somewhere between 12 and 14 bit (and usually such bit depth is used in medical image processing/displays), non trained person is able to perceive 10 bit relatively easily. Please avoid confusion between perceived number of colours (typical human male is able to name only few of them when usually human females has different names for different colours and for them green is definitely not dark mint).
In absolute terms we are limited in a way how many colours we can perceive but in relative way when shades are involved 8 bit is definitely not enough and banding is classical example.

[zerowalker]

Didn't know banding had something to do with how we perceive it, thought it was completely computational rounding errors and nothing more in that sense.
As i mean can't we kinda hide the rounding errors through dither and by so we perceive it as "higher quality" while it's still the same amount of information?

[mzso]

Nope - trained person is capable to perceive somewhere between 12 and 14 bit (and usually such bit depth is used in medical image processing/displays), non trained person is able to perceive 10 bit relatively easily. Please avoid confusion between perceived number of colours (typical human male is able to name only few of them when usually human females has different names for different colours and for them green is definitely not dark mint).
In absolute terms we are limited in a way how many colours we can perceive but in relative way when shades are involved 8 bit is definitely not enough and banding is classical example.

I highly doubt there's any difference in color perception between genders. Woman might be able to name more shades, because of their much higher interest in shallow fashion and such crap.

[zerowalker]

Pretty sure women actually see more colors.
Think they believe it was some evolutionary trait cause they may have looked for berries and colors mattered a lot, something a long those lines.
Sounds stupid though but there was a much better explanation then the one i gave;P

[LigH]

Oh, I guess there is another level of difference: Perceiving vs. realizing the difference of colors (not sure if that is an appropriate term at all). Women and men may possibly have a similar threshold which difference they will recognize as "different colors", and that will also depend on the hue (bluegreen to violet is usually a range where differences are recognized best, on the other hand it lacks of names for individual colors). But the conclusions may be different. You know, women recognizing faint shades of red in their husbands' face had a better chance to survive their anger about a missed hunt... :o

[zerowalker]

You know, women recognizing faint shades of red in their husbands' face had a better chance to survive their anger about a missed hunt...
Haha, love this, made me laugh xd

Truly the thing that was the sole reason for the survival of the human species.

[Jamaika]

Nope - trained person is capable to perceive somewhere between 12 and 14 bit (and usually such bit depth is used in medical image processing/displays), non trained person is able to perceive 10 bit relatively easily. Please avoid confusion between perceived number of colours (typical human male is able to name only few of them when usually human females has different names for different colours and for them green is definitely not dark mint).
In absolute terms we are limited in a way how many colours we can perceive but in relative way when shades are involved 8 bit is definitely not enough and banding is classical example.
I posted this motto. In Poland on film forum was the fuss about the point of 10bit video recording cameras. The problem with archiving. The main thought was, that codec ProRes is needed only for scaling the movie 8bit and everything. The rest is advertising.
maybe for a bt.709 RGB gamut 8bit will be enough, but for larger colorspaces as DCI P3 (video) or AdobeRGB (photo), at least 11bit will be needed, and for ever larger as bt.2020 (UHD BD/TV) or ProPhoto (some imaginary colors) it will take even 12 bit or more.
Good idea. Unfortunately I read the tags, if the potential client has a TV that has BT2020 and correctly converts colors?

[vivan]

Didn't know banding had something to do with how we perceive it, thought it was completely computational rounding errors and nothing more in that sense.
As i mean can't we kinda hide the rounding errors through dither and by so we perceive it as "higher quality" while it's still the same amount of information?The reason you can see banding (even if you generate clean gradient) is because we can see more colors (see difference between 2 close shades) that display can show.

Dithering hides display and/or format limitation (the reason why you have to round), it gives you more average precision while sacrificing local precision - pixels have different values from what they are supposed to have, while average value is closer to the desired one. With dithering higher output bitdepth gives you less noise. This (and fp yuv->rgb conversion) is why output and video bitdepth are completely unrelated.

[mzso]

Pretty sure women actually see more colors.
Think they believe it was some evolutionary trait cause they may have looked for berries and colors mattered a lot, something a long those lines.
Sounds stupid though but there was a much better explanation then the one i gave;P

I'm still a 100% skeptical.
Also the woman were gathering while the men hunted in prehistoric times hypothesis is pretty unfounded. I remember a paper that concluded that man are actually better at spotting food to be gathered. And doesn't make much sense. In my opinion it's most likely that men hunted, meanwhile gathering whatever they found. Women were taking care of children meanwhile doing some soft labor and didn't drag them around.

Plus all the famous painters ever were men.

[zerowalker]

Ah well i don't know much about it, just saw some documentary about it and therefore mentioned it.

However famous painters being men doesn't tell much though, as men is usually of higher status then women, and that probably plays some role.
Then again paintings is more about abstract stuff than actual color.

But there is probably some scientific tests that's been done to see how men differ from women in eye sight.
There should be some difference, as with everything else as we aren't built identical. If it's noticeable however is another story.

Not denying either one as i am not too well read in this topic;P

[mzso]

But there is probably some scientific tests that's been done to see how men differ from women in eye sight.
There should be some difference, as with everything else as we aren't built identical.

We're not identical, on an individual level. It doesn't necessarily mean that the two genders have different capabilities in an any/every trait.

[zerowalker]

We're not identical, on an individual level. It doesn't necessarily mean that the two genders have different capabilities in an any/every trait.

Indeed, hence what i meant it being noticeable or not.
If it's not, then it's basically in the "individual" measure as you say.

[benwaggoner]

Nope - trained person is capable to perceive somewhere between 12 and 14 bit (and usually such bit depth is used in medical image processing/displays), non trained person is able to perceive 10 bit relatively easily.
With specifically designed test patterns! For natural images and some appropriate dithering, 10, 12, and 14 should be pretty well identical for Rec. 709 images. Even 8-bit can be great with enough pixels. HDR needs at least 10.

[zerowalker]

I am confused with the concept of HDR.
Isn't that basically a system to try to force a higher dynamic range, but it doesn't so by pushing the limits,
it's not that the actual range is higher at all, it simple crushes the colours to force details in the dark at the cost of other things etc?

[foxyshadis]

I am confused with the concept of HDR.
Isn't that basically a system to try to force a higher dynamic range, but it doesn't so by pushing the limits,
it's not that the actual range is higher at all, it simple crushes the colours to force details in the dark at the cost of other things etc?

HDR is merely a wider gamut of color (hue and tone) in a range. You can display that wider gamut on device with a lower gamut by compressing what were whites and blacks into greys, kind of like incorrectly converting TV-levels YUV, but you can also dynamically emphasize the brighter parts or the darker parts, and get higher quality gamma conversions for things like a "night mode" or "daytime mode" -- it's more flexible. Movies can easily be graded with the information allowing the player to turn a HDR stream into an intended standard DR stream on playback, by choosing the white and black points and gamma. And of course, you can just have a screen that shows the wider gamut natively! Screens just a few years ago struggled to reach sRGB reliably, but now regularly exceed it, thanks to advances in LED backlighting and OLED, so it's the perfect time for a new standard.

One of the biggest problems with standard dynamic range is its crushed, banded shadows, and an HDR TV offers the possibility of completely fixing that without dithering to the point of killing shadow detail. Similarly in bright areas, but the eye tends to shy away from them, especially in a dark room, so it's not as noticeable. Getting better fidelity is something everyone can cheer.

[vivan]

Even 8-bit can be great with enough pixels.With enough pixels even 1-bit could be enough. Just like all printing is 1-bit.

[mzso]

With enough pixels even 1-bit could be enough. Just like all printing is 1-bit.

Colour printing is not 1 bit. You need 2-3 for the 3-4 colors they use.

[vivan]

Colour printing is not 1 bit. You need 2-3 for the 3-4 colors they use.Even if you can control dot size (I believe that common inkjet printers don't do that, their resolution is high enough) you still either have ink in a specific point or don't.

[Nintendo Maniac 64]

A better example would be DSD - it's an audio stream that's only 1 bit but has a sampling rate of 2822.4 KHz.

[LigH]

I love dithering. There is a library providing some image quantizations with error distributing dithering algorithms, named "libcaca" (yes, with a turd as icon, how funny).

[mzso]

Even if you can control dot size (I believe that common inkjet printers don't do that, their resolution is high enough) you still either have ink in a specific point or don't.

Yes, but you have one of 4-5 colors in that point. CMY(K) and white. So not 1 bit.

[nevcairiel]

Yes, but you have one of 4-5 colors in that point. CMY(K) and white. So not 1 bit.

Its one bit per component. Just like when we talk about 8-bit video, its not 8-bit overall, its 8-bit per component for 24 in total.

[mzso]

Its one bit per component. Just like when we talk about 8-bit video, its not 8-bit overall, its 8-bit per component for 24 in total.

Okay. We typically refer to that as "24 bit", don't we?

[nevcairiel]

Okay. We typically refer to that as "24 bit", don't we?

Not really, everyone is talking about 8-bit or 10-bit video around here. 24 or 30-bit are rare.

[LigH]

A resolution per component is less ambiguous, because there is usually some chroma subsampling, therefore Cb (U) and Cr (V) components won't add 100% of their value to each pixel. And furthermore, greyscale video (Y only) does exist as well.

[Nintendo Maniac 64]

Okay. We typically refer to that as "24 bit", don't we?

There's "bits per pixel" and "bits per channel".

Originally it was more common to refer to the total bits per pixel.

However, around the mid 2000s when pretty much everything supported 8 bits per channel and alpha transparency was becoming more common, the terminology started shifting towards "bits per channel".

I imagine that alpha transparency had a lot to do with it because 48 bits per pixel could be either 12 bits per channel + alpha transparency or 16 bits per channel without transparency. Simply stating the bits per channel eliminate the ambiguity in such a situation.

[LigH]

In addition, as already stated: In YUV 4:2:2 (YUY2 / UYVY), dividing the bits of used data per frame by the number of pixels per frame, every pixel would have only an average bit amount (with hardly any "meaning per pixel") because the two chrominance components share the blue/yellow and the red/green difference from grey among two pixels. With 8 bit per component, the result would be an average 8 + 8:2 + 8:2 = 16 bit; but these 16 bit are not addressable per pixel, only per 2 pixel group. Even worse for YUV 4:2:0 (YV12 / i420), there are shared chroma difference values among a 2×2 pixel square to an average 8 + 8:4 + 8:4 = 12 bit per pixel. Such statistics have too little meaning if your scope is a single pixel, they are even misleading.

[Jamaika]

Some improvements VP10 (currently 12-20% bitrate reduction): (http://encode.ru/threads/2462-Google-VP10-video-codec)

•high bit-depth internal: 10/12 bits (also artificially to improve prediction quality: 2-4% gain for 8-bit content),
•partition structure: 8-way partition (4 in VP9), 128x128 unit size (64x64 in VP9),
•new intra prediction, “recursive 3-/4-tap filtering framework from the left and top edges”, more directional prediction modes,
•Inter-prediction – up to 6 reference frames (3 in VP9),
•InterIntra – “A compound prediction mode that combines an inter- and intra-predictor”,
•OWMC (overlapped wedge motion compensation) - “allows blocks to have oblique partitions”, using “wedge codebook”: for dividing a block into parts using separate predictors (inter/intra),
•OBMC (overlapped block motion compensation) – “blend multiple predictors using motion information from neighboring causal blocks”,
•Global motion: pan/tilt/zoom/shake, gaming,
•“Super transform: transforms that cover multiple prediction blocks, a combination of prediction and transform”,
•Extended transforms: 16 transforms ((DCT/ADST/FlipADST/DST)^2) for 4x4/8x8/16x16, explored 32x32 and 64x64 wavelet/DCT hybrids, transform skip mode, recursive transform units,
•Entropy coding – only Asymmetric Numeral Systems mentioned as much faster for decoding.

[zerowalker]

A bit confused about this stuff.

Google and others work on an Open Video Encoder thingy, but they still make the VP10, then there is Daala which is also aiming for the same thing?
Why are they allied if they are competing, am i missing something here?

[BadFrame]

Why are they allied if they are competing, am i missing something here?

The AOM (Alliance of Open Media) codec is based upon VP10 (which is still in heavy development as a separate branch), but they will use any useful technology which their members have access to, for example if you look at the AOM branch, there are Daala features being added:

https://chromium-review.googlesource.com/#/q/project:webm/aom

I don't know if VP10 will actually materialise as a separate stable codec release or if it will be decprecated as it is the base of the AOM codec (depends on how long it will take to develop I guess).

[mandarinka]

Some improvements VP10 (currently 12-20% bitrate reduction): (http://encode.ru/threads/2462-Google-VP10-video-codec)

•high bit-depth internal: 10/12 bits (also artificially to improve prediction quality: 2-4% gain for 8-bit content),
•partition structure: 8-way partition (4 in VP9), 128x128 unit size (64x64 in VP9),
•new intra prediction, “recursive 3-/4-tap filtering framework from the left and top edges”, more directional prediction modes,
•Inter-prediction – up to 6 reference frames (3 in VP9),
•InterIntra – “A compound prediction mode that combines an inter- and intra-predictor”,
•OWMC (overlapped wedge motion compensation) - “allows blocks to have oblique partitions”, using “wedge codebook”: for dividing a block into parts using separate predictors (inter/intra),
•OBMC (overlapped block motion compensation) – “blend multiple predictors using motion information from neighboring causal blocks”,
•Global motion: pan/tilt/zoom/shake, gaming,
•“Super transform: transforms that cover multiple prediction blocks, a combination of prediction and transform”,
•Extended transforms: 16 transforms ((DCT/ADST/FlipADST/DST)^2) for 4x4/8x8/16x16, explored 32x32 and 64x64 wavelet/DCT hybrids, transform skip mode, recursive transform units,
•Entropy coding – only Asymmetric Numeral Systems mentioned as much faster for decoding.

Note that some of those tools might be sacrificed later due to performance concerns ( :angry: ) or disappointing results. If you look at Daala, it dropped a large parts of originally planned features, with lapping being evaluated for possible removal too IIRC - they are not sure its complexity brings anything on top of simple loop filtering. Global Motion was famously a feature of Mpeg4 ASP, but the consensus was that it was useless, back then.

•Inter-prediction – up to 6 reference frames (3 in VP9)

Aww, I hoped they would be more ambitious, this is still just catching up to HEVC (8) and AVC (16).

Edit:
partition structure: 8-way partition (4 in VP9)
This seems to be just another name for rectangular partitions that AVC/HEVC already has, based on what they show in the video (atlhough it might not support partitions like 4x16 or 8x32?). I guess this is to get around patents, like that convoluted way to copy over b-frames in VP9.

Those oblique and wedge partitions are ambitions though, I wonder if that makes into the final codec (fingers crossed).

"Rotation/zoom motion"
\o/

"Intra-block motion" should also be useful.

Also, anyone who checked the video: is it just me or does the thing they call "OBMC" not really mean OBMC? Isn't that just combining/merging of predictors that conventional codecs do? The blocks on the picture in presentation don't look like being overlapped.

[nevcairiel]

Aww, I hoped they would be more ambitious, this is still just catching up to HEVC (8) and AVC (16).

The fact that HEVC moved down from 16 to 8 should already tell you something - its just not worth it to have such a high number of refs. :)

[mandarinka]

Generally perhaps, but don't you know all that matters in encoding is anime? :devil:

[mzso]

Note that some of those tools might be sacrificed later due to performance concerns ( :angry: ) or disappointing results. If you look at Daala, it dropped a large parts of originally planned features, with lapping being evaluated for possible removal too IIRC - they are not sure its complexity brings anything on top of simple loop filtering. Global Motion was famously a feature of Mpeg4 ASP, but the consensus was that it was useless, back then.

Well, if they remove the lapping transformation, then they removed the only notable thing about the codec. The thing the codec is known for.
They might as well just dump the project and start enhancing existing formats or contribute to VP10. (Unless they put something more radical in there)

[mandarinka]

They might as well just dump the project and start enhancing existing formats or contribute to VP10. (Unless they put something more radical in there)

It's almost what they do now, actually.
Frequency domain intra prediction is dead, some other thing too but I can't recall what it is. They originally thought lapping will spare them from the need to have loopfilter. But without loopfilter, they have terrible ringing because they don't have intra because lapping. I think Daala currently has at least two loopfilters (complex deringing one, then some smoothing(?) thing from Thor), so that beggs the question if the lapping was worth it, ever? Losing intra prediction at least to me sounds like a potential bomb.

The big remains from Daala specialities is their entropy coding and PVQ. Those are still used, but they are also experimenting with porting them to VP10. AOM might mean Daala won't actually ship.

[foxyshadis]

The fact that HEVC moved down from 16 to 8 should already tell you something - its just not worth it to have such a high number of refs. :)

HEVC certainly supports 16 refs, at least for B-frames; x265 just limits it to 8. If x265 ever gets long-term references, or even a reference structure beyond pure hierarchical, those extra refs might come in very handy, but for now, yeah, what's the point?

[nevcairiel]

HEVC certainly supports 16 refs, at least for B-frames; x265 just limits it to 8. If x265 ever gets long-term references, or even a reference structure beyond pure hierarchical, those extra refs might come in very handy, but for now, yeah, what's the point?

While the HEVC bitstream can have 16 references, every individual picture can only access 8 of them, at least in all defined profiles/tiers/levels. But you get a bit of extra flexibility by keeping more around for another frame, I suppose.

[dapperdan]

https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/

VP9 support returns to Windows 10

[Motenai Yoda]

https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/

VP9 support returns to Windows 10

I don't get why disabling vp9 even on desktop...

[Nintendo Maniac 64]

I don't get why disabling vp9 even on desktop...

Because even on the desktop, VP9 decoding is quite intensive - my 2.4GHz Core 2 Duo can only do 1080p 60fps VP9, and that's even in MPC-HC 64bit with D3D Fullscreen and LAVfilters 0.68 (this config gives the lowest CPU utilization possible AFAIK).

Now consider that you will get worse performance in a browser and that Skylake only has maybe twice the IPC of a Core 2 Duo.

Heck, even on my Pentium G3258 at its stock 3.2GHz, using the same lowest-CPU-usage-possible software configuration as the Core 2 Duo PC, it can't handle 3840x2160 VP9 @ 48fps (and not barely either; it also can't do 40fps); it could handle 3840x2160 VP9 @ 30fps though.

EDIT: With my Pentium G3258 @ 4.6GHz, again using the same MPC-HC configuration, I can do 3840x2160 VP9 @ 50fps, but 3840x2160 VP9 @ 60fps is too much.

[BadFrame]

The world’s best VP9 encoder: Eve

Promises to give 5-10% better compression ratio than the official libvpx, and also be 10-20% faster.

Compared to x264 it offers 15-20% better compresion rates, but is ~5x slower.

https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/

No word yet as of availability.

[hajj_3]

The world’s best VP9 encoder: Eve

Promises to give 5-10% better compression ratio than the official libvpx, and also be 10-20% faster.

Compared to x264 it offers 15-20% better compresion rates, but is ~5x slower.

Looks interesting, i shall keep an eye out on this thread for independent comparisons of Eve vs x264 vs x265.

[Selur]

No word yet as of availability.
from the blog entries:
rbultje says:
May 2, 2016 at 3:24 pm

@Braulio: multi-threading is planned, but not yet finished.

@krs: it is currently not available as opensource. We are hoping to test it with customers who are willing to pay for it, so we can build a business around it that can sustain its development and pay the rent etc.
so till the eve encoder is available for public use vp10 and it's successors might be available,..

[BadFrame]

from the blog entries:
so till the eve encoder is available for public use vp10 and it's successors might be available,..

Here's hoping they'll find the same business model as x264/x265 viable, which is a fully open source GPL version, with the option for commercial ventures to purchase a license which allow proprietary use.

[Beelzebubu]

Here's hoping they'll find the same business model as x264/x265 viable, which is a fully open source GPL version, with the option for commercial ventures to purchase a license which allow proprietary use.

I may be stupid, but I just don't see it working. The key issue is that GPL covers redistribution, not use, and therefore most streaming video companies (which is really the primary market where VP9 stands a solid chance of becoming a significant player) will have no incentive to pay at all. After all, they don't redistribute.

Or am I missing something?

[nevcairiel]

I may be stupid, but I just don't see it working. The key issue is that GPL covers redistribution, not use, and therefore most streaming video companies (which is really the primary market where VP9 stands a solid chance of becoming a significant player) will have no incentive to pay at all. After all, they don't redistribute.

Or am I missing something?

This is true, it really only concerns people wanting to ship it as part of their software.

[BadFrame]

I may be stupid, but I just don't see it working.
Or am I missing something?

Well, this is the exact model x264 and x265 is using to make money (free GPL distribution, selling license to use as proprietary, probably coupled with support), maybe the economics will be different now that we are rapidly moving to a streaming era.

I certainly hope the business model remains sustainable, because if not, great projects like x265 will suffer.

[Beelzebubu]

Well, this is the exact model x264 and x265 is using to make money (free GPL distribution, selling license to use as proprietary, probably coupled with support), maybe the economics will be different now that we are rapidly moving to a streaming era.

The one additional thing that doesn't help is the fact that there's a half-decent BSD-licensed VP9 encoder out there. So for VP9, you would really have 3 choices: BSD, GPL or commercial. For H264/HEVC, there's really only two: GPL or commercial.

Anyway, I currently don't see the market opportunity for releasing the encoder under GPL or something similar. I'm not against it, I just don't see it work.

[BadFrame]

The one additional thing that doesn't help is the fact that there's a half-decent BSD-licensed VP9 encoder out there...

I follow your reasoning, taking it further and looking at the actual deployment of VP9 in the wild, it seems to me that it's 99.9% Youtube, which would mean that the realistic target of this new encoder would be Google.

Makes me wonder if they are hoping to be bought by Google, Ronald Bultje who is part of the EVE development team also previously worked under contract for Google on VP9/VP8 IIRC.

Meanwhile Google's current codec development effort is likely being focused on the AOM nextgen codec and VP10 (unless it's assimilated into the OAM codec), I'm not sure they are very interested in spending resources on improving VP9 at this stage.

[wiak]

I follow your reasoning, taking it further and looking at the actual deployment of VP9 in the wild, it seems to me that it's 99.9% Youtube, which would mean that the realistic target of this new encoder would be Google.

Makes me wonder if they are hoping to be bought by Google, Ronald Bultje who is part of the EVE development team also previously worked under contract for Google on VP9/VP8 IIRC.

Meanwhile Google's current codec development effort is likely being focused on the AOM nextgen codec and VP10 (unless it's assimilated into the OAM codec), I'm not sure they are very interested in spending resources on improving VP9 at this stage.
AOM AV1 started on the VP10 codebase, so its safe to assume VP10 is at the end of the road

AOM codebase is a collection of vp10, daala and thor ideas/code

[Clare]

AOM AV1 started on the VP10 codebase, so its safe to assume VP10 is at the end of the road
I am not sure this is true.
On their GIT, there are two distinct codebase for VP10: master and nextgenv2. AOM AV1 seems based of the master codebase of VP10 (in my test , the nextgenv2 branch is noticeably slower (5x) than VP10 master and AV1, which are similar), but a lot of development is still happening daily in nextgenv2.
Maybe they will do like Daala, include bits of it in AV1, but keeping a VP10 branch for research purposes.

[benwaggoner]

AOM AV1 started on the VP10 codebase, so its safe to assume VP10 is at the end of the road
Well, the industry as a whole only switches codecs every decade or so, while VPx gets new versions a lot faster. AOM wants to have a much tighter spec, with profiles, levels, a lot of thought for how to enable efficient hardware implementations, and that kind of stuff.

It's plausible that there could be VP11/12/13 before an AV2.

Although I don't think that introducing a new bitstream spec every few years is a good idea. By the time any VPx was done and decoders started to become common, VPx++ was out. And there wasn't ever time for encoders to really mature targeting a given bitstream spec.

[leonccyiu]

I wanted to point out that Youtube is now encoding 8k videos in VP9 and their file sizes and bit-rates are monstrous unlike the h264 equivalents.

Here are some example videos
https://www.youtube.com/watch?v=QPdWJeybMo8
https://www.youtube.com/watch?v=ChOhcHD8fBA
https://www.youtube.com/watch?v=VXUdY5P0VJA
https://www.youtube.com/watch?v=sGZwH26IwA0
https://www.youtube.com/watch?v=_KoGjIDAFk8

In Chrome on my friends 5820k, it used on average about 70% of his GPU, it was a complete slideshow on an i7 6700. Even with FFvp9 I don't think it'll play smoothly on a quad core i7. It doesn't look like Pascal has 8k hardware acceleration for VP9 unlike HEVC, Kaby Lake might.

Nonetheless I find this exciting. I just wish I could watch this on the 5k iMac in the apple store but Chrome on Mac doesn't use VP9 in Youtube and the CPU's aren't powerful enough to play it back. I could try the Mac pro connected to a 32inch sharp 4k display if I can get vp9 to work in chrome on mac.

[mzso]

Rather sad though that even with this sort of bitrate you get really prominent banding and blocking artifacts. (really noticeable on the Norway video)

[Nintendo Maniac 64]

AFAIK all VP9 hardware decoders support up to 4k 120fps, and 4k @ 120fps has the same pixel count as 8k @ 30fps...

[nevcairiel]

AFAIK all VP9 hardware decoders support up to 4k 120fps, and 4k @ 120fps has the same pixel count as 8k @ 30fps...

One of those is just a metric of speed though, and the other requires more memory for buffers, reference frames and whatnot. Not quite so clear cut.

[mandarinka]

http://www.pcper.com/image/view/69408?return=node%2F65356

Nvidia lists 4K 120Hz HEVC or 8K 30Hz HEVC for its GP104 chip. For VP9 it only shows 4K 120Hz VP9, so it likely can't go to higher resolution even if framerate was low.

[hajj_3]

http://www.pcper.com/image/view/69408?return=node%2F65356

Nvidia lists 4K 120Hz HEVC or 8K 30Hz HEVC for its GP104 chip. For VP9 it only shows 4K 120Hz VP9, so it likely can't go to higher resolution even if framerate was low.

No-one is going to be using 8k vp9 video anyway. By the time 8k video is being used the new codec to succeed vp9 will be out and available as hardware decoders in intel, amd and nvidia chips.

[Blue_MiSfit]

8k is highly desirable for VR (360 video) and VP9 is also a good fit in this market since nobody wants to pay for HEVC licensing.

Of course, the lack of hardware decoders means that VP9 is best used on desktops, but that's fine because the premium VR experiences are tethered to desktop on Rift / Vive.

[Ely]

8k is highly desirable for VR (360 video) and VP9 is also a good fit in this market since nobody wants to pay for HEVC licensing.

Of course, the lack of hardware decoders means that VP9 is best used on desktops, but that's fine because the premium VR experiences are tethered to desktop on Rift / Vive.

Isn't google trying to pressure SoCs manufacturers to bundle a VP9 decoder too ? For example, the Tegra X1 has it, but it can't be the only one.

[Motenai Yoda]

@Ely there are but not for 8K, many not even 4K.

[mandarinka]

Most of newer ARM socs have VP9 decoder - but then they have HEVC too, sometimes even HEVC Main 10 (on PC CPUs/GPUs, HEVC hardware is more common than VP9 though). So regardless of the patent royalties nonsense, HEVC is already there.

[Kurtnoise]

Netflix is targeting VP9 (http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=111296)...

[hajj_3]

Netflix is targeting VP9 (http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=111296)...

Sounds to me that they are looking at replacing h265 with vp9 for 4k video to avoid patent licensing costs. Netflix only uses h265 for 4k resolutions so that would be a smart move even though it will use more bandwidth.

[nevcairiel]

Sounds to me that they are looking at replacing h265 with vp9 for 4k video to avoid patent licensing costs. Netflix only uses h265 for 4k resolutions so that would be a smart move even though it will use more bandwidth.

He also talks about efficiency improvements at the low end to replace H.264/AVC for mobile targets (if the device has VP9 capabilities).

[mzso]

Sounds to me that they are looking at replacing h265 with vp9 for 4k video to avoid patent licensing costs. Netflix only uses h265 for 4k resolutions so that would be a smart move even though it will use more bandwidth.

It'll only use more bandwidth if they encode the videos at higher bitrate. Which they might not. If memory serves they never quite used adequate bitrates to be perceptually lossless.

The Eve encoder people now have a new potential buyer, besides google. :)

[mandarinka]

It'll only use more bandwidth if they encode the videos at higher bitrate. Which they might not. If memory serves they never quite used adequate bitrates to be perceptually lossless.

The Eve encoder people now have a new potential buyer, besides google. :)

The article kind of sounds like they are going with libvpx :(

[Motenai Yoda]

At the high-end (4K, 10-bit) VP9 offers an alternative to HEVC.
Looks like very high-end as IIRC there isn't any consumer device/cpu/gpu capable of hw decoding for this kind of video.

[dapperdan]

I keep reading about 4K TVs that ship with Youtube and Netflix as a ready source of 4K content. I assumed they had hardware support for 4K VP9 for Youtube and HEVC for Netflix. And since they seem to always have both, Netflix could perhaps update their app to use VP9 instead.

[sneaker_ger]

I know Samsung TVs that have a VP9 decoder. (2160p30)

[Motenai Yoda]

I can't find anything about vp9 10bit (profile 1 2 as sneaker_ger wrote down here)

[sneaker_ger]

10 bit is profile 2 but no one uses it productively. No hardware support - I believe TVs and mobile SoCs included. Kaby Lake will be the first. YouTube has announced HDR but whether it will be VP9 10 bit or something else (AV1?) we have to wait and see.

[foxyshadis]

I very much doubt the world will see 10bit vp9 outside of test sequences, unless hardware support becomes universal before AV1 shows up. I'd love it, but at this point it'll probably be in the same situation 10bit AVC was.

[Nintendo Maniac 64]

it'll probably be in the same situation 10bit AVC was.
So 10bit VP9 will find a specific niche that will end up having all of the best versions in said niche be encoded in 10bit VP9?

[Jamaika]

I very much doubt the world will see 10bit vp9 outside of test sequences, unless hardware support becomes universal before AV1 shows up. I'd love it, but at this point it'll probably be in the same situation 10bit AVC was.
You say it is overrated, ex. TV LG G6.
http://www.flatpanelshd.com/article.php?subaction=showfull&id=1459247590
http://www.cnx-software.com/2016/05/19/xiaomi-mi-box-comes-to-the-us-with-android-tv-6-0-running-on-amlogic-s905x-processor/

[mandarinka]

14nm Radeons (Polaris) reportedly have VP9 decoding hardware (8bit only, likely) in addition to (10bit) HEVC.

The Stoney Ridge APU (E2-9010, A6-9210, A9-9410) according to some sources has VP9 decoding, according to some it does not (but maybe there could be a hybrid decoder available?). It does have 10-bit HEVC decoding though, that bit is confirmed.

[zerowalker]

Why can't any HW decoder do h264 10bit, why! ;(
Awesome that at least HEVC gets that.

[Nintendo Maniac 64]

Why can't any HW decoder do h264 10bit, why! ;(

I would guess it's because 10bit AVC is pretty much only ever used for anime bootlegs and demo videos and therefore is arguably too niche to spend resources on.

DISCLAIMER: I too would like 10bit AVC hardware decoding, but I never actually expected it to happen.

[mandarinka]

I think another issue is that the format is not covered by IP decoding blocks you can readily license. Or if it is available, the licensing costs are too high because it is considered pro/enterprise (because of AVC-intra).

Which means you have to do it on your own and it won't integrate with your already present circuitry, so it will be excess transistors, space, will need more complicated interfacing... it probably looks like too much pain to the bigger SoC vendors that have money for such stuff.

----------------------------

Edit:
Looks like the VP9 support is opencl/shader based GPU acceleration. It will be available to the Bristol Rdige APUs too (A8/A10/A12/FX).
http://images.anandtech.com/doci/10362/3%20-%20Stoney%20Ridge_575px.jpg
http://images.anandtech.com/galleries/4890/4%20-%20VP9%20HEVC_575px.jpg
http://images.anandtech.com/galleries/4890/6%20-%20A12_575px.jpg

Edit2:
http://www.amd.com/en-us/products/processors/laptop-processors#
This says that the quadcores are going to support 1080p VP9 ("FHD"), the dualcores (Stoney Ridge) only 720P it seems ("HD"). The latter is not so useful I guess.

[mandarinka]

I very much doubt the world will see 10bit vp9 outside of test sequences, unless hardware support becomes universal before AV1 shows up. I'd love it, but at this point it'll probably be in the same situation 10bit AVC was.

I was surprised too, but Kaby Lake, aka the next gen Intel CPUs launched this year (probably), are going to support hardware decoding of 10bit VP9.

Sources:
https://software.intel.com/sites/default/files/mediasdk_release_notes.pdf

Probably just profiles 0 and 2, not 1 and 3, although the API apparently aknowledges their existence.

This is probably due to 1) youtube planning HDR streaming this way, and 2) google/on2 probably provides IP that chipmakers can use to implement it, while such blocks aren't probably accessible enough for High 10 AVC.

[zerowalker]

Wait, is Youtube gonna use VP9 10bit?
Or am i reading it wrong, can't tell if you are debunking 10bit or not xD.

I would love to see it though, it would do wonders on certain games (Dark ones like Amnesia).

[NikosD]

Are there any VP9 encoders supporting 10 bit encoding ?

I'm trying to encode an uncompressed 10 bit stream to VP9 10bit.

[nevcairiel]

There is only one publically available encoder, libvpx. I don't know about the vpx commandline encoder, but at least using libvpx through ffmpeg allows encoding 10-bit if the libvpx it links to is build with high-bitdepth support.

[Selur]

..don't know about the vpx commandline encoder,..
vpxenc also support 10bit for quite some time now,...

[NikosD]

Thank you both

[mandarinka]

VP9 profile 2 support in ARM's IP block: http://www.anandtech.com/show/10428/arm-announces-mali-egil-video-processor

(Of course, shipping of chips with such hardware will take time, think 1-2 years depending on how long lead did close partners get to license it pre-announcement).

[Nintendo Maniac 64]

I'm more interested in the fact that the above article mentioned encode support and not just decode.

[mandarinka]

I'm more interested in the fact that the above article mentioned encode support and not just decode.

HEVC 10 encode is also a thing (supposedly for streaming HDR games...), so probably feature parity is the motivation. Or more checkboxes?

I didn't check VP9's 10-bit effectiveness gains, but I'm not sure they are that important, since we are talking mobile hardware encoding, which means shit quality from the start.

[Zetti]

Does there exist a freeware VP9 encoder??

[LigH]

How much more free do you want vpxenc or ffmpeg to become?!

[Zetti]

Before i wrote the post tried i search on google and did not find some useful results.

But i will try to search more on vpxenc and ffmpeg for VP9 encoding.

[LigH]

You should have read this thread instead, I guess... ;)

But vpxenc and ffmpeg are CLI encoders. You may also want to look for GUIs using them and providing an easier use.

[Selur]

As a gui, Hybrid supports VP8/9 encoding through vpxenc. (always happy to get some feedback regarding vp8/9 since I dropped using it myself, since a. feedback from devs took normally multiple month b. encoding was slow)

[Jamaika]

You can see that google really hiding from novelties.
As for ffmpeg it isn't possible to determine what version is vpxenc. I suppose that is the first version 1.5.0.
About the latest testing codecs AOM can forget because there are no players. Before you compile codec yourself. The joke lies in the fact that the developers not indicate how they write functions, "config".
Depending on how you configure these files "vpx_config.h, vp8/9/10/av1_enums.h, vp8/9/10/av1_rtcd.h, vp8/9/10/av1_common.h" you have different results at the end.

Greetings to all amateur enthusiasts.

[Jamaika]

Elimination of the truss pixels codecs VPX/AOM at low bitrates.

Theme was already before. Maybe a little interesting, because who uses VPX codec. However, I will return to him. I'll write how you can minimize pixelation.
VPX codec has VBR mode and it's set by default. Should change to the CRB mode {end-usage=cbr}. To increase the quality of the video frame it should be increased the percentage of the average per-frame bitrate {gf-cbr-boost}. The VP9 codec to 200% and AV1 codec to 300%. Does not affect the truss appearing function of {lag-in-frames}.

[wiak]

Polaris from amd has VP9 4k30 support it also has 10-bit HEVC
https://awesome.nwgat.ninja/rx480/Polaris-Tech-Day-Architecture-legally-approved/ef863980c6d742d6be8285356a039ac7-39.png
https://awesome.nwgat.ninja/rx480/Polaris-Tech-Day-Architecture-legally-approved/ef863980c6d742d6be8285356a039ac7-02.png

FYI if you want to read more on the Polaris chips aka Radeon RX 480/470 and 460
https://awesome.nwgat.ninja/rx480/

dunno about 10-bit VP9, perhaps the HW IP info section on the vp9 homepage has more info on what the open hardware design support

[Jamaika]

Does anyone know anything more about the novelties libvpx?
https://groups.google.com/a/webmproject.org/forum/#!topicsearch/webrtc/codec-devel/lo7VYVWrDFI
VP10 is still a work in progress and will be removed from the release v1.6.0
but significant changes have been made to both VP10 and AM1 and we
expect that to continue.

We would like to cut a release candidate within the next week or two.
What is a codec AM1? Maybe this is a typo. :confused:

[Nintendo Maniac 64]

What is a codec AM1? Maybe this is a typo. :confused:

Probably a typo and is referring to AV1, because what he describes is exactly what's going on with AV1.

Either that or it was before "AV1" was the agreed upon name and maybe it was known as AM1 internally or something.

[Jamaika]

Release v1.6.0 Khaki Campbell Duck (https://github.com/webmproject/libvpx/commit/042572177b5c58404836fce3fc221fd077dcd896)

This release improves upon the VP9 encoder and speeds up the encoding and
decoding processes.

- Upgrading:
This release is ABI incompatible with 1.5.0 due to a new 'color_range' enum
in vpx_image and some minor changes to the VP8_COMP structure.

The default key frame interval for VP9 has changed from 128 to 9999.

- Enhancement:
A core focus has been performance for low end Intel processors. SSSE3
instructions such as 'pshufb' have been avoided and instructions have been
reordered to better accommodate the more constrained pipelines.

As a result, devices based on Celeron processors have seen substantial
decoding improvements. From Indian Runner Duck to Javan Whistling Duck,
decoding speed improved between 10 and 30%. Between Javan Whistling Duck
and Khaki Campbell Duck, it improved another 10 to 15%.

While Celeron benefited most, Core-i5 also improved 5% and 10% between the
respective releases.

Realtime performance for WebRTC for both speed and quality has received a
lot of attention.

- Bug Fixes:
A number of fuzzing issues, found variously by Mozilla, Chromium and others,
have been fixed and we strongly recommend updating.

Delete codec VP10 with nextgen
Codec VP10 is in nextgenv2

[LigH]

"Khaki Campbell Duck" ~ (x)kcd :D

[mzso]

The default key frame interval for VP9 has changed from 128 to 9999.

Marvellous. I've been waiting for a long time for masses of unseekable junk videos.

[Motenai Yoda]

"Khaki Campbell Duck" ~ (x)kcd :D

https://imgs.xkcd.com/comics/standards.png

[Quikee]

The default key frame interval for VP9 has changed from 128 to 9999.

This is actually a mistake in the release notes. The change was from 9999 to 128.

[Jamaika]

Impossible. Libvpx v1.5.0 has keyframe interval 128. There are holiday so there is no upgrade ffmpeg order to check this.

[Quikee]

Impossible. Libvpx v1.5.0 has keyframe interval 128. There are holiday so there is no upgrade ffmpeg order to check this.

https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/wlBMewAEBcg

and the exact commit that changed it to 128: https://chromium.googlesource.com/webm/libvpx/+/14828e756f92175c1a3c097c1048c01bbfba43a9%5E%21/vp9/vp9_cx_iface.c

[mandarinka]

14nm Radeons (Polaris) reportedly have VP9 decoding hardware (8bit only, likely) in addition to (10bit) HEVC.

The Stoney Ridge APU (E2-9010, A6-9210, A9-9410) according to some sources has VP9 decoding, according to some it does not (but maybe there could be a hybrid decoder available?). It does have 10-bit HEVC decoding though, that bit is confirmed.

The announced VP9 decoding on Polaris GPUs is reportedly really hybrid (shader-based GPU acceleration), if somebody had doubts.

[blurred]

Delete codec VP10 with nextgen
Codec VP10 is in nextgenv2[/I]
It seems two are being separately developed:
https://aomedia.googlesource.com/aom/
https://chromium.googlesource.com/webm/libvpx/+log/nextgenv2
They seem quite different - the first more Mozilla-Daala related, the second Google VP10.

Which one will become AV1?
Will VP10 be separately released?

[easyfab]

nextgenv2 is vp10 branch ( only google )
https://aomedia.googlesource.com/aom/ is AV1 branch ( with all aom members commits )

on chromium.googlesource.com the old AV1 branch was https://chromium.googlesource.com/webm/aom wich become aomedia.googlesource.com/aom/

[Jamaika]

Codec vp9 v1.6.0 in ffmpeg
Default GOP=128

[nakTT]

Sorry if this is not the right place to ask.

Any of you guys know any free software with extensive settings GUI like MeGUI, Handbrake etc that can do VP9 encoding?

I have been doing many encoding with MeGUI with x264 and x265 but have yet to get my hands on an application that can do VP9 conversion.

Thank you in advance.

[LigH]

Try Hybrid by Selur.

[nakTT]

Try Hybrid by Selur.
Thanks for the suggestion.

[Motenai Yoda]

Someone knows if the new Google Duo video-calling app uses vp9+opus? as it's said it can dynamically reduce the resolution, this sound very like a vp8/9/10 feature

[leonccyiu]

According to a PcPartpicker user who has the GTX1060, if you use Microsoft Edge, it implements hardware acceleration for VP9 on YouTube, he checked this by looking at stats for Nerds and CPU usage while watching 4k60. He also said that Neither Chrome, Firefox or Opera implemented VP9 hardware acceleration.

[wiak]

meybe edge supports Media Foundation and nvidia has a vp9 enabled Media Foundation codec?

[sneaker_ger]

MS explained it some time ago: https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-microsoft-edge/

[leonccyiu]

it'd be nice if Chrome had dxva hardware acceleration for vp9 as google are the ones most aggressively pushing it. Hopefully it'll arrive soon.

[benwaggoner]

it'd be nice if Chrome had dxva hardware acceleration for vp9 as google are the ones most aggressively pushing it. Hopefully it'll arrive soon.


DXVA requires a driver-level codec implementation, typically GPU driver falling back to OS.

Or do you mean DirectComputer/OpenCL or something like that?


Sent from my iPad using Tapatalk

[huhn]

there is full DXVA VP9 support for a while now.

all pascal GPU are supporting this and it should be the same with polaris GPU.
even my "old" 960 maxwell GPU has a fixed function VP9 decoder.

DXVA VP9 support in web browser isn't a dream. it should happen at some time in the feature.

lavfilter is supporting it for over 6 month or something like that.

[NikosD]

Edge already supports it.

But it is for me a huge mystery, how on Earth the company (google) that develops both Chrome and VP9 hasn't managed yet to make HW acceleration feasible in its own browser that forces VP9 codec in Youtube, while Microsoft the other opponent has already done this in its own browser that doesn't forces the use of VP9.

Crazy.

[Blue_MiSfit]

It works in Chrome Canary ;)

[NikosD]

It works in Chrome Canary ;)
And how long is going to take approximately to go through the whole workflow, from Canary to dev from dev to beta and from beta to stable ?

[GTPVHD]

https://www.microsoft.com/en-us/download/details.aspx?id=49188

https://download.microsoft.com/download/9/2/A/92A4E198-67E0-4ABD-9DB7-635D711C2752/DXVA_VPx.pdf

August 2016
This document contains a specification for support of VP8 and VP9 video decoding (according to the available VP8 and VP9 source code and public documents) within the Microsoft Windows DirectX Video Acceleration (DXVA) API/DDI context.

This specification includes support of the VP8 coding format, VP9 Profile 0 (for 8 bit 4:2:0 video) and VP9 Profile 2 in 10 bit mode.

[x265_Project]

Netflix has posted on their Tech Blog, notifying people about a large study they have completed comparing x264, x265 and VP9 (libvpx). The results will be published Wednesday morning.
http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html

We ran a large-scale comparison of x264, x265 and libvpx to see for ourselves whether this 50% bandwidth improvement is applicable to our use case. Most codec comparisons in the past focused on evaluating what can be achieved by the bitstream syntax (using the reference software), applied settings that do not fully reflect our encoding scenario, or only covered a limited set of videos. Our goal was to assess what can be achieved by encoding with practical codecs that can be deployed to a production pipeline, on the Netflix catalog of movies and TV shows, with encoding parameters that are useful to a streaming service. We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair, we generated more than 200 million encoded frames. We applied six quality metrics - PSNR, PSNRMSE, SSIM, MS-SSIM, VIF and VMAF - resulting in more than half a million bitrate-quality curves. This encoding work required significant compute capacity. However, our cloud-based encoding infrastructure, which leverages unused Netflix-reserved AWS web servers dynamically, enabled us to complete the experiments in just a few weeks.

What did we learn?
Here’s a snapshot: x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.

Want to know more?
We will present our methodology and results this coming Wednesday, August 31, 8:00 am PDT at the SPIE Applications of Digital Image Processing conference, Session 7: Royalty-free Video. We will stream the whole session live on Periscope and YouTube: follow Anne for notifications or come back to this page for links to the live streams. This session will feature other interesting technical work from leaders in the field of Royalty-Free Video. We will also follow-up with a more detailed tech blog post and extend the results to include 4K encodes.

[mzso]

Netflix has posted on their Tech Blog, notifying people about a large study they have completed comparing x264, x265 and VP9 (libvpx). The results will be published Wednesday morning.
http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html

x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.
This is weird... So it's worse below and above 1080p, but better or equivalent at 1080p?

[IgorC]

I wonder why MSU hasn't included VP9 this year http://compression.ru/video/codec_comparison/hevc_2016/

[dapperdan]

This is weird... So it's worse below and above 1080p, but better or equivalent at 1080p?

They only tested 480, 720 and 1080. So it sounds like x265 does better overall, but mostly on the lower end.

[dapperdan]

Edge already supports it.

But it is for me a huge mystery, how on Earth the company (google) that develops both Chrome and VP9 hasn't managed yet to make HW acceleration feasible in its own browser that forces VP9 codec in Youtube, while Microsoft the other opponent has already done this in its own browser that doesn't forces the use of VP9.

Crazy.

It's boringly sane actually.

VP9 only helps Youtube save bandwidth if lots of people use it. Restricting it to those with hardware acceleration would basically kill it and make the whole things pointless, so they need to do at least software decode and then hardware as a bonus for low end and mobile devices. Each time they have to choose which to spend developer time on, then software decode is going to have lots of benefits since it will help so many more people it'll basically pay for itself many times over.

They run the numbers based on users bandwidth vs CPU vs visual quality vs user engagment to see whether it's working or not. They initially restricted VP9 to not show on XP devices because these stats showed that people on those devices gave up in disgust. If they're still showing it to you and you have a bad experience with it then presumably their data shows 3 or 4 people (maybe those with modern computers on bad connections) are having a better experience and watching more Youtube ads as a result.


Meanwhile, Microsoft has always been wary aout exposing itself to patents or licence fees, so is more interested in farming that out to 3rd parties and doesn't really care that much if most Edge users don't get VP9
support.

[NikosD]

Interesting point of view

[Motenai Yoda]

from intel 7th core generation slides
http://images.anandtech.com/doci/10610/7th%20Gen%20Intel%20Core%20Performance%20Evaluation-13_575px.png


Intel Video Codec Support
Kaby Lake Skylake Broadwell
H.264 Decode Hardware Hardware Hardware
HEVC Main Decode Hardware Hardware Hybrid
HEVC Main10 Decode Hardware Hybrid No
VP9 8-Bit Decode Hardware Hybrid Hybrid
VP9 10-Bit Decode Hardware No No

H.264 Encode FF & PG-Mode FF & PG-Mode PG-Mode
HEVC Main Encode FF & PG-Mode PG-Mode No
HEVC Main10 Encode FF & PG-Mode No No
VP9 8-Bit Encode FF & PG-Mode No No
VP9 10-Bit Encode No No No

[x265_Project]

Netflix's presentation of their study; A large scale video codec comparison of x264, x265 and libvpx for practical VOD applications, can be watched on YouTube here... https://youtu.be/wi1BefrfTos?t=1h25s

Naturally, if you don't use --tune ssim with x265, results are worse when measured using SSIM. When they avoided --tune psnr and --tune ssim their own visual quality metric showed that x265 delivered the highest efficiency.
http://x265.org.s3.amazonaws.com/img/Netflix_Codec_Comparison_Results_50.png

[Motenai Yoda]

Naturally, if you don't use --tune ssim with x265, results are worse when measured using SSIM. When they avoided --tune psnr and --tune ssim their own visual quality metric showed that x265 delivered the highest efficiency.

well but they avoided to tune for ssim or psnr with vp9 and x264 too for those tests as the 1/3 psnr slide mention "PSNR-tuned configuration", where vp9 give 43.5% bitrate reduction over x264 vs 43.4% of x265 (still there is a 2.5% gain for x265 vs vp9 on averages)
slide 2/3 based on ms-ssim indeed visual quality tuned, and here vp9 performs a bit better

so the point is: will tuning codecs for ssim give more reliable results on ms-ssim or vmaf metrics?

[dapperdan]

They talk about a paper with more details of their results, is that available yet?

[x265_Project]

They talk about a paper with more details of their results, is that available yet?
Not yet. Keep your eye on http://techblog.netflix.com/

[x265_Project]

well but they avoided to tune for ssim or psnr with vp9 and x264 too for those tests as the 1/3 psnr slide mention "PSNR-tuned configuration", where vp9 give 43.5% bitrate reduction over x264 vs 43.4% of x265 (still there is a 2.5% gain for x265 vs vp9 on averages)
slide 2/3 based on ms-ssim indeed visual quality tuned, and here vp9 performs a bit better

so the point is: will tuning codecs for ssim give more reliable results on ms-ssim or vmaf metrics?
It's well known that PSNR and SSIM are somewhat crude quality metrics that don't correlate perfectly with human quality evaluations. Over the years that x264 was optimized, the development team noticed that certain algorithms would deliver better subjective (human) visual quality, but worse objective quality scores (PSNR or SSIM). Knowing that the main goal of a video encoder is to deliver the best subjective visual quality, they optimized for the best experience as judged by humans. To enable PSNR or SSIM driven evaluations to be done more fairly, the x264 team came up with "tunings" that turned off all algorithms that affected these measurements negatively. Of course, no one would ever use --tune PSNR or --tune SSIM for production encoding, as these encodes will always deliver inferior visual quality when evaluated by real people.

As Netflix explained, they did 2 sets of test encodes with x264 and x265. One set was tuned for PSNR (using --tune psnr), and one set was done without this tuning. PSNR tuned encodes are the only valid encodes to use when you use PSNR as a test metric.
So, the first result they showed was a valid comparison...
http://x265.org.s3.amazonaws.com/img/Netflix_Codec_Comparison_Results1_50.png
The second results slide they showed was not valid comparison (you need to use --tune ssim if you want to compare x264 or x265 using SSIM).
http://x265.org.s3.amazonaws.com/img/Netflix_Codec_Comparison_Results2_50.png
Similarly, if you're doing subjective visual quality tests, or using an advanced metric like Netflix's VMAF, which correlates more closely with subjective visual quality assessments, you should not use the --tune PSNR encodes. The third results they showed are valid, as they used the visual quality tuned encodes to compare using their VMAF metric.
http://x265.org.s3.amazonaws.com/img/Netflix_Codec_Comparison_Results_50.png

Of course, no objective (computer calculated) quality metric is as good as humans watching and evaluating video. There are many aspects of a video experience that are hard to measure with mathematical formulas - like motion accuracy, or the degree of noticeable compression artifacts.

Netflix's study is one of the most valid and comprehensive studies ever conducted, as they used real production codecs on a very large and representative sample of high quality real production content (unlike some codec comparisons that used previously compressed content, or used only reference encoders). This study definitely furthers our understanding of the performance that is possible from VP9 and HEVC under real-world conditions. Netflix has an amazingly talented R&D team, and it's awesome that they are willing to publish their research for everyone's benefit.

[x265_Project]

And now, straight from Netflix...http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=113346
Jan Ozer writes...
I asked Netflix which set of results they felt was most significant. Their response was, “We believe that VMAF results will have the best correlation to user perception of quality. We use this metric, and sanity-check against other metrics (PSNR, SSIM, VIF, etc.) internally.”
http://dzceab466r34n.cloudfront.net/StreamingMedia/ArticleImages/InlineImages/108157-Netflix-HEVC-ORG.png

[Jamaika]

Thanks for the explanation. It's nice that someone has developed a metric VMAF but I can't use from that.
According to this chart tune psnr there is no foreseeable result of the ratio of the maximum signal power to the noise power distortive the signal.
Results for Daala.
http://dzceab466r34n.cloudfront.net/StreamingMedia/ArticleImages/InlineImages/107094-Netflix-VAMF-ORG.png
I Wonder, what is my predictable conversion score in function pass2 veryslow?

[mandarinka]

http://x265.org.s3.amazonaws.com/img/Netflix_Codec_Comparison_Results2_50.png


Hmm, could it be that VP9's win in that MS-SSIM test was caused completely just by psy optimizations distorting the result?

IIRC, libvpx doesn't have as extensive set of psyRDO/adaptive quantization tools as x264 developed (and then x265 adapted/extended). Since psy measurably hurts metrics, in this test x265 might have been handicapped while libvpx not, "thanks"to the latter's lack of meaningfully psy (somebody correct me if it has Psy RDO now)?

[x265_Project]

Hmm, could it be that VP9's win in that MS-SSIM test was caused completely just by psy optimizations distorting the result?

IIRC, libvpx doesn't have as extensive set of psyRDO/adaptive quantization tools as x264 developed (and then x265 adapted/extended). Since psy measurably hurts metrics, in this test x265 might have been handicapped while libvpx not, "thanks"to the latter's lack of meaningfully psy (somebody correct me if it has Psy RDO now)?
Yes... it's well known that if you want to measure x264 or x265's SSIM scores, you need to use --tune SSIM for your encodes. If you don't (as with this example), x264 and x265 will be using algorithms that improve visual quality, but produce lower SSIM scores.

How many of you remember this blog post?
http://web.archive.org/web/20100723085702/http://x264dev.multimedia.cx/?p=458

Even when you use --tune PSNR or --tune SSIM, and then compare encoders using PSNR or SSIM, you won't have a fully reliable comparison.

x264 and x265 were not designed to achieve the highest efficiency when measured with PSNR or SSIM. They're designed to achieve the highest visual quality with any content at any chosen bit rate. We could have much higher PSNR or SSIM scores if we simply optimized everything for these objective metrics. But that wouldn't be the best encoder for producing video for actual human beings to watch.

Netflix understands the limitations of PSNR and SSIM, which is why they've invested a lot of time and energy, working with experts at the University of Southern California, into developing a better objective quality measurement tool - Video Multimethod Assessment Fusion (VMAF) (http://techblog.netflix.com/2016/06/toward-practical-perceptual-video.html). VMAF correlates to subjective (human) visual quality assessments much more closely than PSNR, SSIM, or other available objective metrics. VMAF results are a much more reliable predictor of actual human subjective visual quality evaluations.

[LigH]

Then I hope the VMAF specs are publicly available to make an AviSynth plugin implementable... :o

But let's discuss that elsewhere (http://forum.doom9.org/showthread.php?t=173676).

[mandarinka]

Yeah, I'm aware of the ssim/psnr and x264 businesses, I was encoding back then, when VAQ/PsyRDO landed and changed the encoding landscape like nothing in years :) ('08/'09)

I'm thinking that they probably meant to not test the same thing as with plain SSIM, when they run the MS-SSIM metric. Maybe they aimed to use it to gauge the visual quality like with VMAF... be it a good idea or not. I'm not sure how similar is MS-SSIM to SSIM proper. Xiph people use it IIRC, probably thinking it correlated better with visual quality than SSIM.

But x265 is still going to have bigger delta between metrics-tuned and psy-tuned result than libvpx is going to, I think, since libvpx lacks psyrdo. So to the degree MS-SSIM is similar to SSIM, it is probably disadvantaging x265. Hard to know for sure though, I never tried it.

[x265_Project]

Then I hope the VMAF specs are publicly available to make an AviSynth plugin implementable... :o

But let's discuss that elsewhere (http://forum.doom9.org/showthread.php?t=173676).
They open sourced it under the Apache 2.0 license...
https://github.com/Netflix/vmaf

[Jamaika]

Hmm, could it be that VP9's win in that MS-SSIM test was caused completely just by psy optimizations distorting the result?

IIRC, libvpx doesn't have as extensive set of psyRDO/adaptive quantization tools as x264 developed (and then x265 adapted/extended). Since psy measurably hurts metrics, in this test x265 might have been handicapped while libvpx not, "thanks"to the latter's lack of meaningfully psy (somebody correct me if it has Psy RDO now)?
Codecs libvpx and libaom have metric pnsr and ssim.
--tune=<arg> Material to favor
psnr, ssim}
--psnr Show PSNR in status line
The rest I think no one cares.
More interesting to me, how netflix introduced meric to codec Daala. Here probably wrote additional function and included. Daala doesn't have such functions. With the deduction indicates that VMAF can be used for all the codecs.
It is a pity that netflix didn't give the predicted score charts of PNSR / SSIM / VMAF vs DMOS for codecs X265 or VPX.:confused: Probably not to annoy developers.
Results for Daala.
http://cdn1.infoqstatic.com/statics_s1_20160831-0533/resource/articles/a-quality-assessment-tool-for-video-streaming-media/zh/resources/02.png
I'm thinking that they probably meant to not test the same thing as with plain SSIM, when they run the MS-SSIM metric. Maybe they aimed to use it to gauge the visual quality like with VMAF... be it a good idea or not. I'm not sure how similar is MS-SSIM to SSIM proper. Xiph people use it IIRC, probably thinking it correlated better with visual quality than SSIM.

Exceptions results are considerable for Daala

Chroma from Luma is a PSNR in Daala (http://people.xiph.org/~xiphmont/demo/daala/demo4.shtml)
Despite lending visual improvements, Chroma from Luma is a PSNR penalty in Daala. This is not particularly surprising, as neither PSNR nor any of the other common objective quality measures used in video coding represent color perception well, but it is especially interesting as the similar lack of PSNR performance in HEVC testing would certainly have contributed to it being dropped from the final HEVC standard. Perhaps the joint working group might have overlooked that if the spatial version of Chroma from Luma had not also been an apparent performance penalty. I speculate here mainly because our frequency domain implementation is substantially faster than classic intra prediction, not slower.

[herbert]

VideoLAN Dev Days 2016: Update on VPX
Recap on recent VPX developments.

https://www.youtube.com/watch?v=peS2I14w8ow


VideoLAN Dev Days 2016: A VP9 Encoder
Information on ffvp9 until about 6:45, followed by a talk about 'Eve', an alternative VP9 encoder.

https://www.youtube.com/watch?v=t_z52-CBut0

[Selur]

Just wondering: Since av1, vp8 and vp9 seem to be based on the same framework can they be compiled into a single binary? (vpxenc can include vp8, vp9, vp10, so I was wondering if av1 could be added there too)

[Quikee]

Just wondering: Since av1, vp8 and vp9 seem to be based on the same framework can they be compiled into a single binary? (vpxenc can include vp8, vp9, vp10, so I was wondering if av1 could be added there too)

No, they removed everything that won't be used in av1 and renamed everything vp8, vp9, vpx to aom or av1.

[Selur]

Thanks for the info. :)

[mzso]

No, they removed everything that won't be used in av1 and renamed everything vp8, vp9, vpx to aom or av1.

Does that mean they thrashed everything from Daala? Or did-they/will-they merge some stuff?

[Quikee]

Does that mean they thrashed everything from Daala? Or did-they/will-they merge some stuff?

I was referring to how they prepared the initial AOM repository. After that xiph and cisco guys started to merge their coding tools into the code base. From daala there is their entropy coder and deringing filter merged already. PVQ is waiting to be merged. From cisco there is CLPF merged. Everything is still experimental and in flux - no idea which of the coding tools will stay in.

[Clare]

Netflix understands the limitations of PSNR and SSIM, which is why they've invested a lot of time and energy, working with experts at the University of Southern California, into developing a better objective quality measurement tool - Video Multimethod Assessment Fusion (VMAF) (http://techblog.netflix.com/2016/06/toward-practical-perceptual-video.html). VMAF correlates to subjective (human) visual quality assessments much more closely than PSNR, SSIM, or other available objective metrics. VMAF results are a much more reliable predictor of actual human subjective visual quality evaluations.

I've tried to apply VMAF to my image comparison website and I have dubious results… The numbers show JPEG2000 being a clear winner but visually I can't confirm it, JPEG2000 pictures clearly have more artifacts than Daala or BPG at very low bpp. I don't know if I did something wrong or if VMAF is not fit for still images.

VMAF is first graph on this page: http://wyohknott.github.io/image-formats-comparison/lossy_stats.html

[Jamaika]

I've tried to apply VMAF to my image comparison website and I have dubious results… The numbers show JPEG2000 being a clear winner but visually I can't confirm it, JPEG2000 pictures clearly have more artifacts than Daala or BPG at very low bpp. I don't know if I did something wrong or if VMAF is not fit for still images.
You can describe in detail, how did you it?

I wonder summary of your results for lossless.
http://wyohknott.github.io/image-formats-comparison/lossless_stats.html
Today, I would delete bpg and misapplied X265. I stated that as long as the creator will not add a new codec X265, there is no after at about that mention it.

[CruNcher]

Dalaas most hard to rate still results

Ballet Excercise <- edge ringing is really a problem here
Steinway
Sking
Tennis <- The worst Psy Result
Production

especially Tennis and Ballet Excerise are very problematic more bits should have been spend on the faces and edges and less on the plain colored objects

Neither Dalaa nor ACM AV1 seem to handle the Input Noise efficient enough

Clare could you add a 3rd comparison mode on click 3rd result overlay ?

ACM AV1 already seems improved here much better Psy result :)

ACM AV1 detail retention really improved nicely even if it makes issues like banding/ringing more visible now compared to the dalaa state :)


Adventure with the Windmills result is also really interesting

BPG has a nice lanczos decimation good ringing avoidance (filter) when confronted with High Frequency Noise :)

Detail Retention improvement of AV1 gets best visible here :)

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&ogv=t&aom=t

though surely some time will still pass reaching these low bitrate results :)

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=t&aom=t


http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&ogv=t&aom=t

http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&bpg=t&aom=t

http://wyohknott.github.io/image-formats-comparison/#sking*3:1&bpg=t&aom=t

though BPG "eats" parts of the pixel at the tiny level and so destroys whole objects uniformity better to compare @ small level bellow to many really annoying reconstruction failures.

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=s&aom=s

But still better then AV1s current ringing mess :(

at lower then medium AV1 has no real chance with your setup vs bpg and still at medium its psy issues stay problematic

So damn close and partly above jpeg2000 though :)

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&jp2=m&aom=m

improvements over dalaa @ medium are also clearly visible less reconstruction failures

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&ogv=m&aom=m

This is so freaking close only the ringing and some chroma issues :D

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=m&aom=m

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=ll&aom=ll

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&png=ll&aom=ll

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=ll&aom=ll

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&bpg=l&aom=l

@Clare

how do the High Freqency Noise inputs with AV1 look if you leave AQ out maybe it hurts the lower bit distribution to much ending in those awful ringing overflow results ?

aomenc-+d8003fe.exe --passes=2 --end-usage=q --cq-level=$Q

ANd how hard does VMAF punish the ringing ?

[Clare]

Clare could you add a 3rd comparison mode on click 3rd result overlay ?

I didn't do the coding of the tool, so I wouldn't know how to to modify it.

BPG has a nice lanczos decimation good ringing avoidance (filter) when confronted with High Frequency Noise :)

I found it good visually too but it actually smooths out a lot of details comparing to Daala and AV1. AV1 was marginally improved when it added its deringing filter.


how do the High Freqency Noise inputs with AV1 look if you leave AQ out maybe it hurts the lower bit distribution to much ending in those awful ringing overflow results ?

I actually don't know, I've only made some tests with differents settings on Mercado de Lavradores, 1 retained more details, 0, 2, &3 were very simillar, more smoothed like BPG.

ANd how hard does VMAF punish the ringing ?
I don't really know what features it favors, just that its results surprise me. I know that JPEG artifacts are often considered more "visually pleasing" than others which smooth details like WebP, but I didn't expect to have both MozJPEG and JPEG2000 with such an advantage.
VMAF is computed according to a dataset it has "learned" from provided by Netflix, but this dataset was made from videos, so I'm not sure the VMAF is actually a good tool with this dataset for still pictures.

[mzso]

Already posted this in the AV1 thread (http://forum.doom9.org/showthread.php?p=1785666#post1785666), but since it's also related to VP9, posting it here as well:

The Netflix encoding department had a new meet-up where they discussed VP9 vs. H.265 vs. H.264. The Alliance for Open Media was also there and gave a presentation on AV1, where they said they are aiming for a 50% increase in efficiency over VP9/H.265 with AV1. They also said that AV1 in it's current state already beats VP9 by 25-30% (with not yet released Google internal tools). They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:

https://youtu.be/thvSyJN1vsA

:eek:

Yay! let's make everyone buy new CPUs/devices! We're any an consumer economy anyway... God forbid increasing bandwidth costs cut into mega rich corporations' profits. Win-win. (not for the users)

[Motenai Yoda]

if they increase again av1 compression time nobody out industry will use it

btw It's not clear the vp9 part, they talk about up 17% of efficiency loss in 2 pass encoding, but their codec comparison is done with all 2 pass encodes? or costant quantizer/ crf ones?

[kathykit]

Thank you so much!
Thanks of the information! Useful!

[Motenai Yoda]

You're question is probably being answered in the video at the 1 hour 21 minutes 28 seconds mark:

https://youtu.be/thvSyJN1vsA?t=1h21m28s

Thank you, so actually vp9 quantizer based encode will be almost in pair with x265

The Netflix encoding department also has another video up where they explain their internal encoding workflow and where they are stating that quality is more important for them than speed, since they encode simultaneously in chunks distributed over several machines anyway and stitch it together afterwards, see:

https://youtu.be/fsRLHHIoC6E
As I wrote "Industry"

[sneaker_ger]

Netflix is now also using VP9 but currently only for downloads to Android and iOS(*). Streaming to these devices will follow "in the near future".
http://techblog.netflix.com/2016/12/more-efficient-mobile-encodes-for.html

https://lh4.googleusercontent.com/Rd23yc29qLQtG0J0Vg7EdHUs0lFYcvB7knDWFAm1LU6zAOx-RWOCUpAhH1KgFgsxr4fyfR7LcQN6g-EofvSZerV2JvLbi-WOT2_MeuvgGBKkCR_8sFqLnuwHRxrWSKaxK-iDlN61

(*) Well, the blog mentions iOS. I'm not actually sure if Apple now supports VP9. IIRC they were one of the biggest supporters of H.264 for HTML5.

[dapperdan]

I read it as iOS getting the AVCHi-Mobile encodes and Android getting VP9-mobile, which judging by their graph means the Androids will get slightly better quality and/or smaller file size.

[sneaker_ger]

That makes a lot of sense.

[CruNcher]

Youtube is currently in the major phase of VP9 4K introduction so many content already transcoded in so many different bitrate states :)

It will be really interesting how long it will take for them content wise to own 4K user content at this rate especially asian content is flooding it daily now.

It's also in it's core the biggest push of Matroska (as .webm) we ever saw happening and also Opus reach gets so much bigger now :)

If this continues at this rate Netflix Hollywood catalog will be no compare ;)

If users gonna accept it this way also and prefer it over HEVC that would be a fundamental step towards AV1 and it's introduction :)

Especialy interesting lot of the content will be in the end transcoded 4K AVC/HEVC input :D

Yay! let's make everyone by new CPUs/devices! We're any an consumer economy anyway... God forbid increasing bandwidth costs cut into mega rich corporations' profits. Win-win. (not for the users)

Isn't that equation way to simple ;) ?

[dapperdan]

I wonder if the investment in VP8 etc. is now positive for Google. It seemed like a big gamble at the time, but I guess at their scale bandwidth must add up quickly (an article the other day about Android app updates claimed they were saving Petabytes every day due to a relatively simple change in how they sent them) and they seem to have succeeded in changing the conversation on royalty free formats for the web with everyone but Apple publicly on board with AV1, which I guess must have concrete savings attached.

[mzso]

I wonder if the investment in VP8 etc. is now positive for Google. It seemed like a big gamble at the time, but I guess at their scale bandwidth must add up quickly (an article the other day about Android app updates claimed they were saving Petabytes every day due to a relatively simple change in how they sent them) and they seem to have succeeded in changing the conversation on royalty free formats for the web with everyone but Apple publicly on board with AV1, which I guess must have concrete savings attached.

A measly hundred million for a codec by a company that's worth tens of billions? That's nothing. I wouldn't consider it a small gamble. (In comparison AMD buying ATI was a huge gamble) They could have bought a dozens of such companies without much negative effects.

What's surprising to me that with all the effort put into codecs they couldn't make youtube half-way decent. It's still the buggy steaming pile it ever was.
Some parts got definitely worse. They filter every upload automatically so it's filled with butchered (mirrored, cropped, sped-up, etc) videos. Yet they don't filter duplicates, or 100 times re-encoded videos. Even the more modern codecs are used to cut down on the already inadequate bitrate, rather than improving quality. It's as if their main purpose was to make the experience worse for youtube users.

[CruNcher]

1. Not sure what you brabling about first of all what for duplicates of user generated content ?
2. Bitrate is wrong i saw as high as 20 mbps allready for VP9 transcoded for 4K that's a lot for WEB and most of target devices.
3. All Post Processing filter things are only for specific target devices in specifc profiles if the user doesn't adhere to them fully in compliance it's bug fixing of wrong user encoded content nothing more to have 1a delivery experience within the profile boundaries of every target device.

Sure they have to be compromises that is normal if you want to reach as many users as possible on so many devices you have todo compromises these can save you millions of users be able to watch it in the end for 1 user being unhappy with it the equation is simple, you lose against 1 million happy users being able to enjoy and bring Add Revenues in.

Apple fights with the same issues over and over when introducing a new CODEC to their Ecosystem they need to be carefull with it calculating the lose vs win and happy vs unhappy users.

You can never ever make everyone happy that wont work but you can find some balance and VP9 tries that very heavily.


This is why you also go see skepticsm about HEVC on many other platforms still that will want to reach even 1 percent more user base no matter the quality cost at all and that cant do 100 of different encodes at all targeting everything as the big platforms ;)

[sneaker_ger]

AMD "Crimson ReLive" drivers are now available via amd.com (http://support.amd.com/en-us/download). Add VP9 decoding.
VP9 Decode Acceleration:
4K 60Hz GPU-Accelerated Video Streaming enabled on supported Google™ Chrome web browsers.

Requires supported Chrome™ web browser versions with Hardware Acceleration enabled. Compatible with AMD Radeon™ GCN and Radeon RX 400 series enabled products on Windows® 7/8.1/10.

[dapperdan]

"Overview of the VP9 codec":

https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/

[Clare]

"Overview of the VP9 codec":

https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/

I'm still pissed he hasn't open sourced his VP9 encoder. :angry:

[CruNcher]

Ehh he not even released it into Public he stated clearly "its a commercial product" ;)

And it's most likely that at least some Youtube transcodes coming from his Eve Encoder codebase actually ;)

[Clare]

I'm doing some encode using FFMPEG and vpxenc and I have some curious results. Can anyone explain to me why these two similar encodes give wildly different results?

ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -an out.webm
vpxenc --good --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m

For the same parameters I get very different filesizes in the end, with FFMPEG the file is 3,93 MiB, whereas with vpxenc it is only 2,26 MiB. Both are using libvpx 1.6.0. I don't get it.

[smok3]

@Clare: -crf 20 and --cq-level=20 are the same thing?

[Jamaika]

@Clare: And if you used Adobe Webm that you will have the third result. it was written about it.;)
libvpx-vp9 encoder AVOptions:
-auto-alt-ref <int> E..V.... Enable use of alternate reference frames (2-pass only) (from -1 to 2) (default -1)
-lag-in-frames <int> E..V.... Number of frames to look ahead for alternate reference frame selection (from -1 to INT_MAX) (default -1)
-arnr-maxframes <int> E..V.... altref noise reduction max frame count (from -1 to INT_MAX) (default -1)
-arnr-strength <int> E..V.... altref noise reduction filter strength (from -1 to INT_MAX) (default -1)
-arnr-type <int> E..V.... altref noise reduction filter type (from -1 to INT_MAX) (default -1)
backward E..V....
forward E..V....
centered E..V....
-tune <int> E..V.... Tune the encoding to a specific scenario (from -1 to INT_MAX) (default -1)
psnr E..V....
ssim E..V....
-deadline <int> E..V.... Time to spend encoding, in microseconds. (from INT_MIN to INT_MAX) (default good)
best E..V....
good E..V....
realtime E..V....
-error-resilient <flags> E..V.... Error resilience configuration (default 0)
default E..V.... Improve resiliency against losses of whole frames
partitions E..V.... The frame partitions are independently decodable by the bool decoder, meaning that partitions can be decoded even though earlier partitions have been lost. Note that intra predicition is still done over the partition boundary.
-max-intra-rate <int> E..V.... Maximum I-frame bitrate (pct) 0=unlimited (from -1 to INT_MAX) (default -1)
-crf <int> E..V.... Select the quality for constant quality mode (from -1 to 63) (default -1)
-static-thresh <int> E..V.... A change threshold on blocks below which they will be skipped by the encoder (from 0 to INT_MAX) (default 0)
-drop-threshold <int> E..V.... Frame drop threshold (from INT_MIN to INT_MAX) (default 0)
-noise-sensitivity <int> E..V.... Noise sensitivity (from 0 to 4) (default 0)
-undershoot-pct <int> E..V.... Datarate undershoot (min) target (%) (from -1 to 100) (default -1)
-overshoot-pct <int> E..V.... Datarate overshoot (max) target (%) (from -1 to 1000) (default -1)
-cpu-used <int> E..V.... Quality/Speed ratio modifier (from -8 to 8) (default 1)
-lossless <int> E..V.... Lossless mode (from -1 to 1) (default -1)
-tile-columns <int> E..V.... Number of tile columns to use, log2 (from -1 to 6) (default -1)
-tile-rows <int> E..V.... Number of tile rows to use, log2 (from -1 to 2) (default -1)
-frame-parallel <boolean> E..V.... Enable frame parallel decodability features (default auto)
-aq-mode <int> E..V.... adaptive quantization mode (from -1 to 3) (default -1)
none E..V.... Aq not used
variance E..V.... Variance based Aq
complexity E..V.... Complexity based Aq
cyclic E..V.... Cyclic Refresh Aq
-level <float> E..V.... Specify level (from -1 to 6.2) (default -1)
-speed <int> E..V.... (from -16 to 16) (default 1)
-quality <int> E..V.... (from INT_MIN to INT_MAX) (default good)
best E..V....
good E..V....
realtime E..V....
-vp8flags <flags> E..V.... (default 0)
error_resilient E..V.... enable error resilience
altref E..V.... enable use of alternate reference frames (VP8/2-pass only)
-arnr_max_frames <int> E..V.... altref noise reduction max frame count (from 0 to 15) (default 0)
-arnr_strength <int> E..V.... altref noise reduction filter strength (from 0 to 6) (default 3)
-arnr_type <int> E..V.... altref noise reduction filter type (from 1 to 3) (default 3)
-rc_lookahead <int> E..V.... Number of frames to look ahead for alternate reference frame selection (from 0 to 25) (default 25)
Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-allowed=<arg> Spatial resampling enabled (bool)
--resize-width=<arg> Width of encoded frame
--resize-height=<arg> Height of encoded frame
--resize-up=<arg> Upscale threshold (buf %)
--resize-down=<arg> Downscale threshold (buf %)
--end-usage=<arg> Rate control mode
vbr, cbr, cq, q
--target-bitrate=<arg> Bitrate (kbps)
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
--undershoot-pct=<arg> Datarate undershoot (min) target (%)
--overshoot-pct=<arg> Datarate overshoot (max) target (%)
--buf-sz=<arg> Client buffer size (ms)
--buf-initial-sz=<arg> Client initial buffer size (ms)
--buf-optimal-sz=<arg> Client optimal buffer size (ms)

Edit:
Oh, I don't know what you do compiled, but ffmpeg contains only the first version of libvpx 1.6.

[mzso]

So VP9 seems pretty mature these days, right?
I usually use these settings generally to encode AVC:

ffmpeg -i -g 30 -vcodec libx264 -preset slower -crf 18 ki.mkv

What would be roughly identical quality wise with VP9? (with sparing a bit of space, otherwise it's pointless) Are there any convenient presets for encoding speed as for x264?

Can I encode full range 4:4:4 videos like I do with libx264?
ffmpeg -i -pix_fmt yuvj444p -vf scale=out_color_matrix=bt709 -g 30 -vcodec libx264 -preset slower -crf 18 -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 out.mkv
(Which I normally do for screencasts)

[Clare]

@Clare: -crf 20 and --cq-level=20 are the same thing?
I think so, at least on the libvpx wiki, both methods are described as Constant Quality encoding (quote: "crf is the quality value (0-63 for VP9)", si the same thing as cq level).

Oh, I don't know what you do compiled, but ffmpeg contains only the first version of libvpx 1.6.
I didn't compile it myself, it's the latest version from my Linux distro.

[Jamaika]

What would be roughly identical quality wise with VP9? (with sparing a bit of space, otherwise it's pointless) Are there any convenient presets for encoding speed as for x264?
ffmpeg.exe -loglevel verbose -i rgb24_input.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt709:out_range=tv,format=yuv420p - |
x264.exe --demuxer y4m --input-csp i420 --input-depth 8 --input-range tv --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps ??? --keyint 2xfps --nal-hrd none (--vbv-bufsize 40000 --vbv-maxrate 40000)???
--colormatrix bt709 --colorprim bt709 --transfer bt709 --range tv --output "x264_420p_crf28.h264" -

ffmpeg.exe -loglevel verbose -i rgb24_input.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt709:out_range=tv,format=yuv420p - |
vpxenc.exe --bit-depth=8 --input-bit-depth=8 --i420 --codec=vp9 --good --threads=4 --cpu-used=4 --profile=0 --drop-frame=??? --end-usage=q --cq-level=48 --target-bitrate=0 --min-q=0 --kf-max-dist=2xfps --auto-alt-ref=1
--frame-boost=1 --aq-mode=0 --color-space=bt709 --verbose --debug??? --pass=1 --passes=1 --output=114.webm -
Can I encode full range 4:4:4 videos like I do with libx264?
No one wants such comparisons codecs. Everyone wants to prove that the codec is better to the competition.
What is the point of use i444? As you have a source i444. Reportedly TV, Bluray x264 miserably support i444.
(Which I normally do for screencasts)
ffmpeg.exe -loglevel verbose -i yuv420p_rangetv_bt709_input.mp4/mov/mkv -an -f image2 -vf scale=1920:1080:in_color_matrix=bt709:in_range=tv:out_color_matrix=rgb:out_range=pc,format=rgb24 -c:v png -an image001.png

[Neavrie]

@Clare
Try this:
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an out.webm
vpxenc --good -p 1 --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m

or this:
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an -pass 1 -f null -
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an -pass 2 out.webm

vpxenc --good -p 2 --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m

[mzso]

ffmpeg.exe -loglevel verbose -i rgb24_input.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt709:out_range=tv,format=yuv420p - |
x264.exe --demuxer y4m --input-csp i420 --input-depth 8 --input-range tv --output-csp i420 --threads 4 --preset veryslow --tune grain --crf 28 --fps ??? --keyint 2xfps --nal-hrd none (--vbv-bufsize 40000 --vbv-maxrate 40000)???
--colormatrix bt709 --colorprim bt709 --transfer bt709 --range tv --output "x264_420p_crf28.h264" -

ffmpeg.exe -loglevel verbose -i rgb24_input.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt709:out_range=tv,format=yuv420p - |
vpxenc.exe --bit-depth=8 --input-bit-depth=8 --i420 --codec=vp9 --good --threads=4 --cpu-used=4 --profile=0 --drop-frame=??? --end-usage=q --cq-level=48 --target-bitrate=0 --min-q=0 --kf-max-dist=2xfps --auto-alt-ref=1
--frame-boost=1 --aq-mode=0 --color-space=bt709 --verbose --debug??? --pass=1 --passes=1 --output=114.webm -

No one wants such comparisons codecs. Everyone wants to prove that the codec is better to the competition.
What is the point of use i444? As you have a source i444. Reportedly TV, Bluray x264 miserably support i444.

ffmpeg.exe -loglevel verbose -i yuv420p_rangetv_bt709_input.mp4/mov/mkv -an -f image2 -vf scale=1920:1080:in_color_matrix=bt709:in_range=tv:out_color_matrix=rgb:out_range=pc,format=rgb24 -c:v png -an image001.png

Thanks for the answer. For the first part I didn't want full range just a generic replacement for "ffmpeg -i -g 30 -vcodec libx264 -preset slower -crf 18 ki.mkv" (Not for full range, i444)
Also I only want to use ffmpeg, and don't want to pipe to other tools.




No one wants such comparisons codecs. Everyone wants to prove that the codec is better to the competition.
What is the point of use i444? As you have a source i444. Reportedly TV, Bluray x264 miserably support i444.

ffmpeg.exe -loglevel verbose -i yuv420p_rangetv_bt709_input.mp4/mov/mkv -an -f image2 -vf scale=1920:1080:in_color_matrix=bt709:in_range=tv:out_color_matrix=rgb:out_range=pc,format=rgb24 -c:v png -an image001.png

I don't understand what you're saying. What do you mean by "comparisons codecs". Of course everyone wants a better codec, that doesn't exclude 4:4:4 and full-range support

The point of 4:4:4 is to not destroy color information before you even encode the video.

[Jamaika]

I meant x264 vs VP9. Can't compare crf codecs because the files are different bitrates. Different amounts of data in frames B and P. This doesn't mean that it is less worse. Codecs may have better conversion algorithms.

[mzso]

I meant x264 vs VP9. Can't compare crf codecs because the files are different bitrates. Different amounts of data in frames B and P. This doesn't mean that it is less worse. Codecs may have better conversion algorithms.

I wanted settings to roughly the same quality, nothing more.

[Clare]

So VP9 seems pretty mature these days, right?
I usually use these settings generally to encode AVC:

ffmpeg -i -g 30 -vcodec libx264 -preset slower -crf 18 ki.mkv

What would be roughly identical quality wise with VP9? (with sparing a bit of space, otherwise it's pointless) Are there any convenient presets for encoding speed as for x264?

Can I encode full range 4:4:4 videos like I do with libx264?
ffmpeg -i -pix_fmt yuvj444p -vf scale=out_color_matrix=bt709 -g 30 -vcodec libx264 -preset slower -crf 18 -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 out.mkv
(Which I normally do for screencasts)

There is no direct relation between x264's and vp9's crf, it depends on the video. I'd say x264 crf 18 would be similar to a crf between 29 and 33 for vp9.

For encoding speed the main setting is '-cpu-used', between -8 and +8. Higher values speed up the encode at the cost of quality. 1 is the default, usually 1 or 2 is used. You also need to enable multithreading with thread 8 and tile-columns.

For yuv444p, you need to set the profile to 1.

So something like:
ffmpeg -y -i in.y4m -pix_fmt yuv444p -c:v libvpx-vp9 -b:v 0 -profile 1 -crf [29-33] -quality good -threads 8 -cpu-used 2 -tile-columns 4 -an out.mkv

I don't know about colormatrix or full range settings.

[mzso]

Is there a decent guide to the settings at least. Seems a lot more convoluted than libx264. There's "quality", "speed", "cpu-used ", where libx264 had the convenient "preset" options.

Also the video is encoded much faster if I increase crf, which is odd, and also unlike libx264. At the same complexity it should be the same as on higher quality (aka bitrate) settings.

[LigH]

I wanted settings to roughly the same quality, nothing more.

:rolleyes:

During the last years, people have explained repetitively why that won't work well (mainly because you can't really measure a subjective concept like "quality" with objective numbers). The only recommendable strategy is to try to create the same size, as good as it gets, and then compare the quality subjectively (looking at them and deciding which kind of loss looks more annoying).

[Jamaika]

@Clare
Try this:
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an out.webm
vpxenc --good -p 1 --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m
It is some idea. Number of pframes the same. Almost the same, but not the same.
https://www.sendspace.com/filegroup/fhv%2FFn%2BeEFcAMUSn5DQPxA
What bothers me more? Changed framerate in not the newest vpxenc.
Frame rate : 30.036 FPS
Edit:
http://forum.doom9.org/showthread.php?p=1784385#post1784385

[mzso]

:rolleyes:

During the last years, people have explained repetitively why that won't work well (mainly because you can't really measure a subjective concept like "quality" with objective numbers). The only recommendable strategy is to try to create the same size, as good as it gets, and then compare the quality subjectively (looking at them and deciding which kind of loss looks more annoying).

That's why I said roughly, so that I had a starting point

There is no direct relation between x264's and vp9's crf, it depends on the video. I'd say x264 crf 18 would be similar to a crf between 29 and 33 for vp9.

For encoding speed the main setting is '-cpu-used', between -8 and +8. Higher values speed up the encode at the cost of quality. 1 is the default, usually 1 or 2 is used. You also need to enable multithreading with thread 8 and tile-columns.

For yuv444p, you need to set the profile to 1.

So something like:
ffmpeg -y -i in.y4m -pix_fmt yuv444p -c:v libvpx-vp9 -b:v 0 -profile 1 -crf [29-33] -quality good -threads 8 -cpu-used 2 -tile-columns 4 -an out.mkv

I don't know about colormatrix or full range settings.

Thanks for the tips!
Without specifying tile-columns multi-threading doesn't work? (The options "quality" (good, best, realtime), "speed" don't do anything useful?)


On a different note:

It looks like I actually can encode full range:
ffmpeg -i infile -pix_fmt yuv444p -vf scale=out_color_matrix=bt709:out_range=pc -g 30 -vcodec libvpx-vp9 -b:v 0 -quality good -threads 4 -cpu-used 1 -crf 35 vp9-fr.webm
But how do I add correct metadata so that it appears normally? Limited ranges is specified by ffmpeg, because madvr claims: "limited range (claims upstream)", also "matrix bt.709 (best guess)", so that's not specified at all.

I used "-pix_fmt yuvj444p -vf scale=out_color_matrix=bt709 [...] -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709 out.mkv" with libx264 and it appeared normally.

Edit: Nevermind, found it: Just need to add -pix_fmt yuv444p -vf scale=out_color_matrix=bt709:out_range=pc -color_range pc -colorspace bt709

[Clare]

Is there a decent guide to the settings at least. Seems a lot more convoluted than libx264. There's "quality", "speed", "cpu-used ", where libx264 had the convenient "preset" options.

Also the video is encoded much faster if I increase crf, which is odd, and also unlike libx264. At the same complexity it should be the same as on higher quality (aka bitrate) settings.

It is more convoluted, I hope they make a simpler encoder for AV1. I don't know what is the "speed" settings from ffmpeg, there's nothing similar in vpxenc manual.

[nevcairiel]

Is there a decent guide to the settings at least. Seems a lot more convoluted than libx264. There's "quality", "speed", "cpu-used ", where libx264 had the convenient "preset" options.

"speed" is just an (legacy) alias for "cpu-used", which is your primary knob for performance/quality trade-off. Its a bit oddly named for sure.
cpu-used=0 is the slowest and highest quality mode, going up to 9 for vp9 as the fastest mode.

On top of that, you have the quality mode, which is either "good" or "best" (or "realtime" which is only useful for what the name suggests it would be).
"best" is often overkill and even the vpx docs don't recommend using it, its akin to a placebo mode in libx264.

So in short, start with quality=good (which is also the default, so may as well skip it) and try a few cpu-used modes to dial in your performance/quality tradeoff.

Various explanations for the options are here, if it wasn't linked above already:
http://www.webmproject.org/docs/encoder-parameters/

Note that not all options map 1:1 if you use ffmpeg as a wrapper to the encoder, but most probably do.

[mzso]

@nevcairiel
Thanks!

[Clare]

@Clare
Try this:
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an out.webm
vpxenc --good -p 1 --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m

or this:
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an -pass 1 -f null -
ffmpeg -y -i in.y4m -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 8 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-strength 5 -an -pass 2 out.webm

vpxenc --good -p 2 --threads=8 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 -o out.webm in.y4m
I tried that but it doesn't account for the large difference in size.

[Neavrie]

@Clare
vpxenc uses 2-pass mode by default. That's why you get difference in file size.

[Clare]

@Clare
vpxenc uses 2-pass mode by default. That's why you get difference in file size.

Huh you're right! I didn't think a two-pass encode would bring such a huge difference in file size. Now I get the exact same metrics for both FFMPEG and vpxenc.

Thanks a lot.

[Jamaika]

@Clare
For pass one is 600kb difference in 100 frames 4K.
For pass two isn't difference between the file size(~100kb). This is puzzling, but it is worth knowing. So, I understand that the tests should only do to pass two, because otherwise there is no sense.
The correct command is:
ffmpeg.exe -loglevel trace -y -i iphone6s_4k.yuv -c:v libvpx-vp9 -b:v 0 -passlogfile vp9.log -crf 20 -quality good -threads 4 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-type 3 -arnr-strength 5 -pass 1 -an out1a.ivf
ffmpeg.exe -loglevel trace -y -i iphone6s_4k.yuv -c:v libvpx-vp9 -b:v 0 -passlogfile vp9.log -crf 20 -quality good -threads 4 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-type 3 -arnr-strength 5 -pass 2 -an out1b.ivf
vpxenc.exe -v --ivf --good --passes=2 --pass=1 --fpf=vp9.pass --threads=4 --target-bitrate=256 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 --arnr-maxframes=7 --arnr-type=3 --arnr-strength=5 -o NUL iphone6s_4k.yuv
vpxenc.exe -v --ivf --good --passes=2 --pass=2 --fpf=vp9.pass --threads=4 --target-bitrate=256 --cpu-used=2 --tile-columns=4 --end-usage=q --cq-level=20 --arnr-maxframes=7 --arnr-type=3 --arnr-strength=5 -o out2.ivf iphone6s_4k.yuv

[sneaker_ger]

vpxenc has automated two-pass. You only run it once. If you run it twice you are basically doing 4 passes with the first 2 being wasted into NUL. Try running it only once and check if that is the case. It was for me the last time I tested. (Granted, long time ago and I don't remember the commands I used from the top of my head.)

[Jamaika]

OK. I accepted the news, but this command ffmpeg gave different results. Different (~300kb):(
ffmpeg.exe -loglevel trace -y -i iphone6s_4k.yuv -c:v libvpx-vp9 -b:v 0 -crf 20 -quality good -threads 4 -cpu-used 2 -tile-columns 4 -arnr-maxframes 7 -arnr-type 3 -arnr-strength 5 -pass 2 -an out1a.ivf

[easyfab]

Perhaps others settings have not the same defaults in FFmpeg and Vpxenc ?

[sneaker_ger]

Radeon Software Crimson ReLive Edition 16.12.2 Highlights
Fixed Issues
Chromium may fail to utilize hybrid decode for VP9 content.
http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-ReLive-Edition-16.12.2-Release-Notes.aspx

[Selur]

According to https://en.wikipedia.org/wiki/VP9:
VP9 supports HDR video using Hybrid Log-Gamma (HLG) and Perceptual Quantizer (PQ)
but when I compile vp9 using (https://github.com/jb-alvarado/media-autobuild_suite) the vpxenc command line options don't mention it and I can't find any documentation about 'VP9-HLG' which describes how to create such content.
-> Does anyone here have a clue how to create VP9 with HLG ?

Cu Selur

[Jamaika]

VP9 supports HDR video using Hybrid Log-Gamma (HLG) and Perceptual Quantizer (PQ)
https://www.tapatalk.com/topic/47413-avsforum/2559657-hdr-android-7-0
I am writing as an amateur because he didn't compile VP9.
For me, reading google is an option only android 7.0. And I think this is April Fool's Day.
Then it was written that this isn't an option codec VP9 only container matroska. Not this topic.;)
Option container matroska can be found in the directory libwebm / mkvmuxer / mkvmuxerutil.cc
bool IsTransferCharacteristicsValueValid(uint64_t value) {
switch (value) {
case mkvmuxer::Colour::kIturBt709Tc:
case mkvmuxer::Colour::kUnspecifiedTc:
case mkvmuxer::Colour::kReservedTc:
case mkvmuxer::Colour::kGamma22Curve:
case mkvmuxer::Colour::kGamma28Curve:
case mkvmuxer::Colour::kSmpte170MTc:
case mkvmuxer::Colour::kSmpte240MTc:
case mkvmuxer::Colour::kLinear:
case mkvmuxer::Colour::kLog:
case mkvmuxer::Colour::kLogSqrt:
case mkvmuxer::Colour::kIec6196624:
case mkvmuxer::Colour::kIturBt1361ExtendedColourGamut:
case mkvmuxer::Colour::kIec6196621:
case mkvmuxer::Colour::kIturBt202010bit:
case mkvmuxer::Colour::kIturBt202012bit:
case mkvmuxer::Colour::kSmpteSt2084:
case mkvmuxer::Colour::kSmpteSt4281Tc:
case mkvmuxer::Colour::kAribStdB67Hlg:
return true;
}
return false;
}
Edit: Ok, In VP9 has inactive option HDR if we compile (hdr_util.cc, file_util.cc). In theory it should work. The strange thing is that I can't add a transfer option.
https://chromium-review.googlesource.com/#/c/400084/

PS The codec has damaged the function fps.;)

[nevcairiel]

-> Does anyone here have a clue how to create VP9 with HLG ?



VP9 itself doesn't signal any of the HDR metadata, neither in HDR10 (ie. PQ) mode or HLG mode, it needs to be signaled through the container (ie. webm/matroska).

So basically, just encode the content mastered in HLG, and then instruct the container to convey the HLG transfer information during muxing.
Luckily HLG doesn't need any fancy metadata, other then signaling that the content is in fact HLG.

[Selur]

So we will have to wait till muxers like mkvtoolnix, mp4box, ffmpeg,.. support signaling the content as HLG and there isn't anything needed for the encoders to support. :)
Thanks for the explanations.

Cu Selur

[sneaker_ger]

For mkvmerge see:
https://mkvtoolnix.download/doc/mkvmerge.html#d4e2614
https://www.matroska.org/technical/specs/index.html#Colour

[david.copperfield1337]

https://github.com/YouTubeHDR/hdr_metadata

Gesendet von meinem Nexus 7 mit Tapatalk

[Jamaika]

https://github.com/YouTubeHDR/hdr_metadata

Gesendet von meinem Nexus 7 mit Tapatalk
Sorry, something I don't understand. Youtube boasts movies VP9 HDR. Unfortunately, I don't see movies 10bit. Are they done with HDR at 8bit color range tv?
./src/mkvmerge \
-o output.mkv\
--colour-matrix 0:9 \
--colour-range 0:1 \
--colour-transfer-characteristics 0:16 \
--colour-primaries 0:9 \
--max-content-light 0:1000 \
--max-frame-light 0:300 \
--max-luminance 0:1000 \
--min-luminance 0:0.01 \
--chromaticity-coordinates 0:0.68,0.32,0.265,0.690,0.15,0.06 \
--white-colour-coordinates 0:0.3127,0.3290 \
input.mov --colour-bits-per-channel 0:10 ???
--chroma-subsample 0:1,0 ???
--colour-range 0:2 ???

https://www.youtube.com/watch?v=tO01J-M3g0U

[sneaker_ger]

10 bit VP9 is there. Doesn't have to be tagged as 10 bit on the container level to be 10 bit.
https://forum.doom9.org/showpost.php?p=1785300&postcount=543

Meaning of Matroska values are in the specs:
https://www.matroska.org/technical/specs/index.html#Colour

[Jamaika]

Doesn't have to be tagged as 10 bit on the container level to be 10 bit.

None of this don't understand.:(
"Free YouTube download" doesn't see the color matrix or HDR. For me fake.
Stream #0:1(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709/unknown/unknown), 3840x2160, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)

[sneaker_ger]

Read the post I linked. youtube-dl (https://rg3.github.io/youtube-dl/) can download the 10 bit (profile 2) streams.

[Selur]

@sneaker_ger: Thanks.

[Jamaika]

Read the post I linked. youtube-dl (https://rg3.github.io/youtube-dl/) can download the 10 bit (profile 2) streams.
Ah, I understood what was going on. I don't know why so many intricacies.
youtube-dl.exe -o "The World in HDR.webm" -v -f "(mp4)bestvideo/best[height=2160]+bestaudio/best[height=2160]" https://www.youtube.com/watch?v=tO01J-M3g0U
And even displays ffmpeg the message.
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)
Side data:
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.001000, max_luminance=1000.000000
..., but where came it from? It's only change for file 10/12bit apart from the colour range and matix.

[Jamaika]

2017-01-09 v1.6.1 "Long Tailed Duck"
This release improves upon the VP9 encoder and speeds up the encoding and
decoding processes.

- Upgrading:
This release is ABI compatible with 1.6.0.

- Enhancements:
Faster VP9 encoding and decoding.
High bit depth builds now provide similar speed for 8 bit encode and decode
for x86 targets. Other platforms and higher bit depth improvements are in
progress.

- Bug Fixes:
A variety of fuzzing issues.
https://chromium.googlesource.com/webm/libvpx/+/v1.6.1
Patches are added to ffmpeg.;)

[Leeloo Minaï]

Can someone provide a vpxenc 1.6.1 build for Windows x64 ?

[LigH]

I can try to run jb-alvarado's media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite) tonight...

[wiak]

Can someone provide a vpxenc 1.6.1 build for Windows x64 ?
lets hope this works
https://awesome.nwgat.ninja/misc/libvpx-1.6.1-win64.7z

[LigH]

vpx v1.6.1-95-g9efc42f4f (https://www.mediafire.com/file/an4zqj21lfh4bp2/vpx_v1.6.1-95-g9efc42f4f.7z) (static builds, MSYS2, GCC 6.3.0, Win32+Win64)

[Leeloo Minaï]

Thanks for your help !
I asked for the latest standalone version in order to compare with older revisions and FFmpeg builds.

In fact, i get slower encoding for revision 1.6.0 and 1.6.1 than with previous revisions 1.4.0 and 1.5.0 using vpxenc at same parameters (the same appears with FFmpeg too) :

Video properties :
384x256 @ 55fps, 400 frames, YUV420 (game capture from the arcade game "R-Type" (1987) using MAME emulator)

Encoding parameters :
vpxenc test.y4m -o vp9.webm --codec=vp9 -p 2 --pass=1 --fpf=stats.log --good --cpu-used=1 --target-bitrate=400 --end-usage=vbr --auto-alt-ref=1 --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 --static-thresh=0 --drop-frame=0 --min-q=0 --max-q=63
vpxenc test.y4m -o vp9.webm --codec=vp9 -p 2 --pass=2 --fpf=stats.log --good --cpu-used=1 --target-bitrate=400 --end-usage=vbr --auto-alt-ref=1 --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 --static-thresh=0 --drop-frame=0 --min-q=0 --max-q=63


Encoding times :
- 1.4.0 : 1:38,56 (~4.06 fps)
- 1.5.0 : 1:26,25 (~4.64 fps)
- 1.6.1 : 1:38,78 (~4.04 fps)

My laptop is rather old and low-powered (Pentium Dual-Core @ 2.2Ghz under Windows 7 x64), but i still laugh when i read "Faster encoding" :rolleyes:

[Selur]

my guess is the 'faster encoding' would come from some assembler optimizations which might not help on older systems,...

[wiak]

my guess is the 'faster encoding' would come from some assembler optimizations which might not help on older systems,...

that was my first idea too, newer systems has alot of new instructions and moar cores!

[Nintendo Maniac 64]

moar cores!

You know it's becoming mainstream when even Intel is supposedly hopping on this bandwagon with Coffee Lake!

AMD was just too ahead of their time.

[wiak]

You know it's becoming mainstream when even Intel is supposedly hopping on this bandwagon with Coffee Lake!

AMD was just too ahead of their time.
they have been ahead of the time for a while, case in point gcn

[CruNcher]

Not only GCN remember Fusion/HSA as well which every console has become part of and where Mantle arose from :)

[LigH]

cries in German

My best available CPU is still a Phenom-II X6. No AVX to boost modern codecs. Part-time paid full-time jobs. Globalization FTW.

[mandarinka]

cries in German

My best available CPU is still a Phenom-II X6. No AVX to boost modern codecs. Part-time paid full-time jobs. Globalization FTW.

With Phenom, your main problem is lack of SSSE3 and SSE4, not lack of AVX. If you need more recent SIMD instructions tho, I see lots of refurbished office desktops with the likes of Core i5-2400 with prices starting at circa 175 € at the etailers that deal in such machines. Maybe that could be a viable way. Also Xeon E5-2600 chips of the "v1" (Sandy Bridge) category are cheap on ebay, but in this case it is hard to get the needed motherboard for cheap.

(And I bet we would all have even shittier computers and living standards were worse, if this "globalization" didn't occur. It's just scapegoat and/or red herring in somebody's agenda, as it happens.)

Sent from my second hand AMD A10-6800K...

[Nintendo Maniac 64]

I wouldn't be surprised if the Ryzen CPUs launching at the end of this month cause the prices on Sandy Bridge CPUs and LGA1155 systems to completely crater.

[mandarinka]

I wouldn't be surprised if the Ryzen CPUs launching at the end of this month cause the prices on Sandy Bridge CPUs and LGA1155 systems to completely crater.

That would be nice, but the prices of those second-hand office desktops are already low if you consider that they have 4 GB of DDR3 (which got more expensive since 2012 instead of getting cheaper) and W7 license sticker and you can use those serials to activate clean installs of W10 on the machine, AFAIK.

Ryzens will launch at prices of i7-7700K and higher, so they might lower prices of second hand gaming computers, motherboards and CPUs like i5-2500K, i7-2600K and other quadcores that gamers or "enthusiasts" have been buying.

[Nintendo Maniac 64]

Ryzens will launch at prices of i7-7700K and higher

You realize there will be fewer-core versions of Ryzen and not just the 8core/16thread variant...

[CruNcher]

Most probably though the most expensive ones 8 core will be launched first for pre adopters and then later the avg consumer 4 core ones following which would be the opposite from the GPU Strategy ;)

[mandarinka]

You realize there will be fewer-core versions of Ryzen and not just the 8core/16thread variant...

I know (https://s23.postimg.org/tqb06wo0p/9d7312ab91d7c638c9760dd5aec3f46ef3c2aa4c300b9ea9.jpg). My estimate is that they will get to about 150-175 USD price level ( 4C/4T). But currently it seems that such SKUs won't be part of the initial launch, it's unknown when will they start to sell.

[CruNcher]

Interesting now it seems we have a standard for Performance indexing with a Number from Intel and AMD :D

Ryzen 3,5,7
Core 3,5,7


which respectively points to 2,4,8 and 4,6,8 cores with a balancing in between thread executions and clock ;)

So in the middle Intel fights vs 6 cores now with 4 and its AVX2 :)

The most interesting compare point between both at those 65W :)

[nevcairiel]

which respectively points to 2,4,8 and 4,6,8 cores with a balancing in between thread executions ;)

But it doesn't, not for Intel anyway.
There is i7s with 4, 6, 8 and 10 cores.