A surveillance camera streams 10-bit HEVC. Somewhere between the RTSP feed and the inference model, the frames become 8-bit. Nobody notices until the low-light detection rate quietly drops and the root-cause hunt starts at the model instead of the decode boundary where the loss actually happened. That is the failure this article is about. The naive view treats video format as a camera-side detail that ends once frames reach the model — pixels are pixels, and whatever the camera encodes will arrive at the tensor input unchanged. The expert view is that 10-bit HEVC changes the decode stage of a computer vision pipeline, and that stage is where bit depth, chroma subsampling, and hardware decoder support decide whether frames arrive intact, colour-accurate, and at the frame rate you expected. Understanding how 10-bit HEVC actually works is what lets an architect instrument that boundary rather than debug it blind. How does 10-bit HEVC actually work? HEVC (H.265) is a video compression standard. The “10-bit” part refers to bit depth: how many discrete levels each colour channel can represent. An 8-bit channel gives you 256 levels per channel; a 10-bit channel gives you 1024. That is four times the tonal resolution in each of luma and chroma. In practice, the extra bits matter most where tonal gradients are subtle and the signal is compressed into a small part of the range — shadows, backlit scenes, and high-contrast frames where a bright window sits next to a dark corridor. With 8 bits, those regions get quantised into coarse steps, and banding or crushed detail appears in exactly the areas a detector needs to resolve a figure. With 10 bits, the encoder has enough headroom to preserve that structure through compression. HEVC also does something 8-bit workflows sometimes skip: it lets encoders use the extra precision internally even when the source is nominally 8-bit, which reduces compression artefacts. But for CCTV the relevant case is a genuinely 10-bit sensor path, common now on cameras marketed for low-light or wide-dynamic-range scenes. The stream carries 10-bit samples end to end — provided nothing downstream throws the top two bits away. Why bit depth matters for CV detection in low-light or high-contrast scenes The reason this is a computer vision concern and not just a codec concern is that dynamic range and colour fidelity are precisely the inputs low-light and high-contrast detection depends on. A person standing in shadow is a low-contrast target; the discriminative signal is a handful of adjacent tonal steps. Quantise those steps too coarsely and the object stops being separable from the background — not because the model is weak, but because the information was destroyed before the model saw it. Correctly handling 10-bit HEVC at the decode stage preserves that dynamic range and avoids false-negative spikes in shadowed or backlit zones — an observed pattern in surveillance pipelines where the decode path silently downconverts, not a benchmarked rate. The failure is insidious because it is conditional: daytime, well-lit footage looks fine, benchmark clips look fine, and the regression only shows up on the exact frames the extra bit depth was there to protect. If you are already tracking how confidence scores behave in a computer vision pipeline, a decode-side bit-depth loss shows up as a per-camera confidence sag concentrated in low-light hours — a signature worth watching for. What is the difference between 8-bit and 10-bit HEVC in a CV pipeline? The difference is not just image quality in the abstract. It is what survives compression and reaches the tensor input. Aspect 8-bit HEVC 10-bit HEVC Levels per channel 256 1024 Tonal resolution in shadows Coarse; banding under compression Fine; gradients preserved Typical profile Main Main 10 Hardware decode support Near-universal Common on recent GPUs/SoCs, not guaranteed CV risk Banding masks low-contrast targets Silent downconversion to 8-bit if decode path lacks Main 10 Storage / bandwidth Lower Higher (roughly 20–25% more, configuration-dependent) The bandwidth column carries a caveat: the overhead depends on scene complexity, encoder settings, and target bitrate, so treat “roughly 20–25%” as a planning heuristic rather than a fixed figure. The row that causes production incidents is the decode-support row. When a decoder that only implements Main receives a Main 10 stream, one of three things happens: it refuses the stream, it falls back to a software path with a frame-rate penalty, or — worst for CV — it silently downconverts to 8 bits and hands you visually plausible frames that have quietly lost the precision you were paying for. Which HEVC profiles do CCTV cameras and decoders actually support? HEVC organises capabilities into profiles. Three matter for surveillance: Main — 8-bit, 4:2:0 chroma. Universally supported; the safe default and the source of most silent-downconversion incidents when the camera sends more. Main 10 — up to 10-bit, 4:2:0. This is what a 10-bit CCTV camera typically streams. Hardware decode is common on recent NVIDIA (NVDEC), Intel (Quick Sync), and mobile SoC decoders, but you cannot assume it. Main 4:2:2 10 — 10-bit with 4:2:2 chroma subsampling. Less common in fixed CCTV, more in professional capture, and the least likely to have hardware decode on a given box. Mismatches cause silent conversions because the negotiation is not always loud. A pipeline built on FFmpeg or GStreamer will happily select a software decoder or an 8-bit output format if the requested hardware path is unavailable, and unless you explicitly inspect the negotiated pixel format, the substitution is invisible. The same class of profile-support reasoning applies on the encode side — the x265 encoder’s profile and bit-depth flags decide what the stream claims to be, and a mismatch between what x265 produced and what your decoder implements is exactly where the conversion sneaks in. How does chroma subsampling (4:2:0 vs 4:2:2) affect what the inference stage sees? Bit depth is one axis; chroma subsampling is a second, orthogonal one. Subsampling stores colour (chroma) at lower spatial resolution than brightness (luma), because human vision is more sensitive to luminance detail. 4:2:0 halves chroma resolution both horizontally and vertically; 4:2:2 halves it only horizontally, keeping full vertical chroma resolution. For most surveillance detection tasks, luma carries the load and 4:2:0 is adequate. Where 4:2:2 earns its cost is any task that leans on colour edges — license-plate colour discrimination, clothing-colour re-identification, or fine chroma boundaries in reflective or coloured-lighting scenes. The subtle trap: when the decoder converts colour formats to feed a model that expects RGB, a 4:2:0-to-RGB upsample interpolates chroma it never had. That interpolation is usually fine, but if a downstream stage assumes full-resolution chroma, the mismatch is another silent-fidelity issue hiding in the decode path. This is the same “what actually reaches the tensor” discipline that matters for how temporal CV pipelines process video frames in production — the frame the model receives is a decode artefact, not the raw stream. How do I make the decode stage observable? The whole point of understanding 10-bit HEVC is that it lets you instrument the capture/decode boundary instead of debugging blind. A modular pipeline whose capture and decode stages are independently observable turns a multi-day root-cause hunt into an hours-long one, because the format assumption is checked where it is made rather than inferred from a downstream quality metric. Here is a decode-path check you can run at pipeline bring-up and on every camera-firmware or driver change: Inspect the stream’s declared profile. Probe the RTSP/RTP stream (FFprobe reports profile and pix_fmt) and record whether it is Main, Main 10, or Main 4:2:2 10. This is the contract the camera claims. Inspect the negotiated decoder output format. Do not trust the request — log the actual output pix_fmt your decoder produced (p010 / yuv420p10le for 10-bit; nv12 / yuv420p for 8-bit). A Main 10 input with an 8-bit output pixel format is a silent downconversion, caught. Confirm the decode path is the one you intended. Log whether NVDEC / Quick Sync / a software fallback served the frame, and the sustained decode frame rate per camera. A software fallback under a Main 10 stream is both a fidelity and a throughput risk. Assert bit depth at the tensor boundary. Check the dtype and value range entering the model. Frames that were 10-bit at the sensor but arrive as 8-bit tensors localise the loss to the decode stage, not the model. Watch per-camera confidence by time-of-day. A downconversion signature is a low-light confidence sag on specific cameras; wire this into your monitoring so the regression is an alert, not a discovery. Each of these is cheap to add at the decode boundary and expensive to reconstruct after the fact. That asymmetry is the entire argument for instrumenting the stage up front. We build vision systems this way as a matter of course, and the pattern generalises well beyond HEVC — any point where an upstream assumption can be silently violated deserves an observable checkpoint. The broader engineering approach sits within our computer vision practice, where the capture and decode stages are treated as first-class, independently observable parts of the pipeline rather than a black box in front of the model. What performance and hardware-decoder trade-offs does 10-bit HEVC introduce? Nothing here is free. 10-bit Main 10 decode is more work than 8-bit Main, and the trade-offs land at the capture and decode boundary — the busiest part of a multi-camera pipeline. Decode cost. 10-bit hardware decode is heavier than 8-bit, and a software fallback is dramatically heavier. On a box aggregating dozens of camera streams, a handful of streams silently falling back to software can saturate CPU and starve the rest — a throughput failure that presents as dropped frames, not a decode error. Bandwidth and storage. The roughly 20–25% overhead noted earlier (a configuration-dependent planning heuristic, not a fixed figure) multiplies across every camera and every day of retention. Memory format. 10-bit frames use wider pixel formats (p010, 16 bits per sample stored), increasing decode buffer footprint and the cost of any colour conversion feeding the model. The right decision is not “always use 10-bit” or “always downconvert to save cost.” It is: decide per deployment whether the scenes you actually run in — low-light, high-contrast, colour-critical — justify the decode budget, and once you decide, make the decision observable so it cannot be silently reversed by a driver update or a camera-firmware change. The decode-format check above is what turns an intended trade-off into an enforced one. FAQ How should you think about 10-bit HEVC in practice? 10-bit HEVC (H.265) encodes each colour channel with 1024 levels instead of the 256 an 8-bit channel provides — four times the tonal resolution in luma and chroma. In practice that extra headroom preserves subtle gradients through compression, which matters most in shadows, backlit scenes, and high-contrast frames where 8-bit quantisation would produce banding or crushed detail. The stream carries 10-bit samples end to end, provided nothing in the decode path discards the extra precision. What is the difference between 8-bit and 10-bit HEVC, and why does bit depth matter for CV detection in low-light or high-contrast CCTV scenes? 8-bit HEVC (Main profile) gives 256 levels per channel; 10-bit (Main 10) gives 1024. Bit depth matters for detection because a target in shadow is a low-contrast object whose discriminative signal is a few adjacent tonal steps — quantise those too coarsely and the object stops being separable from the background before the model ever sees it. The result is false-negative spikes concentrated in exactly the low-light and backlit frames the extra bit depth was meant to protect. Which HEVC profiles (Main, Main 10, Main 4:2:2 10) do CCTV cameras and hardware decoders actually support, and how do mismatches cause silent conversions? Main (8-bit, 4:2:0) is near-universally supported; Main 10 (10-bit, 4:2:0) is common on recent NVIDIA NVDEC, Intel Quick Sync, and mobile SoC decoders but not guaranteed; Main 4:2:2 10 is least likely to have hardware decode on a given box. Mismatches cause silent conversions because pipelines built on FFmpeg or GStreamer will quietly select a software decoder or an 8-bit output format when the requested hardware path is unavailable — the substitution is invisible unless you inspect the negotiated pixel format. How do I make the decode stage of a CV pipeline observable so a 10-bit-to-8-bit downconversion is caught before it degrades model quality? Log four things at the decode boundary: the stream’s declared profile, the decoder’s actual negotiated output pixel format, which decode path (NVDEC/Quick Sync/software) served each frame, and the dtype and value range at the tensor input. A Main 10 stream that produces an 8-bit output format, or a 10-bit sensor path that arrives as an 8-bit tensor, is a silent downconversion caught at the boundary rather than inferred days later from a quality metric. Complement this with per-camera confidence tracking by time-of-day, since a downconversion signature is a low-light confidence sag on specific cameras. What performance and hardware-decoder trade-offs does 10-bit HEVC introduce at the capture and decode boundary? 10-bit Main 10 decode is heavier than 8-bit Main, a software fallback is dramatically heavier, and 10-bit frames use wider pixel formats (p010) that increase buffer footprint and colour-conversion cost. On a box aggregating many streams, a few silently falling back to software can saturate CPU and cause dropped frames elsewhere; bandwidth and storage rise by roughly 20–25% (a configuration-dependent planning heuristic). The right call is to decide per deployment whether low-light, high-contrast, or colour-critical scenes justify the decode budget — and then make that decision observable so a driver or firmware update cannot silently reverse it. How does chroma subsampling (4:2:0 vs 4:2:2) in a 10-bit HEVC stream affect what the inference stage sees? 4:2:0 halves chroma resolution both horizontally and vertically; 4:2:2 halves it only horizontally, keeping full vertical chroma detail. For most detection tasks luma carries the load and 4:2:0 is adequate, but colour-critical work — plate-colour discrimination, clothing-colour re-identification, fine chroma boundaries — benefits from 4:2:2. The subtle trap is that converting 4:2:0 to the RGB a model expects interpolates chroma that was never captured, so any downstream stage assuming full-resolution chroma inherits a silent-fidelity mismatch hiding in the decode path. The question worth carrying out of this is not “should we use 10-bit HEVC” but “where in our pipeline does an upstream format assumption go unchecked” — because a silent 10-bit-to-8-bit conversion is one instance of a class, and the pipeline observability audit is where that class of decode-boundary failure gets caught before it reaches the model.
