re: file sizes after web encoding

Hi all,

bought Squeeze 4.1 (love it) but am a little confused about the size of the files after output. I've been playing and testing a lot, then decided to do a run of 5 outputs using only slight variations.

The audio for each was QDesign at 40 kbps and a sample rate of 32000 and in Mono.

For the video (of 5 minutes & 2 secs) the generic levels i used were Sorenson 3 pro, 2-Pass VBR, Bidirectional Frames, Minimum Quality of 50, Auto Keyframe on Scene Change @ 50 and image smoothing.

These are the outputs for the variables:

1) 400 kbps - 320x240 - 25 frames/sec - Key Frame every 250 - 15.8 megs
2) 400 kbps - 320x240 - 12.5 frames/sec - Key Frame every 125 - 16 megs
3) 400 kbps - 320x240 - 12.5 frames/sec - Key Frame every 250 - 15.9 megs

4) 300 kbps - 320x240 - 15 frames/sec - Key Frame every 150 - 12.4 megs
5) 300 kbps - 320x240 - 25 frames/sec - Key Frame every 250 - 12.2 megs
6) 300 kbps - 240x180 - 25 frames/sec - Key Frame every 150 - 13.5 megs

Now what is confusing me is:

a) Why is no.1) the smallest file size in the 400 kbps when it uses the most frames/sec, and the same in the 300 kbps with no. 5) being the smallest?

b) Why is no.6) the largest of the 300 kbps when it is the smallest window size of the 3?

Am I going mad? Have I made a big boob somewhere. I though Data Rate, Frames/second and Window size where the 3 biggest elements that affected file size.

Also, if I go for number 5) is 12.2 megs a fair size for a 5 minute video (aiming for 512k connection - it's total Data Rate being 339)

Ok, thanks for any input, and i understand if this post is skipped, ultimately it is down to me to learn (and i'm trying) but i thought i'd try my luck.

Jules

Aimless Musings:

<<2-Pass VBR>>>

That's magic right there. If you are compressing motion efficiently, it doesn't matter what the frame rate is, the motion, and the data size will remain mainly constant--or a lot more constant than you think.

I wish you have kept everything constant and only changed *one* thing. You only need to do that in two test per sample to get an idea which one is going to give you the best return for the effort.

As you are finding out, the *content* can get you. Since you are compressing motion, a movie with no motion will compress to zero (metaphorically). British Drawing Room Comedies compress to 8 KB. American Movie Battle Scenes don't compress at all.

This is connected to a posting I made elsewhere on the forum. Compression is not a "push this button and that happens" kind of affair. It's swoozy and slippery.

Koz

Thanks Koz, nice to know the VBR is a) good to use and b) means i can keep the frame rate high. Am going to keep testing with single changes. This is my first time compressing for the web, so although testing only 2 would be great, i'm pretty much going to keep going till i get a handle on it.

Does the VBR negate changes in window size as well?

Oh, made a mistake in the settings no.6) was 15 frames/sec. Still don't understand why that one was a larger file...?

15 Frames per Second is generally thought to be the minimum frame rate where most people still see continuous motion. Below that, it gets perceptably choppy. We never do anything lower than 15.

The size of the frame isn't generally associated with 2-Pass. What 2-Pass does is inspect the relationship of successive frames--twice for accuracy--and generates compression personality that reflects just the changes.

If you have two video frames that were the same, the combination might compress to, say 1M. If you had fifteen frames that were all the same, it would still compress to 1M since there were no differences anywhere in spite of the program inspecting the sequence twice. If you had fifteen frames where each pixel was radically different in each frame (explosions, rotating pictures, snowstorms), it would compress to 15M--almost no savings at all.

Other things happen, but that's the idea.

You can get reduced file sizes by counting the colors. If you have cartoons made up of only three or four colors, that can save enourmously in compression--there should be a setting for that.

The Quality setting affects individual pictures. The lower, the worse.

One of the persistant I/O Operators discovered that he could get good looking pictures at smaller file sizes by *deselecting* the Set For Internet Streaming option. I don't know what that actually does.

Compression is a front-loaded operation. It takes you hours to compress something well so that the user can play it back clearly in real time. Any time the compressor asks you if you want to hurry up, say no.

Koz