mmick wrote:musicvid: handbrake is a video converter, uses no filters per se...
HandBrake does have filters and each filter in the pipeline requires some number of frames. In order to keep the pipeline moving without delays, there is a fifo that buffers the output of the previous stage and feeds the next stage. Each stage in the pipeline can have between 16 and 32 buffers waiting in the fifo. This adds up when your pipeline looks like:
Code: Select all
reader->decoder->sync->vfr filter->denoise filter->deinterlace filter->scale filter->encoder->muxer
Also, libx264 can buffer many more frames than HandBrake's internal pipeline does for pre-analysis which is done in it's lookahead thread. This is where most people get into trouble with memory. The slower x264 presets add more lookahead buffers.
...has a very simple UI and it does not have the RAM requirements as a proper video editor.
True, HandBrake probably doesn't have the memory needs of a quality video editor, but the UI has nothing to do with it. Video editors can consume lots of memory because they cache lots of decoded frames, which HandBrake will also do when certain settings are used. HandBrake definitely has the potential to consume a lot of memory, but can also be tuned to use less through proper choice of settings.
That said, 2 GB of RAM (well inside the 32-bit limit, which is 4 GB) should be more than enough, and personally I never needed more than 1.2 GB of RAM for my blu ray conversions...
You don't get 4GB of ram on 32bit windows. You get just a shade over 3GB due to windows brain damage.
It is "enough" unless you want to do HD encodes with x264 slower preset which has a very large lookahead buffer. Then you are likely to run into trouble. So long as you are satisfied with medium or faster presets, you may be "ok".
I used to do some (VERY basic) video editing on an AMD E-450 + 4 GB RAM + Windows 7 32-bit with full hd sources (the AMD E450 has hardware decode for h264) and besides taking forever to encode, it never ran out of memory or had issues.
Yes, it is possible (as I said above). But you can get better performance and/or better quality if you use more memory.
So, we could cripple the 32bit version and disable all the features that would push it beyond 3GB memory usage (so that it doesn't crash when an unwary user pushes the limits). Or we could just quit supporting 32bit. Since it is more work to publish a crippled encoder, we choose to quite supporting 32bit.
