An Analogy About Bit Rates

One of the hardest concepts for many people to understand when compressing video for the web is that the size of the source file does not affect the size of the compressed file.

It would seem logical that if the source file was really big, the compressed file would be really big. Or, if the source file was really small, the compressed file would be really small. You’d think so, but you’d be wrong. It isn’t intuitive, but its the truth.

This morning, an analogy came to mind to help explain this seemingly bizarre situation.

A DIGRESSION

But, first, a short digression into video compression terminology.

Compression is the process of taking a large file and making it smaller. We do this by sampling portions of the larger file and storing them into the smaller file.

Bit rate is a measure of the number of bits – ones and zeros – that move from Point A to Point B in a second. Bit rate is often measured in “Thousands of bits per second” (Kbps) or “Millions of bits per second” (Mbps). When we are dealing with the Internet and media playback, all these bits move in single file.

You set the bit rate as you prepare a media file for compression and bit rate is the SOLE determiner of the size of the compressed file.

Image quality, on the other hand, is determined by several factors:

• Codec (i.e. H.264)
• Video frame size, in pixels
• Video frame rate, in frames per second
• The amount of movement, either camera or talent, between frames
• Bit rate

While there are two types of bit rates – variable (VBR) and constant (CBR) – for the purposes of this analogy, we can treat them as the same.

THE ANALOGY

Imagine I’m standing next to a bubbling mountain brook, holding a 1-cup plastic measuring cup in my hand. For you metric types, this 1-cup measuring cup holds 250 ml of water.

My instructions are to sample that brook once a second. (In other words, I’ve been given a “dip it up” rate of one measuring cup per second.)

At the end of four seconds, I have sampled (compressed) one quart (one liter) of water.

Now, through the magic of analogy, the scene dissolves and I’m standing beside a small lake, holding the same instructions.

Once I start dipping, I know that every four seconds I’m going to dip up one quart (liter) of water, regardless of how big that lake is.

Whoosh! A swish pan just deposited me in a small fishing boat out in the middle of the Atlantic Ocean. There’s water as far as I can see.

Yet, because my dip-up instructions haven’t changed, I know that, even though I’m floating on more water than my mind can imagine, I’ll be sampling (compressing) one quart (one liter) of water every four seconds.

THE MEANING

Because bit rates are fixed at the start of compression, and because bit rates are the sole determiner of file size, it doesn’t matter how big the source file is.

But, then, why create large source files in the first place? Its because of that word “sampling” that I used earlier. If all we have to work with is a small brook, maybe the water is too shallow to fully fill the cup, or maybe we pick up a bit of sand from the bottom. Because the original stream is so small, there’s a good chance our water samples could get contaminated.

However, when we move into a very large body of water, the cup is always full of pure water. There’s less risk of contamination. Our final results are always much better.

For this reason, I always recommend exporting projects at the highest quality your project will support, then compressing from that large master file. It’s an extra step, but it always yields better results. And, now you know why.

---

Bookmark the permalink.