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

[TheRyuu]

See https://forum.doom9.org/showthread.php?p=1144364#post1144364

[gav1577]

Ok guys please could someone explain as simple as possible what rdo optimize does an how does it benefit fgo ? Thanks

[TheRyuu]

Ok guys please could someone explain as simple as possible what rdo optimize does an how does it benefit fgo ? Thanks

See http://forum.doom9.org/showthread.php?t=138293

[gav1577]

See https://forum.doom9.org/showthread.php?t=138293

Thanks wizboy11 :)

[survivant001]

This build also doesn't have the hrd pulldown (does anyone even use that?)


It's not the patch to make it works on the PS3 ?

[tymoxa]

It's not the patch to make it works on the PS3 ?
Not only PS3. This patch allows х264-encoded videos to be reproduced on standalone blu-ray players.
Hrd-pulldown patch is really needed.

[Atak_Snajpera]

I think that hrd is automatically added during muxing in TSmuxer

[TheRyuu]

Because people like to complain:
x264.859.modified.tenbillion (http://www.mediafire.com/?tnbsyoqejoc) (how many 859 builds do we have now???) :p

Patches:
hrd pulldown
fix win stdin
meprepass
gxRC
x264_progress
nr fix
gaussian cplxblur
2pass vbv
new RDO

Enjoy

[gav1577]

Hi there i have been searching trying to find out what the 2pass vbv patch does but cant seem to find out much about it please could someone explain what this patch does the benefits and usage please thanks

[LoRd_MuldeR]

Hi there i have been searching trying to find out what the 2pass vbv patch does but cant seem to find out much about it please could someone explain what this patch does the benefits and usage please thanks


From the changelog:

commit 7331ea4e381898421a1a908ed57f73126faacd36
Author: Gabriel Bouvigne <gabriel.bouvigne@joost.com>
Date: Mon Jun 2 12:53:01 2008 -0600

2-pass VBV support and improved VBV handling
Dramatically improves 1-pass VBV ratecontrol (especially CBR) and provides support for VBV in 2-pass mode. This consists of a series of functions that attempts to find overflows and underflows in the VBV from the first-pass statsfile and fix them before encoding.
1-pass VBV code partially by Dark Shikari.

[gav1577]

Thanks LoRd_MuldeR much appreciated but one thing i am unclear of is there cmd switch or is the patch automatically activated ?

[Atak_Snajpera]

Because people like to complain:
x264.859.modified.tenbillion (how many 859 builds do we have now???)

Patches:
hrd pulldown
fix win stdin
meprepass
gxRC
x264_progress
nr fix
gaussian cplxblur
2pass vbv
new RDO

Enjoy

wizboy11 could you compile with latest psy patch 0.22?

[TheRyuu]

wizboy11 could you compile with latest psy patch 0.22?

I was already on it before you asked >_>

------------------------------------------

x264.861.modified.exe (http://www.mediafire.com/?gknvsmldmy0)
(Alt Download Site (http://www.zshare.net/download/13006439902b0087/))

Patches:
x264_progress.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_fix_win_stdin.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff
gxRC.diff <---DTS 02 patch but aligned

avis input, mp4 output, pthreads activated upon configure. (statically linked pthreads)
Built with GCC 3.4.5, fprofiled.

Couple notes:
vbv has been integrated into git as well as the nr threads fix.

New option : --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

me-prepass:
activated with --me-prepass
off by default

gxRC:
Activated at subme levels 6 and 7.

[Atak_Snajpera]

Thanks!

[survivant001]

Couple notes:
vbv has been integrated into git as well as the nr threads fix.


that's mean that we wont' see vbv_0x.. patch anymore because they are in the common branch right ?

just to know because I'm only using 2 passes.

[TheRyuu]

that's mean that we wont' see vbv_0x.. patch anymore because they are in the common branch right ?

just to know because I'm only using 2 passes.

The patch has been integrated into the git so you won't see the patch in the list anymore because it's already there :p

[gav1577]

Nice 1 wizboy11 :thanks:

[TheRyuu]

x264.869.modified.exe (http://www.mediafire.com/?xb4ittdi0nz)
(alt DL link (http://www.zshare.net/download/130689194e58f8bb/))

x264 Rev. 869 Modified Patch Build
Avis Input, mp4 output, pthreads config.

Built with GCC 3.4.5, make fprofiled, and statically linked pthreads. (means no pthreads.dll required in x264 directory)

Patches:
x264_gxRC.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_progress.diff
x264_psyRDO_0.22.diff

The x264_fix_win_stdin.diff patch has been committed into the git so that has been left out.

Notes:
See the psyRDO thread (http://forum.doom9.org/showthread.php?t=138293) on usage of it although I briefly explained it in an above post.
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

me-prepass:
Use --me-prepass flag to activate, off by default
Runs a half-pel search at a slight speed cost to improve quality with any --me mode.

x264_gxRC.diff:
Activated at subme levels 6 and 7, basically increases quality at little to no speed reduction.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[bokonon]

Thanks wizboy11

x264.869.modified.exe (http://www.mediafire.com/?xb4ittdi0nz)
(alt DL link (http://www.zshare.net/download/130689194e58f8bb/))

x264_gxRC.diff:
Activated at subme levels 6 and 7, basically increases quality at little to no speed reduction.

I've done a search for this and i get no results other than your posts in this thread. What does it really do/where can i read more?

[TheRyuu]

Thanks wizboy11

I've done a search for this and i get no results other than your posts in this thread. What does it really do/where can i read more?

gxRC actually isn't worth it after talking with some x264 devs. The speed/quality tradeoff just isn't worth it.

So it will be removed from later builds. It's in this thread, just look back if you want to learn a little about it I think.

[TheRyuu]

New build, basically just changing the patches (using less).

x264.869.modified.02.exe (http://www.mediafire.com/?svdk4z9vmz3)

Patches:
x264_progress.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff

Notes:
Removed gxRC patch because there's a reason it wasn't committed into the git. (speed/quality trade off totally not worth it)

x264_me-prepass_DeathTheSheep.01.diff:
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa.

x264.gaussian.cplxblur.01.diff:
improves 2 pass rate control

x264_psyRDO_02.diff:
see thread (http://forum.doom9.org/showthread.php?t=138293)
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[gav1577]

Hi how much of a difference can --me-prepass make? basically is there a noticeable difference because it slows things down quite a bit for me and i cant see any difference with it turned on or off. is it more effective for lower bitrates ?

[Dark Shikari]

Hi how much of a difference can --me-prepass make? basically is there a noticeable difference because it slows things down quite a bit for me and i cant see any difference with it turned on or off. is it more effective for lower bitrates ?No it isn't very useful. The benefit is on par with --me umh -> esa or something like that.

[gav1577]

Thanks for the help Dark Shikari

[lexor]

//snip from git for gaussian blur patch
for(j=0; j<=cplxblur*2 && j<=i; j++){
ratecontrol_entry_t *rcj = &rcc->entry[i-j];
double gaussian_weight = weight * exp(-j*j/200.0);

Are we trusting gcc to take that double definition out of the loop? I know early 4.x's couldn't be always relied on to do that (though I encountered it with larger objects, not primitives). Even though if it stays in there performance shouldn't suffer measurably, still seems like bad form.

[Dark Shikari]

//snip from git for gaussian blur patch
for(j=0; j<=cplxblur*2 && j<=i; j++){
ratecontrol_entry_t *rcj = &rcc->entry[i-j];
double gaussian_weight = weight * exp(-j*j/200.0);

Are we trusting gcc to take that double definition out of the loop? I know early 4.x's couldn't be always relied on to do that (though I encountered it with larger objects, not primitives). Even though if it stays in there performance shouldn't suffer measurably, still seems like bad form.Its actually better for GCC to define a variable as close as possible to where its used. But it doesn't matter here; the main problem was a C99-ism in code a few lines later, and your issue as been resolved in the same patch, r871.

[MasterNobody]

Collection of patches that I use for building x264vfw (useful not only for VfW): bm_x264_patch_collection.r870.zip (http://stashbox.org/132452/bm_x264_patch_collection.r870.zip)
List of independent patches:
x264_32x32samples_crash.r870.diff
x264_cosmetic.r870.diff
x264_debug_defines.r870.diff
x264_fix_stats_file_work.r870.diff
x264_frames_memoryleak.r870.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff
x264_psy_rdo.r870.diff
x264_thread_pool.r870.diff
x264_vaq2mod.03.r870.diff

Patches that depends of others:
bm_x264_thread_pool.r870.diff depends of x264_fix_stats_file_work.r870.diff, x264_frames_memoryleak.r870.diff, x264_multithreading_Nth_pass_ratecontrol.r870.diff
bm_x264_vfw2cli.r870.diff depends of x264_fix_stats_file_work.r870.diff

All in one patches:
bm_x264_cli_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_exp_VAQ2mod_PsyRDO_fixed.r870.diff
bm_x264_normal_fixed.r870.diff

Description of the patches here (http://mailman.videolan.org/pipermail/x264-devel/2008-January/003921.html).

CLI-version build with this patches here: x264_CLI_870bm_VAQ2mod_PsyRDO_fixed.zip (http://stashbox.org/132124/x264_CLI_870bm_VAQ2mod_PsyRDO_fixed.zip)
Build with GCC (GCC TDM-3 for MinGW) 4.3.0 and YASM 0.7.1.2093
Configuration:
Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[Razorholt]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.

[TheRyuu]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.

me-prepass is only really worth it when using --me esa or higher. It's not even that useful, tesa is probably just better.

-------------------------------------------

x264.871.modified.exe (http://www.mediafire.com/?ulvxaxxz0dj)

GCC 3.4.5 make fprofiled build.

Patches:
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_psyRDO_02.diff
x264_progress.diff

More git commits means less patches. Guassian blur was committed so that's off the list now too.

x264_me-prepass_DeathTheSheep.01.diff:
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa. Isn't really worth it since --me tesa will provide better motion searching. But since it has a flag and it's default is off I include it.

x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[gav1577]

Thanks wizboy11

[MasterNobody]

Thanks a lot MasterNobody!

I don't see me-prepass patch listed here. What is your opinion on this patch? Apparently it has been "fixed" but I don't know what that means since I can't test it.I don't use me-prepass patch. As for the "fixed" than it stays here to indicate that this build didn't crash with multithreading on CPUs with SSE2 (my first build of 870 crashes due to the bug in x264_thread_pool patch, which I than fix).

[IgorC]

me-prepass is only really worth it when using --me esa or higher. It's not even that useful, tesa is probably just better.


Speaking mostly of DVD resolution:
me-prepass + umh has higher metric increase and speed then tesa with or w/o merange 24. Visually I think also.
Even 3d pass has higher metric boost then tesa ( ~ 0.1 avisynth SSIM = ~ 1%. Maybe a bit less)
I know that metric isn't ideal indicator of quality but it's already very hard to see difference.
I prefer umh+prepass and maybe 3dpass. Practically the same quality and much higher speed.

Maybe tesa and merange 24 perform better on HD.
It's just my experience.

[cyberbeing]

That is pretty much what I have found as well for DVD resolution content using --me-prepass. I just did a test comparison earlier today with a crf 10 encode on a high motion scene and umh + me-prepass was 38% faster (19% slower than w/o me-prepass) and had about 0.5% lower bitrate than esa.

I also did a test with a crf 17 encode on a low motion scene and esa was 67% slower than umh + me-prepass and again the me-prepass encode had the lowest bitrate by a slight margin.

Overall, considering that the speed hit from me-prepass is so much less than esa and tesa, I don't see it as all that bad a thing if you want to push a bit of extra quality out of your encode but aren't patient enough for esa or tesa.

[burfadel]

In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?

[Dark Shikari]

In reference to me-prepass, does x264 normally do a hpel search on a frame, and if so are the results from the me-prepass recycled (if they can be)? I'm assuming there may be elements of the frame encoded that has had me-prepass over it that no longer require any ME, so are those elements skipped when me-prepass is enabled?ME-prepass is just a simple ugly hack to do tons of hex searches. Its not particularly pretty or efficient.

[TheRyuu]

x264.877.modified.exe (http://www.mediafire.com/?4t4d3mzsreh)
(alt DL link (http://www.uploadjockey.com/download/9767026/x264.877.modified.exe))

Patches:
x264_hrd_pulldown.04_interlace.diff
x264_progress.diff
x264_psyRDO_0.22.diff
x264_me-prepass_updated.02.diff <---nothing more then a compatibility update to make it compatible with psyRDO patch.

Notes:
Few git commits fix up some asm coding. Also a slight speedup in trellis. See x264 GIT for more details (http://git.videolan.org/?p=x264.git;a=summary)

x264_me-prepass_updated.02.diff
use the --me-prepass flag to activate the half pel search. Improves quality using any --me mode but isn't really worth it until you get up to --me esa. Isn't really worth it since --me tesa will provide better motion searching. But since it has a flag and it's default is off I include it.

x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

[techouse]

x264_x86_r877_techouse (http://techouse.project357.com/builds/x264_x86_r877_techouse.7z)

Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep_techouse_fix.diff (http://pastebin.com/f62aea32f)

x264_progress.diff

x264_psy_rdo_0.22.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 8th 2008, 11:55:51 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

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

x264_x86_r877_FGO_techouse (http://techouse.project357.com/builds/x264_x86_r877_FGO_techouse.7z)

Source: x264 r877 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_FGO_techouse_fix.diff (http://pastebin.com/f7dcb4e0f)

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

x264_progress.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 8th 2008, 13:21:54 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

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

I built both cause some of you still prefer testing which perform better. ;)

Enjoy ;)

[MythCreator]

For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?

[Dark Shikari]

For my experience,Psy RDO just make more block than ssd in low and ultra low bitrate,Would Dark Shikari do some work to improve that?I can't do anything unless you give me a specific example of what you're talking about. And by a specific example I mean two .h264 files, one with psy and one without, at the same bitrate.

[MythCreator]

@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others

[techouse]

@Dark Shikari:Well , I will do that some days later, I just del the source..
@techouse:You don't have a yasm.exe at your /MinGW/bin ? I just noticed that your build have no optimization to SSE/SSE2 and others

http://git.videolan.org/?p=x264.git;a=commit;h=86c70b0fccc46752e03d3ed7fc5733dab31b5a41


many changes to which asm functions are enabled on which cpus.

with Phenom, 3dnow is no longer equivalent to "sse2 is slow", so make a new flag for that.

some sse2 functions are useful only on Core2 and Phenom, so make a "sse2 is fast" flag for that.

some ssse3 instructions didn't become useful until Penryn, so yet another flag.

disable sse2 completely on Pentium M and Core1, because it's uniformly slower than mmx.

enable some sse2 functions on Athlon64 that always were faster and we just didn't notice.

remove mc_luma_sse3, because the only cpu that has lddqu (namely Pentium 4D) doesn't have "sse2 is fast".

don't print mmx1, sse1, nor 3dnow in the detected cpuflags, since we don't really have any such functions. likewise don't print sse3 unless it's used (Pentium 4D).

And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder

[MythCreator]

http://git.videolan.org/?p=x264.git;a=commit;h=86c70b0fccc46752e03d3ed7fc5733dab31b5a41



And I have nasm.exe and yasm.exe in my C:\MingGW\bin folder


Ah , sorry and thanks~

[bob0r]

x264.880.modified.01.exe (http://files.x264.nl/x264.880.modified.01.exe)
x264.880.modified.01.source.zip (http://files.x264.nl/x264.880.modified.01.source.zip)

x264.psyRDO.0.22.diff
http://forum.doom9.org/showthread.php?t=138293
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264.progress.indication.01.diff
http://forum.doom9.org/showthread.php?t=135905

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Here is the output of the patching process:
http://files.x264.nl/x264.880.modified.01.patch.out.txt

Here is the output of the compiling process:
http://files.x264.nl/x264.880.modified.01.fprofiled.out.txt


gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/set.o encoder/set.c
encoder/set.c: In function `x264_sps_init':
encoder/set.c:215: warning: unused variable `cpbBrVclFactor'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-use -c -o encoder/encoder.o encoder/encoder.c
encoder/encoder.c: In function `x264_encoder_encode':
encoder/encoder.c:1278: warning: 'cpb_removal_delay' might be used uninitialized in this function


darkorange = x264_hrd_pulldown.04_interlace.diff

The warnings that are not in the GIT code are highlighted with a color, and should not be there.
(The GIT warnings are there because of a bug in Windows, they prevent the usage of extended zones, example: x264 --zones 1,100,bframes=0)
The GIT warnings:

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o common/common.o common/common.c
common/common.c: In function `x264_param_parse':
common/common.c:252: warning: unused variable `saveptr'

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer -fprofile-generate -c -o encoder/ratecontrol.o encoder/ratecontrol.c
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:564: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:607: warning: unused variable `saveptr'

[TheRyuu]

x264.883.modified.exe (http://www.mediafire.com/?xzwgm1gucmv)
x264.833.modified.source.rar (http://www.mediafire.com/?me1tqou2t1x)

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)

Other then that, not much to report this week. As always, notes on additional options added through the psyRDO patch:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

[Ranguvar]

Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!

[Wishbringer]

is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?! :confused:

[survivant001]

Wasn't ME-Prepass enabled by "--me-prepass" in commandline and otherwise disabled?! :confused:

yep.. he is just confused.

[TheRyuu]

Thanks, Dragon! Been waiting for an 883 build, especially without me-prepass. Hey, is it possible for someone to make a build where this can be disabled/enabled through the CLI?

Thanks again!

I make notes for a reason.
Removed me-prepass due to incompatibility (only really useful on esa anyway, and going to tesa would probably be more beneficial then using me-prepass)

I believe the type of loop used in me.c was changed and is the cause for the incompatibility. However I'm not about to go and try and hack it together for something that probably a.) won't work and b.) isn't really worth the effort.

[Ranguvar]

'Apologies'... I did read the notes, I just didn't know that me-prepass was already triggered by a switch.

[TheRyuu]

x264.886.modified.exe (http://www.mediafire.com/?gdmcekznhcu)
x264.886.modified.source.rar (http://www.mediafire.com/?dmga3jzzsbc)

Patches:
x264_progress.diff
x264_hrd_pulldown.04_interlace.diff
x264_psyRDO_0.22.diff

Notes:
Nothing new other then a few git commits (speed things up slightly cause GCC is a dumb-ass at unrolling loops (and some inline stuff I don't understand), at least I think that's what the commits do :p)

As always, additional options added by the patches:
x264_psyRDO_02.diff:
see thread
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.