Maximizing your memory usage of your application based on the Expression Encoder SDK

Fact 1: Currently, our SDK is 32-bit only due to a lot of our dependencies. This brings a few limitations, including a theoretical memory usage limit of 4GB. But because of complex OS memory usage rules, compiled 32-bit applications are limited to access only 2GB by default (this is true on both running on a 32-bit OS or a 64-bit OS via WOW64).

 

Fact 2: Encoding video, especially when using HD sources and/or encoding to SmoothStreaming, requires loads of memory. In fact, some encoding operations requires so much memory that our encoding pipeline has to reduce the number of concurrent encoding streams because it's starving memory-wise.

 

Fact 3: Memory is much cheaper, with some <$1000 PCs having 12GB of RAM. Concurrently, the 64-bit Windows OS market share has never been higher and users are successfully running their 32-bit applications via Wow64.

 

Until Expression Encoder is available in a 64-bit flavor, that 2GB limitation will be a serious bottleneck affecting performance on custom applications using the Encoder SDK.

 

Is there a way to mitigate that 2GB memory limit on a 32bit application? In a word: yes.

 

For a Native application, you can use the "/LARGEADDRESSAWARE" linker flag, which will let a 32-bit application running on a 64-bit OS allocate up to 2GB of extra user-mode memory, effectively doubling the usable memory and therefore removing some of that bottleneck. And while that flag never got ported to the managed linker, you can also achieve the same result by doing this post-link operation:

 

EditBin.exe /LARGEADDRESSAWARE C:\...\bin\Debug\<YourApplication>.exe

 

Unfortunately, it’s a little more complicated to take advantage of this extra memory on a 32-bit based OS, as it does involve adding a boot flag ("/3GB") to reduce the kernel memory allocation in favor of user-mode memory, which will provide up to an extra 1GB to applications. But it comes at a price and should be avoided on XP since it may affect system stability because of some GPU memory mapping. A lot more information on this subect is available on those 2 pages:

https://msdn.microsoft.com/en-us/library/ms791558.aspx

https://support.microsoft.com/kb/291988

 

It's worth noting that the “/LARGEADDRESSAWARE” flag will simply be ignored on a 32-bit OS if the “/3GB” boot flag isn’t set, so there are no drawbacks in modifying your app with EditBin as explained above.

 

Please also note that we already did this operation on the Encoder GUI (EncoderUI.exe) for our users’ convenience, but that step will be required if you want your custom application using the Encoder SDK to be able to use more than 2GB of memory.

 

Here is a good blog entry with more details on this topic: https://bilbrobloggins.com/wow64/hidden-secrets-of-w0w64-ndash-large-address-space/

Comments

• Anonymous
  March 25, 2010
  How on earth does Expression Encoder progressively consume memory (>3.5GB) until it dies halfway thru an encode of 720p source material (to a ZuneHD), whereas the older Windows Media Encoder happily cranks away thru the entire file, all the time allocating less than 150MB of RAM? This with identical codes and encoding paramters on the same machine? What is it doing?

• Anonymous
  April 15, 2010
  Any news on Expression Encoder 4, team? Blend 4 is already in beta and both Blend 4 and Web 4 are going to be free upgrades for v3 owners.