A camera streams 10-bit HEVC. The inference stage expects an 8-bit tensor. Nobody wrote code to bridge the gap, so the extra bit depth you paid decode cycles for gets quietly thrown away at exactly the camera zones where it mattered most. That is the whole problem in one sentence, and it is more common than it should be. The tempting way to think about 10-bit HEVC is as a quality dial — turn it up, get “better video.” That framing is not wrong so much as it hides the part that actually breaks pipelines. Bit depth is not a cosmetic property of the stream. It is an upstream input that changes what the decode stage produces and what the inference stage must accept. Treat it as a first-class, observable property of the capture-and-decode boundary and you get a maintainable pipeline. Treat it as a codec knob and you get one that silently degrades in low light, backlit doorways, and high-dynamic-range scenes — the exact conditions surveillance exists to cover. What does 10-bit HEVC actually change? HEVC (H.265) is the codec; bit depth is a separate axis. An 8-bit stream represents each luma (brightness) sample with 256 possible levels. A 10-bit stream uses 1024. That is a 4× increase in the number of distinguishable brightness steps per pixel, and it applies before any spatial compression the codec performs. Where those extra levels pay off is smooth gradients. When a scene has a slow brightness ramp — the wash of a streetlight across a wall, the sky behind a backlit entrance, the falloff of an IR illuminator across a dark car park — 8-bit runs out of levels to represent the transition. The result is banding: visible stair-steps where there should be a continuous gradient. Ten bits give the encoder enough headroom to keep those transitions smooth, so the same scene retains detail in shadows and near-clipped highlights that 8-bit flattens into blocks. For a human operator watching a monitor, this is a “nicer picture.” For a detection model, it is signal. A person standing in the dim edge of a frame is separated from the background by small brightness differences. If those differences fall below the quantization step of 8-bit encoding in that part of the tonal range, the contrast that a detector relies on simply is not in the pixels anymore. This is why bit depth belongs in the same conversation as confidence scores in computer vision — degraded input tone directly suppresses the confidence a model can assign to a marginal detection. 8-bit vs 10-bit HEVC: when does the extra depth earn its cost? The extra bit depth is not free, and it does not help every scene. In a well-lit, evenly exposed corridor, an 8-bit and a 10-bit stream will look nearly identical to a detector, because the tonal range in use is coarse enough that 256 levels cover it comfortably. The value shows up specifically where the tonal range is stretched — low light, high dynamic range, and gradual gradients. Here is the decision framing we use when a client asks whether a camera zone justifies 10-bit: Camera zone characteristic 8-bit adequate? 10-bit earns its cost? Even indoor lighting, controlled exposure Yes Marginal — rarely worth the decode overhead Backlit entrance (bright outside, dark inside) No — highlight/shadow detail clips Yes — recovers detail in both extremes Night / IR-illuminated with falloff gradients No — banding in the dim regions Yes — preserves low-contrast targets Wide dynamic range (glare + deep shadow) No — one exposure loses one end Yes — extra levels span the range Bandwidth- or compute-constrained edge node Depends Only if the challenging-lighting recall gain is measured, not assumed The honest answer is that 10-bit is worth it where you can observe a recall difference in the challenging zones — not everywhere by default. We treat this as a per-zone decision, not a fleet-wide policy, because paying 10-bit decode cost on evenly lit cameras buys nothing. How does 10-bit HEVC reduce banding in low-light surveillance? Banding is a quantization artifact. When a smooth gradient is stored with too few levels, adjacent pixels that should differ by a fraction of a level get rounded to the same value, and you see flat bands separated by hard steps. The number of available levels is exactly what sets the smallest brightness difference the format can preserve. Ten-bit encoding gives 1024 levels instead of 256, so the smallest representable brightness step is roughly a quarter of the 8-bit step (an observed-pattern consequence of the level count, not a fixed image-quality guarantee — actual banding depends on the scene and encoder settings). In practice, on the low-light and backlit footage we have profiled, the difference is most visible in the darkest quarter of the tonal range, which is precisely where night-time surveillance detail lives. The encoder can hold a gradient smooth through the shadows instead of collapsing it into blocks, and a detector working that region has real contrast to key on rather than quantization steps. This connects directly to how temporal CV pipelines process object detection in video: a tracker that loses a target for a few frames because banding suppressed detection in the dim edge of a frame will fragment the track, and fragmented tracks cascade into worse downstream counting and alerting. The failure that eats your fidelity: silent 8-bit downsampling The trap is not encoding 10-bit. It is what happens after decode. Many inference stages — and many of the preprocessing paths built around them — silently assume an 8-bit input tensor. When a 10-bit frame arrives, one of several things happens, none of them announced: The decode library outputs 8-bit by default because nobody set the output pixel format, discarding the two extra bits at the decode boundary. The frame decodes to a 10-bit surface, then a color-conversion or resize step (a cv2.cvtColor or an implicit uint8 cast) truncates it to 8-bit before the model sees it. The GPU decode path (NVDEC via FFmpeg or a hardware pipeline) is configured for an 8-bit surface format, so the extra depth never leaves the decoder. In every case you paid the higher decode cost — 10-bit HEVC decode is measurably more expensive per stream than 8-bit — and then threw the fidelity away before inference. You get the compute bill of 10-bit and the recall of 8-bit. This is the worst of both, and because it is silent, it survives code review, passes functional tests on well-lit clips, and only shows up as unexplained missed detections in the night footage months later. The fix is to make bit depth a testable property, not an assumption. A temporal video CV pipeline should log the pixel format at the decode boundary and assert the tensor dtype the model actually receives. If you designed the decode stage to emit 10-bit and the model consumes uint8, that mismatch should be an alert at deploy time, not a mystery at 2 a.m. Which observable metrics reveal that bit depth is being mishandled? You cannot fix what you do not measure. These are the signals we instrument at the capture/decode boundary to catch bit-depth mishandling before it becomes a recall problem: Decoded pixel format, logged per stream. If the source is 10-bit (e.g. yuv420p10le) but the decoded surface reads back as an 8-bit format, the extra depth was dropped at decode. This is the single most diagnostic check. Model input tensor dtype and range. Confirm the tensor the model receives spans the depth you intended. A tensor that maxes at 255 when it should span 1023 is a truncation fingerprint. Per-stream decode cost. A 10-bit stream that decodes at the same cost as 8-bit is suspicious — either the decoder is silently falling back to 8-bit output, or it is not doing what you configured. Recall delta on challenging-lighting zones. Track detection recall specifically on low-light and backlit cameras. A gap between those zones and well-lit ones, holding the model constant, is where bit-depth loss shows up in the numbers that matter. Track fragmentation rate. Rising track breaks concentrated on dim-scene cameras corroborates that inference is losing marginal detections upstream. Making these observable is the design discipline that separates a pipeline you can reason about from one you can only guess about. The same principle governs any production temporal pipeline: the properties that determine correctness should be measurable at the boundary where they enter, not inferred from failures at the end. What is the decode compute cost, and how does it hit throughput? Ten-bit HEVC decode is more expensive per frame than 8-bit. The extra samples widen the memory footprint per surface and the arithmetic in the reconstruction and in-loop filters. On the hardware and streams we have profiled, the practical effect is a lower sustainable per-decoder stream count at a given resolution and frame rate — you fit fewer 10-bit streams on the same GPU decode block or CPU budget than 8-bit (observed-pattern; the exact ratio depends on resolution, chroma subsampling, and whether decode is hardware-accelerated, so size it against your own hardware rather than a headline figure). The engineering consequence is that bit depth belongs in your capacity model. If a security-operations pipeline sizes per-camera throughput SLOs assuming 8-bit decode and then deploys 10-bit cameras, the decoder saturates earlier than planned, frames back up, and latency-sensitive alerting slips. For teams thinking about where decode and inference share a compute budget, this interacts with broader real-time detection throughput and cost planning — decode is not free headroom the inference stage can ignore. This is a good moment to point at where this work lives in practice. The teams designing observable, maintainable video pipelines around these boundaries are doing computer vision engineering work, where the decode/inference contract is an explicit design surface rather than an accident of default library settings. FAQ How does 10-bit HEVC work in practice? HEVC (H.265) compresses video; the “10-bit” part describes how many brightness levels each luma sample carries — 1024 versus 8-bit’s 256. In practice it means smoother gradients and less banding in scenes with a stretched tonal range, at the cost of a larger, more expensive decode. It is an upstream property of the stream that changes what the decode and inference stages downstream must handle, not a simple quality dial. What is the difference between 8-bit and 10-bit HEVC, and when does the extra bit depth actually matter for CCTV? Eight-bit gives 256 luma levels, 10-bit gives 1024 — four times the brightness resolution. The difference matters where the tonal range is stretched: low light, backlit entrances, IR-illuminated scenes with falloff, and wide dynamic range. In evenly lit, controlled scenes the two look nearly identical to a detector, so 10-bit earns its cost only where you can observe a recall gain in the challenging zones. How does 10-bit HEVC reduce banding and preserve detail in low-light or high-dynamic-range surveillance scenes? Banding is a quantization artifact: too few levels force a smooth gradient into visible stair-steps. Ten-bit encoding provides enough levels that the smallest representable brightness step is roughly a quarter of the 8-bit step, so gradients stay smooth through the shadows and near-highlights. That preserved contrast is exactly what a detection model keys on for marginal targets in dim or backlit frames. What is the decode compute cost of 10-bit HEVC compared to 8-bit, and how does it affect per-camera throughput? Ten-bit decode is measurably more expensive per stream — wider surfaces and heavier reconstruction — so you fit fewer 10-bit streams on the same GPU decode block or CPU budget. If throughput SLOs are sized assuming 8-bit and 10-bit cameras are deployed, the decoder saturates earlier than planned and latency-sensitive alerting slips. Bit depth therefore belongs explicitly in the capacity model, sized against your own hardware. How do I make sure my CV inference stage handles 10-bit input instead of silently downsampling to 8-bit? Make bit depth a testable property rather than an assumption: log the decoded pixel format per stream, assert the dtype and range of the tensor the model actually receives, and treat a mismatch as a deploy-time alert. Watch for silent truncation points — decode output format defaults, cvtColor/resize steps, and GPU decode surface formats configured for 8-bit. If the source is 10-bit but the tensor maxes at 255, fidelity is being discarded before inference. Which observable metrics at the capture/decode boundary reveal that bit depth is being mishandled? The most diagnostic is the decoded pixel format per stream — a 10-bit source that reads back as 8-bit dropped its depth at decode. Corroborate with model input tensor dtype/range, per-stream decode cost (10-bit that costs the same as 8-bit is suspicious), recall delta on challenging-lighting zones, and track fragmentation concentrated on dim-scene cameras. When is 10-bit HEVC worth the added decode and bandwidth cost for a security-operations pipeline? It is worth it on camera zones where you can measure a detection-recall gain in low-light, backlit, or high-dynamic-range conditions — and only there. Treat it as a per-zone decision, not a fleet-wide default, because paying 10-bit decode and bandwidth cost on evenly lit cameras buys no recall and just saturates your decoders earlier. Bit depth is the kind of pipeline property that is invisible right up until it is expensive. If you cannot point to the pixel format at your decode boundary and the dtype your model consumes, you do not yet know whether the fidelity you are paying for reaches the stage that needs it — and that unknown is the one that hides in the night footage.
