x264 x86_64 on Windows Vista

[Blue_MiSfit]

Hey folks,

So I recently took the plunge into Vista, and decided to go full tilt and risk x64.

It's been good so far. Everything works.

I would like to squeeze as much performance out of my X2 3800+ as possible, so I'm wondering if anyone is doing Windows x86_64 builds of x264's CLI encoder?

MeGUI gives me the x86 builds only. I know it's possible, because people do it on Linux all the time. I might have to compile it myself?

Suggestions!

~MiSfit

[burfadel]

First :) if you mean Windows XP x64, or Vista x64, its not x86_64! for 64 bit applications, you have to have all steps 64 bit, so therefore:
Megui x64,
Avisynth x64
all the filters thereof x64.

edit: I should have noted that sometimes drivers may be notated as x86_x64 to refer to the package containing both x86 and x64 versions of the driver in the one package. All other references of programmes as x86_x64, where its a 32 bit programme that works on both x86 and x64 computers is incorrect.

[Dark Shikari]

And the advantage of 64-bit in x264 is very very minimal anyways.

[squid_80]

And the advantage of 64-bit in x264 is very very minimal anyways.

~10% speed increase is very very minimal? Methinks you've not tried it...

Blue_MiSfit: Cef has up-to-date 64-bit builds.

[Dark Shikari]

~10% speed increase is very very minimal? Methinks you've not tried it...10%? That's surprising; I thought the only ASM code that benefited at all was SA8D (8x8 SATD)?

[akupenguin]

First :) if you mean Windows XP x64, or Vista x64, its not x86_64! for 64 bit applications, you have to have all steps 64 bit, so therefore:
Megui x64,
Avisynth x64
all the filters thereof x64.
Megui does not need to be 64bit. It's a separate program.
You can also get away with 32bit Avisynth + filters, by decoding in a separate program (e.g. avs2yuv) and piping to x264. There's some overhead though, and Megui doesn't do it for you.

I should have noted that sometimes drivers may be notated as x86_x64 to refer to the package containing both x86 and x64 versions of the driver in the one package. All other references of programmes as x86_x64, where its a 32 bit programme that works on both x86 and x64 computers is incorrect.
True but irrelevant. The question was about x86_64, not x86_x64.

10%? That's surprising; I thought the only ASM code that benefited at all was SA8D (8x8 SATD)?
All asm benefits, because x86_64 has a better calling convention (though the windows x86_64 calling convention isn't as good as the linux calling convention: fewer registers for arguments, some xmm are nonvolatile, and some overhead in a stack frame).
And x264 isn't entirely asm, the C part benefits from extra registers too.

[Blue_MiSfit]

You can also get away with 32bit Avisynth + filters, by decoding in a separate program (e.g. avs2yuv) and piping to x264. There's some overhead though, and Megui doesn't do it for you.


How exactly can this be done, and how much overhead is associated?

Thanks guys! I will look around for 64 bit builds.

~Misfit

[burfadel]

I didn't think of that method! but wouldn't the time and effort taken negate the speed benefits of using x264_x64?

[akupenguin]

How exactly can this be done, and how much overhead is associated?
avs2yuv in.avs -raw - | x264 - widthxheight --fps ...
Maybe I should clean up one of those piped yuv4mpeg patches on the mailinglist, or implement content-based filetype detection. Either would eliminate the need to put width,height,fps on the commandline. I normally use named pipes to deal with this, but they don't exist on windows.

Overhead on linux is 2% at fast x264 settings with no filtering, or 0.5% at hq-insane. In any case, far less than the speed benefit of 64bit x264. (Actually I compared `mencoder` vs `mencoder | x264`, not `x264` vs `avs2yuv | x264`, but the costs should be the same.) Windows might be different depending on how efficient its pipe implementation is. Also, since pipes depend on the shell, cygwin/msys might be more or less efficient than cmd.exe.
Overhead does not appear to depend on single vs dual core, though on single core the cpu time increases, while on dual core the wallclock time increases without changing cpu time.

I didn't think of that method! but wouldn't the time and effort taken negate the speed benefits of using x264_x64?
That depends on whether it takes you seconds or hours to write the shell script. It didn't take me any time or effort, but people who only know how to use Megui might want to wait until/if Megui ever supports it automatically.

[Blue_MiSfit]

Akupenguin -

Thanks! Unfortunately I try this and have issues:

c:\x264 test\x64>"c:\x264 test\x64\avs2yuv.exe" "c:\x264 test\test.avs" -raw -
| "c:\x264 test\x64\x264.exe" -720x480 --fps 23.976 --crf 18 --keyint 240 --min-
keyint 24 --ref 10 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 2 --analyse p8
x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-
input --cqmfile "D:\x264 Matricies\High Bitrate\Transparent\M4G HRM V2.cfg" --pr
ogress --no-dct-decimate --no-psnr --no-ssim --output "c:\x264 test\64bit.264"
c:\x264 test\x64\x264.exe: invalid option -- 7
c:\x264 test\test.avs: 720x480, 24000/1001 fps, 2001 frames
Output error: wrote only 491401 of 518400 bytes


Maybe I misunderstood you?

~MiSfit

[akupenguin]

typo, should be
- 720x480
"-" means stdin, not an option prefix.

[Blue_MiSfit]

Thanks :)


c:\x264 test>test
Testing 32 Bit:

avis [info]: 720x480 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [warning]: VBV maxrate specified, but no bufsize.
x264 [info]: slice I:13 Avg QP:17.15 size: 4369000:00
x264 [info]: slice P:402 Avg QP:19.69 size: 21828
x264 [info]: slice B:586 Avg QP:21.35 size: 6014
x264 [info]: mb I I16..4: 14.6% 77.4% 8.0%
x264 [info]: mb P I16..4: 2.5% 11.7% 0.4% P16..4: 46.4% 24.4% 14.5% 0.0% 0
.0% skip: 0.2%
x264 [info]: mb B I16..4: 0.2% 0.7% 0.0% B16..8: 36.7% 2.0% 3.8% direct:
0.7% skip:55.9%
x264 [info]: 8x8 transform intra:79.6% inter:99.6%
x264 [info]: direct mvs spatial:1.7% temporal:98.3%
x264 [info]: ref P 70.2% 12.6% 5.0% 3.1% 2.2% 2.0% 1.7% 1.0% 1.0% 1.3%
x264 [info]: ref B 79.0% 12.8% 2.8% 1.7% 1.0% 0.9% 0.7% 0.4% 0.3% 0.4%
x264 [info]: kb/s:2465.5

encoded 1001 frames, 4.41 fps, 2466.04 kb/s

Testing 64 Bit:
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
x264 [warning]: VBV maxrate specified, but no bufsize.
c:\x264 test\test.avs: 720x480, 24000/1001 fps, 1001 frames
x264 [info]: slice I:13 Avg QP:17.15 size: 43690
x264 [info]: slice P:402 Avg QP:19.69 size: 21815
x264 [info]: slice B:586 Avg QP:21.35 size: 5902
x264 [info]: mb I I16..4: 14.6% 77.4% 8.0%
x264 [info]: mb P I16..4: 2.5% 11.7% 0.4% P16..4: 46.5% 24.3% 14.5% 0.0% 0
.0% skip: 0.2%
x264 [info]: mb B I16..4: 0.2% 0.7% 0.0% B16..8: 35.6% 2.0% 3.8% direct:
0.7% skip:57.1%
x264 [info]: 8x8 transform intra:79.4% inter:99.6%
x264 [info]: direct mvs spatial:9.9% temporal:90.1%
x264 [info]: ref P 69.8% 12.9% 4.9% 3.1% 2.1% 2.1% 1.7% 1.0% 1.0% 1.3%
x264 [info]: ref B 79.2% 12.7% 2.7% 1.7% 1.0% 0.9% 0.6% 0.5% 0.3% 0.4%
x264 [info]: kb/s:2451.9

encoded 1001 frames, 4.74 fps, 2452.44 kb/s

c:\x264 test>


Seems to make around 7% difference (with a profile based on HQ-Slowest but with a CQM) - the 2-3% overhead of AVS2YUV makes sense!

Anyway - it's pretty simple to set up - and a 7% boost for free is good stuff IMO! Now to get it working automagically with MeGUI

~MiSfit

[akupenguin]

Something went wrong. Your two encodes are not identical.

[Blue_MiSfit]

Hmm... I'm using builds from different sources. The x64 is from Cef, and the x86 build is from MeGUI auto update (whoever compiles those).

Both output raw streams play just fine and look great...

What could cause non-identical output given identical input and settings?

~MiSfit

[akupenguin]

The stat that shows the greatest difference is "direct mvs". Not all patches just add options. One of the patches on the x264 mailinglist that I haven't merged yet modifies the decision of direct type. iirc Cef included it.