Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th January 2012, 21:05   #1  |  Link
fmagreed2
Registered User
 
Join Date: Sep 2010
Posts: 17
Effect of RAM on h.264 encoding speed?

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.
fmagreed2 is offline   Reply With Quote
Old 7th January 2012, 21:11   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
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!
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 7th January 2012 at 21:28.
LoRd_MuldeR is offline   Reply With Quote
Old 7th January 2012, 21:31   #3  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
06_taro is offline   Reply With Quote
Old 7th January 2012, 21:46   #4  |  Link
fmagreed2
Registered User
 
Join Date: Sep 2010
Posts: 17
I'm on 64bit, no worries there.
fmagreed2 is offline   Reply With Quote
Old 7th January 2012, 22:10   #5  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by 06_taro View Post
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 7th January 2012, 22:30   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
x264 compiles with large address awareness by default.
Dark Shikari is offline   Reply With Quote
Old 8th January 2012, 14:39   #7  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by 06_taro View Post
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.
hello_hello is offline   Reply With Quote
Old 8th January 2012, 16:05   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by hello_hello View Post
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!

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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 8th January 2012 at 16:17.
LoRd_MuldeR is offline   Reply With Quote
Old 8th January 2012, 16:25   #9  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
MasterNobody is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.