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

skystrife · 21st November 2008, 23:23

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 · 22nd November 2008, 01:56

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

Audionut · 22nd November 2008, 03:29

Quote:

Originally Posted by skystrife

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

Trouble shooting is soooo much fun.

komisar · 25th November 2008, 19:15

1034 CLI version with (x264-devel) (PATCH) single frame flashes

http://komisar.gin.by/

MasterNobody · 25th November 2008, 23:10

Few new patches from me (MasterNobody / BugMaster): http://stashbox.org/306091/x264_misc_diff_r1032.zip
x264_fix_2pass.r1032.diff - fix this bug introduced in r1020
x264_vs_compilation_fix.r1032.diff - fix compilation with MS VisualStudio after r1030
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 · 26th November 2008, 00:43

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 · 26th November 2008, 01:17

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

skystrife · 26th November 2008, 01:40

Quote:

Originally Posted by LoRd_MuldeR

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 · 26th November 2008, 01:42

Quote:

Originally Posted by skystrife

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 · 26th November 2008, 02:01

Quote:

Originally Posted by LoRd_MuldeR

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
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 · 26th November 2008, 02:03

Code:

(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 · 26th November 2008, 02:13

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

Reminds me to the crash in x264_malloc as reported here:
http://forum.doom9.org/showthread.ph...81#post1215181

kemuri-_9 · 26th November 2008, 02:23

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 · 26th November 2008, 02:45

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

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 · 26th November 2008, 03:56

x264-r1038.rar

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_02

skystrife · 26th November 2008, 04:13

Quote:

Originally Posted by 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.

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 · 26th November 2008, 04:25

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 · 26th November 2008, 05:34

skystrife
Try builds with x264_error_memoryleaks.03.r1032.diff patch or at least replace

Code:

    z->param = malloc( sizeof(x264_param_t) );

with

Code:

    z->param = x264_malloc( sizeof(x264_param_t) );

in parse_zone function

P.S. I mentioned this error in post1211218 in x264_error_memoryleaks.03.r1019.diff description.

burfadel · 26th November 2008, 06:25

Quote:

Originally Posted by skystrife

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 · 26th November 2008, 10:24

Updated collection of my patches: bm_x264_patch_collection.r1038.zip

21st November 2008, 23:23	#1381 \| Link
skystrife Registered User Join Date: Feb 2007 Posts: 176	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. -_-; Last edited by skystrife; 22nd November 2008 at 01:49.

25th November 2008, 19:15	#1384 \| Link
komisar Registered User Join Date: Aug 2008 Location: Minsk, Belarus Posts: 235	1034 CLI version with (x264-devel) (PATCH) single frame flashes http://komisar.gin.by/ __________________ ..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..

26th November 2008, 00:43	#1386 \| Link
skystrife Registered User Join Date: Feb 2007 Posts: 176	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. Last edited by skystrife; 26th November 2008 at 01:10.

26th November 2008, 01:17	#1387 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,248	Can the crash in your build be tracked down to a certain CPU type? What if you use "--no-asm" to encode ??? __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

26th November 2008, 02:13	#1392 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,248	Looks like the crash happens in ntdll.dll (Windows Native API), but it originates from x264_free() in "common.c" Reminds me to the crash in x264_malloc as reported here: http://forum.doom9.org/showthread.ph...81#post1215181 __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

22nd November 2008, 01:56	#1382 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	Never had an issue with x264 due to it being Vista x64 here either!

25th November 2008, 23:10	#1385 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	Few new patches from me (MasterNobody / BugMaster): http://stashbox.org/306091/x264_misc_diff_r1032.zip x264_fix_2pass.r1032.diff - fix this bug introduced in r1020 x264_vs_compilation_fix.r1032.diff - fix compilation with MS VisualStudio after r1030 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

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

26th November 2008, 02:45	#1394 \| Link
video_magic Registered User Join Date: Jan 2005 Posts: 368	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 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.) __________________ Thankyou!, I am grateful for any help

26th November 2008, 03:56	#1395 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	x264-r1038.rar Patched with, x264_hrd_pulldown.09_interlace x264_win_zone_parse_fix_02

26th November 2008, 04:25	#1397 \| Link
Audionut Registered User Join Date: Nov 2003 Posts: 1,281	I'm in the process of building GDB so I can hopefully debug some builds on my machine. How about continuing this on irc.

26th November 2008, 05:34	#1398 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	skystrife Try builds with x264_error_memoryleaks.03.r1032.diff patch or at least replace Code: z->param = malloc( sizeof(x264_param_t) ); with Code: z->param = x264_malloc( sizeof(x264_param_t) ); in parse_zone function P.S. I mentioned this error in post1211218 in x264_error_memoryleaks.03.r1019.diff description. Last edited by MasterNobody; 26th November 2008 at 05:39.

26th November 2008, 10:24	#1400 \| Link
MasterNobody Registered User Join Date: Jul 2007 Posts: 552	Updated collection of my patches: bm_x264_patch_collection.r1038.zip