x264 Windows x64 support

[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]

Originally Posted by roozhou

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

[roozhou]

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

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]

Originally Posted by roozhou

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]

Originally Posted by Dark Shikari

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]

Originally Posted by roozhou

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
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
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]

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

http://mailman.videolan.org/pipermai...er/005300.html

[kemuri-_9]

confirmed as working (and thanks for fixing pthreads64 as well)

here's a build to match the current similar megui build

Platform:   X86_64
System:     MINGW
asm:        yes
avis input: yes
mp4 output: yes
pthread:    yes
debug:      no
gprof:      no
PIC:        no
shared:     no
visualize:  no

fprofiled:  yes

mods:
x264_win64_support.01.r1057.diff
x264_mingw_has_strtok_r.diff
x264_mingw_aligned_04.diff
x264_hrd_pulldown.09_interlace.diff

x264_x64.exe

getting a 5-10% speedup on my own quick tests compared to x86

Edit:
now with mp4 output support

[Audionut]

Nice work guys. I wonder if I can get a compiler working.

[kemuri-_9]

got gpac to compile in mingw64...
whoever decided that char *'s should be compared by using != in zlib should be shot.

Edit:
it's broken for being used to test string non-equivalency...

[squid_80]

Originally Posted by kemuri-_9

got gpac to compile in mingw64...
whoever decided that char *'s should be compared by using != in zlib should be shot.

What's wrong with checking non-equivalency for a pointer?

[asarian]

Originally Posted by kemuri-_9

x264_x64.exe

getting a 5-10% speedup on my own quick tests compared to x86

Pardon my ignorance in the matter, but I've been having bad experiences with running the x86 version of x264 in a 64-bit OS (Windows 2008 Server). Keep getting the dreaded "x264 stopped responding" error ever so often. So, does this one run stable inside Windows 2008 (Datacenter)?

And is the 'Ugly fades' issue, mentioned here:

http://forum.doom9.org/showthread.php?t=143444

also resolved in this version? Otherwise there's no point in having the extra threads for my multi-core environment.

Thanks

[Ranguvar]

Originally Posted by kemuri-_9

got gpac to compile in mingw64...
whoever decided that char *'s should be compared by using != in zlib should be shot.

fix nfo pls?

[squid_80]

Originally Posted by kemuri-_9

got gpac to compile in mingw64...
whoever decided that char *'s should be compared by using != in zlib should be shot.

Edit:
it's broken for being used to test string non-equivalency...

Oh you mean char arrays not pointers

Yeah that's pretty dumb, almost as much as using strcmp for checking security signatures (thanks nintendo!).

[burfadel]

Originally Posted by asarian

Pardon my ignorance in the matter, but I've been having bad experiences with running the x86 version of x264 in a 64-bit OS (Windows 2008 Server). Keep getting the dreaded "x264 stopped responding" error ever so often. So, does this one run stable inside Windows 2008 (Datacenter)?

Thanks

Next time that happens, check at what point it crashes. I have seen that happen a couple of times (out of hundreds of encodes), and for me it happens after encoding. The encoded file is intact and you can manually mux it with YAMB, well at least in my case anyway!

I thought it was an issue regarding one of the filters I was using, avisynth, or staxrip

[asarian]

Originally Posted by burfadel

Next time that happens, check at what point it crashes. I have seen that happen a couple of times (out of hundreds of encodes), and for me it happens after encoding. The encoded file is intact and you can manually mux it with YAMB, well at least in my case anyway!

I thought it was an issue regarding one of the filters I was using, avisynth, or staxrip

it has happened to me once after encoding, but often in-between somewhere. This "Program X stopped responding" feature in Vista and Windows 2008 is real annoying. Especially since I suspect x264 doesn't really hang, but is just being very busy (as it should be).

[burfadel]

Ah ok! For the couple of times it has happened to me, and its not just with the latest versions, I'm not sure how far back it would go (hasn't always done it), its always at the end of the encode! Its not a major issue since the encoded file is still fine, but it would be good if it didn't happen - I'm guessing that it would be a very difficult problem to find, and it may not even be x264 which is causing it. It could be avisynth... Are you using Avisynth v2.5.8 RC4?