Page 1 of 2

[Implemented] VP9 support

Posted: Sun May 26, 2013 4:06 am
by Ayoross
Hello Guys,

Any plan to add google's VP9 codec as a video compression format ?

http://www.webmproject.org/code/

Re: VP9 support

Posted: Wed May 29, 2013 4:57 pm
by Deleted User 11865
It's not even final yet. Some sort of libvpx support (or preferably, a faster implementation) is planned, but not a high-priority feature.

Re: VP9 support

Posted: Wed May 29, 2013 5:40 pm
by s55
I had a play with VP8 and it was awfully slow. Theres a prototype patch on reviewboard but I not convinced that there wouldn't be an uproar blaming us, when it's just a slow encoder.

IT wasn't able to make realtime encoding on a DVD source when x264 with medium preset was over 150fps (Some 8 to 10 times faster and people moan about this being slow)

I'll give it a shot once the code matures but If it's anything like VP8, it's probably not worth my time.

Re: VP9 support

Posted: Mon Jun 10, 2013 10:22 pm
by Ayoross
VP8 wasn't convincing, but VP9 will be. Even if compression time is ten times the x264's one, if we can have same quality but a much smaller file, it'll be good, I believe.

Re: VP9 support

Posted: Mon Jun 10, 2013 10:41 pm
by JohnAStebbins
:lol: :roll:
The same claims were made of VP8. I'm waiting till I see the pudding.

Then there's the small matter of device support. Google hasn't yet demonstrated that they have the clout necessary to coerce hardware manufacturers to build this into their chips.

Re: VP9 support

Posted: Mon Jun 17, 2013 5:34 pm
by JohnAStebbins
Just for the sake of putting this topic to bed (again), I checked out the latest source code for vp9, built it, and did a quick test.

Code: Select all

git clone https://code.google.com/p/webm.libvpx/
cd webm.libvpx
./configure
make
./vpxenc birds.y4m -o vp8-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp8
./vpxenc birds.y4m -o vp9-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp9
The vp8 encode speed was about 8fps
The vp9 encode started out at about 20 seconds per frame and continued to get slower as it progressed. I stopped it after 10 frames where it had reached 1 minute per frame.

For comparison, x264 medium preset gets 28fps, slow preset gets 18fps, slower preset gets 12fps, veryslow preset gets 9fps, and placebo preset gets 3fps.
So the only thing slower than vp8 is the placebo preset and vp9 can't even find the ballpark.

This is obviously a long long Looong way from usable.

Someone else did a "quick" quality comparison of h.265, x264, vp8, and vp9. vp9 still lost to x264.
http://forum.doom9.org/showpost.php?p=1 ... stcount=71

Re: VP9 support

Posted: Tue Jun 18, 2013 11:03 pm
by TedJ
JohnAStebbins wrote:The vp9 encode started out at about 20 seconds per frame and continued to get slower as it progressed. I stopped it after 10 frames where it had reached 1 minute per frame.
Hey, doesn't everyone have an idle 3 months to encode a movie? ;)

Re: VP9 support

Posted: Tue Jun 18, 2013 11:07 pm
by Deleted User 11865
JohnAStebbins wrote:The vp9 encode started out at about 20 seconds per frame and continued to get slower as it progressed. I stopped it after 10 frames where it had reached 1 minute per frame.
The cool thing is, we can implement TempGaussMC deinterlace and not have it be the bottleneck!

Re: VP9 support

Posted: Thu Oct 10, 2013 4:11 pm
by JohnAStebbins
Before anyone gets all excited about recent claims here... https://groups.google.com/a/webmproject ... O3fF_1Wry4
I sanity checked the claim made of an "x80 speed up for --cpu-used=2".

I pulled the latest code and have run the same test as above using the same input file on the same machine. I now get about 3 fpm. So that cuts the encode time for a movie from 3 months to about 1 month. Improving, but not yet useful unless you can afford a data-center dedicated to encoding like google.

Re: VP9 support

Posted: Thu Oct 10, 2013 5:13 pm
by Deleted User 11865
I wonder how much they had to raise their budget when they added VP8 support to YouTube…

Re: VP9 support

Posted: Mon Jan 26, 2015 7:06 pm
by JohnAStebbins
It's been a year and a few months, so time to check progress again :mrgreen:

I've changed my tests some. I wanted to compare quality to x264 and x265, so I've added average bitrate tests. I wanted to compare VP8, VP9, x264, and x265 at 300kbps, but it turns out neither VP8 or VP9 are capable of generating files at this bitrate with my test source. VP8 can't generate anything below 2mbps, which pretty much puts it out of the comparison entirely. VP9 can't generate anything below about 480kbps. I tried many variations on settings to see if anything could be done to improve VPx rate control. Nothing helped. So I decided to use 512kpbs to compare VP9, x264, and x265. The VP8 test is only useful for speed comparison since it can't generate a file at a low bitrate useful for quality comparisons.

Here's the test script:

Code: Select all

#! /bin/bash

echo "VP8 ABR test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp8-abr-test.webm --i420 -w 1920 -h 1080 -p 2 -t 12 --good --cpu-used=2 --end-usage=vbr --target-bitrate=512 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --auto-alt-ref=1 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --lag-in-frames=25 --min-q=0 --max-q=63  --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --codec=vp8

echo "VP9 ABR test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp9-abr-test.webm --i420 -w 1920 -h 1080 -p 2 -t 12 --good --cpu-used=2 --end-usage=vbr --target-bitrate=450 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --auto-alt-ref=1 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --lag-in-frames=25 --min-q=0 --max-q=63  --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --codec=vp9

echo "x265 ABR test"
time ../x265/build/linux/x265 --input ~/Videos/Samples/birds.y4m -p medium --bitrate 512 --psy-rd 1.0 --pass 1 -o x265-abr-test.hevc
time ../x265/build/linux/x265 --input ~/Videos/Samples/birds.y4m -p medium --bitrate 512 --psy-rd 1.0 --pass 2 -o x265-abr-test.hevc

echo "x264 ABR test"
time ../x264/x264 --preset medium --bitrate 512 --pass 1 -o x264-abr-test.264 ~/Videos/Samples/birds.y4m
time ../x264/x264 --preset medium --bitrate 512 --pass 2 -o x264-abr-test.264 ~/Videos/Samples/birds.y4m

echo "VP8 CQ test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp8-cq-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp8

echo "VP9 CQ test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp9-cq-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp9
Here's the output:

Code: Select all

VP8 ABR test
Pass 1/2 frame 2200/2201  316944B    1152b/f   69082b/s   77172 ms (28.51 fps)
Pass 2/2 frame 2200/2189 8672779B  198872 ms 11.06 fps [ETA  0:00:02]    3624F   5095F   4699F   4989F   4703F   4628F   4517F   5242F   4907F   5327F   6806F   2770F   4706F   5235F   5197FPass 2/2 frame 2200/2213 8792571B   31972b/f 1916462b/s  123117 ms (17.87 fps)

real	3m33.823s
user	12m11.598s
sys	2m18.288s
VP9 ABR test
Pass 1/2 frame 2200/2201  352160B    1280b/f   76758b/s  114534 ms (19.21 fps)
Pass 2/2 frame 2200/2176 2265682B  716507 ms 3.07 fps [ETA  0:00:07]    7356F    577F    561F    390F    570F    510F    391F    655F    622F    475F    534F    464F    388F    285F     70F Pass 2/2 frame 2200/2200 2290595B    8329b/f  499266b/s  606462 ms (3.63 fps)

real	12m13.757s
user	12m10.900s
sys	0m2.609s
x265 ABR test
y4m  [info]: 1920x1080 fps 60000/1001 i420p8 sar 1:1 frames 0 - 2199 of 2200
x265 [info]: HEVC encoder version 1.4+424-2b93cf2a5ac8
x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 17 / 3 / 8
x265 [info]: CTU size / RQT depth inter / intra  : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge         : dia / 57 / 2 / 1
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-512 kbps / 1.0 / 1
x265 [info]: tools: rd=2 psy-rd=1.00 early-skip deblock sao signhide fast-intra tmvp stats-write 
x265 [info]: frame I:      9, Avg QP:39.93  kb/s: 30916.76                      
x265 [info]: frame P:    529, Avg QP:41.84  kb/s: 1360.66 
x265 [info]: frame B:   1662, Avg QP:49.08  kb/s: 92.17   
x265 [info]: global :   2200, Avg QP:47.30  kb/s: 523.28  
x265 [info]: Weighted P-Frames: Y:21.0% UV:13.4%
x265 [info]: consecutive B-frames: 1.9% 8.4% 8.2% 42.2% 39.4% 

encoded 2200 frames in 69.55s (31.63 fps), 523.28 kb/s

real	1m9.598s
user	8m6.803s
sys	0m7.737s
y4m  [info]: 1920x1080 fps 60000/1001 i420p8 sar 1:1 frames 0 - 2199 of 2200
x265 [info]: HEVC encoder version 1.4+424-2b93cf2a5ac8
x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 17 / 3 / 8
x265 [info]: CTU size / RQT depth inter / intra  : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-512 kbps / 1.0 / 1
x265 [info]: tools: rd=3 psy-rd=1.00 deblock sao signhide tmvp stats-read 
x265 [info]: frame I:      9, Avg QP:40.46  kb/s: 29070.34                      
x265 [info]: frame P:    529, Avg QP:43.02  kb/s: 1123.43 
x265 [info]: frame B:   1662, Avg QP:50.27  kb/s: 166.44  
x265 [info]: global :   2200, Avg QP:48.49  kb/s: 514.80  
x265 [info]: Weighted P-Frames: Y:12.5% UV:9.8%
x265 [info]: consecutive B-frames: 1.9% 8.4% 8.2% 42.2% 39.4% 

encoded 2200 frames in 110.58s (19.90 fps), 514.80 kb/s

real	1m50.648s
user	14m9.863s
sys	0m3.074s
x264 ABR test
y4m [info]: 1920x1080p 1:1 @ 60000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile Main, level 4.2
x264 [info]: frame I:9     Avg QP:50.88  size: 12922                           
x264 [info]: frame P:1025  Avg QP:51.00  size:  2005
x264 [info]: frame B:1166  Avg QP:51.00  size:   179
x264 [info]: consecutive B-frames:  1.1% 77.8% 20.7%  0.4%
x264 [info]: mb I  I16..4: 100.0%  0.0%  0.0%
x264 [info]: mb P  I16..4:  4.4%  0.0%  0.0%  P16..4:  7.0%  0.0%  0.0%  0.0%  0.0%    skip:88.7%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  0.3%  0.0%  0.0%  direct: 0.3%  skip:99.4%  L0:47.3% L1:52.7% BI: 0.0%
x264 [info]: final ratefactor: 55.15
x264 [info]: coded y,uvDC,uvAC intra: 2.2% 46.9% 0.0% inter: 0.2% 0.7% 0.0%
x264 [info]: i16 v,h,dc,p: 70% 19% 10%  1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29%  6% 45%  2%  6%  4%  3%  3%  1%
x264 [info]: i8c dc,h,v,p: 100%  0%  0%  0%
x264 [info]: Weighted P-Frames: Y:9.2% UV:0.4%
x264 [info]: kb/s:518.96

encoded 2200 frames, 131.57 fps, 518.96 kb/s

real	0m16.939s
user	1m12.356s
sys	0m3.700s
y4m [info]: 1920x1080p 1:1 @ 60000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile High, level 4.2
x264 [info]: frame I:9     Avg QP:51.00  size:  8822                           
x264 [info]: frame P:1025  Avg QP:51.00  size:  1525
x264 [info]: frame B:1166  Avg QP:51.00  size:   447
x264 [info]: consecutive B-frames:  1.1% 77.8% 20.7%  0.4%
x264 [info]: mb I  I16..4: 55.3% 44.7%  0.0%
x264 [info]: mb P  I16..4:  1.1%  0.2%  0.0%  P16..4:  8.4%  0.2%  3.1%  0.0%  0.0%    skip:87.0%
x264 [info]: mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  8.6%  0.0%  0.0%  direct: 0.0%  skip:91.4%  L0: 5.5% L1:94.5% BI: 0.0%
x264 [info]: 8x8 transform intra:28.0% inter:99.8%
x264 [info]: coded y,uvDC,uvAC intra: 4.0% 33.2% 0.0% inter: 0.2% 0.5% 0.0%
x264 [info]: i16 v,h,dc,p: 66% 23%  7%  4%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  9%  6% 70%  3%  3%  3%  3%  2%  1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu:  6%  2% 12% 15% 46%  2% 15%  2%  0%
x264 [info]: i8c dc,h,v,p: 100%  0%  0%  0%
x264 [info]: Weighted P-Frames: Y:9.2% UV:0.4%
x264 [info]: ref P L0: 70.4%  0.2% 19.7%  8.9%  0.8%
x264 [info]: ref B L0: 94.3%  5.2%  0.5%
x264 [info]: ref B L1: 99.7%  0.3%
x264 [info]: kb/s:471.73

encoded 2200 frames, 119.72 fps, 471.73 kb/s

real	0m18.445s
user	2m15.715s
sys	0m2.823s
VP8 CQ test
Pass 1/1 frame 2200/2200 111219012B  404432b/f 24241724b/s  219617 ms (10.02 fps)

real	3m46.811s
user	16m26.213s
sys	7m7.010s
VP9 CQ test
Pass 1/1 frame 2200/2176 72484897B 1613314 ms 1.36 fps [ETA  0:00:17]   17962F  17071F  19079F  10777F     38F 260069F  14184F  16328F  19388F  18338F  19053F  17966F  20494F  11503F     40FPass 1/1 frame 2200/2200 73159421B  266034b/f 15946109b/s 1629224 ms (1.35 fps)

real	27m16.336s
user	27m13.783s
sys	0m1.329s
Some observations:
VP9 has come a long way in speed improvements, but it still a ways away from what I would consider usable. I found a post from June 2013 that says they disabled multi-threaded encoding to focus on quality improvements. The post says they would re-enable threaded encode "later this year". It still hasn't happened. If they fixed this, ABR encoding would be competitive with x265 and be somewhat usable IMO. CQ encoding is too slow regardless of threaded encoding. It seems they have put very little effort into constant quality encoding.

At the tested bitrate, VP9 and x265 are very comparable in quality in my subjective opinion. I'm not looking at metrics here, just looking at the image to determine if I like it or not. x264 completely falls apart at these bitrates and is unusable junk. And as mentioned above, no VP8 comparison is possible due to the encoder's bitrate limitations.

Speed comparison:
VP8 ABR 10 fps
VP9 ABR 3 fps
x265 ABR 12 fps
x264 ABR 63 fps
VP8 CQ 10 fps
VP9 CQ 1.3 fps

Previously I only checked VP9 CQ encoding speed which was about 0.05 fps. You can see there has been quite an improvement here. But 36 hours to encode a 90 minute movie is still excessive IMO.

In summary, VP9 quality is quite good at low bitrates. I didn't compare at higher bitrates where it still may lose to x264 as it did in the past. But if they would only fix the rate control of the encoder so that more reproducible results were possible and improve the speed by another factor of about 10, I think I could actually start recommending its use. Maybe next year :lol:

Re: VP9 support

Posted: Tue Jan 27, 2015 6:48 pm
by Djfe
thx for the review of the current x265 and vp9 status

now we have a post to link to if other people are asking for support :D

Re: VP9 support

Posted: Thu Jan 29, 2015 9:20 pm
by VP9
JohnAStebbins wrote: I didn't compare at higher bitrates where it still may lose to x264 as it did in the past.
I would check that again. In my current tests, VP9 is beating x264 from low to high bitrates (It didn't previously):

x264 / VP9:
42.95 / 43.40 dB (500 kbps)
46.27 / 46.51 dB (1500 kbps)
47.52 / 47.73 dB (2500 kbps)

And that is because I used "faster" settings with VP9. I am waiting for "slower" tests to finish and it scored 43.66 dB at 500 kbps.

x264 settings used 1st/2nd pass:
x264 --bitrate <bitrate> --preset placebo --tune psnr --threads 1 --ratetol 0.10 --keyint infinite --min-keyint 240 --bframes 8 --ref 1 --no-8x8dct --partitions none --trellis 0 --fast-pskip --me dia --subme 2 --merange 12 --rc-lookahead 48 --no-dct-decimate --pass 1 <input> -o <output>

2nd pass:
x264 --bitrate <bitrate> --preset placebo --tune psnr --threads 1 --ratetol 0.10 --keyint infinite --min-keyint 240 --bframes 8 --ref 4 --me esa --subme 11 --merange 12 --rc-lookahead 48 --no-dct-decimate --pass 2 <input> -o <output>

Notes:
I compiled the latest libvpx with different settings from the default, if that matters.

Re: VP9 support

Posted: Thu Jan 29, 2015 9:40 pm
by GhostMotleyX
I would like VP9 support also, even if it is in Alpha or Beta. I'd like to be able to try it out. I can't even get H.265 to work in VLC or when I upload to YouTube so this would be great.

Re: VP9 support

Posted: Thu Feb 12, 2015 10:07 pm
by s55
No need to me too. When Googles VP9 encoder improves a bit further to fit our definition of usable, the plan is we'll enable it. Until then, be patient.

Re: [Planned] VP9 support

Posted: Thu Feb 26, 2015 2:13 am
by yaowu
multithreaded encoding is supported in libvpx vp9 encoder already: https://groups.google.com/a/webmproject ... YMn21BA5cJ

If you enable multhreaded encoding for vp9, you should see a significant speed up comparing to single threaded encoding.

Re: [Planned] VP9 support

Posted: Thu Feb 26, 2015 5:31 pm
by JohnAStebbins
Thanks for pointing this out. For anyone who wants to experiment with this, VP9 multi-threading is dependent on column tiling. Since minimum tile width is 256, max tile colums for HD content (1920 width) would be 7 if there were not other constraints (and there are). The command line option to enable tile columns is --tile-columns and takes a parameter which is the number of columns log2. Since the value is log2, the max number of columns supported for HD content is 4 because the next permissible value would push columns to 8. So for HD content, you can add "--tile-columns=2" the command.

Running my test script with this enhancement gives this output:

Code: Select all

=========================================================
VP8 ABR test

real    3m41.504s
user    12m7.211s
sys 1m50.141s

=========================================================
VP9 ABR test

real    6m49.911s
user    15m15.558s
sys 0m4.180s

=========================================================
x265 ABR test

(pass 1)
real    1m10.968s
user    8m5.643s
sys 0m8.122s

(pass 2)
real    1m52.885s
user    14m13.952s
sys 0m3.116s

=========================================================
x264 ABR test

(pass 1)
real    0m16.541s
user    1m11.144s
sys 0m3.702s

(pass 2)
real    0m17.817s
user    2m12.436s
sys 0m2.403s

=========================================================
VP8 CQ test

real    3m48.098s
user    16m23.856s
sys 7m14.511s

=========================================================
VP9 CQ test

real    12m13.454s
user    37m29.705s
sys 0m2.942s
Updated encode speeds for VP9 are:
VP9 ABR 5 fps
VP9 CQ 3 fps

To refresh your memory, without tile columns:
VP9 ABR 3 fps
VP9 CQ 1.3 fps

So it isn't "a significant speed up" as yaowu suggests. Not only are you limited to at best 4 threads for HD content, but it appears that the multi-threading is not all that effecient. With 4 threads, we only get a 1.6x speed improvement for ABR and a 2.3x speed improvement for CQ. It's better, but not the speed boost I was hoping for from multi-threading. And not the factor of 10x that they need to approach a competitive speed. But encoding a movie in 9 to 15 hours is definitely better than the 3 months that we started at :mrgreen:

I haven't been able to find any analysis of the effect of tile columns on quality. If anyone knows of any tests that have been done regarding this, please post a link.

Re: [Planned] VP9 support

Posted: Thu Feb 26, 2015 10:43 pm
by yaowu
Just to answer the question on the effect of tile columns on quality, the impact of tile columns on compression quality is very very small. It is neglectable for all practical purposes.

Re: [Planned] VP9 support

Posted: Sat Apr 04, 2015 4:24 pm
by JohnAStebbins
libvpx 1.4.0 released https://groups.google.com/a/webmproject ... zYWenmdUM8
So time for another round of tests.

Same script as last time

Code: Select all

#! /bin/bash

echo "========================================================================"
echo "VP8 ABR test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp8-abr-test.webm --i420 -w 1920 -h 1080 -p 2 -t 12 --good --cpu-used=2 --end-usage=vbr --target-bitrate=512 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --auto-alt-ref=1 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --lag-in-frames=25 --min-q=0 --max-q=63  --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --codec=vp8

echo
echo "========================================================================"
echo "VP9 ABR test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp9-abr-test.webm --i420 -w 1920 -h 1080 -p 2 -t 12 --good --cpu-used=2 --end-usage=vbr --target-bitrate=450 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --auto-alt-ref=1 --static-thresh=0 --bias-pct=50 --minsection-pct=0 --maxsection-pct=2000 --lag-in-frames=25 --min-q=0 --max-q=63  --arnr-maxframes=7 --arnr-strength=5 --arnr-type=3 --codec=vp9 --tile-columns=2 --frame-parallel=1

echo
echo "========================================================================"
echo "x265 ABR test"
echo "(pass 1)"
time ../x265/build/linux/x265 --input ~/Videos/Samples/birds.y4m -p medium --bitrate 512 --psy-rd 1.0 --pass 1 -o x265-abr-test.hevc
echo
echo "(pass 2)"
time ../x265/build/linux/x265 --input ~/Videos/Samples/birds.y4m -p medium --bitrate 512 --psy-rd 1.0 --pass 2 -o x265-abr-test.hevc

echo
echo "========================================================================"
echo "x264 ABR test"
echo "(pass 1)"
time ../x264/x264 --preset medium --bitrate 512 --pass 1 -o x264-abr-test.264 ~/Videos/Samples/birds.y4m
echo
echo "(pass 2)"
time ../x264/x264 --preset medium --bitrate 512 --pass 2 -o x264-abr-test.264 ~/Videos/Samples/birds.y4m

echo
echo "========================================================================"
echo "VP8 CQ test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp8-cq-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp8

echo
echo "========================================================================"
echo "VP9 CQ test"
time ./vpxenc ~/Videos/Samples/birds.y4m -o vp9-cq-test.webm --i420 -w 1920 -h 1080 -p 1 -t 12 --good --cpu-used=2 --end-usage=cq --cq-level=10 --target-bitrate=25000 --fps=60000/1001 --kf-min-dist=0 --kf-max-dist=360 --codec=vp9 --tile-columns=2 --frame-parallel=1

echo
echo "========================================================================"
echo "x265 CQ test"
time ../x265/build/linux/x265 --input ~/Videos/Samples/birds.y4m -p medium --crf 20 --psy-rd 1.0 -o x265-cq-test.hevc

echo
echo "========================================================================"
echo "x264 CQ test"
time ../x264/x264 --preset medium --crf 20 -o x264-cq-test.264 ~/Videos/Samples/birds.y4m
And the results

Code: Select all

VP8 ABR  10.3 fps
VP9 ABR   5.7 fps (14% improvement)
x265 ABR 12.2 fps
x264 ABR 62.8 fps

VP8 CQ    9.8 fps
VP9 CQ    3.3 fps (10% improvement)
x265 CRF 10.2 fps
x264 CRF 35.0 fps
So there are some improvements, but again the difference is marginal. We're still looking at the better part of 10 hours to encode an HD movie.

Re: [Planned] VP9 support

Posted: Fri Oct 30, 2015 11:28 pm
by Marsu42
JohnAStebbins wrote:libvpx 1.4.0 released
libvpx 1.5.0 is coming, a first test indicates ~20% performance gain: https://groups.google.com/a/webmproject ... LIDrS6aC50 ... don't be shy to re-test with the current dev code :-) as only bugfixes are left until release.
JohnAStebbins wrote:So there are some improvements, but again the difference is marginal. We're still looking at the better part of 10 hours to encode an HD movie.
With respect: So what? Personally, I'd use vp9 as an alternative streaming codec for browsers that don't support x264 ... and for this we're talking not about re-coding your whole hd movie library, but about short internet clips.

If vp9 has a noticeable quality-per-bit boost over the mediocre vp8, I'm sure there are lots of folks out there who would be happy to let an encode run overnight and get a modern webp encode.

Re: [Planned] VP9 support

Posted: Sat Oct 31, 2015 4:06 pm
by Deleted User 13735
quality-per-bit boost
Just what scale and units are used to measure and represent that?

Re: [Planned] VP9 support

Posted: Sun Nov 01, 2015 2:57 am
by mduell
Hey look, it's November 2015 and VP9 still sucks.

Re: [Planned] VP9 support

Posted: Tue Nov 03, 2015 11:46 pm
by Marsu42
mduell wrote:Hey look, it's November 2015 and VP9 still sucks.
Hey, no matter what date it is - there are (still) browsers around that don't support mpeg/h264 (not to speak h265), so for reliable streaming you need to dual-encode to vpx - which makes vp9 your best bet atm...

Re: [Planned] VP9 support

Posted: Thu Nov 12, 2015 10:04 pm
by JohnAStebbins
Another vpx release (1.5), another benchmark

Code: Select all

|         | Quad     | Quad   | Hex     |
|         | Ivy      | Haswell| Sandy-E |
|         | i7-3630QM| i7-4470| i7-3930K|
| Encoder | 2.4GHz   | 3.4GHz | 3.2GHz  |
|---------------------------------------|
|VP8  ABR |  8.2     | 11.7   | 10.1    |
|VP9  ABR |  4.4     |  6.3   |  4.5    |
|x265 ABR |  5.4     | 17.6   | 15.3    |
|x264 ABR | 50.0     | 71.0   | 71.0    |
|VP8   CQ |  8.6     | 10.9   | 11.8    |
|VP9   CQ |  2.9     |  4.0   |  3.2    |
|x265  CQ |  5.6     | 15.8   | 13.5    |
|x264  CQ | 26.8     | 39.2   | 40.7    |
Unfortunately, I don't have access to the same machine I used last time. So I did the same tests on a variety of machines I have lying about. The Quad Haswall is the closest match for the last benchmark run.

And as you can see, little has changed. If you use x264 as the ruler and scale values to match the numbers on the machine in my previous benchmark, VP9 encode speed change is within the error bars. (i.e. nada, VP9 ABR 35 / 39 * 6.3 = 5.7 and VP9 CQ 35 / 39 * 4.0 = 3.6).

Nothing to see here. Move along, these aren't the droids you're looking for.

Re: [Planned] VP9 support

Posted: Tue Feb 16, 2016 11:26 pm
by Marsu42
JohnAStebbins wrote:Move along, these aren't the droids you're looking for.
Actually these *are* the very droids that make a huge difference, but the evil Handbrake empire fails to recognize (i.e. implement) them :->