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

[juGGaKNot]

You should select linux(LF)

Reinstalled,

windows style = git config --global core.autocrlf true
UNIX style=git config --global core.autocrlf false

same problem.

Changes since Git-1.5.4-preview20080202

New Features
• Comes with official git 1.5.5.
• core.autocrlf is enabled (true) by default. This means git converts to Windows line endings (CRLF) during checkout and converts to Unix line endings (LF) during commit. This is the right choice for cross-platform projects.

true/false/input nothing works, what version do you use ?

[elguaxo]

I downloaded and reinstalled Git-1.6.4-preview20090730.exe. I chose this and now the patching works.

http://img81.imageshack.us/img81/5581/unix.th.png (http://img81.imageshack.us/img81/5581/unix.png)

:)

[Trahald]

@JUGGAKNOT
i presume you did redownload (git clone) after the change? or 'git reset --hard' i think should work too. make sure save changes youve made if any

[juGGaKNot]

@JUGGAKNOT
i presume you did redownload (git clone) after the change? or 'git reset --hard' i think should work too. make sure save changes youve made if any

removed git, crapcleaner, reinstalled unix style ( git config --global core.autocrlf is false )

so

MSYS + MinGW + Git + YASM

Remove "bin\rxvt.exe" file

Open msys\etc\fstab in Notepad, replace d:/min /mingw

export PATH="$PATH:/d/git/bin"
cd /d/
git clone git://git.videolan.org/x264.git
cd /d/x264
git reset --hard
./configure ( Assembler YES, Pthread YES )

Modify x264.c preset placebo > preset juggaknot

param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->b_aud = 1;
param->b_nal_hrd = 1;

patch -p1 < /d/win.diff
patch -p1 < /d/hrd.diff
make fprofiled VIDS=sample.avs

compiles fine, i get a 498kb x264.exe

x264.exe" --pass 1 --slow-firstpass --preset juggaknot --bitrate x --output NUL avs
x264.exe" --pass 2 --preset juggaknot --bitrate x --output x avs

Makes

Writing library : x264 core 68 r1195M 5d75a9b
Encoding settings : cabac=1 / ref=10 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=10 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=0 / mbaff=0 / bframes=4 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=200 / ratetol=1.0 / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=20000 / vbv_bufsize=20000 / ip_ratio=1.10 / pb_ratio=1.10 / aq=2:1.00

I think the problem was i have a 2l fanta here not a 10l cola.

THNX.

[rack04]

I have the latest git but I'm unsure how to properly apply these patch files. I have the latest git and I have copied the patches to the project directory. Do I just type:

patch < x264_hrd_pulldown.15_interlace.diff -p0

and

patch < x264_win_zone_parse_fix_05.diff -p0

If I try that MSYS asks for a file to path.

[LoRd_MuldeR]

If you run from x264 root directory (this is where x264.c and x264.h are located), the correct command for most patches is:
patch -p1 < somepatch.diff

[rack04]

Great thanks. One other question, how do I configure for mp4 output?

[LoRd_MuldeR]

Great thanks. One other question, how do I configure for mp4 output?

GPAC is needed:
http://gpac.sourceforge.net/home_download.php

The configure script should detect it automatically, if installed.

[rack04]

GPAC is needed:
http://gpac.sourceforge.net/home_download.php

The configure script should detect it automatically, if installed.

Is there an installer for GPAC? All I see is the source code.

[juGGaKNot]

k, i'm getting tired of editing the x264.c so i want to make a diff

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->b_aud = 1;
param->b_nal_hrd = 1;
}

what else do i need in the diff to make sure it patches right ?

[roozhou]

Is there an installer for GPAC? All I see is the source code.
You don't have to download the source code and compile it on your own. It's a waste of time and energy.

Thanks to Sherpya we can get headers and pre-compiled libraries here:
http://oss.netfarm.it/mplayer/pkgs/libgpac_static-mingw32-0.4.5-gcc45.tar.bz2

Unzip it to your mingw folder and they should work.

[rack04]

Is the x264.exe created by "make fprofiled VIDS=/c/x264/riverbed.1920x1080.yuv" the final build? Or do I need to "make" after the fprofiled is complete?

[kemuri-_9]

k, i'm getting tired of editing the x264.c so i want to make a diff

what else do i need in the diff to make sure it patches right ?

clone the repository, edit the files as necessary, and then do a git diff and have the output redirect to a file i.e.
git diff > custom_profile.diff

then you can use this produced file with patch to replicate the changes with the non-edited file(s)

Is the x264.exe created by "make fprofiled VIDS=/c/x264/riverbed.1920x1080.yuv" the final build? Or do I need to "make" after the fprofiled is complete?
when make fprofiled finishes, that's the fprofiled binary....

[rack04]

when make fprofiled finishes, that's the fprofiled binary....

Excellent thanks.

Here is my x264 build:

x264 core:68 r1195 5d75a9b (http://www.mediafire.com/?sharekey=5d73f4b17331fe365a3d773badf21430e04e75f6e8ebb871)

Built on August 3, 2009, gcc: 4.4.0

$ ./configure --extra-cflags="-march=core2"

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

You can run 'make' or 'make fprofiled' now.

$ make fprofiled VIDS="riverbed.1920x1080.yuv"

Used patches:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[juGGaKNot]

clone the repository, edit the files as necessary, and then do a git diff and have the output redirect to a file i.e.
git diff > custom_profile.diff

then you can use this produced file with patch to replicate the changes with the non-edited file(s)

Every time git is updated or until the diff fails to patch ?

i got http://en.pastebin.ca/1516972

it seems valid for builds with hrd and zone fix.

[LoRd_MuldeR]

Every time git is updated or until the diff fails to patch ?.

If you made the patch as suggest by Kemuri, you can use that patch to re-apply your modifications every time you checked out the latest version from GIT.

However in case there are changes in the GIT version that make your patch fail, you will need to adjust the patch (or simply make a new patch against latest GIT).

[juGGaKNot]

If you made the patch as suggest by Kemuri, you can use that patch to re-apply your modifications every time you checked out the latest version from GIT.

However in case there are changes in the GIT version that make your patch fail, you will need to adjust the patch (or simply make a new patch against latest GIT).

I made it as suggested by you, git diff x264.c > 444.dif

git diff > 444.diff fails

now i patch win zone fix 05 then hrd

after i test my diff win zone fix 05 then hrd than my diff ?

[komisar]

I have published a new version of mingw cross-compile toolchain with gcc441 with Graphite loop transform framework (http://komisar.gin.by/mingw/index.html).
If you're interested - test please.
Build scripts and step-by-step description also published.

x264 1195 updated...
http://komisar.gin.by/

[juGGaKNot]

As soon as git is updated komisar.

[LoRd_MuldeR]

I have published a new version of mingw cross-compile toolchain with gcc441 with Graphite loop transform framework (http://komisar.gin.by/mingw/index.html).
If you're interested - test please.

Seems to work for me. Thanks!

[rack04]

when make fprofiled finishes, that's the fprofiled binary....

The reason I asked is because the time stamp on the file doesn't change.

[LoRd_MuldeR]

The reason I asked is because the time stamp on the file doesn't change.

The "make fprofiled" command does the following:

1. It builds x264 with -fprofile-generate
2. It runs several test encodes to collect profiling information
3. It re-builds x264, this time with -fprofile-use

So the very last thing it does is creating a new binary. I'd suspect the timestamp of x264.exe to change at that moment ;)

(Note that "make fprofiled" does that all for you. You don't need run "make" once again! This would actually replace the "fprofiled" binary with a non-profiled one ^^)

[kemuri-_9]

The reason I asked is because the time stamp on the file doesn't change.

*irritated*

fprofiled:
$(MAKE) clean
mv config.mak config.mak2
sed -e 's/CFLAGS.*/& -fprofile-generate/; s/LDFLAGS.*/& -fprofile-generate/' config.mak2 > config.mak
$(MAKE) x264$(EXE)
$(foreach V, $(VIDS), $(foreach I, 0 1 2 3 4 5 6 7, ./x264$(EXE) $(OPT$I) --threads 1 $(V) -o $(DEVNULL) ;))
rm -f $(SRC2:%.c=%.o)
sed -e 's/CFLAGS.*/& -fprofile-use/; s/LDFLAGS.*/& -fprofile-use/' config.mak2 > config.mak
$(MAKE)
rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
mv config.mak2 config.mak
endif

...

clean:
rm -f $(OBJS) $(OBJASM) $(OBJCLI) $(SONAME) *.a x264 x264.exe .depend TAGS
rm -f checkasm checkasm.exe tools/checkasm.o tools/checkasm-a.o
rm -f $(SRC2:%.c=%.gcda) $(SRC2:%.c=%.gcno)
- sed -e 's/ *-fprofile-\(generate\|use\)//g' config.mak > config.mak2 && mv config.mak2 config.mak


make fprofiled deletes any binary that's already there and makes a profile-capable binary, profiles, and then makes the profiled binary.

chances are you're looking at the creation timestamp which usually never changes, look at the modified timestamp

[rack04]

make fprofiled deletes any binary that's already there and makes a profile-capable binary, profiles, and then makes the profiled binary.

chances are you're looking at the creation timestamp which usually never changes, look at the modified timestamp

*not-irritated*

Thanks! :)

[rack04]

x264 r1195 32-bit

Download (http://www.megaupload.com/?d=1G1GDIO0)

Built by rack04 on August 5, 2009, 8:24:42 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with a 300 frame PNG sequence of Big Buck Bunny

Patched with:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

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

[juGGaKNot]

x264_x86_r1198_juGGaKNot (http://www.mediafire.com/download.php?dez2jqve5mn)
GCC 4.4.1, generic, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff (http://www.mediafire.com/download.php?kqymujywhtw)

It is fprofiled on a uncompressed source with very high motion.

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), Doom9.org Macroblock tree Ratecontrol thread (http://forum.doom9.org/showthread.php?t=148686) and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.

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

BTW with mbtree commited i get the "mbtre + b-piramid" not suported warning dark, will you update to avoid this or is it k ?

Waiting for HRD 16.

[rack04]

BTW with mbtree commited i get the "mbtre + b-piramid" not suported warning dark, will you update to avoid this or is it k ?

What do you mean update? b-pyramid isn't supported. That is what the message is telling you.

What doesn't it work with yet?

--b-pyramid

[juGGaKNot]

to get fprofiled it encodes, it uses some settings, in one encode it uses --b-pyramid + mbtree and displays a warning

also pbratio is in the --longhelp, does it still exist ( i guess when not using mbtree ) ?

[wyti]

Add mean Add, very slow is only a new profile, but placebo still exist.

And the warning, not very important it display this warning and internally disable b-pyramid, and a new update will probably come to support B-pyramid

[komisar]

Trahald, is this correct adaptation to 1198 version?
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1198.diff)

[rack04]

Trahald, is this correct adaptation to 1198 version?
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.15_interlace.fix.1198.diff)

I tried this patch and during the 2nd pass it kept throwing an error about "ratecontrol_init: can't open mbtree stats file".

avis [info]: 640x480 @ 60.00 fps (200 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [error]: ratecontrol_init: can't open mbtree stats file
x264 [error]: x264_encoder_open failed

[komisar]

rack04, strange... I don't see any error. Can you post command-line? (more likely it is not because of this patch)

[rack04]

rack04, strange... I don't see any error. Can you post command-line?

Echo.
Echo.
Echo.[ %TIME% ] Encoding pass 1 ...
Echo.

@Echo on
"%x264_PATH%" --preset veryfast --tune film --pass 1 --slow-firstpass --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --level 4.1 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 24000 --direct auto --b-adapt 2 --nal-hrd --output NUL "%INPUT_VIDEO%" 2>"%SOURCE_FOLDER%\%SOURCE_FILENAME%-1pass.txt"
@Echo off

Echo.
Echo.
Echo.[ %TIME% ] Encoding pass 2 ...
Echo.

@Echo on
"%x264_PATH%" --preset slower --tune film --pass 2 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --level 4.1 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 24000 --no-fast-pskip --sar 1:1 --aud --nal-hrd --output "%SOURCE_FOLDER%\%SOURCE_FILENAME%-output.h264" "%INPUT_VIDEO%" 2>"%SOURCE_FOLDER%\%SOURCE_FILENAME%-2pass.txt"
@Echo off

[rack04]

This is the build that I'm using:

x264 core:69 r1198M a1ed468 32-bit

Download (http://www.mediafire.com/?sharekey=ec060338ab9d891fe7c82ed4b8f0c380e04e75f6e8ebb871)

Built by rack04 on August 7, 2009, 10:47:09 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with 200 frames of BigBuckBunny.avs, 200 frames of LosslessTouhou.mkv, and 250 frames of riverbed.1920x1080.yuv

Patched with:

x264_hrd_pulldown.15_interlace.fix.1198.diff
x264_win_zone_parse_fix_05.diff

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

[juGGaKNot]

x264_x86_r1198_HRD_fix_juGGaKNot (http://www.mediafire.com/download.php?zmkxzlnyngn)
GCC 4.4.1, modified, fprofiled, patched
Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff (http://www.mediafire.com/download.php?kqymujywhtw)
x264_hrd_pulldown.15_interlace.fix.1198.diff (http://www.mediafire.com/download.php?lgng2dkyoyz)

It is fprofiled on a uncompressed 300 frames source with very high motion

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

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.

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

It patches right, it encodes right.

[komisar]

rack04, with "--preset ultrafast/veryfast/faster" stats.mbtree not created... :-\ In this presets mb-tree disabled...
Add --mbtree for 1st pass.

[rack04]

rack04, with "--preset ultrafast/veryfast/faster" stats.mbtree not created... :-\

So is this considered a bug in the x264 or my fault for a bad command line? I think since --slow-firstpass is an option the mbtree should take into account --preset ultrafast/veryfast/faster in the first pass.

[juGGaKNot]

Rack rc-lookahead is disabled on the second pass, your setup is useless for mbtree.

[rack04]

Rack rc-lookahead is disabled on the second pass, your setup is useless for mbtree.

How do you figure? Default is 40.

Although now that I look at the mediainfo information:

Encoding settings: cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.0:0.2 / mixed_ref=1
/ me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=3 / nr=0 / decimate=1
/ mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=24 / keyint_min=1 / scenecut=40 / rc_lookahead=24
/ rc=2pass / mbtree=1 / bitrate=10732 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0
/ qblur=0.5 / vbv_maxrate=24000 / vbv_bufsize=30000 / ip_ratio=1.40 / aq=1:1.00


:confused:

[juGGaKNot]

Read the mbtree thread

rc-lookahead is disabled on second pass since 0.11, rc1 will show lookahead 0, commited version has a tweak to show the first pass value.

Changes in 0.11:

2. Lots of trivial parameter-handling fixes, e.g. lookahead automatically disabled on second pass.

[Dark Shikari]

Lookahead is clipped to keyint.

[juGGaKNot]

Lookahead is clipped to keyint.

Really ? so bd users have to use 24 max hmm.

rack

Always use the same preset in both passes.

[akupenguin]

so bd users have to use 24 max hmm.
Lookahead>keyint would not be useful. We don't strictly stop the lookahead at the next keyframe, but that's only for consistency with the previous frames in the GOP that had more dependents. No frame will ever actually affect anything more than a keyint ahead, so it would just be wrong to include those in the lookahead window.

[imk]

x264-r1201M-imk-win.7z (http://imk.cx/pc/x264/x264-r1201M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

x264-r1201M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1201M-imk-osx.7z)

I didn't use the hrd or win zone patch for this build. When those patches are updated, I'll make new builds.

[juGGaKNot]

x264_x86_r1201_juGGaKNot (http://www.mediafire.com/download.php?yxnmxtjiyzt)
GCC 4.4.1, generic, fprofiled.
Source: GIT

It is fprofiled on a uncompressed 300 frames source with very high motion

Please check Doom9.org patches thread (http://forum.doom9.org/showthread.php?t=130364), Doom9.org Macroblock tree Ratecontrol thread (http://forum.doom9.org/showthread.php?t=148686) and GIT shortlog (http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog) for more info.

Compiled by juGGaKNot (http://forum.doom9.org/member.php?u=144865) with GCC 4.4.1 on Windows XP SP-2 32-bit.


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

I didn't use the hrd or win zone patch for this build. When those patches are updated, I'll make new builds.

What he said.

BTW its not M ( i think ), no patches applied ...

[rack04]

x264 core:70 r1206M 01a693d 32-bit

Download (http://www.megaupload.com/?d=VEQJ7738)

Built by rack04 on August 9, 2009, 9:11:59 AM CST
GCC: 4.4.1 (x86.core2.Komisar)
--extra-cflags="-march=core2"
fprofiled with 200 frames of BigBuckBunny.avs, 200 frames of LosslessTouhou.mkv, and 250 frames of riverbed.1920x1080.yuv

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

[imk]

x264-r1206M-imk-win.7z (http://imk.cx/pc/x264/x264-r1206M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

x264-r1206M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1206M-imk-osx.7z)

[kemuri-_9]

so i decided to update the win zone patch for everyone (even though i don't use it).
it took longer to find the 05 revision backward traversing this thread than to fix the darn thing :sly:

x264_win_zone_parse_fix_06.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_06.diff)

[juGGaKNot]

Look 2 posts up, the diffs are linked in all my posts :)

[kemuri-_9]

Look 2 posts up, the diffs are linked in all my posts :)
not the file, you link to threads where the patches exist within posts.
which is effectively useless when a thread such as this one is over 100 pages.
but whatever, i had found the rev 05 win zone patch on page 78 of this thread, and that's all i cared about.