Current Patches, Where to get them, How they affect speed/output

[tobinaka]

May I introduce Japanese current patches here? Sorry for the bother, but I thought this thread best to tell you them. Though I'm just a Japanese x264 user, not a programmer, I want to tell you about them because I've not found them in the forum. The author gave me OK.


In Japan, Seraphy (http://seraphy.fam.cx/~seraphy/)'s builds may be the most popular because he provides them also as x264 GUI plug-ins for AviUtl (http://spring-fragrance.mints.ne.jp/aviutl/). (AviUtl is a video editor free-software developed by KEN and is very popular in Japan. I'll explain it more on a proper thread If you want.)

Seraphy's builds have 3 version: no-patched, MixAQ and OreAQ. There is no need for talking about no-patched one. The other two are applied particular AQ patches in addition to common ones (thread_pool, selectable arranged QNS, Psy RDO, ME-prepass, RDO by DeathTheSheep, new B-frame dicision, updated arranged vaq2mod_fgo). The difference between the latter two versions is just which patches is selected for AQ. Both AQ patches were made for encoding animes.


MixAQ:

MixAQ mixes VAQ and Halli's AQ. In a word, MixAQ is -VAQ +HAQ. My understanding of VAQ is that VAQ allocates bits more to flat area and less to changeful area. But that is when --aq-strength has a positive value. If the negative value is possible for --aq-strength? Seraphy tried it and then saw VAQ with negative values allocated bits less to flat area and more to changeful area. That is good to encode animes. And what is more, worried for execive cut-down and allocating shortage, he added Haali's AQ for support. Finally, MixAQ makes -VAQ allow HAQ to allocate bits more to bright blue area and dark area. To use MixAQ, set --aq2-strength and --aq2-sensitivity for HAQ in addition. It's possible to use only VAQ by setting --aq2-strength 0.


OreAQ:

OreAQ is also a arranged mod from VAQ and HAQ, but is different from MixAQ ("Ore" means "I" in Japanese.) OreAQ is focused on luma and chroma, especially on the former. OreAQ classifies MBs into 4 types: Bright, Middle, Dark, M.Dark (maybe stand for Mega-Dark). OreAQ tends to lower or keep QPs with middle luma to protect gradations. About the others, it lowers QPs only when necessary and basically raises QPs. That is because color noises stand out rather than gradations in areas of high and low lumas. Chroma values are used for diciding whether QPs need to lower or not. The luma of M.Dark MB is near or at zero, so we can hardly see anything there even if there is any color noise. Thus, OreAQ raises QPs at M.Dark MBs. OreAQ is good to encode animes, and more bit-economical than MixAQ maybe.


You can get Seraphy's builds and their diffs here (http://seraphy.fam.cx/~seraphy/program/x264/%E3%81%8A%E3%81%BE%E3%81%91/). "x264patch" includes MixAQ, 7 common patches I described above, and their diffs. "x264OreAQ" includes OreAQ, 7 common patches and OreAQ diff. The files "x264gui.auo" and "x264gui.ini" are the plug-ins for AviUtl.

Since rev928, he has added --aq-debug option to both patched versions. This puts the log of QP's variations caused by AQ and enable us to see the changes on AviUtl. It's also possible to simulate AQ changes moving --aq-strength and --aq-sensitivity up and down. That is very useful but needs futher explanations as this post is already long enough.

As x264 builds by Japanese, VFR maniac's Experimental builds (http://www.esnips.com/web/VFRmaniac-Softwares) are available, too. That includes MixAQ and OreAQ. MixAQ is his idea.

I hope you are interested in Japanese usages and this post contribute to x264's discussions. Thanks!

[elguaxo]

sounds interesting. thanks tobinaka!

[bob0r]

x264.938.modified.01.exe (http://files.x264.nl/x264.938.modified.01.exe)
libx264-61.938.modified.01.dll (http://files.x264.nl/libx264-61.938.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd)
x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

[G_M_C]

x264.938.modified.01.exe (http://files.x264.nl/x264.938.modified.01.exe)
libx264-61.938.modified.01.dll (http://files.x264.nl/libx264-61.938.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd)
x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2)
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff


thx bob0r

[shon3i]

As x264 builds by Japanese, VFR maniac's Experimental builds are available, too. That includes MixAQ and OreAQ. MixAQ is his idea.
I just downloaded this build, and it have four different AQ's, FGO, PsyRD+Psy Trellis. I definitly must try this on some very low bitrate :)

[skystrife]

r940 has been reported to have a bad threading issue. Please revert to using r938 for the time being.





x264.940.modified.exe (http://www.mediafire.com/?eaamdijaaaa) - Alternate Download (http://skystrife.com/x264/x264.940.modified.exe)
libx264-61.940.modified.dll (http://www.mediafire.com/?sjiecjeibdb) - Alternate Download (http://skystrife.com/x264/libx264-61.940.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[Sharktooth]

thanks. got it's way into megui auto-update.

[tobinaka]

sounds interesting. thanks tobinaka!
Thanks for your quick reply. MixAQ is really interesting and worth trying.:) If you can, take your time to entertain their accumulated improvements.
I've found MixAQ wise because If I want I can use normal VAQ on MixAQ. In this way, MixAQ can deal with encoding both animes and non-animes like live-actions better than normal VAQ.

-to use -VAQ+HAQ: --aq-strength <negative> --aq2-strength <positive>
e.g.) --aq-strength -1.0 --aq2-strength 0.7

-to use only normal VAQ: --aq-strength <positive> --aq2-strength <zero>
e.g.) --aq-strength 1.0 --aq2-strength 0

I just downloaded this build, and it have four different AQ's, FGO, PsyRD+Psy Trellis. I definitly must try this on some very low bitrate
As you know, Japanese are good for dealing with something low like cars of low-fuel consumption.:)

Anyway, VFR maniac's Experimental builds is really experimental as its name. He's built them to check for conflicts among codes of official and patches as well as seeing how they affect speed/output. He's made MixAQ and OreAQ really both stable and reliable. His advantages appear on the info.txt in his builds. He subdivides diffs by functions: his improving zones, Seraphy's correct stack alignment, etc.

Not only that, he's noticed some bugs in official opitions. At any rate, see VFR maniac's site (http://www.esnips.com/web/VFRmaniac-Softwares), read his comments in english. But they should be talked about on another proper thread.

[Dark Shikari]

Anyway, VFR maniac's Experimental builds is really experimental as its name. He's built them to check for conflicts among codes of official and patches as well as seeing how they affect speed/output. He's made MixAQ and OreAQ really both stable and reliable. His advantages appear on the info.txt in his builds. He subdivides diffs by functions: his improving zones, Seraphy's correct stack alignment, etc.

Not only that, he's noticed some bugs in official opitions. At any rate, see VFR maniac's site (http://www.esnips.com/web/VFRmaniac-Softwares), read his comments in english. But they should be talked about in another proper thread.It would be nice if such people made the minimal effort to submit patches to the developers rather than relying on the faint hope that someone else will do it for them (or, as I have seen in some places, believing that the official developers don't care about them and therefore monopolizing the patches...)

And language is not an excuse, we have multiple Japanese speakers in the official IRC channel, including (afaik) akupenguin himself.

[CruNcher]

MixAQ sounds great indeed exactly what i thought off when we discussed VAQ way back then :) (tough DS said it isn't possible to mix them, so nice to see that someone pulled it of)
Now we have to see how it does Visualy compared vs VAQ alone, tough wouldn't HAQ interfer heavily with VAQ in --aq-mode 2 now ?

[Sharktooth]

x264 r940 is broken with threads > 1. i already reverted the megui auto-update to r938. so even the modified patched builds are affected. x264 devs are working on a fix.
sadly the r940 was up on the megui auto-update for few hours. so i hope it didnt give too much headaches to megui users.
im really sorry, it's totally my fault. in the future i will test the builds using multiple threads (i usually do it with 1 thread) before uploading them into the auto-update server.

edit: r941 has just been commited with a fix.

[Dark Shikari]

x264 r940 is broken with threads > 1. i already reverted the megui auto-update to r938. so even the modified patched builds are affected. x264 devs are working on a fix.
sadly the r940 was up on the megui auto-update for few hours. so i hope it didnt give too much headaches to megui users.
im really sorry, it's totally my fault. in the future i will test the builds using multiple threads (i usually do it with 1 thread) before uploading them into the auto-update server.No, its my fault for not testing threads before I committed the fix (and a tiny bit akupengiun's for not noticing it when he approved my commit of the patch).

Its fixed (http://git.videolan.org/?p=x264.git;a=commitdiff;h=ae8da3e5c85562d1018b9f85c601884022f070a3) though.

[tobinaka]

It would be nice if such people made the minimal effort to submit patches to the developers rather than relying on the faint hope that someone else will do it for them (or, as I have seen in some places, believing that the official developers don't care about them and therefore monopolizing the patches...)

And language is not an excuse, we have multiple Japanese speakers in the official IRC channel, including (afaik) akupenguin himself.

I agree. Certainly it's efficient that one to bring it up should come it into action. If I could write codes, I would, but regrettably I can't. About other Japanese, wait for a moment. Even my introductions here must be unusual until now. I've seen they have felt thier patches little worth for Doom9's Forum developers. I've never felt so, then I introduced them here... I really agree with you, Dark Shikari. My postings are partially to encourage them. But it needs some time and steps.

In Japan, free-software developments in a group are still uncommon. I would have to say that SourceFourge.jp has only begun even if it launched in 2002. Many tools have been developed privately, and anonymous users have discussed on them in 2ch-forum and so on. That's paticular... often inefficient... but that's Japanese common style. Open-sourced projects are still less fashionalbe in Japan. Then, many Japanese free-software developers are not used to joining and discussing in Doom9's-Forum-like forums. The same can be said for IRC. Not to monopolize their patches.

Actually, language is not an excute. Even my poor English has been read kindly by you all (Thanks a lot!!). And I found the official IRC really easy to join and discuss on when I tried it, even I've not known akupenguin could use Japanese.:) The problem should be customs. That makes things difficult. But things must be better gradually, then the different cultures will make things interesting. You're right. But it needs some time and steps, like this discussions between you and I. I'll promote Japanese developers to join the official discussions. For now, consider their patches.

[Dark Shikari]

Actually, language is not an excute. Even my poor English has been read kindly by you all (Thanks a lot!!).Poor English? Your English is quite good; slightly awkward at times but overall very good for a non-native speaker. I don't think you have to worry about not being understood ;)

[skystrife]

x264.941.modified.exe (http://www.mediafire.com/?erarzojaidh) - Alternate Download (http://skystrife.com/x264/x264.941.modified.exe)
libx264-61.941.modified.dll (http://www.mediafire.com/?hdah9uwdjyz) - Alternate Download (http://skystrife.com/x264/libx264-61.941.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[kemuri-_9]

working on patching r942, due to the whitespace cosmetic changes, ended up having to use the -l option in patch (ignore whitespace distinctions) to get them to apply without rejections.
just as a heads up for the others.

[skystrife]

x264.942.modified.exe (http://www.mediafire.com/?alccau1e6qj) - Alternate Download (http://skystrife.com/x264/x264.942.modified.exe)
libx264-61.942.modified.dll (http://www.mediafire.com/?ujidb9cywxn) - Alternate Download (http://skystrife.com/x264/libx264-61.942.modified.dll)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

All patches are included with the source.

gcc 3.4.5 fprofiled build.

[G_M_C]

This is probably a very obvious question .... but :o .... what's the .DLL for ?

[Shinigami-Sama]

This is probably a very obvious question .... but :o .... what's the .DLL for ?

stuff like ffmpeg and avidemux

[skystrife]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

[TL0]

I read some of the posts by VFR maniac at his site and he mentions a bug in the zone option.

I noticed the bug at x264's zones.
When you use zones, x264_validate_parameters is called twice from two functions.
The one is x264_encoder_open, the other is x264_encoder_reconfig.
So, VAQ_GLOBAL + zones has the bug, which modifies qcomp twice.
I patched it as follows.
if( h->param.rc.f_aq_strength <= 0 )
h->param.rc.i_aq_mode = 0;
/* VAQ effectively replaces qcomp, so qcomp is raised towards 1 to compensate. */
- if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL )
+ if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL && ((h->param.rc.psz_zones && !h->param.rc.i_zones) || !h->param.rc.psz_zones) )
h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress + h->param.rc.f_aq_strength / 0.7, 0, 1);
h->param.analyse.i_noise_reduction = x264_clip3( h->param.analyse.i_noise_reduction, 0, 1<<16 );

But the bug was not able to be removed by it completely.
How can we remove this bug?

does anybody know if this is correct and if it has any negative effect on quality if zone option is used currently?

[gigah72]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

i tried to build fprofiled, but i get a crash in nasm on 945 & 946 (others i didn't try and with the usual patches) in both in deblock-a.asm.
http://img235.imageshack.us/img235/2919/nasmcrashro5.png (http://imageshack.us)
http://img235.imageshack.us/img235/2919/nasmcrashro5.9af9d64905.jpg (http://g.imageshack.us/g.php?h=235&i=nasmcrashro5.png)

[Sharktooth]

use yasm.

[gigah72]

use yasm.

thanks, now it works. funny that i never had a problem before.

if someone wants to try (at you own risk) 946 (exe & lib with patches):

http://www.mediafire.com/?sharekey=40642d9359c527a2ab1eab3e9fa335cae43ea9d1ebf82fba

[bob0r]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

Confirmed:
it crashes at the begin on the fourth fprofile run.
Trying to figure out whats the cause right now.

[Sagekilla]

Sorry but, where is r946? When I goto x264.nl I only see r944.

[wyti]

in Git, actually cause r946 cause problem to fprofiling there is no build at this time.

[kemuri-_9]

r946 is in the GIT, x264.nl often gets behind and needs bob0r's magic touch to get it updated.

fprofiling works for me, though i alter the profiles to include some patch profiling too:
./x264.exe --crf 30 -b1 -m1 -r1 --thread-input --psy-rd 0.0:0.0 --me dia --aq-mode 0 --asm 890 --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 16 -b2 -m3 -r3 --thread-input --psy-rd 0.0:0.0 --me hex -8 --direct spatial --aq-mode 1 --no-dct-decimate ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 26 -b2 -m5 -r2 --thread-input --psy-rd 0.0:0.0 --me hex -8 -w --cqm jvt --b-adapt 2 --nr 100 ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 18 -b3 -m7 -r5 --thread-input --psy-rd 0.0:0.0 --me umh -8 -t1 -A all --mixed-refs --b-rdo -w --b-pyramid --direct auto --bime --no-fast-pskip ../x264_build1.y4m --progress -o NUL ;
./x264.exe --crf 22 -b3 -m6 -r4 --thread-input --psy-rd 1.0:1.0 --me esa -8 -t2 -A all --mixed-refs --b-rdo --bime ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 --crf 24 -b3 -m7 -r3 --thread-input --psy-rd 0.2:0.2 --me tesa -8 -t1 --mixed-refs --b-rdo --bime ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 -q0 -m6 -r2 --thread-input --psy-rd 0.0:0.0 --me hex -Aall ../x264_build1.y4m --progress -o NUL ;
./x264.exe --frames 50 -q0 -m2 -r1 --thread-input --psy-rd 1.0:0.0 --me hex --no-cabac ../x264_build1.y4m --progress -o NUL ;

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSE3 Cache64
x264 [info]: slice I:88 Avg QP:27.98 size: 8050:00:00
x264 [info]: slice P:3073 Avg QP:29.79 size: 7024
x264 [info]: slice B:1189 Avg QP:31.87 size: 1412
x264 [info]: consecutive B-frames: 44.2% 55.8%
x264 [info]: mb I I16..4: 73.4% 0.0% 26.6%
x264 [info]: mb P I16..4: 23.4% 0.0% 16.1% P16..4: 25.2% 7.0% 1.3% 0.0% 0.0% skip:27.0%
x264 [info]: mb B I16..4: 1.4% 0.0% 0.0% B16..8: 18.4% 1.0% 0.6% direct: 5.9% skip:72.7% L0:30.1% L1:47.4% BI:22.5%
x264 [info]: kb/s:1322.5
encoded 4350 frames, 18.65 fps, 1322.67 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:100 Avg QP:13.55 size: 28448 PSNR Mean Y:60.31 U:65.29 V:63.54 Avg:60.51 Global:51.84
x264 [info]: slice P:2893 Avg QP:15.79 size: 26977 PSNR Mean Y:48.61 U:50.65 V:49.32 Avg:48.89 Global:46.93
x264 [info]: slice B:1357 Avg QP:18.02 size: 10265 PSNR Mean Y:47.05 U:49.56 V:47.97 Avg:47.41 Global:45.27
x264 [info]: consecutive B-frames: 44.0% 32.5% 23.5%
x264 [info]: mb I I16..4: 37.7% 23.3% 39.0%
x264 [info]: mb P I16..4: 7.5% 18.1% 23.3% P16..4: 23.3% 9.3% 5.6% 0.0% 0.0% skip:12.8%
x264 [info]: mb B I16..4: 2.6% 0.0% 0.0% B16..8: 37.5% 5.4% 6.1% direct:21.4% skip:27.0% L0:32.4% L1:35.5% BI:32.1%
x264 [info]: 8x8 transform intra:35.4% inter:51.2%
x264 [info]: ref P L0 83.1% 10.6% 6.3%
x264 [info]: ref B L0 85.0% 15.0%
x264 [info]: SSIM Mean Y:0.9937623
x264 [info]: PSNR Mean Y:48.394 U:50.647 V:49.228 Avg:48.698 Global:46.404 kb/s:5231.35
encoded 4350 frames, 17.79 fps, 5231.54 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:102 Avg QP:21.87 size: 12615 PSNR Mean Y:53.33 U:61.89 V:59.56 Avg:54.03 Global:43.66
x264 [info]: slice P:2175 Avg QP:27.03 size: 8669 PSNR Mean Y:41.43 U:46.78 V:43.84 Avg:42.07 Global:38.96
x264 [info]: slice B:2073 Avg QP:29.66 size: 3576 PSNR Mean Y:38.77 U:44.53 V:41.68 Avg:39.55 Global:37.79
x264 [info]: consecutive B-frames: 19.7% 28.4% 51.9%
x264 [info]: mb I I16..4: 35.9% 45.9% 18.2%
x264 [info]: mb P I16..4: 9.0% 29.7% 6.3% P16..4: 23.9% 6.8% 1.4% 0.0% 0.0% skip:22.8%
x264 [info]: mb B I16..4: 8.4% 0.0% 0.0% B16..8: 24.5% 2.1% 1.2% direct:13.9% skip:50.0% L0:34.9% L1:48.5% BI:16.6%
x264 [info]: 8x8 transform intra:55.1% inter:54.6%
x264 [info]: ref P L0 84.3% 15.7%
x264 [info]: SSIM Mean Y:0.9750468
x264 [info]: PSNR Mean Y:40.440 U:46.065 V:43.178 Avg:41.146 Global:38.422 kb/s:1520.28
encoded 4350 frames, 10.20 fps, 1520.46 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:59 Avg QP:13.21 size: 12098 PSNR Mean Y:65.26 U:67.45 V:66.05 Avg:65.31 Global:53.06
x264 [info]: slice P:2880 Avg QP:19.08 size: 16859 PSNR Mean Y:46.19 U:48.18 V:46.52 Avg:46.34 Global:44.63
x264 [info]: slice B:1411 Avg QP:21.95 size: 5156 PSNR Mean Y:44.71 U:47.14 V:45.33 Avg:44.97 Global:43.01
x264 [info]: consecutive B-frames: 44.5% 32.1% 8.5% 14.9%
x264 [info]: mb I I16..4: 54.2% 40.2% 5.7%
x264 [info]: mb P I16..4: 8.7% 29.7% 3.4% P16..4: 27.5% 11.1% 6.0% 0.5% 0.2% skip:12.9%
x264 [info]: mb B I16..4: 0.5% 2.2% 0.3% B16..8: 37.9% 2.6% 2.5% direct: 6.4% skip:47.6% L0:36.4% L1:41.5% BI:22.1%
x264 [info]: 8x8 transform intra:69.6% inter:79.5%
x264 [info]: direct mvs spatial:96.3% temporal:3.7%
x264 [info]: ref P L0 76.9% 12.0% 6.0% 2.8% 2.4%
x264 [info]: ref B L0 79.3% 14.6% 4.1% 2.1%
x264 [info]: ref B L1 96.5% 3.5%
x264 [info]: SSIM Mean Y:0.9911334
x264 [info]: PSNR Mean Y:45.965 U:48.105 V:46.398 Avg:46.152 Global:44.083 kb/s:3119.60
encoded 4350 frames, 4.97 fps, 3119.76 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:58 Avg QP:15.85 size: 10880 PSNR Mean Y:63.58 U:67.26 V:66.06 Avg:64.16 Global:50.41
x264 [info]: slice P:2881 Avg QP:23.00 size: 13992 PSNR Mean Y:43.68 U:47.95 V:46.21 Avg:44.39 Global:42.51
x264 [info]: slice B:1411 Avg QP:26.08 size: 3472 PSNR Mean Y:42.42 U:46.86 V:44.90 Avg:43.10 Global:40.98
x264 [info]: consecutive B-frames: 44.5% 32.1% 8.5% 14.9%
x264 [info]: mb I I16..4: 53.1% 41.5% 5.4%
x264 [info]: mb P I16..4: 7.9% 28.6% 2.2% P16..4: 28.9% 9.9% 7.0% 0.3% 0.1% skip:15.2%
x264 [info]: mb B I16..4: 0.5% 1.9% 0.1% B16..8: 37.4% 1.4% 1.9% direct: 4.1% skip:52.6% L0:35.0% L1:46.1% BI:18.8%
x264 [info]: 8x8 transform intra:72.5% inter:67.3%
x264 [info]: ref P L0 80.3% 10.3% 6.2% 3.2%
x264 [info]: ref B L0 83.8% 11.1% 5.2%
x264 [info]: SSIM Mean Y:0.9860930
x264 [info]: PSNR Mean Y:43.539 U:47.854 V:46.052 Avg:44.234 Global:41.993 kb/s:2529.25
encoded 4350 frames, 3.97 fps, 2529.42 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP:10.00 size: 94 PSNR Mean Y:100.00 U:100.00 V:100.00 Avg:100.00 Global:100.00
x264 [info]: slice P:23 Avg QP:23.41 size: 3554 PSNR Mean Y:46.98 U:55.16 V:54.38 Avg:48.36 Global:46.55
x264 [info]: slice B:26 Avg QP:25.98 size: 421 PSNR Mean Y:43.66 U:51.86 V:49.06 Avg:44.96 Global:44.52
x264 [info]: consecutive B-frames: 16.3% 36.7% 6.1% 40.8%
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 11.3% 21.4% 0.4% P16..4: 29.3% 3.2% 0.6% 0.0% 0.0% skip:33.8%
x264 [info]: mb B I16..4: 0.3% 0.3% 0.0% B16..8: 16.6% 0.0% 0.1% direct: 0.9% skip:81.8% L0:26.9% L1:68.3% BI: 4.8%
x264 [info]: 8x8 transform intra:57.0% inter:85.0%
x264 [info]: ref P L0 94.1% 4.2% 1.7%
x264 [info]: ref B L0 95.8% 4.2%
x264 [info]: SSIM Mean Y:0.9878109
x264 [info]: PSNR Mean Y:46.310 U:54.342 V:52.526 Avg:47.624 Global:45.449 kb/s:445.32
encoded 50 frames, 7.88 fps, 448.37 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP: 0.00 size: 12900
x264 [info]: slice P:49 Avg QP: 0.00 size: 59494
x264 [info]: mb I I16..4: 99.9% 0.0% 0.1%
x264 [info]: mb P I16..4: 3.2% 0.0% 20.9% P16..4: 35.0% 8.0% 9.1% 1.3% 0.9% skip:21.5%
x264 [info]: ref P L0 77.2% 22.8%
x264 [info]: kb/s:13993.5
encoded 50 frames, 13.85 fps, 14018.52 kb/s

yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:1 Avg QP: 0.00 size: 95400
x264 [info]: slice P:49 Avg QP: 0.00 size: 73169
x264 [info]: mb I I16..4: 99.9% 0.0% 0.1%
x264 [info]: mb P I16..4: 22.5% 0.0% 20.1% P16..4: 33.1% 11.5% 8.5% 0.0% 0.0% skip: 4.3%
x264 [info]: kb/s:17213.9
encoded 50 frames, 40.00 fps, 17216.06 kb/s


Skystrike & bob0r: are you two profiling with avs scripts?
if so then you might be hitting the 2GB mem limit causing x264 to silent crash/quit.

[Sharktooth]

gcc 4.3.1 profiling works...
gcc 3.4.6 profiling crashes...
gcc 3.4.6 debug works...
gcc 3.4.6 debug with -O3 crashes...

Program received signal SIGSEGV, Segmentation fault.
0x0042d96b in block_residual_write_cabac (h=0x1af, cb=0x22cfc0,
i_ctxBlockCat=5, i_idx=0, l=0xed8790, i_count=64) at ./common/bs.h:225
225 if( val < 255 )
:confused:
devz working on it.

[LoRd_MuldeR]

r946 won't fprofile properly on my end with the patches I have been using in my previous builds. x264 randomly will "stop working."

Does this happen for anyone else?

The "Psy RDO v0.6" patch won't apply to r946 at all :(

$ patch -p1 < ../x264-psyrd-0.6.diff
patching file `common/common.c'
patching file `common/common.h'
Hunk #1 succeeded at 381 (offset 4 lines).
Hunk #2 succeeded at 460 (offset 4 lines).
patching file `common/dct.h'
patching file `encoder/analyse.c'
patching file `encoder/encoder.c'
patching file `encoder/macroblock.c'
Hunk #2 FAILED at 121.
Hunk #4 succeeded at 447 with fuzz 2.
Hunk #5 succeeded at 495 with fuzz 2.
1 out of 5 hunks FAILED -- saving rejects to encoder/macroblock.c.rej
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #1 FAILED at 50.
1 out of 5 hunks FAILED -- saving rejects to encoder/rdo.c.rej
patching file `x264.c'
patching file `x264.h'

[gigah72]

see here:
http://forum.doom9.org/showpost.php?p=1173030&postcount=716

[LoRd_MuldeR]

see here:
http://forum.doom9.org/showpost.php?p=1173030&postcount=716

Sorry, I missed that post. With that option the patch applies successfully and compiles successfully... :)

[MythCreator]

x264.947.modified.exe (http://www.mediafire.com/?awyqlgnaja2)

Patches used:

x264_psy_rdo_0.6.diff
x264_new_bframe_decision_04.diff <-- This patch is highly experimental, only enabled with --b-adapt 2.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff


gcc 4.2.4 fprofiled build.

[bob0r]

x264.947.modified.01.exe (http://files.x264.nl/x264.947.modified.01.exe)
libx264-61.947.modified.01.dll (http://files.x264.nl/libx264-61.947.modified.01.dll)

x264-psyrd-0.6.diff (on by default, adjust with: --psy-rd) <-- patch using -l parameter (ignore whitespaces): patch -p1 -l < x264-psyrd-0.6.diff

x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

Not using x264.new.bframes.decision.04.diff (highly experimental, enabled with: --b-adapt 2) because it fails --no-b-adapt

[tobinaka]

does anybody know if this is correct and if it has any negative effect on quality if zone option is used currently?

VFR maniac himself wrote its diff. Get it here (http://www.esnips.com/web/VFRmaniac-Softwares).

x264_fix_extended_zones.diff

This patch removes bugｓ of aq-mode=2 + zones, and extended zones doesn't function (for some options). And this deduplicates unnecessary warnings. Support using AQ in the zones.

Oh, VFR maniac's English message does make some contrary senses against his comment on his Japanese blog.
He actually want to say that: his diff will remove "the bugs in aq-mode 2 + zones", "failure functions of extending zones for some options" and "unnecessarily duplicated warnings".

The current zones usage increases qpcomp by the value of aq-strength twice. That's because zones call x264_validate_parametes, where some operations are done. He corrects it by adding another argument to x264_validate_parametes and determining if it's called in zones or not. He wants at least this AQ part to be commited.

He said he straggled to write it up because you developers caught him by my link ;) Japanese have just some reasons of hesitating to use official supports. But they will be pleased if they can help x264 development by their own efforts like you all! (go easy on them/us, DS:))

[Ranguvar]

This new interest in odd patches is good :) People like Komisar666 and these new Japanese devs have amassed a ton of patches, and while some (VAQ2mod, anyone?) seem rather useless, I'd definitely like to hear what the developers think of them.

[skystrife]

I think I'd be more inclined to do testing with some of the new VAQ patches if they weren't written with fgo and/or other patches required, but were a patch against the direct source code.

[Ranguvar]

http://sites.google.com/site/ranguvar13/x264-builds

Direct Download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0948.7z?attredirects=0), Mirrors (http://www.uploadjockey.com/download/3658403/rang_x264_r0948.7z)

x264 r948 from Git.

Open this archive with the free, multi-platform tool 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary for most Windows PCs, and a binary optimized for Core 2 CPUs. The latter provides a performance increase of ~6% in my testing. Will vary.

Official source can be found at: http://x264.nl/
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog
Patches and discussion at Doom9's forum: http://forum.doom9.org/


Applied patches (included, unchanged, in the patches folder):

x264.progress.indication.01.diff
x264_hrd_pulldown.09_interlace.diff
x264-psyrd-0.6.diff
x264.new.bframes.decision.04.diff


Compiled by Ranguvar on August 22nd, 2008, with GCC 4.3.1 on Windows XP Professional x64 SP2.

CLI used for generic build: ./configure --extra-cflags="-pipe" && make fprofiled VIDS="../enctests/deadline_cif.y4m ../enctests/foreman_cif.y4m ../enctests/garden_sif.y4m ../enctests/grandma_qcif.y4m ../enctests/husky_cif.y4m ../enctests/mobile_cif.y4m ../enctests/suzie_qcif.y4m"
CLI used for Core 2 build: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled VIDS="same_as_above"

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[wyti]

Thanks for the build, it's nice too see all the details of your patch ;)

[martino]

I've been wondering whether anyone tried to do speed comparisons between a build compiled by GCC 3.4.5 and 4.3.*, since I got the 3.4.5 one to encode faster and would like to know whether anyone else experienced the same, or something different.

[Ranguvar]

3.4.x seems to create faster builds than 4.3.x in my experience (though not by much). This should change eventually. However, the 4.3.x series adds better Core 2 optimization, and trounces 3.4.x when creating a Core 2-optimized build.

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

ICC still beats both out though, by a fair amount... I'm going to be getting it soon, unless x264 has incompatibilities with it. :)

[Dark Shikari]

ICC still beats both out though, by a fair amount... I'm going to be getting it soon, unless x264 has incompatibilities with it. :)ICC has (afaik) the same stack alignment problem that MSVC does.

[Ranguvar]

ICC has (afaik) the same stack alignment problem that MSVC does.
Crap.

[kemuri-_9]

ICC doesn't really help those of us on the AMD side of the fence either :rolleyes:

[Ranguvar]

Yeah, but I already provide a generic and a Core 2 build, so I'd probably do something similar; the generic one would be GCC and the Core 2 one would be ICC.

So, ICC-compiled code does not work on AMD? Or there's just a slowdown? Enough to make GCC faster?

[gigah72]

about how much faster are you guys talking, as the most important stuff is already in asm?
in my comparisons between my builds (march=pentium2) and the others linked here, i never got noteworthy differences ...
someone wrote about a gain of 1,1% between plain make and make fprofiled. so if i encode 600min i win ~6min, but fprofiled takes also time ...
now i'm using a short clip, that will make fprofiled take longer by 5 min then without, but i get smaller exe.
what is your experiance with differnt vids for fprofiled?
and how much is difference you talk about between gcc 3.4.5 and 4.3.1 or others?

[martino]

However, the 4.3.x series adds better Core 2 optimization, and trounces 3.4.x when creating a Core 2-optimized build.
Interesting. I guess this is worth a re-test for me...

@gigah72
For me it was negligible in 1st pass, but 2nd was about 2-3fps faster on 704x480 video, with trellis 2, subme 7, partitions all, ref 8, bframes 5, and not sure about the rest, but probably defaults.


EDIT:
ICC has (afaik) the same stack alignment problem that MSVC does.
What does this mean in practical terms?

[akupenguin]

However, the 4.3.x series adds better Core 2 optimization,
Not really. x264 compiled with gcc 4.2.3 march=k8, 4.3.1 march=k8, and 4.3.1 march=core2 are all within about 0.2% speed of each other on core2... and sometimes it's the k8 ones that are faster.
4.3.x did improve autovectorization (from nonexistent to atrocious), but that doesn't matter to us.

[gigah72]

Interesting. I guess this is worth a re-test for me...

@gigah72
For me it was negligible in 1st pass, but 2nd was about 2-3fps faster on 704x480 video, with trellis 2, subme 7, partitions all, ref 8, bframes 5, and not sure about the rest, but probably defaults.


EDIT:

What does this mean in practical terms?

well, that's a lot, but i have different scenario, i'm encoding to 1280x720 with crf18 or 20 with something like sharktooths megui ps3-xbox360 profile ... maybe that's why i don't see such difference

[Shinigami-Sama]

What does this mean in practical terms?

its slower... because it has to use slower functions, or a whole other function to re-align the data