Less motion = less new pixel info = smaller size.

The more motion you have the more the pixel's change. So, it needs to store the new pixel info.

Well I just ran a test, both arguments make sense so an experiment seemed in order. I'll admit they are not real world.

Took a 10 sec clip of checkerboard generated media.

Rendered at default bit rate with no motion: 3,006 Kbytes

Used track pan/crop to move pattern from lower RHS to upper LHS.

Rendered with same settings: 4,030 Kbytes.

That's a big difference.

Of cousre the image has no chroma information and very little detail so the encoder is not being stressed.
It's inspired me to run some tests on some noisy jittery video to see what happens when I mask out the superflous bits that have a lot of motion.

Does a lot of motion in the video effect the rendering time?

DVDA is saying its going to take 40 hours to prepair a one hour movie.

The last one I did only took 18 hours

Using DVDA to do the encoding

500 mh processor

The fewer new image frames, the lesser number of information frames, and the smaller the file will be to a certain degree. Redundancy is a good thing. Ralph LaBarge's book on MPEG encoding has some great formula's and tables for figuring this out.
If I were working with VHS footage, I'd crop it anyway, to get rid of the noise bed found on nearly all VHS footage, unless you have an external TBC to 'fix' it. It adds noise, which means new pixels in every frame, which means lots of compression information, which also equals a lesser quality image, even if the noise is not seen on a monitor. It's still in there. Just by cropping DV media by a couple pixels, you'll usually see a slight difference as well, because it removes the fringing found in the DV format.

It must have a slight impact but the hard part is working out if there is motion and then optimising how to encode it.

I think your biggest problem is that 500 MHz processor.
Temporal compression such as mpeg 1,2 or 4 is very processor intensive.

AMEN...I'm amazed it will even run on that proc.

If there is a lot of motion then there will be a corresponding increase in the level of visible artifacts at any given bitrate. For a really crummy video you will be able to see artifacts even if running at the maximum bitrate (~9Mb/sec).

One eye-opener for me last year was encoding (with CinemaCraft, not MainConcept) a DV avi of three people walking along the famous San Antonio "Riverwalk." The shot was handheld and there was lots of activity in the scene, but when I used CinemaCraft's advanced features to get inside the MPEG2 encode and look at the bitrate and quantization levels for the video, I was stunned to see that the encoder was just blown away by only a few parts of the video. In syncing up the timelines, I discovered that one of the three people in the video was wearing a golf shirt with intricate patterns. Whenever that shirt was in the video, the encoder just went nuts trying to encode it.

Another reason to ban golf shirts.

I couldn't believe the results from the test farss did. I was certain that all that mattered was the encoding rate. So, I duplicated his test: I put the checkerboard on the timeline and rendered. I then used pan/crop to create a few keyframes, and moved the checkerboard around, and then rendered again.

I used the standard DVD Architect MPEG2 template which uses VBR at 6,000,000 bps average, 8,000,000 max.

I was amazed: The non-moving checkerboard file size was only 16% of the size of the checkerboard that moved. This is exactly what farss observed.

I then changed to CBR (constant bit rate) and repeated the experiment. The two files were identical.

Now I was puzzled.

I would have expected the VBR results to produce identical file sizes, just like the CBR test did. I have been using a bitrate calculator to figure out the largest average bitrate I can use and still make my video and audio exactly fit on one single DVD-R. I've been hitting it pretty darn close, and I've been using VBR, not CBR. If the checkerboard test reflects what goes on with real video, then the bitrate calculator shouldn't be able to accurately predict file size. But, in my experience, it predicts almost exactly, every time.

How to reconcile the checkerboard encode with my bitrate calculator experience? Time for one more experiment.

What if I used a real video clip that has minimum movement (like a talking head) rather than absolutely no movement at all? What if I then took this clip and pan/cropped it to artifically generate lots of movement?

I took 20 seconds of a man sitting in a sofa holding an infant and encoded at 6,000,000 average, 8,000,000 max VBR. I then panned/cropped the clip and repeated the render at the same exact settings.

Result? There was less than a 2% difference in file size (and the one with lots of movement was the smaller of the two). Bingo.

Conclusion: Because the checkerboard test had absolutely no motion whatsoever, it created a "pathological" case that doesn't reflect the real world. Using real video, the file size is determine entirely by the average bitrate, not by the motion -- or lack thereof -- in the video.