Effect of RAM on h.264 encoding speed?

[fmagreed2]

How much of a part does system memory play when it comes to video (re)encoding?

I'm currently only using 3GB, since the system was originally designed for gaming and you rarely need more than that for games.

I've recently started ripping my movies to an HTPC drive and I'm wondering if it would be worth the money to upgrade my RAM to 12GB ($60) or so, or if it would just go to waste.

[LoRd_MuldeR]

Given that you want to encode with x264, memory consumption should not be such a big deal, unless you raise the RC-Lookahead a lot or run a lot of encodes in parallel.

The default values for RC-Lookahead (even with the slower presets) have been chosen conservatively in order to keep the memory usage low enough.

Encoding 1080p video (1920x1080) in x264 with "veryslow" preset, no pre-processing (reading directly from AVI file) and otherwise default settings uses ~1GB of memory here.

So you could still run three encodes in parallel without going out of RAM. Note that, unless your system gets low on physical RAM and starts using the page file, all is fine!

In other words: Installing more RAM doesn't improve the encoding speed at all, except when your system was low on RAM (during the encoding process) before the RAM upgrade.

Unless you use a 64-Bit system with 64-Bit OS and 64-Bit x264, the maximum possible memory usage of each encoder instance is 2 GB anyway.

Having said that, RAM has become very cheap and having more RAM certainly doesn't hurt. Also, complex Avisynth scripts (just think of QTGMC!) may eat a lot of memory...

Just be sure you have a 64-Bit OS, if you are going to extend your physical RAM beyond 3 GB. Otherwise only the first ~3 GB will be used!

[06_taro]

Unless you use a 64-Bit system with 64-Bit OS and 64-Bit x264, the maximum possible memory usage of each encoder instance is 2 GB anyway.

3 GB actually.

[fmagreed2]

I'm on 64bit, no worries there.

[LoRd_MuldeR]

3 GB actually.

The maximum amount of memory that a 32-Bit process can allocate, regardless of whether it is running on a 32-Bit or 64-Bit OS, is 2 GB by default.

That's because the OS reserves the other half of the process' 4 GB virtual address space for its own purpose.

You are right that this 2GB/2GB division can be changed to 3GB/1GB, if (and only if!) the binary was compiled with /LARGEADDRESSAWARE parameter.

[Dark Shikari]

x264 compiles with large address awareness by default.

[hello_hello]

3 GB actually.

At the risk of being argumentative, both my PCs are 32 bit and have 4GB of RAM and Windows shows 3.5GB of it.
I thought the total 4GB of memory Windows can see simply included the RAM on the video card? Currently both PCs have a video card with 512MB of RAM. At one stage I had two video cards in one of the PCs (512MB again) and with two cards installed the amount of RAM Windows claimed I had installed dropped down to 3GB.

[LoRd_MuldeR]

At the risk of being argumentative, both my PCs are 32 bit and have 4GB of RAM and Windows shows 3.5GB of it.
I thought the total 4GB of memory Windows can see simply included the RAM on the video card? Currently both PCs have a video card with 512MB of RAM. At one stage I had two video cards in one of the PCs (512MB again) and with two cards installed the amount of RAM Windows claimed I had installed dropped down to 3GB.

You have to differentiate between maximum "physical" memory the system can use overall and the "virtual" memory each process can allocate! :scared:

With a 32-Bit Windows, the maximum "physical" memory is limited to ~3GB. Actually the physical address space is 4GB, but "memory mapped I/O" takes away some addresses and you end up with ~3 GB.

This limit on "physical" memory (i.e. RAM modules) for the whole system has been removed in 64-Bit Windows.

Completely unrelated, however, is the question how much "virtual" memory each process (e.g. one instance of x264) running on the system can allocate!

An, as a matter of fact, a 32-Bit process (regardless of whether it is running on a 32-Bit or 64-Bit OS!) can allocate at most 4 GB of virtual memory, because all memory addresses are 32-Bit wide.

But the OS reserves a part of the process' 32-Bit "virtual" address space for it's own purposes. So, after all, each 32-Bit process can allocate a maximum of 2 GB or 3 GB (as the OS reserves 2 GB or 1 GB*).

The per-process limit on "virtual" memory has been removed only for "true" 64-Bit processes. Of course running 64-Bit processes implies a 64-Bit OS as well...

__________________
(*) By default the OS will reserve 2 GB of the 4 GB virtual address space for its own, leaving 2 GB for the app. But, if the EXE was compiled with /LARGEADDRESSAWARE, then the OS only reserves 1 GB for its own, giving the app 3 GB.

[MasterNobody]

But the OS reserves a part of the process' 32-Bit "virtual" address space for it's own purposes. So, after all, each 32-Bit process can allocate a maximum of 2 GB or 3 GB (as the OS reserves 2 GB or 1 GB*).

The per-process limit on "virtual" memory has been removed only for "true" 64-Bit processes. Of course running 64-Bit processes implies a 64-Bit OS as well...

__________________
(*) By default the OS will reserve 2 GB of the 4 GB virtual address space for its own, leaving 2 GB for the app. But, if the EXE was compiled with /LARGEADDRESSAWARE, then the OS only reserves 1 GB for its own, giving the app 3 GB.
32-bit process with /LARGEADDRESSAWARE on 64-bit OS can use almost all 4 GB of "virtual" memory (http://support.microsoft.com/kb/889654/en-us).