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

[skystrife]

I take it you have all the normal updates applied (normal means updates available on the download site, windowsupdate etc as there are many times more hotfixes available than normal updates for all Microsoft products)? Many people still don't have SP1 installed due to the windowsupdate debacle...

What build of ntdll.dll do you have? Mines 6.0.6001.22221

Yeah, all the updates installed have been from Windows Update. ntdll version is 6.0.6001.18000. /me wonders why it's less than what you have.

And, I just got a friend to get the build to crash on his system, so it's not just me. (Note that it crashes intermittently; sometimes I need to run it about five times before I get the crash, but others it just crashes instantly.)

[Audionut]

For what it's worth, my ntdll version is 6.0.6001.18000 also.

Date modified 21/01/2008

[MasterNobody]

skystrife
Did you try what I write here: #post1217256 (http://forum.doom9.org/showthread.php?p=1217256#post1217256)?

P.S. I think x264_win_zone_parse_fix_02.diff have bugs. I highly doubt about correctness of this actions:
tok = ( char * ) x264_realloc( tok, i_tok+1 );
I think you have crash in x264_realloc

[kemuri-_9]

how's that a bug?

[MasterNobody]

kemuri-_9
At least you need to initialize tok before first call to x264_realloc. Like this: x264_win_zone_parse_fix_03.diff (http://stashbox.org/307641/x264_win_zone_parse_fix_03.diff)

[kemuri-_9]

yeah, i'll give you that one,
there is a small chance that the memory allocated for the char * is not 0'd out and will conflict with the first call to x264_realloc, causing a seg fault,

but if that's truly the cause, i would expect more randomness in success/failure.
especially in skystrife's case who's getting purefire failures.

[burfadel]

That build is from hotfix update KB955455, not a general release update :) This is where the confusion comes in to play with service packs, many say that a service pack is a recompiled version of all the released updates which is incorrect! Microsoft doesn't release most of their updates, and the above is one of them.

The update can be requested here (its an automated process):
http://support.microsoft.com/kb/955445/en-us

Hotfixes are released almost daily, some of them install later revisions of files than earlier hotfixes, but the hotfixes themselves aren't listed as replacements for earlier hotfixes. I download them just out of interest, and some of them can be a little interesting. Including the normal updates there are over 276 unique (from what I can tell) updates!

If you're curious, open task manager and check out the memory usage of explorer.exe without any explorer windows open. Run the following update:
http://support.microsoft.com/kb/955555/en-us

Then when back in windows (and even after doing stuff) check out the memory use of explorer.exe again. You'll find that its much (unbelievability) lower :)!

The build includes all updates both listed on the update site and internal modifications to the code, the above gives an indication of how things are now being coded/compiled better by Microsoft, at least it seems that way!

[Audionut]

x264-r1040.rar (http://rapidshare.com/files/167859766/x264-r1040.rar)


Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03

[kemuri-_9]

i've been snooping around here and there, and came across some extra aligned memory allocation methods for both mingw and msvc
(which currently x264 has to hand align for both of these)

mingw (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned.diff)
adds a requirement to have mingw's mingwex library (patch currently assumes it's just there).
msvc (http://kemuri9.net/dev/x264/patches/x264_msvc_aligned.diff)
they've been there since VC7.1
mingw+msvc (http://kemuri9.net/dev/x264/patches/x264_mingw_msvc_aligned.diff)
necessary, since the singles will reject each other

i would like to see if some people could help in testing these,
to see if there's any conflicts and noticeable performance gain/loss,
to then see if they're worth using permanently.
(ofc definitely not if there's any noticeable performance loss)

thanks in advance.

Edit:
dev input on whether or not that these functions are already known to be slower, would also be useful.

[Audionut]

x264-r1040-patch.rar (http://rapidshare.com/files/168068203/x264-r1040-patch.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03
x264_mingw_aligned.diff

2 runs with this build.
E:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 11.21 fps, 7300.59 kb/s

E:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 11.26 fps, 7300.59 kb/s


2 runs with my original revision 1040 build.
K:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\111.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 10.84 fps, 7300.59 kb/s

K:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 10.44 fps, 7300.59 kb/s

[skystrife]

x264.1040M.exe (http://www.mediafire.com/?jnytznqheyk) - Alternate Download (http://skystrife.com/x264/x264.1040M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

The 03 version of the zones patch appears to have fixed the crashing issue. Thanks MasterNobody!

[laserfan]

x264.1040M.exe (http://www.mediafire.com/?jnytznqheyk) - Alternate Download (http://skystrife.com/x264/x264.1040M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

The 03 version of the zones patch appears to have fixed the crashing issue...
Just a note to say "THANKS" skystrife for your quality/timely builds!

:thanks:

[skystrife]

x264.1042M.exe (http://www.mediafire.com/?t1lmjn2jtme) - Alternate Download (http://skystrife.com/x264/x264.1042M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

x264-r1042.rar (http://rapidshare.com/files/168377004/x264-r1042.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03
x264_mingw_aligned.diff

[kemuri-_9]

ok, so i've been trying to benchmark standard builds of msvc and mingw against the built-in aligned memory functions in the patches above.

my findings are:
MSVC - up to 1.5% slower (honestly, with how broken msvc is, not really surprising)
MinGW - up to 1% faster

so:
A. the msvc one is dropped due to noticeable performance loss.
B. It turns out that the library that the mingw aligned memory methods lie within is (always?) automatically included in the build,
so there's not an extra dependency like originally thought of.
thus, new patch to reflect this (also redone to minimize code changes):
x264_mingw_aligned_02.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned_02.diff)

as a small side note, i suspect that cygwin would have some similar functions,
but as i don't develop within it, i don't know what they actually are.

[Audionut]

x264-r1046.rar (http://rapidshare.com/files/168799673/x264-r1046.rar)

x264 0.65.0+1046 71d34b4
built on Nov 30 2008, gcc: 3.4.5 (mingw-vista special r3)

Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned_02.diff

[Dark Shikari]

as a small side note, i suspect that cygwin would have some similar functions,
but as i don't develop within it, i don't know what they actually are.x264 doesn't use Cygwin; it's compiled with -mno-cygwin on Cygwin systems.

[kemuri-_9]

x264 doesn't use Cygwin; it's compiled with -mno-cygwin on Cygwin systems.

well, i was referring to what the aligned memory function names/prototypes are.
the choices (of course) are
A. linux standard prototypes
B. some special prototypes (ex. mingw's were much more similar to the msvc prototypes than linux's)

but as i've never used cygwin, i don't know which one it falls under,
nor if using the built-in aligned methods will cause a positive performance difference

[MasterNobody]

Here is patch that allow to use --no-b-adapt (--b-adapt 0) along with --pre-scenecut (and so with multiple threads): x264_no_b_adapt_with_pre_scenecut.r1046.diff (http://stashbox.org/310366/x264_no_b_adapt_with_pre_scenecut.r1046.diff)

P.S. --no-b-adapt sometimes useful for testing purposes (also someone can consider that this is bug that it doesn't work with --pre-scenecut or multithreading).

[skystrife]

I'm getting a crash during fprofiling when I use the updated mingw patch, kemuri. If I use the previous one I can't get it to crash, but I can readily get the new patch version to crash.


Here's a backtrace from a debug build (using the settings from the fprofile run that made it crash):

(gdb) file x264
Reading symbols from C:\msys\1.0\home\Chase\x264/x264.exe...done.
(gdb) run --crf 30 -b1 -m1 -r1 --me dia --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr --progress -o NUL test.y4m
Starting program: C:\msys\1.0\home\Chase\x264/x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr --progress -o NUL test.y4m
gdb: do_initial_child_stuff: process 5328
gdb: kernel event for pid=5328 tid=3888 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
Error: dll starting at 0x77211000 not found.

Error: dll starting at 0x75a41000 not found.

Error: dll starting at 0x77211000 not found.

Error: dll starting at 0x77341000 not found.

ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_BREAKPOINT at 0x775c0004
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
yuv4mpeg: 1920x1080@12570329/524288fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.0
gdb: child_resume.SetThreadContext: thread 5328.0xf30 0:00:00
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x775df217

Program received signal SIGSEGV, Segmentation fault.
0x775df217 in ntdll!RtlDecompressBuffer ()
(gdb) bt
#0 0x775df217 in ntdll!RtlDecompressBuffer ()
#1 0x1900e308 in ?? ()
#2 0x00000020 in ?? ()
#3 0x00345010 in ?? ()
#4 0x0027f84c in ?? ()
#5 0x75ac3593 in KERNEL32!GetNumaAvailableMemoryNode ()
#6 0x00340000 in ?? ()
#7 0x00000000 in ?? () from
#8 0x1900e308 in ?? ()
#9 0x0027f898 in ?? ()
#10 0x763c9d6b in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
#11 0x00340000 in ?? ()
#12 0x00000000 in ?? () from
#13 0x1900e308 in ?? ()
#14 0x723d3e7a in ?? ()
#15 0x00000020 in ?? ()
#16 0x00000000 in ?? () from
#17 0x00345010 in ?? ()
#18 0x026251d0 in ?? ()
#19 0x00000000 in ?? () from
#20 0x0027f898 in ?? ()
#21 0x0040eb7d in x264_log (h=0x340000, i_level=0,
psz_fmt=0x1900e308 <Address 0x1900e308 out of bounds>)
at common/common.c:598

Any ideas? (I'll continue to use the previous patch for now.)

[kemuri-_9]

hmm... strange... i'll have to crack at it then.

Edit:
ok, i'm confirming the crash, i suspect that the way the 2nd patch works is interfering with some of the calls to free() on non aligned memory.
i'll work a new one out using the first patch as a starting point.

Edit Edit:
ok, new patch
preventing breaking cygwin building (as the first probably did break it)
preventing overwriting basic mem functions to avoid aligned freeing non aligned mem (problem with the second)
x264_mingw_aligned_03.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned_03.diff)

[skystrife]

Thanks, kemuri.

x264.1046M.exe (http://www.mediafire.com/?nfjlmmjzgzm) - Alternate Download (http://skystrife.com/x264/x264.1046M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Willyfan]

I'm trying to compile x264, dowloaded from the last snapshot and patched with the last patch, using visual studio 2008. (I want to try to apply a old patch for slicing support, for BD specs problem). I convert from VC 7 to visual studio without problem, and the porgram compile without errot, but when I try to encode the encoding is very slow. There is something I need to do? Many thanks.
William

[LoRd_MuldeR]

Some of the assmbler functions are not working with MSVC compiler and will be disabled. Hence MSVC builds are a bit slower than MinGW/GCC builds.

Also make sure yasm.exe (nasm.exe isn't supporetd anymore) is available in your build environment. Otherwise all assembler code is disabled and you will get a really slow build...

[Willyfan]

What is the best compiler I must to use for the best result (under XP)?

[LoRd_MuldeR]

What is the best compiler I must to use for the best result (under XP)?

There is no "best" compiler and you are not allowed to ask what's best. Use the compiler that works most convenient for you ;)

I personally use TDM's Experimental GCC/MinGW32 Builds (http://www.tdragon.net/recentgcc/) plus MSYS (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=89960). It seems most of the x264 builds floating around are MinGW/GCC builds :)

[Willyfan]

There is no "best" compiler and you are not allowed to ask what's best.
I'm really sorry, the question was what compiler was the best for x264, or if x264 is compiled with a specific compiler. Not what is the best compiler at all. Anyway, many thanks for your advice.
William

[LoRd_MuldeR]

I'm really sorry, the question was what compiler was the best for x264, or if x264 is compiled with a specific compiler. Not what is the best compiler at all. Anyway, many thanks for your advice.
William

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...

(Not that if you use TDM's MinGW/GCC and MSYS, you still need to install yasm.exe separately. The pthread lib is already included in TDM's installer)

[Audionut]

This should help get you started with Mingw.

http://forum.doom9.org/showthread.php?p=723782#post723782

[kemuri-_9]

I've ran comparisons of mingw and msvc builds,
in my case it was gcc 3.4.5 fprofiled and 2008 (vc++ 9) w/ PGO,
and they were fairly close in speeds, so this is not the problem.

there's a few possibilities that would have the MSVC version go slow:
A1. it's in debug configuration (which is extremely slow compared to release)
A2. Release config is not fully optimized.

B. the problem may be that it's not compiling with asm support
make sure HAVE_MMX is defined in the preprocessor section of the
projects.

C. no pthread support
the .vcproj's do not have pthread (nor gpac) support by default,
you'll need to compile, and then add the respective folders to the library and include paths for the x264 and libx264 solutions
(gpac to x264, pthreads to both)
then add in the proper preprocessor defines to have x264/libx264 go looking for them to compile with support.
(MP4_OUTPUT and HAVE_PTHREADS iirc)

[Willyfan]

C. no pthread support
the .vcproj's do not have pthread (nor gpac) support by default,
you'll need to compile, and then add the respective folders to the library and include paths for the x264 and libx264 solutions
(gpac to x264, pthreads to both)
then add in the proper preprocessor defines to have x264/libx264 go looking for them to compile with support.
(MP4_OUTPUT and HAVE_PTHREADS iirc)

Yes, I think that this is my problem. Now I downloaded the last version of pthread library (2.8.0). A question about gpac: this one is a framework, and need compilation, and not a library. Can you explain to me how to use gpac in MSVC? Many thanks!
William

[Dark Shikari]

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...Certainly any compiler that doesn't define __GNUC__, however, couldn't be the best, as that disables a whole lot of inline assembly and such.

[foxyshadis]

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...

No, that's the advice for 'best' video questions. Here, 'best' is possible to answer because there's only one recommended & supported compiler for x264: gcc. I still say it's better to err on the side of being helpful than on being a rules lawyer, but admittedly not everyone agrees.

Willy, you should still get used to asking for 'recommended' or 'your recommendations' if you stick around here long, though.

[Dark Shikari]

No, that's the advice for 'best' video questions. Here, 'best' is possible to answer because there's only one recommended & supported compiler for x264: gcc. I still say it's better to err on the side of being helpful than on being a rules lawyer, but admittedly not everyone agrees.ICC works as well, since it has a GCC compatibility mode.

[Audionut]

x264 0.65.0+1051 549cc55 (http://rapidshare.com/files/172339645/x264-r1051.rar)
built on Dec 11 2008, gcc: 3.4.5 (mingw-vista special r3)


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff

There was an error trying to patch x264_win_zone_parse_fix_03.diff, and i'm not clever enough to fix it.

[bob0r]

For x264_win_zone_parse_fix_03.diff, change:

- char *p, *tok, *saveptr;

to

- char *p, *tok, UNUSED *saveptr;

[Audionut]

Yep, that fixed it. Thanks bob0r.

x264_win_zone_parse_fix_04.diff (http://rapidshare.com/files/172375397/x264_win_zone_parse_fix_04.diff)


As above but with the zone patch.
x264-r1051-A.rar (http://rapidshare.com/files/172377727/x264-r1051-A.rar)

[skystrife]

x264.1051M.exe (http://www.mediafire.com/?20tndewntxz) - Alternate Download (http://skystrife.com/x264/x264.1051M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

i will no longer be supporting the
x264_win_zone_parse_fix patch i originally started.

for the reason of:
I've successfully added BugMaster's strtok_r to my mingw's native libraries.
it works like a charm,
thus the patch is not needed for me anymore ;)

[Sharktooth]

kemuri-_9: please submit the changes to the mingw team. maybe they will consider to add them in future versions.

[skystrife]

i will no longer be supporting the
x264_win_zone_parse_fix patch i originally started.

for the reason of:
I've successfully added BugMaster's strtok_r to my mingw's native libraries.
it works like a charm,
thus the patch is not needed for me anymore ;)

This may be a dumb question, but how did you go about doing this?

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

x264.1055M.exe (http://www.mediafire.com/?gtzygdgwmrz) - Alternate Download (http://skystrife.com/x264/x264.1055M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

This may be a dumb question, but how did you go about doing this?

put it most simply 'library hacking' though i wouldn't slate it as 100% hacking,
due to the way the mingw libraries are setup as ar packages.

[Audionut]

x264-r1056.rar (http://rapidshare.com/files/173767502/x264-r1056.rar)

Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

[kemuri-_9]

This may be a dumb question, but how did you go about doing this?

I've finished standardizing a shell script which should be able to handle patching any mingw installation...
(in other words, tell me if it says it didn't work with supplying what didn't work)

files:
install_strtok_r.sh (http://kemuri9.net/dev/mingw/install_strtok_r.sh): "./install_strtok_r.sh /mingw" - should work for most (requires base directory prefix of lib and include dirs as a parameter - which for most is /mingw)
x264_mingw_check_strtok_r.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_check_strtok_r.diff): recognize existence of strtok_r to not define it as strtok if strtok_r does exist.

Edit:
oh right, here's a patch for msvc users to use its version of reentrant strtok (and thus have zone support).
x264_msvc_zones_fix.diff (http://kemuri9.net/dev/x264/patches/x264_msvc_zones_fix.diff)

[skystrife]

Thanks again, kemuri; the script worked like a charm.

x264.1057M.exe (http://www.mediafire.com/?nmuzkwjttmj) - Alternate Download (http://skystrife.com/x264/x264.1057M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_mingw_check_strtok_r.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

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

x264.1057M.x64.exe (http://www.mediafire.com/?5m0uzndzzdi) - Alternate Download (http://skystrife.com/x264/x264.1057M.x64.exe)

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

[burfadel]

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references :)

[Dark Shikari]

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references :)The first is the first part of an evil plan to make an obnoxiously fast SATD function. Current estimations say that we might be able to beat the current one by over 60% on Conroe Core 2. Once all the parts of the evil plan come together, they may result in the largest speed gain in a single patch in at least a year.

The second one is a prototype of an attempt to make exhaustive a little bit faster.

Wait for them to be finished and committed :p

[burfadel]

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? :) I realise its not nice to annoy developers with such questions, but I think its justified in this case :D.

Keep up the great work! Its appreciated by a lot of people. Merry Christmas/Seasons greetings!

[Dark Shikari]

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? :) I realise its not nice to annoy developers with such questions, but I think its justified in this case :D.At ordinary encoding settings, SATD can be up to 20-25% of encoding time.

Do the math.

(By the way, we define "60% faster" as "60% more SATDs can be done in the same period of time", not "takes 60% less time").

[kemuri-_9]

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

reasons for the crash could be one of the following:
1. it might be crashing due to the mingw aligned patch, since the function names are different for mingw x64.*1

2. the win zone patch also includes a memory allocation change since 03,
this change is meant to fix possible incorrect allocations, which could rear it's ugly head in data manipulation and when freeing the data which would result in seg faults.
the strtok_r patch does not include the supposed memory allocation fix, as it's never crashed for me in mingw builds, only in msvc builds.

*1
I'm holding on releasing the updated patch, since I'm not sure what's going on with mingw x64 having the necessary aligned memory prototypes commented out in the header file.
(options are that the methods are not implemented or not needed, but i'm not exactly sure which one it is - current patch assumes the latter)

you can try out my build listed in the win x64 support thread to see if it proceeds to crash so i can determine if the patches are ok to release or need some working.