The mathematics of bitrate

The raw rate

Before any compression, a video signal is a stream of samples. The raw rate follows directly from how many samples each picture carries and how many pictures are sent each second. For a picture of W by H picture elements and a channel count C, the number of samples per picture is W × H × C. Multiply by the frame rate f and by the number of bits b used to store each sample, and the raw rate in bits per second appears. In one line: raw rate = W × H × C × f × b.

Take a 1920 by 1080 picture at full colour, three channels, thirty pictures per second, eight bits per sample. The arithmetic gives 1920 × 1080 × 3 × 30 × 8 bits per second, which is about 1.49 gigabits per second. That figure is the honest starting point: it is what the signal would occupy if nothing were discarded, and it shows how far compression must carry the problem.

The chroma factor

The channel count C is not always three. Under 4:2:2 the two chroma channels carry half as many samples as luma, so the effective count is 2. Under 4:2:0 they carry a quarter, so the effective count is 1.5. The raw rate therefore falls by one third and one half respectively before a single transform coefficient is computed. Repeating the example above with the effective count 1.5 gives 1920 × 1080 × 1.5 × 30 × 8, about 746 megabits per second — the same picture, half the raw data, at the cost of reduced colour resolution.

Bits per pixel

A useful intermediate quantity is the number of bits the finished stream spends per picture element. It is simply the bitrate divided by the product of picture size and frame rate: bits per pixel = rate ÷ (W × H × f). It is a normalised way to compare operating points that have different sizes and rates. A 1080p stream at 8 megabits per second spends about 0.13 bits per picture element; the same rate applied to a 4K picture spends only about 0.03 bits per element, which is why the larger picture cannot look as clean at the same rate.

A worked estimate, start to finish

Suppose a design must deliver 4K at sixty pictures per second using a modern standard, and the quality target is a bits-per-pixel figure of 0.10. The picture is 3840 by 2160, so it holds 8.29 million elements. Multiply by the frame rate of sixty to get 497 million elements per second. Multiply by 0.10 bits per element to get about 49.7 megabits per second. Allow a further fifteen per cent for audio, system data and headroom, and the design should be provisioned at about 57 megabits per second.

The estimate can be run in reverse. Given a channel of 40 megabits per second and a requirement to keep 0.10 bits per element, the largest 4K frame rate that fits is found by dividing 40 million by the product of picture elements and bits per element, which gives about forty-eight pictures per second. Neither direction is exact — the true rate depends on the content and on the encoder — but both give a defensible first number, and a defensible first number is worth more than a guess dressed as a measurement.

The limits of the estimate

These formulas describe the average behaviour of a well-designed encoding stage. They do not capture the moments when a scene resists compression: a burst of confetti, a hard cut, a rapid pan. Real encoders hold a buffer, let the instantaneous rate rise above the average for a short time, and recover afterwards. The buffer is what reconciles a variable-rate signal with a fixed-rate channel, and its size is a design choice in its own right. The mathematics of bitrate is therefore the beginning of a plan, not the end of one: it fixes the budget, and the encoder decides how the budget is spent.