[Implemented] VP9 support
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
[Implemented] VP9 support
Hello Guys,
Any plan to add google's VP9 codec as a video compression format ?
http://www.webmproject.org/code/
Any plan to add google's VP9 codec as a video compression format ?
http://www.webmproject.org/code/
Re: VP9 support
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
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.
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
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.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: VP9 support
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.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: VP9 support
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.
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
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 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
Hey, doesn't everyone have an idle 3 months to encode a movie?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.
Re: VP9 support
The cool thing is, we can implement TempGaussMC deinterlace and not have it be the bottleneck!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.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: VP9 support
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.
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
I wonder how much they had to raise their budget when they added VP8 support to YouTube…
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: VP9 support
It's been a year and a few months, so time to check progress again
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:
Here's the output:
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
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
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
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
Re: VP9 support
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
now we have a post to link to if other people are asking for support
Re: VP9 support
I would check that again. In my current tests, VP9 is beating x264 from low to high bitrates (It didn't previously):JohnAStebbins wrote: I didn't compare at higher bitrates where it still may lose to x264 as it did in the past.
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.
-
- Posts: 4
- Joined: Thu Jan 29, 2015 9:37 pm
Re: VP9 support
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
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
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.
If you enable multhreaded encoding for vp9, you should see a significant speed up comparing to single threaded encoding.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: [Planned] VP9 support
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:
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
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.
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
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
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
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.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: [Planned] VP9 support
libvpx 1.4.0 released https://groups.google.com/a/webmproject ... zYWenmdUM8
So time for another round of tests.
Same script as last time
And the results
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.
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
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
Re: [Planned] VP9 support
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:libvpx 1.4.0 released
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.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.
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
Just what scale and units are used to measure and represent that?quality-per-bit boost
Re: [Planned] VP9 support
Hey look, it's November 2015 and VP9 still sucks.
Re: [Planned] VP9 support
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...mduell wrote:Hey look, it's November 2015 and VP9 still sucks.
- JohnAStebbins
- HandBrake Team
- Posts: 5725
- Joined: Sat Feb 09, 2008 7:21 pm
Re: [Planned] VP9 support
Another vpx release (1.5), another benchmark
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.
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 |
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
Actually these *are* the very droids that make a huge difference, but the evil Handbrake empire fails to recognize (i.e. implement) them :->JohnAStebbins wrote:Move along, these aren't the droids you're looking for.