I'm an avid gamer. Occasionally I like to record my gameplay with Fraps and upload it on YouTube. For my encoding I use Komisar's x264 codec in VirtualDub with the following settings: link to image

Now, I'm trying to write a small blog article because I recently retired my old Q6600 and upgraded to 2700k.

Here's a small snippet from the draft:

Encoding speed is measured in (average) frames per second. The more, the merrier. It's also important to know that there are, what I like to call, "motion-heavy" and "motion-light" scenes.


Motion-heavy scenes take much longer to encode than motion-light ones, at least that was my experience in those 2+ years since. I might of course be totally wrong about this, and unfortunately I don't have hard statistics to show for, i.e. benchmarks while encoding. Just my observation, unfortunately.

Now, regarding the linked codec, used encoding software and linked settings, am I correct in the statement about motion-heavy and motion-light scenes?

My personal experience says yes. It takes me much longer to encode scenes where a lot is happening on the screen as opposed to motion light ones. Using the same codec, same encoding software and same settings as linked above.

  • This is easy to test: make an uncompressed AVI etc from a single solid colored frame (i.e. 1 mins of one frame), and then make one from a grouping of frames generated using random noise or cloud filter (i.e. 1 mins of these frames repeated randomly). Then run your encoder on each. – horatio Dec 14 '11 at 17:01
  • @Gareth: For future reference: I did not give you permission to upload the setting image to imgur. Yes, I'm it's original author. So kindly have the decency to ask before you do it, would you? – Grumpy ol' Bear Jan 6 '12 at 10:25

Video compression is basically encoding the differences between a frame and the next one. So the more differences between two frames, the more data you will have to write. That's actually a lot more complex than that, but that's the basis. You will notice that on DVDs or any other fixed bandwidth compression (MPEG1, MPEG2, h.264, etc.), still images are almost perfect, while moving ones are blurry. That's because a lot of movement involves more data to write, so a tradeoff has to be made.

  • These are not fixed bandwidth compressions, it is only matter of "rate control". – KovBal Jan 6 '12 at 12:33

I am not sure the amount of data to process is significant. Since every frame has the exact same amount of pixels, you can only generate "more data" if you have already run complicated motion estimation algorithm(s) and even so, the resultant P/B frame is only going to be smaller (as otherwise motion compensation would be useless). The memory bandwidth on modern systems is so high that I don't think the amount of data contributes to the encoding speed at all.

A encoder must first run some algorithm, for each frame, to determine which frame type is should use. This algorithm can be complicated but the complexity should be roughly the same for every frame (so not a factor here). However, when it determines a P / B is needed, very complicated motion estimation algorithms must be run with different parameters to determine which is the best way to compress the motion in the frame. When the selection of reference frames comes into play, like in B frames, the previous complexity will be multiplied.

These are additional complexities, thus computing time, that only occur when the encoder decides motion compensation can better compress the frame than simple pixel differences, so motion-heavy scenes takes longer to compute. This also explains why compression time benefits more from faster processors rather than faster storage.


Obviously there is much more data to process when encoding with motion-heavy.

So technically yes, it influence the total encoding time and motion heavy will be longer to encode than motion light.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.