Video Bitrate and Model Accuracy: What Compression Costs You

Halving a video archive’s bitrate halves its storage bill exactly. What it does to your detector’s accuracy is not knowable from first principles and there is no public table you can look it up in. This page derives the half you can compute, gives the arithmetic for the half you must measure, and shows how to put both on one axis.

What compression actually removes

Modern video codecs are block-based transform coders. Each block is predicted — from neighbouring pixels within the frame for an intra-coded block, or from a displaced region of a reference frame for an inter-coded one — and only the residual is transformed, quantised and entropy-coded. The quantisation step is the lossy part, and it discards the high-spatial-frequency coefficients first, because those are the ones the transform concentrates least energy in and the ones human vision is least sensitive to.

In H.264 the quantisation parameter runs from 0 to 51 and the step size doubles for every increase of 6, so QP 34 quantises eight times as coarsely as QP 16. The specification is published by the ITU as Recommendation H.264. x264’s constant-rate-factor control exposes the same scale, with a default CRF of 23 and a rough rule that each increase of 6 roughly halves the bitrate; the FFmpeg H.264 encoding guide documents it.

Three further losses are easy to forget because they are not controlled by the quality knob. Chroma subsampling at 4:2:0 stores colour at half resolution in each dimension before any quantisation happens, which matters for anything separating objects by colour. Rate control under a hard bitrate cap spends its budget on intra-coded frames and starves the predicted frames between them, so quality oscillates within each group of pictures. And reducing frame rate removes motion information entirely while leaving every still frame pristine, which is invisible to an appearance model and fatal to an action recogniser.

The saving, derived exactly

This half is pure arithmetic and it is exact. A stream at B megabits per second stores 3600 × B megabits per hour, which is 450 × B megabytes, or 0.45 × B gigabytes per hour. Take a 500-camera deployment recording continuously, with 30-day retention, and two candidate encodes.

per-hour storage:  0.45 x B GB

  6.0 Mbps  ->  2.70 GB/hour
  1.2 Mbps  ->  0.54 GB/hour

500 cameras x 24 h/day:

  6.0 Mbps  ->  500 x 24 x 2.70 = 32,400 GB/day
  1.2 Mbps  ->  500 x 24 x 0.54 =  6,480 GB/day

30-day rolling retention:

  6.0 Mbps  ->   972,000 GB resident
  1.2 Mbps  ->   194,400 GB resident

assumed object-storage price: $0.021 per GB-month

  6.0 Mbps  ->  $20,412 / month
  1.2 Mbps  ->   $4,082 / month

  saving    ->  $16,330 / month

The accuracy side, as a template

There is no equivalent derivation for accuracy, and any page that gives you one is inventing it. The relative drop depends on the task, the detector, the object sizes in your footage, the scene content and the encoder settings, and it is not transferable between deployments. What is transferable is the arithmetic that turns your own measurement into a decision.

Suppose you measure a baseline mean average precision of 0.82 on losslessly stored clips, and your own sweep produces relative drops of 1%, 5% and 15% at three encode settings. The placeholders below are assumptions to be replaced — they are not measurements and they are not typical values.

baseline mAP (measured on your own clips) : A0 = 0.82

  CRF 23  ~ 6.0 Mbps   relative drop 1%   ->  0.82 x 0.99 = 0.8118
  CRF 32  ~ 3.0 Mbps   relative drop 5%   ->  0.82 x 0.95 = 0.7790
  CRF 40  ~ 1.2 Mbps   relative drop 15%  ->  0.82 x 0.85 = 0.6970

accuracy given up moving from CRF 23 to CRF 40:

  0.8118 - 0.6970 = 0.1148 mAP

cost of keeping it, from the storage block above:

  $16,330 / month  /  0.1148 mAP  =  $142,200 per mAP point per month

That last line is the number the decision actually turns on, and it is the reason to do the sweep. If a point of mAP is worth less than about $142,000 a month to your business, the aggressive encode is correct. If the missed detections carry a liability, it is not. Nothing about the argument requires the drops above to be right; it requires them to be yours.

What degrades first

• Small objects and text. A licence plate 20 pixels tall occupies two and a half 8×8 transform blocks vertically. The character strokes are the highest-frequency content in the frame, so they are the first thing quantisation removes. A setting that keeps a face perfectly readable can leave a plate unrecoverable, which is why scene text recognition is the task that constrains the encode in most surveillance deployments.
• Fine motion. At low bitrate the encoder allocates few bits to predicted frames, so fast movement smears. Optical flow computed on such footage is systematically wrong, and anything built on flow inherits the error.
• Colour-based separation. Chroma subsampling plus coarse chroma quantisation collapses similar hues, which breaks appearance embeddings used for re-identification across frames.
• Scene-level classification, last. Whole-frame category prediction relies on low-frequency layout, which survives almost everything. If your only task is “is this an indoor scene”, compress freely.

There is one more effect that surprises people: a detector trained on clean images and evaluated on compressed ones is suffering a domain shift, not only an information loss. Fine-tuning on footage at the bitrate you will actually deploy recovers a meaningful part of the drop without any change to the encode, and it is usually the cheapest lever available. The video coding community treats this as a first-class problem — MPEG has an ongoing Video Coding for Machines activity aimed at codecs optimised for machine consumption rather than human viewing.

Measuring your own curve

The sweep is half an hour of work and it replaces every borrowed number on this page. Hold out a few hundred clips with ground-truth labels, encode each at several settings from one source, and score the same model on each.

for crf in 18 23 28 32 36 40; do
  ffmpeg -y -i source.mp4 -c:v libx264 -crf "$crf" -preset medium \
         -an "eval_crf$crf.mp4"
done

# record the delivered bitrate for each, do not assume it
ffprobe -v error -select_streams v:0 \
        -show_entries format=bit_rate -of csv=p=0 eval_crf32.mp4

Three things to get right. Encode from the original source every time, never by re-encoding an already-compressed intermediate, or you are measuring generation loss as well. Record the delivered bitrate with ffprobe rather than assuming the CRF-to-bitrate mapping above, which is content-dependent and varies by more than a factor of two between a static corridor and a busy street. And evaluate the whole pipeline, not the detector alone: a tracker that loses identity under compression costs you more than the per-frame mAP suggests.

Finally, decide the question before you sweep. “What bitrate should we use” has no answer; “what is the cheapest encode at which recall on plates under 25 pixels stays above 0.9” has one, and it is a different answer from the same question asked about faces. Pick the one task whose failure actually costs you something, set the acceptable floor on it first, and let every other task inherit whatever encode that constraint produces.