x264 Windows x64 support

[MasterNobody]

Can somebody with Core2 (I am interested in SSSE3 and SSE4) to test this package of x264 for Windows x64: http://stashbox.org/328100/x264win64_mingw.rar.
Needed to check:
1) Does it starts at all (It is first time I compile in MinGW for x64)
2) Doesn't checkasm crash and goes through all tests
3) Does x264 correctly work

[LoRd_MuldeR]

1) Does it starts at all (It is first time I compile in MinGW for x64)

Yes.

2) Doesn't checkasm crash and goes through all tests

Yup. All tests are "[OK]" :)

3) Does x264 correctly work

Encodes. First test looks good :cool:

But no Avisynth input due to lack of Avisynth x64, so I tested a raw YUV sample.

C:\Downloads\x264win64_mingw>x264.exe --crf 22 --output c:\wurst.mkv C:\Downloads\foreman_qcif.176x144.yuv
x264 [info]: file name gives 176x144
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 1.1
x264 [info]: slice I:2 Avg QP:22.99 size: 5381 PSNR Mean Y:39.55 U:43.83 V:45.32 Avg:40.66 Global:40.35
x264 [info]: slice P:298 Avg QP:26.81 size: 647 PSNR Mean Y:36.15 U:41.04 V:41.95 Avg:37.30 Global:37.21
x264 [info]: mb I I16..4: 0.5% 0.0% 99.5%
x264 [info]: mb P I16..4: 0.1% 0.0% 0.9% P16..4: 39.8% 25.0% 16.8% 0.0% 0.0% skip:17.4%
x264 [info]: SSIM Mean Y:0.9636046
x264 [info]: PSNR Mean Y:36.170 U:41.057 V:41.972 Avg:37.326 Global:37.228 kb/s: 135.74

encoded 300 frames, 270.51 fps, 136.11 kb/s

Good work :thanks:

[Dark Shikari]

Can somebody with Core2 (I am interested in SSSE3 and SSE4) to test this package of x264 for Windows x64: http://stashbox.org/328100/x264win64_mingw.rar.
Needed to check:
1) Does it starts at all (It is first time I compile in MinGW for x64)
2) Doesn't checkasm crash and goes through all tests
3) Does x264 correctly work:thanks:

[Snowknight26]

checkasm crashes after outputting this:

x264: using random seed 46208040
x264: MMX
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- add_idct4 : [OK]
- dct4x4dc : [OK]
- idct4x4dc : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- coeff_last : [OK]
- cabac : [OK]
x264: MMX Cache64
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSE2Slow
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- ssim : [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- add_idct8 : [OK]
- hpel filter : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- dequant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSE2Fast
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
x264: SSE2Fast Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
x264: SSE3
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSSE3
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- quant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSSE3 Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]

x264 crashes after it outputting this:
x264.exe --crf 22 --output test.mkv test.yuv 1916x818
x264 [warning]: width or height not divisible by 16 (1916x818), compression will
suffer.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.0

[LoRd_MuldeR]

checkasm crashes after outputting this:

What is your CPU? :confused:

[Snowknight26]

Q6600.

[LoRd_MuldeR]

Q6600.

It doesn't crash on my Q6600. I ran it several times. Mine is a "Kentsfield", your's too?

[Snowknight26]

Yes, it is. (http://valid.canardpc.com/show_oc.php?id=463136)

[LoRd_MuldeR]

Yes, it is. (http://valid.canardpc.com/show_oc.php?id=463136)

But it's a G0 stepping, while mine is a B3 stepping. Also are you on Vista x64 or Windows XP x64?

[Snowknight26]

Vista x64.

[LoRd_MuldeR]

Vista x64.

So it's either a G0-specific problem or a Vista-specific problem ;)

[ghostonline]

B3 is more buggy than G0. it is either due to the OS or the overclock...

[Audionut]

Checkasm runs fine here on a G0 stepping Q6600 on Vista 64.

Will try x264 in an hour or 2.

[squid_80]

Link seems to be down?

[Audionut]

Mirror (http://rapidshare.com/files/174112242/x264win64_mingw.rar)

[squid_80]

Ok, checkasm runs fine but the CLI won't encode from avs or uncompressed YV12 avi input, it just exits at frame 1.

Edit: It's actually crashing and being silently terminated because there's no function unwind info. Here's where it crashes:
image00000000_00400000+0xbeb54:
00000000`004beb54 660f7f7c2418 movdqa oword ptr [rsp+0x18],xmm7 ss:00000000`0022bb18=000000000230867100000000004c5038
If you kept the map file you should be able to find which function is responsible.

[Audionut]

Checkasm runs fine.

E:\x264>checkasm
x264: using random seed 3034587448
x264: MMX
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- add_idct4 : [OK]
- dct4x4dc : [OK]
- idct4x4dc : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- coeff_last : [OK]
- cabac : [OK]
x264: MMX Cache64
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSE2Slow
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- ssim : [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- add_idct8 : [OK]
- hpel filter : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- dequant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSE2Fast
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
x264: SSE2Fast Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
x264: SSE3
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSSE3
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- quant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSSE3 Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]


X264 does not.


E:\x264>x264 --crf 22 -o e:\test.264 e:\test.avs
avis [info]: 1280x528 @ 23.98 fps (3429 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.1

E:\x264>

[Snowknight26]

Audionut, I don't think checkasm completed successfully because thats exactly where mine stops. It outputs an ASCII smile when it finishes, so obviously ours didn't.

[Audionut]

Oh. Indeed. Thanks.

[squid_80]

Audionut, I don't think checkasm completed successfully because thats exactly where mine stops. It outputs an ASCII smile when it finishes, so obviously ours didn't.
Oh, now I see checkasm is also crashing on a similar instruction:
image00000000_00400000+0x9dba4:
00000000`0049dba4 660f7f7c2418 movdqa oword ptr [rsp+0x18],xmm7 ss:00000000`0022ecf8=00000000003d81fd00000000004a4088How come checkasm doesn't print the function being tested before actually running the test, and print the [OK] afterwards?

[Snowknight26]

Yea, thats the same instruction that I was getting when running it through WinDBG.

[akupenguin]

How come checkasm doesn't print the function being tested before actually running the test, and print the [OK] afterwards?
Because it's simpler this way, especially if I want to print extra diagnostics without screwing up the formatting, or I don't want to print anything if there turns out not to be an asm version of the current cputype. And I've never had an opportunity to wonder what was crashing, since I normally use checkasm to verify changes to one function at a time. And the next step after a crash is to get a backtrace, which would tell me the function name if I didn't know it already.

[MasterNobody]

Here is test2 version (where I hopefully fixed previous crash): x264win64_mingw_test2.rar (http://www.mediafire.com/?4otiwbjmrex)
Also compiled x264_avs.exe (x264.exe with AviSynth support) but don't know would it work (because there is no AviSynth for x64 as I know), it depends from AVIFIL32.dll (does it exists on all Windows x64 versions? Vista?)

[squid_80]

Avisynth x64 (http://forum.doom9.org/showthread.php?t=87623). It works with x264_avs.exe (crash is fixed too).
Any chance of adding pthread support? Compared to 32-bit with --threads 1 it looks 10% faster.

[burfadel]

Whats the performance of the 64 bit version like? since most of the optimisations are 32 bit(?) only?

[Dark Shikari]

since most of the optimisations are 32 bit(?) only?Since when? This would be news to me.

[squid_80]

Whats the performance of the 64 bit version like? since most of the optimisations are 32 bit(?) only?
If you're talking about MasterNobody's 64-bit x264, I just said it's 10% faster. If you're talking about avisynth x64, it varies greatly depending on the script; in a lot of cases there isn't fallback C code for avisynth's asm so I just left the functions out. This means a script may not open but if it does it should always (in theory) be faster. AFAIK available plugins are limited to the ones listed on my homepage.

[Audionut]

Just to confirm that it's working here too. And thread support would be great.

[kemuri-_9]

the mingw64 team already has a working copy of win x64 pthreads, but first let's get the asm situation settled first ok?
pthreads is external to x264; the asm is internal to it, so asm needs to get fixed.

[squid_80]

Well for starters it appears the asm is already working.
The last time I built pthreads for win64 (which admittedly was over 2 years ago) there was a small handle leak issue that Cef found and fixed. Apart from that all I had to do was change the target architecture, so IMO it's not like I was asking for a huge time-consuming task to be performed.

[kemuri-_9]

well, mingw 64 is currently using gcc 4.4.0 which is still in development (aka broken?),
so it would likely be easier to get a fully capable x64 version if the msvc project was reinstated and brought up to date

[RunningSkittle]

c:\x264_64>x264_avs --crf 22 -o D:\dvdrips\Testing\test.264 D:\dvdrips\pulp.avs
x264 [error]: could not open input file 'D:\dvdrips\Testing\pulp.avs'

Q6600 G0 (333*9)

c:\x264_64>checkasm
x264: using random seed 213923
x264: MMX
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- add_idct4 : [OK]
- dct4x4dc : [OK]
- idct4x4dc : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- coeff_last : [OK]
- cabac : [OK]
x264: MMX Cache64
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSE2Slow
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- ssim : [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- add_idct8 : [OK]
- hpel filter : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- dequant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSE2Fast
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel satd : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
x264: SSE2Fast Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
x264: SSE3
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: SSSE3
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- quant : [OK]
- denoise dct : [OK]
- decimate_score : [OK]
- coeff_last : [OK]
x264: SSSE3 Cache64
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
x264: PHADD
- pixel satd : [OK]
- zigzag_frame : [OK]
x264: All tests passed Yeah :)

:)

[LoRd_MuldeR]

well, mingw 64 is currently using gcc 4.4.0 which is still in development (aka broken?),
so it would likely be easier to get a fully capable x64 version if the msvc project was reinstated and brought up to date

Well, MatserNobody used "gcc: 4.4.0 20080921 (experimental)" and apparently his build is now fully working (it only lacks pthreads).

[squid_80]

well, mingw 64 is currently using gcc 4.4.0 which is still in development (aka broken?),
so it would likely be easier to get a fully capable x64 version if the msvc project was reinstated and brought up to date
At least MSVC x64 builds shouldn't be crippled as much as x32, since the stack alignment problems shouldn't happen.

[LoRd_MuldeR]

At least MSVC x64 builds shouldn't be crippled as much as x32, since the stack alignment problems shouldn't happen.

According to checkasm.exe all ASM functions (inclduing SSE) do work in MasterNobody's build, created with MinGW x64.

If so, no need for MSVC x64. Or did he disable some ASM functions in that build? :confused:


[EDIT]

Think I read your post wrong :o

You said that MSVC x64 is less crippled than MSVC x86, not that MSVC x64 is less crippled than MinGW x64.

[squid_80]

Yeah x64 has a 16-byte aligned stack so MSVC shouldn't be able to screw up (in theory). But on the downside you lose inline asm.

[kemuri-_9]

well, the problem i've been having is actually getting
gcc 4.4.0 to accept the external pthreads library that the mingw64 team created,
and since it doesn't work tried compiling from the source, but then it doesn't contain all the function definitions that are necessary to actually work.

and yes, the stack alignment problem supposedly does not exist in the x64 msvc version,
so the only thing it would be missing is some inline asm compared to a speculated fully working x64 mingw version...

Edit:
mingw64 will have a better grounding once gcc 4.4.0 (which it's basing upon) has stabilized... (stabilized at least enough for an official release).

[roozhou]

well, the problem i've been having is actually getting
gcc 4.4.0 to accept the external pthreads library that the mingw64 team created,
and since it doesn't work tried compiling from the source, but then it doesn't contain all the function definitions that are necessary to actually work.

and yes, the stack alignment problem supposedly does not exist in the x64 msvc version,
so the only thing it would be missing is some inline asm compared to a speculated fully working x64 mingw version...

Edit:
mingw64 will have a better grounding once gcc 4.4.0 (which it's basing upon) has stabilized... (stabilized at least enough for an official release).

I wonder whether there is a way to use Windows API instead of pthread, which finally calls Windows API, to implement multithreading on win64.

[LoRd_MuldeR]

I wonder whether there is a way to use Windows API instead of pthread, which finally calls Windows API, to implement multithreading on win64.

The is a way to use the native Windows API, of course.

But the big point for pthreads is that it's portable between POSIX (Linux, Unix, etc) and Windows.
If you re-write x264 to use the Windows API instead of pthreads, then it wouldn't work for Linux anymore!
And you certainly don't wont to maintain two completely different code paths for Linux and Windows...

[roozhou]

The is a way to use the native Windows API, of course.

But the big point for pthreads is that it's portable between POSIX (Linux, Unix, etc) and Windows.
If you re-write x264 to use the Windows API instead of pthreads, then it wouldn't work for Linux anymore!
And you certainly don't wont to maintain two completely different code paths for Linux and Windows...

Code from xvidcore/motion_smp.h

#ifdef WIN32

# include <windows.h>
# define pthread_t HANDLE
# define pthread_create(t,u,f,d) *(t)=CreateThread(NULL,0,f,d,0,NULL)
# define pthread_join(t,s) { WaitForSingleObject(t,INFINITE); \
CloseHandle(t); }
# define sched_yield() Sleep(0);
static __inline int pthread_num_processors_np()
{
DWORD p_aff, s_aff, r = 0;
GetProcessAffinityMask(GetCurrentProcess(), (PDWORD_PTR) &p_aff, (PDWORD_PTR) &s_aff);
for(; p_aff != 0; p_aff>>=1) r += p_aff&1;
return r;
}

[LoRd_MuldeR]

So you want to implement your own wrapper for the Windows API to get a pthread-style interface.

What is the benefit over using the pthreads library, which basically does the same, is already working stable, saves you a lot of work and keeps your code clean & simple?

[squid_80]

Code from xvidcore/motion_smp.h

#ifdef WIN32

# include <windows.h>
# define pthread_t HANDLE
# define pthread_create(t,u,f,d) *(t)=CreateThread(NULL,0,f,d,0,NULL)
# define pthread_join(t,s) { WaitForSingleObject(t,INFINITE); \
CloseHandle(t); }
# define sched_yield() Sleep(0);

Xvid doesn't use any* synchronization methods though, I think x264 does.

(*Sleep() is not a synchronization primitive (http://www.virtualdub.org/blog/pivot/entry.php?id=62).)

[roozhou]

So you want to implement your own wrapper for the Windows API to get a pthread-style interface.

What is the benefit over using the pthreads library, which basically does the same, is already working stable, saves you a lot of work and keeps your code clean & simple?

That's not true. To build under MSVC one needs to download and compile pthread (it's neither in x264's git repository nor shipped with Visual Studio). This does cost me more time than writing a simple wrapper for Windows API as well as producing larger and slower binaries.

[Dark Shikari]

That's not true. To build under MSVC one needs to download and compile pthread (it's neither in x264's git repository nor shipped with Visual Studio). This does cost me more time than writing a simple wrapper for Windows API as well as producing larger and slower binaries.You do know the reason that pthreads were switched to in the first place, right?

They were very significantly faster than native threads. I doubt that Windows threads sped up that much in the 2 intervening years...

[roozhou]

You do know the reason that pthreads were switched to in the first place, right?

They were very significantly faster than native threads. I doubt that Windows threads sped up that much in the 2 intervening years...

This is very interesting because pthread uses native threads at last. If native thread runs slower than pthread that means you are not using threads in the right way.

[LoRd_MuldeR]

This is very interesting because pthread uses native threads at last. If native thread runs slower than pthread that means you are not using threads in the right way.

So just because the pthreads library makes use of the Windows API, doesn't mean that every single operation in the pthreads API will be mapped 1:1 to a Windows API function!

Whenever an operation can be handled in a library, which is running in user mode, an expensive syscall to the os kernel (switch context from user mode to kernel mode and back to user mode) can be avoided.

For the same reason pthreads on Linux now uses Futexes in order to avoid expensive syscalls whenever possible....

(BTW: In fact the Win32 API is a "high level" API (implemented by kernel32.dll and friends). There also is the "native" API (implemented in ntdll.dll), which usually is never called directly by an application. Only indirectly through Win32 API calls. The calls to the "native" API finally trap into kernel mode and execute the corresponding kernel function. So much for Win32 API is fast ^^)

[MasterNobody]

MSVC 2008 build with pthreads: x264win64_r1057_msvc2008.rar (http://stashbox.org/328761/x264win64_r1057_msvc2008.rar)
I have problems to compile with pthreads in MinGW. Would try it little more and then post patch in mailing list.

[MasterNobody]

Here is MinGW build with pthreads: x264win64_r1057_mingw.rar (http://stashbox.org/328884/x264win64_r1057_mingw.rar)
Now you can test speed between MSVC / MinGW and between 32bit / 64bit (32bit build: http://mirror01.x264.nl/x264/revision1057/x264.exe)

P.S. 64bit is not profiled (because I use cross-compiler on 32bit system)

[kemuri-_9]

MasterNobody, can you toss me the patches you have?
i can try and see if i can replicate everything in my MinGW64 environment.

[MasterNobody]

MasterNobody, can you toss me the patches you have?
i can try and see if i can replicate everything in my MinGW64 environment.

http://mailman.videolan.org/pipermail/x264-devel/2008-December/005300.html