x264 32 or 64 bit version ? Big difference ?

[lutinor]

If you have a 64bit os/cpu , is it really better ? :confused:

[mariush]

The 64 bit version is slightly faster and does not have the limitation of 2 GB per process the 32 bit version has (issue you may stumble upon if you were to encode 1080p content with extremely high quality settings, like -placebo for example)

On the other hand, if you use Avisynth scripts as source for the encoder, some Avisynth plugins are available only in the 32bit flavor so you'd have to use a 32bit version of Avisynth, therefore you'd also have to use the 32bit version of x264 (well, technically you can get around that and make it work but it's outside the scope of this explanation).

Short story... try both versions. Stick with what works better for you.

edit: Hi Mulder :p

[LoRd_MuldeR]

If you have a 64bit os/cpu , is it really better ? :confused:

It's a bit faster, so if you have a 64-Bit CPU with 64-Bit operating system, then you should go with 64-Bit x264 :)

Of course 64-Bit x264 will need 64-Bit Avisynth. And 64-Bit Avisynth will need 64-Bit Avisynth-Plugins! But it won't run into the 2 GB memory limit of 32-Bit processes.

(There are ways to use 32-Bit Avisynth with 64-Bit x264 tough)

[IgorC]

http://tinyurl.com/3jbpnyx

[lutinor]

It's a bit faster, so if you have a 64-Bit CPU with 64-Bit operating system, then you should go with 64-Bit x264 :)

Of course 64-Bit x264 will need 64-Bit Avisynth. And 64-Bit Avisynth will need 64-Bit Avisynth-Plugins! But it won't run into the 2 GB memory limit of 32-Bit processes.

(There are ways to use 32-Bit Avisynth with 64-Bit x264 tough)

Haha ^^ But if i don't use Avisynth ? I only use x264.exe :)

[Blue_MiSfit]

Even better. 64 bit all the way!

[CarlEdman]

Sound advice in this thread. Only three points to add:

1. Encoding 1080p content may run up against the 2 gByte limit not only at stupid settings like 'placebo', but even at demanding, but sane, settings like 'veryslow'

2. You can use 32-bit avisynth with x264 64-bit using a great little tool called avs2pipe. http://forum.doom9.org/showthread.php?t=160383. I've been doing this for years (with a slightly less well written tool than avs2pipe mostly, with avs2pipe in the last few weeks). Just have 32-bit avs2pipe run your avisynth scripts and pipe the uncompressed output in y4m format to x264 64-bit.

3. There is a 64-bit version of Avisynth which supposedly works with 64-bit x264 and a number of the most important filters have been ported to it. http://code.google.com/p/avisynth64/. I have not tried it, but the next time I get around to redoing my build process, I will try to switch to that for two reasons:

(a) 64-bit avisynth is a fair bit faster according to all reports. With some of the demanding filters I use this would be a big win.

(b) The y4m format does not transmit timecodes to x264. So if you have timing issues, using an avisynth internal to x264, rather than going through y4m, may be necessary.

[aegisofrime]

3. There is a 64-bit version of Avisynth which supposedly works with 64-bit x264 and a number of the most important filters have been ported to it. http://code.google.com/p/avisynth64/. I have not tried it, but the next time I get around to redoing my build process, I will try to switch to that for two reasons:

(a) 64-bit avisynth is a fair bit faster according to all reports. With some of the demanding filters I use this would be a big win.

(b) The y4m format does not transmit timecodes to x264. So if you have timing issues, using an avisynth internal to x264, rather than going through y4m, may be necessary.

That is correct, I have been using it for a long time and it works great with a 20% speedup. It's just too bad the developer disappeared.

[sneaker_ger]

(b) The y4m format does not transmit timecodes to x264. So if you have timing issues, using an avisynth internal to x264, rather than going through y4m, may be necessary.

Since AviSynth is purely CFR that can't fix anything that can't be fixed by the --fps parameter.

[CarlEdman]

sneaker_ger, you are right--I was using imprecise language.

What I meant was that x264 now accepts a --timecode-in parameter which is useless when the image stream delivered to x264 already has had its fields variously munged (de-telecined or de-interlaced, respectively) by avisynth before it even receives the frame stream. With a timecode-aware avisynth built into x264, we could finally have the potential to correctly deal with non-cfr content (including such common cases as the partially interlaced, partially telecined content), which was such a headache previously.

[J_Darnley]

No matter how you use avisynth, if you want VFR, you will need a timecodes file.

[sneaker_ger]

sneaker_ger, you are right--I was using imprecise language.

What I meant was that x264 now accepts a --timecode-in parameter which is useless when the image stream delivered to x264 already has had its fields variously munged (de-telecined or de-interlaced, respectively) by avisynth before it even receives the frame stream. With a timecode-aware avisynth built into x264, we could finally have the potential to correctly deal with non-cfr content (including such common cases as the partially interlaced, partially telecined content), which was such a headache previously.

You mean that someone has a VFR-Hack for AviSynth in the pipe? I honestly don't see it coming.

But people have been creating VFR content with AviSynth for a long time now, as there are workarounds. But these workarounds work equally well for both "direct" AviSynth input and piping solutions.

[burfadel]

I believe x264 is also fairly unoptimised when comparing with the x86 version when it comes to x64.

It doesn't really matter what the program is, x64 versions should be faster than their x86 counterparts unless done incorrectly.