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

skystrife · 27th November 2008, 04:04

Quote:

Originally Posted by burfadel

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 · 27th November 2008, 04:19

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

Date modified 21/01/2008

MasterNobody · 27th November 2008, 08:13

skystrife
Did you try what I write here: #post1217256?

P.S. I think x264_win_zone_parse_fix_02.diff have bugs. I highly doubt about correctness of this actions:

Code:

            tok = ( char * ) x264_realloc( tok, i_tok+1 );

I think you have crash in x264_realloc

kemuri-_9 · 27th November 2008, 08:41

how's that a bug?

MasterNobody · 27th November 2008, 09:19

kemuri-_9
At least you need to initialize tok before first call to x264_realloc. Like this: x264_win_zone_parse_fix_03.diff

kemuri-_9 · 27th November 2008, 09:43

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 · 27th November 2008, 09:51

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 · 27th November 2008, 11:45

x264-r1040.rar

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03

kemuri-_9 · 27th November 2008, 20:20

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
adds a requirement to have mingw's mingwex library (patch currently assumes it's just there).
msvc
they've been there since VC7.1
mingw+msvc
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 · 28th November 2008, 01:04

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.

Code:

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.

Code:

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 · 28th November 2008, 07:50

x264.1040M.exe - Alternate Download

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 · 28th November 2008, 15:47

Quote:

Originally Posted by skystrife

x264.1040M.exe - Alternate Download

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!

skystrife · 29th November 2008, 00:05

x264.1042M.exe - Alternate Download

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 · 29th November 2008, 00:06

x264-r1042.rar

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03
x264_mingw_aligned.diff

kemuri-_9 · 30th November 2008, 09:33

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

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 · 30th November 2008, 10:46

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 · 30th November 2008, 11:42

Quote:

Originally Posted by kemuri-_9

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 · 30th November 2008, 17:50

Quote:

Originally Posted by Dark Shikari

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 · 30th November 2008, 20:32

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

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 · 1st December 2008, 06:42

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):

Code:

(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.)

27th November 2008, 08:13	#1403 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	skystrife Did you try what I write here: #post1217256? P.S. I think x264_win_zone_parse_fix_02.diff have bugs. I highly doubt about correctness of this actions: Code: tok = ( char * ) x264_realloc( tok, i_tok+1 ); I think you have crash in x264_realloc Last edited by MasterNobody; 27th November 2008 at 08:25.

27th November 2008, 08:41	#1404 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	how's that a bug? __________________ custom x264 builds & patches \| F@H \| My Specs

27th November 2008, 09:43	#1406 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	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. __________________ custom x264 builds & patches \| F@H \| My Specs

27th November 2008, 09:51	#1407 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	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! Last edited by burfadel; 27th November 2008 at 12:01.

27th November 2008, 20:20	#1409 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	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 adds a requirement to have mingw's mingwex library (patch currently assumes it's just there). msvc they've been there since VC7.1 mingw+msvc 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. __________________ custom x264 builds & patches \| F@H \| My Specs Last edited by kemuri-_9; 27th November 2008 at 20:33.

27th November 2008, 04:19	#1402 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	For what it's worth, my ntdll version is 6.0.6001.18000 also. Date modified 21/01/2008

27th November 2008, 09:19	#1405 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	kemuri-_9 At least you need to initialize tok before first call to x264_realloc. Like this: x264_win_zone_parse_fix_03.diff

27th November 2008, 11:45	#1408 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	x264-r1040.rar Patched with, x264_hrd_pulldown.09_interlace x264_win_zone_parse_fix_03

28th November 2008, 07:50	#1411 \| Link
skystrife Registered User Join Date: Feb 2007 Posts: 176	x264.1040M.exe - Alternate Download 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!

29th November 2008, 00:05	#1413 \| Link
skystrife Registered User Join Date: Feb 2007 Posts: 176	x264.1042M.exe - Alternate Download 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.

29th November 2008, 00:06	#1414 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	x264-r1042.rar Patched with, x264_hrd_pulldown.09_interlace x264_win_zone_parse_fix_03 x264_mingw_aligned.diff

30th November 2008, 09:33	#1415 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	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 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. __________________ custom x264 builds & patches \| F@H \| My Specs

30th November 2008, 10:46	#1416 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	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 Last edited by Audionut; 30th November 2008 at 10:48.

30th November 2008, 20:32	#1419 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	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 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).

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode