Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
|
3rd August 2009, 01:17 | #1 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
x264 "Macroblock Tree Ratecontrol" testing (committed)
Warning: (not really) Highly Experimental It's done and committed! Grab the latest x264 from x264.nl! Patch RC1 Download RC1 (Windows, old) Download RC1 (Windows debug build, old) Patch v0.13 Download 0.13 (Windows) Download 0.13 (Windows debug build) Patch v0.11 Download 0.11 (Windows, old) Download 0.11 (Windows debug build, old) Patch v0.09 (old) Download 0.09 (Windows, old) Download 0.09 (Windows debug build, old) Updates: Changes in RC1: 1. Statsfile format changed; now takes only 2 bytes per macroblock. Varying-endianness now supported. Error handling improved. 2. More commandline validation fixes. 3. Clip propagation factors just in case they overflow. 4. Change default lookahead to 40 to save some memory. 5. It's now called --rc-lookahead, not --lookahead, at Akupenguin's request. 6. Various other things, just read the damn commit message in the patch. Changes in 0.13: 1. Bugs fixed in the VBV patch. It's still separate, as per below. 2. B-adapt 1 now supported. 3. All B-adapt code is now merged into MB-tree code instead of duplicated. B-adapt 1 should be slightly better than it was before (even without MB-tree). In general, all three B-adapt modes now use the same basic framework. 4. MB-tree strength is now adjustable through qcomp. Raising qcomp lowers MB-tree strength; it works the same way that qcomp did before MB-tree, with qcomp 1 meaning constant frame quantizer. This lets you experiment a bit more; there's some possibility that the default qcomp 0.6 is not the psy-optimal value--it might be higher. 5. New --no-psy option, which disables all psy optimizations in x264 that don't improve PSNR or SSIM. This includes psy-RD/trellis, but also the recently-added chroma lambda offset and the magical "num_frames = j" line that causes MB-tree to pretend that non-scenecut I-frames don't exist. 6. "Fast" preset is now slower, "faster" preset added to cover the gap. 7. MB-tree is now default on presets "fast" and higher. Lookahead values are smaller for faster presets. Changes in 0.11: 1. VBV now supported. Includes a separate VBV patch which fixes most VBV issues that MB-tree has; this will be committed separately, as it doesn't require MB-tree. It should also improve 1-pass VBV (especially CBR) performance on clips with lots of static content, e.g. anime, CGI. Do note that CBR doesn't benefit much from MB-tree though, especially with small buffer sizes. 2. Lots of trivial parameter-handling fixes, e.g. lookahead automatically disabled on second pass. FAQ: How do I use it? It's on by default. --no-mbtree turns it off. What doesn't it work with yet? --b-pyramid How can I tweak it? --lookahead; default is 50, higher takes more memory and is slower, but should give better results. It's probably overkill for most sources. If you get crashes immediately after the lookahead fills up, you probably ran out of memory (max is 2GB for x264 on 32-bit Windows). --qcomp; works the same as it did before with actual qcomp, higher numbers lower MB-tree strength. How much does it cost, speed-wise? A bit. Not too much though. Speed cost is linearly proportional to --lookahead. How can I help test it? Use it. Make sure you don't get any odd errors or warnings, such as asserts failing, crashes, etc. Try various combinations of the relevant settings (b-adapt, bframes, mbtree, lookahead, pass 1/2, crf, keyint, scenecut) that I might not have thought of. Try it on various sources; see if you can find places where, with --tune ssim, at the same bitrate as without mbtree, it gives worse SSIM (or, equally, places where Global PSNR goes down with tune psnr). Make sure it doesn't fall apart visually either. Also, note that CRF is redefined again by this patch--I set it so that it kept the same bitrate on Blackpearl as before, but it may vary for different videos. What does it actually do? It tracks the propagation of information from future blocks to past blocks across motion vectors. It could be described as localizing qcomp to act on individual blocks instead of whole scenes. Thus instead of lowering quality in high-complexity scenes (like x264 currently does), it'll only lower quality on the complex part of the scene, while for example a static background will remain high-quality. It also has many other more subtle effects, some potentially negative, most probably not. This helps at all bitrates, but can even help at phenomenally low bitrates where the video would otherwise fall apart completely, like in this 67kbps anime clip. Should I go around distributing this patch and getting everyone I know to use it for their everyday encodes? No. The commandline options here may change in the future, as may the statsfile format and various other aspects of the patch, so it's not a good idea to make this patch something that gets put in ordinary x264 builds. Furthermore, I might have broken something unrelated to mbtree. Why does it give different output even without mbtree? B-adapt (all modes) was slightly modified to work better with mbtree, so the frametype decisions may change somewhat. What improvement does it give? I've gotten up to a 70% SSIM increase. You're joking, right? No. Seriously? How the hell can you get a 70% quality increase? Magic. OK, you're just making this u--wait a minute, what's this new statsfile, and why is it using up all my hard disk space? Oh, that? Kyahahahahahaha.
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 10th August 2009 at 22:53. |
3rd August 2009, 02:10 | #4 | Link | |
Registered User
Join Date: Aug 2007
Posts: 1,430
|
Quote:
Funny how the QP for the mbtree version is twofold that of a normal build: Code:
C:\temp\Encoding\test>cd .. C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264_mbtree_x64 --crf 19 --mbt ree --bframes 4 --b-adapt 2 --ref 4 --b-pyramid --direct auto --deblock -3:-3 - -subme 10 --trellis 2 --analyse all --no-dct-decimate --me umh --ssim --fps 2400 0/1001 --output "test/test.mbtree.mkv" - 480x320 x264 [info]: 480x320 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 2.1 test/test.avs: 480x320, 10000000/417083 fps, 481 frames x264 [info]: slice I:240 Avg QP:20.82 size: 79 x264 [info]: slice P:241 Avg QP:24.08 size: 79 x264 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% x264 [info]: mb I I16..4: 100.0% 0.0% 0.0% x264 [info]: mb P I16..4: 90.4% 0.0% 0.0% P16..4: 9.2% 0.0% 0.0% 0.0% 0 .0% skip: 0.4% x264 [info]: 8x8 transform intra:0.0% inter:-1.$% x264 [info]: coded y,uvDC,uvAC intra:0.0% 0.1% 0.0% inter:0.0% 0.0% 0.0% x264 [info]: ref P L0 0.0% 100.0% x264 [info]: SSIM Mean Y:1.0000000 x264 [info]: kb/s:15.2 encoded 481 frames, 151.83 fps, 16.87 kb/s C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264.x64 --crf 19 --bframes 4 --b-adapt 2 --ref 4 --b-pyramid --direct auto --deblock -3:-3 --subme 10 --trel lis 2 --analyse all --no-dct-decimate --me umh --ssim --fps 24000/1001 --output "test/test.mkv" - 480x320 x264 [info]: 480x320 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 2.1 test/test.avs: 480x320, 10000000/417083 fps, 481 frames x264 [info]: slice I:240 Avg QP:10.04 size: 83 x264 [info]: slice P:241 Avg QP:10.01 size: 91 x264 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% x264 [info]: mb I I16..4: 100.0% 0.0% 0.0% x264 [info]: mb P I16..4: 90.4% 0.0% 0.0% P16..4: 9.2% 0.0% 0.0% 0.0% 0 .0% skip: 0.4% x264 [info]: 8x8 transform intra:0.0% inter:-1.$% x264 [info]: coded y,uvDC,uvAC intra:0.0% 0.1% 0.0% inter:0.0% 0.0% 0.0% x264 [info]: ref P L0 0.0% 100.0% x264 [info]: SSIM Mean Y:1.0000000 x264 [info]: kb/s:16.7 encoded 481 frames, 162.39 fps, 18.08 kb/s C:\temp\Encoding>pause Press any key to continue . . . Last edited by Snowknight26; 3rd August 2009 at 02:12. |
|
3rd August 2009, 02:12 | #5 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Yes. |
|
3rd August 2009, 02:14 | #6 | Link | |
Registered User
Join Date: Aug 2007
Posts: 1,430
|
Quote:
Crash after 100 frames: Code:
C:\temp\Encoding\test>cd .. C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264_mbtree_x64 --crf 19 --mbt ree --lookahead 500 --bframes 16 --b-adapt 2 --ref 4 --b-pyramid --direct auto --deblock -3:-3 --subme 10 --trellis 2 --analyse all --no-dct-decimate --me umh --ssim --fps 24000/1001 --output "test/test.mbtree.mkv" - 1920x816 x264 [info]: 1920x816 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 4.0 test/test.avs: 1920x816, 10000000/417083 fps, 1378 frames Output error: wrote only 1785423 of 2350080 bytes C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264.x64 --crf 19 --bframes 16 --b-adapt 2 --ref 4 --b-pyramid --direct auto --deblock -3:-3 --subme 10 --tre llis 2 --analyse all --no-dct-decimate --me umh --ssim --fps 24000/1001 --output "test/test.mkv" - 1920x816 x264 [info]: 1920x816 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 4.0 test/test.avs: 1920x816, 10000000/417083 fps, 1378 frames 250 frames: 2.03 fps, 7743.86 kb/s Last edited by Snowknight26; 3rd August 2009 at 02:21. |
|
3rd August 2009, 01:59 | #7 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
__________________
http://www.7-zip.org/ |
3rd August 2009, 02:11 | #8 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
|
3rd August 2009, 02:11 | #9 | Link | |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
Quote:
Great patch. Untill now I can say I get +4% of bitrate improvement for the same OPSNR and +20% for the same SSIM (foreman test sequence). Last edited by IgorC; 3rd August 2009 at 02:13. |
|
3rd August 2009, 02:50 | #10 | Link |
Registered User
Join Date: Aug 2007
Posts: 1,430
|
I have to say, the bitrate difference can be enormous sometimes:
Code:
C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264_mbtree_x64 --crf 19 --mbt ree --bframes 0 --b-adapt 0 --ref 0 --direct spatial --deblock -3:-3 --subme 1 - -trellis 0 --analyse all --me umh --ssim --fps 24000/1001 --output "test/test.mb tree.mkv" - 1920x816 x264 [info]: 1920x816 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 4.0 test/test.avs: 1920x816, 10000000/417083 fps, 1378 frames x264 [info]: slice I:20 Avg QP:14.02 size:131728 x264 [info]: slice P:1358 Avg QP:15.01 size: 37773 x264 [info]: mb I I16..4: 24.8% 47.2% 28.0% x264 [info]: mb P I16..4: 22.4% 18.9% 1.6% P16..4: 35.4% 8.6% 1.8% 0.1% 0 .0% skip:11.2% x264 [info]: 8x8 transform intra:44.2% inter:41.4% x264 [info]: coded y,uvDC,uvAC intra:35.8% 87.5% 74.4% inter:13.7% 58.9% 19.6% x264 [info]: SSIM Mean Y:0.9929551 x264 [info]: kb/s:7506.7 encoded 1378 frames, 30.29 fps, 7506.94 kb/s C:\temp\Encoding>avs2yuv -raw test/test.avs - | x264.x64 --crf 19 --bframes 0 --b-adapt 0 --ref 0 --direct spatial --deblock -3:-3 --subme 1 --trellis 0 --ana lyse all --me umh --ssim --fps 24000/1001 --output "test/test.mkv" - 1920x816 x264 [info]: 1920x816 @ 23.98 fps x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 x264 [info]: profile High, level 4.0 test/test.avs: 1920x816, 10000000/417083 fps, 1378 frames x264 [info]: slice I:21 Avg QP:10.66 size:187241 x264 [info]: slice P:1357 Avg QP:11.45 size: 73091 x264 [info]: mb I I16..4: 23.5% 37.2% 39.3% x264 [info]: mb P I16..4: 20.8% 17.8% 5.0% P16..4: 32.7% 10.9% 4.0% 0.4% 0 .1% skip: 8.4% x264 [info]: 8x8 transform intra:40.7% inter:31.8% x264 [info]: coded y,uvDC,uvAC intra:51.6% 88.9% 81.5% inter:36.5% 73.8% 41.9% x264 [info]: SSIM Mean Y:0.9953622 x264 [info]: kb/s:14353.1 encoded 1378 frames, 26.12 fps, 14353.34 kb/s |
3rd August 2009, 02:58 | #12 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Well you're shooting for crf 19 and getting AVG QP's of 10.
__________________
http://www.7-zip.org/ |
3rd August 2009, 07:27 | #15 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Pass 2 is slower with --b-adapt 2
__________________
http://www.7-zip.org/ |
3rd August 2009, 07:30 | #16 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
The only decent looking encode of that I ever got was using PEP and ROI encoding, specifying a max QP for the static parts of the image so that the crazy motion parts wouldn't starve the background of bits and drive up their QP so high. Once encoded at a decent QP on the I-frame, they would be pretty much skip blocks the rest of the GOP and so didn't take up material bandwidth anyway. Cool to see something that could achieve similar results without manual ROI and with moving images. |
|
3rd August 2009, 07:32 | #17 | Link | ||
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Quote:
It naturally does a whole lot of these sort of things in addition to the obvious effect of locally optimal qcomp. |
||
3rd August 2009, 07:57 | #19 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Or do it right and use softsubs |
|
3rd August 2009, 07:56 | #20 | Link |
C# Addict
Join Date: Oct 2008
Location: Saudi Arabia
Posts: 114
|
Sorry for my noobness
I use AviDemux so I need to compile libx264 DLL with this patch ... Can somebody point me to the right direction ? Edit : Found It ! Last edited by TheImperial2004; 3rd August 2009 at 08:22. |
Tags |
development, testing, x264 |
|
|