Retention Shortfall After a Codec Decision
A retail chain has 40 cameras across 3 stores recording to a central NVR. Design assumed H.265 at an average 2 Mbps per camera, 24/7, with 60 TB usable storage for 60-day retention. After go-live, the storage calculator shows only 38 days achieved. Investigation finds 12 older cameras only support H.264, motion-heavy aisles push peak bitrates well above average, and audio is enabled on all cameras. The customer's insurer requires 60 days.
1. Explain the gap and list remediation options in order of cost/impact.
Read the worked answer
The design used an optimistic average. Reality:
- 12 H.264 cameras consume more than the H.265 assumption.
- Busy aisles push VBR peaks above the 2 Mbps average, so real average is higher.
- Audio adds a small but nonzero bitrate on every stream.
Options, cheapest first:
- Trim waste: disable audio where not needed, cap max bitrate with VBR ceilings, reduce frame rate on low-value cameras (stockroom, back-of-house), and confirm no camera is streaming higher than necessary.
- Re-encode/dual-stream: record a right-sized stream rather than the highest; ensure recording uses the efficient profile.
- Replace the 12 H.264 cameras with H.265 models - biggest structural gain but capital cost.
- Add storage to close the remaining gap.
Recalculate retention with measured bitrates (not design assumptions) after each step and present the insurer-compliant path.
2. How do you prevent this class of error in future designs?
Read the worked answer
Base storage sizing on measured bitrate per camera under real scene load, including peaks and night noise, not on datasheet averages. Account for codec mix explicitly (list which cameras are H.264 vs H.265), include audio overhead, and add a safety margin. Validate with a pilot recording before committing to a retention SLA, and re-verify after any camera or firmware change.