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

[shon3i]

B-pyramid is not completly safe even with lowering reference frames. There is small chances to keep stream on standard with b-pyramid but that is gambling.

[Audionut]

x264-r1028.rar (http://rapidshare.com/files/163652679/x264-r1028.rar)

-Add subme=0 (fullpel motion estimation only)
Only for experimental purposes and ultra-fast encoding. Probably not a good idea for firstpass.

-Nehalem optimization part 2: SSE2 width-8 SAD
Helps a bit on Phenom as well
~25% faster width8 multiSAD on Nehalem

[azulazules]

If you use x264, there is a formula I like posted by Selur on:
http://forum.doom9.org/showpost.php?p=1212843&postcount=14

Even with it, it seems it is still possible the h264 stream is not 100% compliant, thus breaking hardware decodes.

In your case, I guess you can go with the following:1920x1088 High@4.1 NO bframe NO b-pyramid ==> max #ref= 4, min #ref=0
1920x1088 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 4, min #ref=2
1920x1088 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 3, min #ref=3
1920x800 High@4.1 NO bframe NO b-pyramid ==> max #ref= 5, min #ref=0
1920x800 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 5, min #ref=2
1920x800 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 4, min #ref=3
1280x720 High@4.1 NO bframe NO b-pyramid ==> max #ref= 9, min #ref=0
1280x720 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 9, min #ref=2
1280x720 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 8, min #ref=3
1280x544 High@4.1 NO bframe NO b-pyramid ==> max #ref=12, min #ref=0
1280x544 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref=12, min #ref=2
1280x544 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref=11, min #ref=3Now, another question could be: is it usually better to use one more REF and not b-pyramid? :p

BTW, aren't we OT here?

[Dark Shikari]

BTW, aren't we OT here?Indeed.

[kemuri-_9]

thanks to Emp3r0r's help, a bug in the win zone parse patch i made was discovered
(which incidentally only seemed to have affected Vista, as it worked fine on my XP)

here's the fixed patch
x264_win_zone_parse_fix_02.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_02.diff)

[Blue_MiSfit]

What exactly does this zone parse patch do??

~MiSfit

[LoRd_MuldeR]

What exactly does this zone parse patch do??

~MiSfit

Think it refers to this problem:
http://forum.doom9.org/showpost.php?p=1211426&postcount=1307

[kemuri-_9]

yes
it's one of the available solutions to the --zones parameter on windows

having only 1 zone works fine all ready,
but specifying multiple zones fails and has x264 error+quit without either of the fixes.
only on windows that is... <_<

[wata]

skystrife x264.1028.modified.exe failed when using multi-zones, have to go back to r1024

--[Information] [11/16/2008 3:45:56 PM] Encoding started
--[Error] An error occurred: x264 [error]: invalid zone param: d = (null)
--[Error] An error occurred: x264 [error]: failed to parse zones
--[Error] An error occurred: x264 [error]: x264_encoder_open failed

[skystrife]

x264.1028.modified.02.exe (http://www.mediafire.com/?1tzzmzmtnyz) - Alternate Download (http://skystrife.com/x264/x264.1028.modified.02.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_custom_strtok_r.r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(kemuri's patch doesn't appear to work on my machine where as MasterNobody's patch does, so I'll use it for now).

[kemuri-_9]

(kemuri's patch doesn't appear to work on my machine where as MasterNobody's patch does, so I'll use it for now).

the updated one doesn't?

[skystrife]

Nope, for some reason it would just crash (without any error messages) using either the old or the new patch. *shrug*

Maybe something in my mingw environment is screwing the patch somehow, but there weren't any strange warnings or anything when I patched.

[Audionut]

No problems here. :confused:

Revision 1028 (http://rapidshare.com/files/164874957/x264-r1028-patched.rar)

Patched with x264_win_zone_parse_fix_02.diff

[G_M_C]

No problems with techouse's builds either, and he mentiones no applied patches (asside from the NAL-HRD-patch).

[skystrife]

I'll try again with the next revision's build.

EDIT: I tried again with a clean build (make clean, git checkout -f, patch -p1 <x264_win_zone_parse_fix_02.diff, ./configure --extra-cflags="-march=pentium2", make) and it crashes with this command line: x264 --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv LosslessTouhou.avs

Could it have something to do with gcc 3 vs gcc 4?

EDIT(2): No, just tested with gcc 4 on here to no avail... odd.

[skystrife]

x264.1029.modified.exe (http://www.mediafire.com/?mtktyy1ymzw) - Alternate Download (http://skystrife.com/x264/x264.1029.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_custom_strtok_r.r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[video_magic]

Hello, Skystrife - please could you tell me whether your build that you have in the post above is fast for someone with a normal P4 HT, I don't know much about this sort of thing, sorry :thanks:

I just would like to encode a little faster if possible than maybe using the otherwise great builds which I have sometimes used from x264.nl . Any encoding speed increase is welcome because I have many hours of tapes that I am capturing and then backing up.
I'm using XP SP2.
My CPU details are here:

http://processorfinder.intel.com/details.aspx?sSpec=SL9KF

[Shinigami-Sama]

CPU specific builds are moot with x264 does its own runtime CPU detection for its ASM code
so...

[akupenguin]

CPU specific builds are moot with x264 does its own runtime CPU detection for its ASM code
That's true for any CPU other than P4. But P4 is so perverse that you do need to compile specially for it.

[Dark Shikari]

That's true for any CPU other than P4. But P4 is so perverse that you do need to compile specially for it.By that logic, its so perverse that we'd need to write custom asm for it (due to the 6-clocks-to-move-between-registers issue).

Not like I care enough about the P4 to do that.

[akupenguin]

It's so perverse that we don't care enough to write custom asm for it. But if you can get some of that speedup just from gcc -march, that's easy. Now, if what you're saying is that we don't care enough to publish P4 builds, so you'll only get one if you compile it yourself, then I agree.

[Audionut]

x264-r1029.rar (http://rapidshare.com/files/165918146/x264-r1029.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_02

All my builds are built with gcc 3.4.5 fprofiled. March=prescott

[techouse]

EDIT(2): No, just tested with gcc 4 on here to no avail... odd.
So does x264_win_zone_parse_fix_02 break x264 when compiled with GCC4 or not?

[Audionut]

skystrife is having problems with the zone patch with both gcc 3 and 4.

I have no problems with gcc 3.4.5. But i've got a clean build of xp and mingw + gcc running in a virtual machine.

If that makes any difference.

[video_magic]

Being a P4-pervert I will try this build from Audionut and thanks to You guys :)

I did have a P4 prescott before I got the 775 Cedar Mill stepping D0 (65 Watts to run cooler) so I hope that build will be 'close enough'.

Big thanks again everyone for helping me.

[skystrife]

I'm running Vista x64 natively with mingw. It's odd to me that patched or unpatched unexpectedly crashes without giving me any error messages when using zones (I never get the "failed to parse zones" error, it just stops working entirely). Maybe it's a Vista specific thing?

Just a reminder to those using my build: the zones patch I am using worked with that build, so there's nothing for you to worry about. It's just me trying to figure out why the alternative patch (much smaller) isn't working on my end.

[kemuri-_9]

you don't seem to be the only one with problems with running x264 on vista x64...
as this thread (http://forum.doom9.org/showthread.php?t=142925) seems to be leaning towards unexplainable vista x64 failure as well.

i'm on XP x64 myself (and satisfied)

[skystrife]

Testing using Audionut's build to rule out my mingw environment atm.

...and a crash. Issue must be specific to Vista (and maybe x64). I will continue to use MasterNobody's patch for now.

Wonder why Vista chokes on that bit of code?

[Audionut]

Running Vista 64 here.

No Problems.

edit. I tested my build with the command line you posted earlier.

x264 --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv test.avs

[Sharktooth]

/me suggests skystrife to check his system for stability...

[skystrife]

If there was an issue with stability I would have caught it by now. x264 only crashes with the zones parameter, nothing else. (And I've already tested for stability recently anyway, the system is fine).

I'll rule it out as a problem on my end, though I will continue to use MasterNobody's patch.

EDIT: Just tested with Audionut's build on another Vista x64 machine and it worked just fine. Odd; I'll continue to troubleshoot on my pc then.

EDIT2: *facepalm* It was an avisynth issue, not an x264 issue. -_-;

[burfadel]

Never had an issue with x264 due to it being Vista x64 here either!

[Audionut]

EDIT2: *facepalm* It was an avisynth issue, not an x264 issue. -_-;

Trouble shooting is soooo much fun. :rolleyes:

[komisar]

1034 CLI version with (x264-devel) (PATCH) single frame flashes (http://mailman.videolan.org/pipermail/x264-devel/2008-November/005208.html)

http://komisar.gin.by/

[MasterNobody]

Few new patches from me (MasterNobody / BugMaster): http://stashbox.org/306091/x264_misc_diff_r1032.zip
x264_fix_2pass.r1032.diff - fix this bug (http://forum.doom9.org/showthread.php?t=142922) introduced in r1020 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=418cace8646a6f546a9026da47f79fad7285f577)
x264_vs_compilation_fix.r1032.diff - fix compilation with MS VisualStudio after r1030 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=f9dba8bb274dffb19394db20912823464efcb8e1)
x264_vs_compilation_fix_and_clean.r1032.diff - same as x264_vs_compilation_fix.r1032.diff but also removes old not working configuration Release64 and absent files of decoder

[skystrife]

Ok, well fun, the bug is back. If I build an exe using the patch, it crashes instantly after loading the input file (I'm now using a yuv4mpeg input to rule out avisynth). If I use Audionut's build, it crashes 20% of the time right before printing the "encoded 300 frames, xx.xx fps, xxx.xx kb/s". The output file is ~50 frames short.

The system is not overclocked (it was before but I've brought it back to stock) and the memory is fine (just ran a 12h memtest86). I have no idea wtf is causing this.

I've created a second partition and installed a clean Vista x64 to it (slipstreamed the 4GB fix into the normal install media) and tried running x264 after the install (cd'd to the original partition and ran it from there). My build still crashes, and I can replicate the pattern I'm seeing with Audionut's build. I know this is probably getting off topic, but does anyone have the slightest idea what's going on here?

Interestingly enough, the build that instantly crashes on my machine works flawlessly on other machines (tested on 32-bit XP and 64-bit Vista). This further perplexes me.

I'm about ready to blame my install media.

[LoRd_MuldeR]

Can the crash in your build be tracked down to a certain CPU type? What if you use "--no-asm" to encode ???

[skystrife]

Can the crash in your build be tracked down to a certain CPU type? What if you use "--no-asm" to encode ???

Just got Audionut's to crash with --no-asm. =/ Machine is running a Q6700, friend's machine that I tested on (x64 Vista) was running an E6700 and worked fine.

My build crashes instantaneously with --no-asm as well. Note that it works fine save for zones; I can only replicate the crash when I'm using the zones parameter.

[LoRd_MuldeR]

Just got Audionut's to crash with --no-asm. =/ Machine is running a Q6700, friend's machine that I tested on (x64 Vista) was running an E6700 and worked fine.

My build crashes instantaneously with --no-asm as well.

I'd say: Make a build with --enable-debug and do a stacktrace when it crashes...

[kemuri-_9]

I'd say: Make a build with --enable-debug and do a stacktrace when it crashes...

my new permanent x264 build w/ debug symbols can be found here (http://kemuri9.net/dev/x264/x264_debug.exe)
the debug version is now standardized into my automatic compilation scripting setup,
so it'll update along with the other builds i have.

I find that it should be helpful for such situations when weird crashes occur to nail down the reasons.

[skystrife]

(gdb) run
Starting program: C:\msys\1.0\home\Chase\x264/x264.exe --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o NUL foreman_cif.y4m
gdb: do_initial_child_stuff: process 3228
gdb: kernel event for pid=3228 tid=3924 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
Error: dll starting at 0x775c1000 not found.

Error: dll starting at 0x75aa1000 not found.

Error: dll starting at 0x775c1000 not found.

Error: dll starting at 0x774f1000 not found.

ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_BREAKPOINT at 0x778a0004
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x778bf217

Program received signal SIGSEGV, Segmentation fault.
0x778bf217 in ntdll!RtlDecompressBuffer ()
(gdb) bt full
#0 0x778bf217 in ntdll!RtlDecompressBuffer ()
No symbol table info available.
#1 0x1c0769b8 in ?? ()
No symbol table info available.
#2 0x00000000 in ?? () from
No symbol table info available.
#3 0x02777150 in ?? ()
No symbol table info available.
#4 0x0027f80c in ?? ()
No symbol table info available.
#5 0x75b23593 in KERNEL32!GetNumaAvailableMemoryNode ()
No symbol table info available.
#6 0x00c60000 in ?? ()
No symbol table info available.
#7 0x00000000 in ?? () from
No symbol table info available.
#8 0x1c0769b8 in ?? ()
No symbol table info available.
#9 0x0027f858 in ?? ()
No symbol table info available.
#10 0x76f89d6b in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#11 0x00c60000 in ?? ()
No symbol table info available.
#12 0x00000000 in ?? () from
No symbol table info available.
#13 0x1c0769b8 in ?? ()
No symbol table info available.
#14 0xa2704883 in ?? ()
No symbol table info available.
#15 0x00000000 in ?? () from
No symbol table info available.
#16 0x00000001 in ?? ()
No symbol table info available.
#17 0x02777150 in ?? ()
No symbol table info available.
#18 0x76fa24b5 in strtoui64 () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#19 0xd4a8eabb in ?? ()
No symbol table info available.
#20 0xfffffffe in ?? ()
No symbol table info available.
#21 0x76ff5a50 in tempnam_dbg () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#22 0x0027f820 in ?? ()
No symbol table info available.
#23 0x76f8d516 in strncmp () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#24 0x0027ffc4 in ?? ()
No symbol table info available.
#25 0x76fa24b5 in strtoui64 () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#26 0xd4af2d5b in ?? ()
No symbol table info available.
#27 0xfffffffe in ?? ()
No symbol table info available.
#28 0x0027f868 in ?? ()
No symbol table info available.
#29 0x0040ed43 in x264_free (p=0xc60000) at common/common.c:733
p = (void *) 0x1c0769b0

I'm new to debugging anything, so let me know if I'm Doing It Wrong.

[LoRd_MuldeR]

Looks like the crash happens in ntdll.dll (Windows Native API), but it originates from x264_free() in "common.c" :confused:

Reminds me to the crash in x264_malloc as reported here:
http://forum.doom9.org/showthread.php?p=1215181#post1215181

[kemuri-_9]

except that it's failing on a free, which is the oppositte of malloc...
where as malloc can fail when it can't get the memory it needs for allocation,
for free to fail, it means there's no allocated memory to free (freeing a null or unmalloc'd pointer)

and if it was indeed a null or unmalloc'd pointer that was causing free to fail, it should fail consistently across computers/platforms.

[video_magic]

Hey Audionut - thanks for that P4 Prescott build, which is indeed faster than the one from x264.nl , Mainly it is a lot more noticeably so on the first pass :thanks:

I noticed that r1038 is out and wondered whether you might put a Prescott build of that up, because I'm going to leave this machine for half a week encoding.

(Next step in my quest for speed is get a mobo that supports ddr2-800 memory (which my ram is) to run at that speed, someone told me matching 1/1 ram to my CPU bus speed is the best thing I can do if I'm going to not 'bottleneck' encoding.)

[Audionut]

x264-r1038.rar (http://rapidshare.com/files/167452005/x264-r1038.rar)


Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_02

[skystrife]

except that it's failing on a free, which is the oppositte of malloc...
where as malloc can fail when it can't get the memory it needs for allocation,
for free to fail, it means there's no allocated memory to free (freeing a null or unmalloc'd pointer)

and if it was indeed a null or unmalloc'd pointer that was causing free to fail, it should fail consistently across computers/platforms.

Should, but unless my original disc is corrupt in some way then something else is borking. I just tried an install from the original disc, no updates installed, no slipstream (popped out 3 sticks of ram to avoid 4GB install bug) and replicated the crash.

(Sorry for clogging up the thread).

For now, I'll use the custom strtok_r patch since that doesn't seem to reproduce the crash on my machine. The crash is really weird, though, and I'd like to find out what's causing it. D=

[Audionut]

I'm in the process of building GDB so I can hopefully debug some builds on my machine.

How about continuing this on irc.

[MasterNobody]

skystrife
Try builds with x264_error_memoryleaks.03.r1032.diff (http://stashbox.org/306370/x264_error_memoryleaks.03.r1032.diff) patch or at least replace
z->param = malloc( sizeof(x264_param_t) );
with
z->param = x264_malloc( sizeof(x264_param_t) );
in parse_zone function

P.S. I mentioned this error in post1211218 (http://forum.doom9.org/showthread.php?p=1211218#post1211218) in x264_error_memoryleaks.03.r1019.diff description.

[burfadel]

Should, but unless my original disc is corrupt in some way then something else is borking. I just tried an install from the original disc, no updates installed, no slipstream (popped out 3 sticks of ram to avoid 4GB install bug) and replicated the crash.

(Sorry for clogging up the thread).

For now, I'll use the custom strtok_r patch since that doesn't seem to reproduce the crash on my machine. The crash is really weird, though, and I'd like to find out what's causing it. D=

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

[MasterNobody]

Updated collection of my patches: bm_x264_patch_collection.r1038.zip (http://stashbox.org/306696/bm_x264_patch_collection.r1038.zip)