Axis Communications’ white paper, Bitrate control for IP video, explains that encoded video must fit finite network and storage capacity. The bitrate controller watches the amount of generated data and adjusts compression according to a selected strategy. That strategy affects whether changing scene complexity appears as changing storage use or changing image quality.
\nVariable bitrate (VBR) prioritizes consistent quality and allows bitrate to rise when the scene becomes complex. Its central risk is unpredictable storage consumption. Motion, rain, foliage, low-light noise, crowds, or other changes can make the same camera generate much more data than a quiet planning sample.
\nMaximum bitrate (MBR) keeps average bitrate below a configured limit, allowing only temporary overshoot. If the scene needs more data than the limit permits, the encoder increases compression without regard to the evidence the operator needs. Axis warns that a low cap can remove forensically relevant detail, especially as the gap between scene demand and the limit grows.
\n\nAverage bitrate (ABR) treats retention and allocated storage as a budget over time. Unused capacity from quiet periods can support temporarily higher bitrate during busy periods while the controller works toward the long-term target. Axis describes ABR with a carefully chosen maximum limit as a useful combination for many continuously recorded systems because it can protect storage while permitting temporary bitrate peaks and reporting degradation events.
\nBitrate also depends on codec, resolution, frame rate, compression, group-of-pictures length, image processing, stabilization, night exposure, noise, lighting, and what moves in the view. A longer GOP can reduce storage but make random access slower. A calculation based only on resolution and frame rate therefore cannot prove either retention or usable evidence.
\n\nDefine the recorded task at marked locations: detection, recognition, identification, transaction review, object detail, or another operational need. Capture representative clips using the proposed camera, lens, production codec, and VMS. Include daylight, darkness, rain or snow where relevant, headlights, busy movement, empty periods, and the noisiest expected low-light condition.
\nHave the intended users retrieve, play, pause, digitally zoom, and export those clips through the normal workstation. Approve the lowest quality that still performs the written task. A vendor preview or live main stream does not validate the recorded stream.
\n\nUse VBR when forensic quality is the priority and the network and storage have measured headroom. Use a maximum limit only when a real path or recorder constraint requires it, and set the limit from passing high-complexity clips rather than a low default. Use ABR only where the camera, VMS, recording pattern, and monitoring support its behavior; confirm that scheduled gaps or event-only recording do not invalidate the assumptions.
\nDocument codec, stream, resolution, frame rate, GOP, compression, bitrate mode, target, maximum, retention, measured range, test scene, and approver. Treat changes to WDR, noise reduction, stabilization, exposure, analytics overlays, or field of view as capacity changes that require review.
\n\nAlert when projected retention falls below policy and when the encoder must degrade quality to meet its budget. Review samples from the highest-bitrate hours and the darkest hours, not merely the average day. Periodically perform a timed retrieval and export from the oldest expected footage.
\nThe successful configuration makes two statements true at once: the system retains the required duration, and the most demanding recorded event still contains the detail the requirement promised. Meeting only the storage number is not video-system acceptance.
\n\n