Question about bitrate..

[Brad Ballew]

So having worked in video production for a few years, I have learned a lot about how video and compression work. I understand 4:4:4, 4:2:2, and 4:2:0 and can visualize it and see how it effects the footage especially when pushed. I understand how it borrows color info from surrounding pixels instead of giving each pixel it's own color info.

But I never completely understood exactly what is happening when you are adjusting bit rate. I understand how to manipulate it and I a have a good feel for how to use it to balance file size and quality. However, how does info get thrown away, or not included in the export when you are adjusting bit rate?

[Seth Bloombaum]

It really depends on the codec and the encode controls that are exposed by a particular compression product.

The amazing math geniuses who design codecs make use of every trick and strategy they can invent to make the info more visually meaningful. The game is to throw away data but keep image quality.

First, there are various non-perceivable compressions. Run-length-encoding (RLE) comes to mind. If you have a string of zeros (bits) in a particular digital word (byte), then there are models that would say "6 zeros" instead of "000000". And many other math tricks.

As we get into perceptual encoding, the maths work with how we perceive color, motion, and resolution. You mentioned 4:4:4, etc. the point of these is that though the higher color resolution is frequently important in our various post processes, the human eye is less sensitive to differences in color values than it is to differences in luma values. So that full chroma resolution is not needed for distribution.

Then there are strategies like RLE that are applied to adjacent pixels. If a block of pixels are the same color in a particular frame, a single piece of data would define that color and the group of pixels it would be applied to.

Finally, in temporal (time) encoding, if a pixel or group is the same color across successive frames...

Most bitrate settings will affect several of these individual compression elements, but, e.g., at high compression you start to see groups of pixels that are the same color that maybe shouldn't (macroblocking).

This is really the briefest outline. I am no creator of codes or mathematician, but like many who do a lot of video compression, I've soaked up some of these strategies as I've tried to determine exactly what effect a particular encoder control might have.

[Brad Ballew]

Thank you for that Seth. That makes a lot of sense. That is really interesting and gives me a greater appreciation for whats going on when my video is getting compressed. Now I feel I have a better grasp on the inner workings of compression.

Much appreciated! :)

[David Heath]

Originally Posted by Brad Ballew

But I never completely understood exactly what is happening when you are adjusting bit rate. I understand how to manipulate it and I a have a good feel for how to use it to balance file size and quality. However, how does info get thrown away, or not included in the export when you are adjusting bit rate?

There are some good illustrative example pictures at the end of this article - JPEG - Wikipedia, the free encyclopedia

I'll let you decide how much or little of the maths you want to read! :-)

That refers to JPEG (mainly applicable to stills) but the principles of DCT are fundamental to most modern codecs - DV, DVCPro, MPEG2, AVC-Intra, H264 etc.

For video, it's possible to additionally take advantage of frame by frame similarities to get comparable quality at even lower bitrates. That's at the expense of additional processing complexity. The benefits will depend on how much movement is in the shot - more movement=more differences between frames=less benefit - but it should give the possibility of about a 2-3x improvement.

If you don't want the maths, then at the simplest level first think of dividing the image into 8x8 blocks of pixels. First approach is to establish the average value of the block, averaging all 64 pixels. Then work out the difference between the average and each pixel, and save the differences. The differences can be "simplified" to save data - and max compression would be to discard all the differences. (So the picture is just made up of 8x8 uniform blocks!) Try opening a photo in Photoshop and saving it as JPEG with differing compression levels.

The examples at the bottom of the link show what happens when too little data is used - you can see the flaws. More advanced coding uses extra tricks to help disguise the discrepencies - such as variable block size, eg 4x4 blocks as well as 8x8 in those areas of the picture which can benefit. How well they work depends on how good the coder is, but (as example) H264/AVC may look as good as MPEG2 at half the bitrate. There's a very important caveat to that though. The tricks are designed to help disguise flaws, the lower the bitrate the more the flaws, so codecs such as H264 are more efficient at low bitrates than high. (At high bitrates with (say) MPEG2, the flaws will be slight, so much less for the H264 "tricks" to disguise.)

That's why H264 is so good for web and broadcast use, but why high bit rate AVC-HD doesn't give results equivalent to twice it's bitrate (42 Mbs) . It's better than if you just used 21 Mbs to encode as MPEG2, but nowhere near as good as 42 Mbs MPEG2 would be.

[Jon Fairhurst]

One thing that adds to the variability of the bit rate is Hamming Coding.

In Hamming Coding, the most likely DCT pattern gets a very simple code, say, 0. The next two most common patterns get 10 and 11. The next four most likely patterns get 100, 101, 110, and 111 and so on. For a common situation, where DCT blocks are all black or all gray, very few bits need to be transmitted. For random, complex stuff, more bits are required.

This all happens within a frame, rather than between frames.

JPEG uses Hamming Coding. A constant bitrate codec, like DV, usually does not.