A camera records in 10-bit HEVC. The stream lands on a decode node, gets converted to a frame buffer, and is handed to a detection model. Somewhere in that chain, the extra tonal detail 10-bit was meant to preserve may already be gone — and nobody set out to throw it away. It happened silently, in a transcode step or a color-conversion default that someone chose for convenience two deployments ago. That is the real problem with 10-bit HEVC in video analytics: it is treated as a storage-and-bandwidth setting, when it is actually a decision about what a model can see. Bit depth sits upstream of the false-alarm rate. If you crush shadows and blow highlights before inference, you hand the detector a harder image than the sensor captured — and you pay for that in misclassifications the model has no way to avoid. What does 10-bit HEVC actually encode? HEVC (H.265) is a video codec. “10-bit” refers to the number of bits used to represent each color channel per pixel — not to the codec’s compression efficiency, and not to resolution. An 8-bit channel stores 256 possible values (0–255); a 10-bit channel stores 1,024 (0–1023). That is four times the tonal granularity per channel, which in a YUV 4:2:0 stream (the common surveillance layout) means far finer gradation in the luma plane where most detection signal lives. The extra values do not make the image “brighter” or “sharper” in the naive sense. They reduce quantization steps between adjacent tones. In a scene with a smooth gradient — a dim car park at dusk, a corridor lit by a single fixture — 8-bit encoding forces neighbouring shades into the same bucket. The visible result is banding. The invisible result, for a detection model, is that texture and edge information in near-black and near-white regions gets flattened before the network ever sees it. Three facts are worth stating plainly, because they get conflated constantly: 10-bit and 8-bit HEVC are both H.265; the difference is the pixel format (yuv420p10le versus yuv420p), not the codec (observed across video pipelines we've built; not a codec-spec claim). Higher bit depth is a tonal-precision choice, independent of resolution and frame rate. A 1080p 10-bit stream and a 1080p 8-bit stream have the same pixel count. The benefit concentrates in high-dynamic-range and low-light content. In a flat, well-lit, mid-tone scene, the extra bits carry almost no additional detection-relevant signal. Why 8-bit conversion hurts detection where it matters The place bit depth changes outcomes is the tail of the tonal range — deep shadow and bright highlight. This is also where a large share of scene-driven false positives concentrate in surveillance analytics. A detector that keeps firing on shadows moving across a wall at night, or on the bloom around a bright light source, is often reacting to noise that 8-bit quantization has amplified. Here is the mechanism. When a 10-bit source is downconverted to 8-bit, the 1,024 luma levels are mapped onto 256. In the shadows, dozens of distinct near-black values collapse into a handful. A subtle edge — the boundary between a person and the dark background behind them — that was represented by a smooth 10-bit ramp becomes a hard step or disappears entirely. The model now has to distinguish object from background using less information than the sensor actually captured. Under conditions like a poorly lit loading bay at 3am, that missing gradation is exactly the signal that separates a real intrusion from a passing shadow. None of this helps if the detail never survives to inference. And that is the part teams miss. How does a pipeline accidentally discard 10-bit detail? The stream can be perfectly 10-bit end to end on paper and still be 8-bit by the time the model runs. The loss happens at one of a small number of well-known choke points, and each one is easy to introduce by accident. Stage How the loss happens How to check Transcode / re-encode A pipeline normalises all inputs to yuv420p (8-bit) for “compatibility” before storage or inference Inspect the intermediate stream: ffprobe should report yuv420p10le, not yuv420p Hardware decode Some decode paths (older NVDEC profiles, certain fixed-function blocks) return an 8-bit surface even from a 10-bit bitstream Confirm the decoder’s output surface format, not just that decode “works” Color conversion The cvtColor / RGB conversion feeding the model casts to uint8, truncating 10-bit luma to 8-bit before the tensor is built Check the dtype of the array handed to the model — uint8 means the detail is already gone Model input contract The network was trained and exported expecting 8-bit RGB, so even a 10-bit frame is quantized at the input layer Confirm the model’s preprocessing normalisation range and input dtype The pattern we see most often is the third one. A team keeps a genuinely 10-bit ingest and archive, feels good about the storage decision, and then feeds the detector through an OpenCV cvtColor call that produces an 8-bit array. Every downstream frame the model sees is 8-bit. The bandwidth was spent; the analytics benefit was discarded in one line of preprocessing. Verifying this is not glamorous, but it is decisive. Trace the dtype from decode to tensor. If any stage in the object-detection path casts to uint8, the bit depth your archive preserves is not the bit depth your model uses. Our walkthrough of how temporal CV pipelines process video in production covers where these decode-and-preprocess stages sit relative to the detector, which is useful context when you go looking for the leak. The bandwidth and decode-cost trade-off 10-bit is not free, and pretending otherwise is how it ends up over-specified. Two costs matter. Bandwidth and storage: 10-bit HEVC typically adds on the order of 20–30% to bitrate versus 8-bit at comparable perceived quality (observed range across the encodes we've profiled; not a benchmarked figure — it varies with content and encoder settings). For a large camera estate, that is a real line item. Decode cost: 10-bit decode is more expensive than 8-bit, and the hardware path matters. Modern NVDEC and equivalent fixed-function decoders handle 10-bit HEVC in hardware, but the moment you fall back to software decode — or a profile the hardware does not accelerate — the CPU cost per stream rises and your per-node stream density drops. On an edge box counting streams-per-watt, that can be the difference between one node and two. The encoder side of this trade-off, and where x265’s rate-control decisions land, is covered in how the x265 codec handles HEVC encoding. So the honest framing is a conditional one, not a blanket recommendation. When 10-bit HEVC earns its cost — a quick rubric Worth it: HDR or wide-dynamic-range cameras; frequent low-light operation; scenes where false alarms concentrate in shadows or highlights; a decode-and-inference chain you have confirmed preserves 10-bit end to end. Marginal: Mid-tone, evenly-lit indoor scenes; models trained and exported for 8-bit input with no plan to retrain; estates where decode density is the binding constraint. Overkill: Any pipeline that transcodes or cvtColor-casts to 8-bit before inference — you are paying full 10-bit bandwidth for an 8-bit analytics result. Fix the leak first, then decide whether the bit depth is worth keeping. That last row is the one that catches people. If your model input contract is 8-bit and there is no roadmap to change it, 10-bit ingest is bandwidth spent for no detection benefit. The decision to record in 10-bit and the decision to feed 10-bit to the model are separate decisions, and both have to be true for the bandwidth to pay off. How bit depth interacts with camera and scene choices Bit depth does not act alone. It is one variable in the set of upstream choices that shape the false-positive rate — sensor dynamic range, exposure and gain control, lens flare behaviour, IR-cut switching at dusk, and codec settings all feed the same downstream detector. Treating any one of them as an isolated storage or hardware knob is the error. A camera with strong wide-dynamic-range sensing benefits most from 10-bit encoding, because it captures a tonal range 8-bit encoding cannot represent without clipping. Pair a WDR sensor with 8-bit HEVC and you throw away the tonal detail the sensor worked to capture. Pair a low-dynamic-range camera with 10-bit HEVC and you spend the bandwidth on precision the sensor never produced. The bit depth should match what the sensor and scene actually deliver, and the model should be able to consume it. This is why we treat bit depth as part of the scene-and-camera reasoning that drives false alarms, not as a codec footnote. The verification stage that catches scene-driven misclassifications only helps if the inputs reaching it carry the detail those scenes contain. Correct bit-depth handling is a prerequisite for that verification to do its job — it does not replace it. You can see the broader system context on our [computer vision practice page](computer vision), which frames where ingest and preprocessing sit relative to the rest of a production analytics pipeline. The same site’s home page points to the surrounding engineering work. FAQ What should you know about 10 bit hevc in practice? 10-bit HEVC is H.265 video where each color channel is stored with 10 bits (1,024 levels) instead of 8 (256). In practice it preserves finer tonal gradation — especially in shadows and highlights — which reduces banding and retains edge and texture detail that 8-bit quantization flattens. It is a pixel-format choice (yuv420p10le), independent of resolution and frame rate. What is the difference between 8-bit and 10-bit HEVC, and when does the extra bit depth actually matter? Both are the same codec; the difference is 256 versus 1,024 tonal levels per channel. The extra bit depth matters in high-dynamic-range and low-light scenes, where 8-bit forces neighbouring near-black or near-white tones into the same bucket. In flat, evenly-lit mid-tone scenes the difference carries almost no detection-relevant signal. Does 10-bit HEVC improve detection accuracy in low-light or high-dynamic-range surveillance scenes? It can, but only if the 10-bit detail survives to inference. In shadow- and highlight-heavy scenes — where scene-driven false alarms concentrate — preserving tonal gradation gives the detector more information to separate real objects from noise. If the pipeline downconverts to 8-bit before the model runs, there is no accuracy benefit regardless of how the stream was recorded. What are the bandwidth, storage, and decode-cost trade-offs of 10-bit HEVC versus 8-bit? 10-bit HEVC typically adds on the order of 20–30% to bitrate at comparable perceived quality, and it is more expensive to decode. Hardware decoders handle 10-bit HEVC, but a software or unaccelerated fallback raises CPU cost per stream and lowers per-node stream density. On edge nodes constrained by decode throughput, that density hit can be the binding cost. How can a video-analytics pipeline accidentally discard 10-bit detail before inference, and how do I prevent it? The detail is lost at transcode, hardware decode, color conversion, or the model’s input contract — most commonly a cvtColor/RGB cast to uint8 in preprocessing. Prevent it by tracing the dtype from decode to tensor: ffprobe should show yuv420p10le, and the array handed to the model must not be uint8. If any stage casts to 8-bit, the bit depth your archive keeps is not the one your model uses. How does bit depth interact with scene and camera choices that drive false positives? Bit depth is one of several upstream variables — sensor dynamic range, exposure, gain, codec settings — that jointly shape the false-positive rate. A wide-dynamic-range sensor benefits most from 10-bit; a low-dynamic-range camera gains little from it. Match the bit depth to what the sensor and scene actually deliver, and confirm the model can consume it. When is 10-bit HEVC overkill for a video-analytics deployment? It is overkill whenever the pipeline transcodes or casts to 8-bit before inference — you pay full 10-bit bandwidth for an 8-bit analytics result. It is also marginal for mid-tone, evenly-lit indoor scenes and for models fixed at an 8-bit input contract with no plan to retrain. Fix any preprocessing leak first, then decide whether the bit depth is worth keeping. The number that actually decides this The useful question is not “should we use 10-bit HEVC?” It is “does the tonal detail we are recording survive all the way to the model, and does our sensor and scene actually produce detail worth preserving?” Both have to hold. When they do, correct bit-depth handling removes a class of shadow-and-highlight false alarms at the input, before any verification stage has to work around them. When they do not, 10-bit is bandwidth spent on precision the model never sees. If you are unsure which side of that line your deployment sits on, the first artifact to reach for is an ingest-and-preprocessing audit — the A2 Production CV Readiness Assessment checks whether your decode and preprocessing chain preserves the bit depth your detection models actually need, or quietly downconverts 10-bit HEVC to 8-bit before inference. That is the failure class this whole discussion is about: silent bit-depth loss between the archive and the tensor.
