x264 x86_64 on Windows Vista

Blue_MiSfit · 24th October 2007, 08:36

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 · 24th October 2007, 08:41

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 · 24th October 2007, 08:46

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

squid_80 · 24th October 2007, 08:58

Quote:

Originally Posted by Dark Shikari

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 · 24th October 2007, 09:07

Quote:

Originally Posted by squid_80

~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 · 24th October 2007, 09:09

Quote:

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

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.

Quote:

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.

Quote:

Originally Posted by Dark Shikari

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 · 24th October 2007, 18:34

Quote:

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 · 24th October 2007, 18:50

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

akupenguin · 24th October 2007, 19:38

Quote:

Originally Posted by Blue_MiSfit

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

Code:

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.

Quote:

Originally Posted by burfadel

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 · 25th October 2007, 06:30

Akupenguin -

Thanks! Unfortunately I try this and have issues:

Code:

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 · 25th October 2007, 06:34

typo, should be

Code:

- 720x480

"-" means stdin, not an option prefix.

Blue_MiSfit · 25th October 2007, 08:34

Thanks

Code:

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 · 25th October 2007, 08:40

Something went wrong. Your two encodes are not identical.

Blue_MiSfit · 25th October 2007, 08:57

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 · 25th October 2007, 10:37

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.

24th October 2007, 08:36	#1 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 6,024	x264 x86_64 on Windows Vista 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 __________________ These are all my personal statements, not those of my employer :)

24th October 2007, 08:41	#2 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	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. Last edited by burfadel; 24th October 2007 at 08:50.

25th October 2007, 06:34	#11 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	typo, should be Code: - 720x480 "-" means stdin, not an option prefix.

25th October 2007, 08:57	#14 \| Link
Blue_MiSfit Derek Prestegard IRL Join Date: Nov 2003 Location: Los Angeles Posts: 6,024	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 __________________ These are all my personal statements, not those of my employer :)

24th October 2007, 08:46	#3 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	And the advantage of 64-bit in x264 is very very minimal anyways.

24th October 2007, 18:50	#8 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	I didn't think of that method! but wouldn't the time and effort taken negate the speed benefits of using x264_x64?

25th October 2007, 08:40	#13 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	Something went wrong. Your two encodes are not identical.

25th October 2007, 10:37	#15 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	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.