10-Bit HEVC vs HEVC: Checking Decode Support in CCTV CV Pipelines

A 10-bit HEVC stream (the Main 10 profile) only helps a computer vision pipeline if every stage between the camera and the model keeps all ten bits. You find out whether your decoders really handle 10-bit HEVC by querying the decoder you actually run and checking the output format at each hand-off, not by trusting a spec sheet. NVIDIA’s own decoder guide recommends exactly that: query the hardware capabilities and decide based on what is present.

Decode is one stage among several and deserves the same per-stage instrumentation for camera pipelines: when low-light detection quietly drops, you want to know whether the frames arrived intact before anyone starts retraining the model.

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?

The Main 10 profile allows 8 to 10 bits per sample with 4:2:0 chroma sampling, and any decoder that conforms to Main 10 must also decode plain Main bitstreams. In the bitstream, the ATSC 3.0 video standard requires each sequence parameter set (SPS) to set bit_depth_luma_minus8 and bit_depth_chroma_minus8 both to 0 or both to 2, meaning 8-bit or 10-bit with identical luma and chroma depth. Main 10 was part of the first approved HEVC version in April 2013, alongside Main and Main Still Picture.

The difference is the number of intensity levels. Eight bits per sample gives 256 shades per primary colour, about 16.78 million colours in total, while ten bits gives 1,024 shades per primary, about 1.07 billion colours.

Resolution and bit depth are independent properties: “1080p” is the frame size and “10-bit HEVC” says the stream was encoded with 10 bits per sample, almost always as Main 10. It is not sharper than 1080p. It holds finer gradations of tone at the same resolution, and that only matters if the decoder and everything downstream preserve them.

How does 10-bit HEVC reduce banding and keep detail in low-light or high-contrast scenes?

A higher bit depth gives smoother tonal transitions, which is what removes colour banding.

A 2019 study on camera parameters and network generalisation (arXiv 1912.03604) measured this at the sensor level: on raw sensor data without demosaicing, detection on 8-bit data reached an [email protected] of 0.38, and 10-bit quantisation raised it to 0.79. The authors show why: the 8-bit camera lacked the intensity resolution to separate a car from its surroundings, and the 10-bit camera did not. That study quantised raw sensor data rather than decoding an HEVC stream, so treat it as evidence that the levels matter, not as a figure for your codec chain.

The x265 documentation recommends adaptive quantisation for 8-bit encodes and for low-bitrate 10-bit encodes, to prevent colour banding and blocking. A 10-bit stream starved of bitrate can still band, and that is worth knowing before you blame the decoder.

Main, Main 10 and 4:2:2 10: what each HEVC hardware decoder accepts

HEVC profiles are contracts. An encoder may use any subset of a profile’s coding tools, but a decoder for that profile must support every tool the profile allows. The table below summarises what matters at the decode boundary.

Hardware support arrived unevenly. NVIDIA’s GeForce GTX 960, released in January 2015, carried the first full fixed-function HEVC Main/Main10 hardware decoder in a discrete graphics card. Intel’s Skylake processors (August 2015) had full fixed-function Main decoding but only hybrid or partial Main10 decoding, and full fixed-function Main10 decoding came with Kaby Lake, announced in August 2016. Intel’s support documentation says graphics on 9th-generation Core processors and older were limited to HEVC 4:2:0 for hardware encoding and decoding.

On the NVIDIA side, the NVDECODE API lists HEVC Main, Main10 and Main12, with Main 4:2:2/4:4:4 10/12 support (excluding YUV400) depending on the GPU. The NVDECODE guide’s per-generation entries range from Main10 and Main12 up to Level 6.0, through added 4:4:4 chroma support, to the full Main 4:2:2/4:4:4 10/12 set. Read that carefully: only some entries list Main 4:2:2 10, so a 4:2:2 10-bit stream should be checked by capability query rather than assumed.

What happens on a device that lacks the profile? The documented outcomes include decoder creation failing, a fall back to software decoding, or output in a format different from the input. Jellyfin’s documentation describes the fallback case: partial GPU acceleration leads to higher CPU usage and lower transcoding speed. Read the profile from the stream itself: ffprobe reports the codec profile and pixel format for the first video stream.

How does 10-bit HEVC compare with 10-bit H.264 and 10-bit AV1 on bitrate, quality and device reach, and why does the answer depend on the content and device mix?

On bitrate, HEVC can achieve 25% to 50% better compression than H.264 at the same quality. One April 2013 comparison at 3840×2160 put HEVC Main and Main 10 against H.264 High and High 10 and found an average PSNR-based bitrate reduction of 45% for inter-frame video. Those figures come from the HM-10.0 and JM-18.4 encoders on 3840×2160 sequences, not from your CCTV footage.

Hardware decoder support is where 10-bit H.264 loses. Jellyfin’s documentation states that no Intel, NVIDIA or AMD GPU supports hardware decoding of H.264 High 10, which only Apple Silicon and Rockchip handle, and it recommends moving such video to HEVC Main 10.

NVIDIA’s FFmpeg guide says AV1 offers better compression than HEVC but advises checking platform compatibility, and NVDEC lists AV1 among its supported codecs. Our sources give no measured 10-bit AV1 versus 10-bit HEVC figure on surveillance content, so the honest answer is that it depends on three things: whether your cameras emit AV1 at all, whether every decoder in the chain (edge box, VMS, inference server) has AV1 10-bit in hardware, and whether the bitrate saving matters more than the reach you give up.

Chroma subsampling in a 10-bit HEVC stream: 4:2:0 versus 4:2:2

What 4:2:0 versus 4:2:2 changes for the inference stage

A pixel format string such as yuv420p10le encodes the colour space, the chroma subsampling, the planar layout and the bit depth; 4:2:2 keeps half the horizontal chroma and 4:2:0 keeps a quarter of the chroma data of 4:4:4. Main 10 constrains colour subsampling to 4:2:0, so most 10-bit camera streams carry full-resolution luma with chroma at half resolution in both directions.

For detection, that usually matters less than bit depth. 4:2:0 keeps luma at full resolution and cuts only the chroma. Chroma resolution starts to matter when the task depends on colour at small scales: a high-visibility vest at distance, a vehicle colour, a coloured warning light. There a 4:2:2 source would hold more, if the decoder supports it. The trap is the conversion step.

How 4:2:2 10-bit fits broadcast and contribution workflows

In broadcast, contribution feeds are 4:2:2 10-bit and distribution formats 4:2:0 10-bit. NVIDIA’s FFmpeg guide describes converting P210 (4:2:2 10-bit) contribution feeds to P010 (4:2:0 10-bit) on the GPU as a common broadcast workflow. Software encoders will not do that conversion for you: x265 requires the input chroma subsampling to match the output, performs no chroma conversion, and needs a profile that supports it. When a contribution feed lands in an analytics pipeline, the question is therefore which stage performs the 4:2:2 to 4:2:0 step and whether it keeps 10 bits while doing it.

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?

Make the decode stage observable by asserting the bit depth at each hand-off and logging it per camera, so a conversion shows up as a changed value in a log rather than as a drift in model confidence weeks later. This is the reason we prefer modular, observable pipelines over end-to-end systems: when something breaks, you need to know where and why.

NVIDIA’s decoder guide notes that decoder output usually matches the input bit depth and subsampling, but can be configured to differ, and advises checking that the desired output format is supported before creating the decoder. Through FFmpeg, NVDEC writes NV12 for yuv420p input. A re-encode without an explicit -pix_fmt lets FFmpeg pick the encoder’s preferred format.

Decode-boundary checklist

1. Read the source. Use ffprobe to read the stream’s codec profile and pixel format and record them; yuv420p10le means 10-bit 4:2:0.
2. Query the decoder, not the datasheet. With the NVDECODE API, call cuvidGetDecoderCaps() with nBitDepthMinus8 set to 2 for 10-bit, and check that nOutputFormatMask includes P010.
3. Request the 10-bit output format explicitly. An unsupported output format makes decoder creation fail with CUDA_ERROR_NOT_SUPPORTED, which is the loud failure you want.
4. Log decoder status. NVDEC decode status queries are supported for HEVC on Maxwell and newer GPUs, though the decoder detects only a limited number of errors.
5. Watch the luma histogram. NVDEC can collect luma histogram data during decoding at no performance cost, before any scaling or cropping.
6. Assert at the model input. Check the tensor’s dtype and value range per camera at least once per session, and alert when it changes.

How do I make sure the inference stage handles 10-bit input instead of silently downsampling to 8-bit?

Silent downsampling also happens in ordinary code: an image library that loads into uint8, a resize that casts, a normalisation that divides by 255 on data that was never 8-bit. Carry frames as 16-bit containers (or float) from decode to the first model layer, and check that the scaling in preprocessing matches how the decoder packs its 10-bit samples.

There is a second half to this that teams miss. The same 2019 generalisation study found that a network trained on 10-bit data scored 0.71 when evaluated on 16-bit data, and one trained on 16-bit scored 0.68 on 10-bit, concluding that the network uses the number of levels as an important signal. A model trained on 8-bit footage and suddenly fed 10-bit frames is a distribution shift, not a free upgrade, so a move to 10-bit decode belongs alongside a retraining or fine-tuning plan and a before-and-after evaluation on your own low-light clips.

How do I check our GPU servers’ compute capability, VRAM and driver against a vendor’s minimums?

Read the three values directly from each server, compare each with the vendor’s documented minimum, and record a pass or fail per requirement. The values are a short command away: nvidia-smi reports GPU name, total memory and driver version, and the CUDA deviceQuery sample reports compute capability. Compare per server, not per model number, because two machines with the same GPU can run different drivers.

The verdict depends on which requirement fails:

• All minimums met: pass, and proceed to a workload test.
• Compute capability below the minimum: a hard blocker; compute capability is fixed per GPU generation and no software setting raises it.
• Driver version below the minimum: usually a driver update rather than a hardware problem, but check it separately, because a newer driver may need a newer kernel or a maintenance window.
• VRAM below the minimum: soft or hard depending on the software.

That last case needs care. A VRAM shortfall is workable only if the vendor’s software supports reducing its memory footprint (smaller batch sizes, mixed precision or, for training, gradient checkpointing) without breaking a required function or dropping throughput below what you need. Each workaround has a cost: smaller batches lower throughput and, in training, can change convergence. Video features also consume memory: NVIDIA’s FFmpeg guide notes that the HEVC and AV1 ultra-high-quality encode mode needs significantly more GPU memory, and it recommends 8 GB or more for high-bitrate HEVC encoding. A vendor’s minimum may be conservative or optimistic at the margin, so a borderline pass still deserves a load test.

A useful capability audit delivers, for each device, the measured value against the stated minimum, a pass or fail, the size of the gap, and whether the gap can be closed in software, by a driver update or only by new hardware, with upgrade cost and lead time attached where hardware is the answer.

Can our existing encoders and decoders really do hardware HEVC at 1080p60?

HEVC hardware encode and decode throughput depends on the specific hardware at each site, not on HEVC being “supported” in general, so a venue that passes does not show that one with different equipment will.

TechnoLynx defines the 1080p60 HEVC encode and decode requirement for each venue and for the master-control decode chain, benchmarks every site’s existing encoder and decoder hardware against it, validates the measured frame rate and resolution against the target, and delivers a capability audit with a costed, lead-time-scoped upgrade path for any venue that needs new NVENC- or NVDEC-capable hardware. Where hardware falls short, the same audit tests x265 software encode latency and quality as a possible interim path.

NVIDIA states that fully accelerated NVENC and NVDEC encoding and decoding is supported on Turing and newer GPUs, and it points to its Video Encode and Decode Support Matrix for per-GPU codec capabilities and engine counts. Published SDK throughput figures are measured with the SDK’s own high-performance applications, and FFmpeg runs slightly slower because of software overhead and setup time. When benchmarking decode to null, add -hwaccel_output_format cuda; without it, every frame is copied from GPU to host memory before being discarded, which lowers the reported frame rate.

The 10-bit cost shows in NVIDIA’s own figures. The NVDEC application note for Video Codec SDK 13.0, measured at 1920×1080 YUV 4:2:0, lists Ampere decode throughput of 1415 for 8-bit HEVC and 1299 for HEVC Main10. That is about 8% lower for Main 10 ((1415 − 1299) ÷ 1415) on that generation. The headroom against a single 1080p60 stream is large, but it narrows once one GPU decodes dozens of cameras and runs inference at the same time.

Three caveats belong in any audit. Firmware and driver versions can change codec support independently of the chip, so record the current state and not the nominal capability. Intel graphics on 9th-generation Core processors and older stop at 4:2:0. And none of our sources gives a per-venue upgrade cost or lead time; those figures depend on vendor stock and need revalidating close to procurement.

Cameras deserve the same scrutiny as decoders. One AI detection vendor, IntelliSee, gives a minimum of 1080p at 15 frames per second for reliable gun detection, with the coverage area subtending 40 to 60 pixels of weapon width at maximum range, and recommends a camera placement audit before go-live. Your vendor’s numbers will differ, but the practice carries over: audit each camera’s resolution, frame rate, angle and HEVC profile against the stated minimums before deployment.

If the hardware path is missing, can x265 software encoding keep up?

Possibly, but you have to measure it on your CPUs under realistic load, because our sources contain no measured 1080p60 latency or quality figure for x265 on current hardware. x265 produces 10-bit output with --output-depth 10, binding libx265_main10 when the linked library is a different depth, and it offers 10-bit profiles including main10, main422-10 and main444-10. It can dither when reducing input to its internal bit depth, diffusing errors from one row of pixels to the next.

The trade-off is structural. To hold 60 frames per second in software, you move to faster presets, which give up compression efficiency, and lookahead adds frames of latency; on a CPU already busy with other work, the encoder may not sustain the rate at all. Treat x265 as an interim measure for a venue whose upgrade cannot land in time, and only after its added latency and quality loss are confirmed tolerable for the contribution chain.

How do I tell routine 8-to-10-bit HEVC transcoding artefacts apart from tampering?

Build a reference set: take known-clean footage, push it through exactly the 8-bit to 10-bit HEVC pipeline you use in operation, and record what your tamper-detection tool flags on it. Anything flagged on that clean set is a false positive caused by your own transcoding, and the tool has to be judged against it.

The research gives reasons to expect the transcoding to leave traces. Safonov and Vatolin (2022) note that no up-conversion technique can accurately predict the least significant bits of true high-bit-depth video, so bit-depth enhancement is always noticeable on close examination. They also found that true high-bit-depth video and up-converted video are often indistinguishable by objective quality metrics. Their up-conversion detector worked on video compressed with FFmpeg’s H.265 encoder, but detection was harder after compression, because compression modifies the least significant bits and flattens the traces. Its quality fell as bitrate decreased and became less reliable at low values. The authors state that the effect of other codecs’ post-processing has not been tested.

HEVC re-encoding itself is also detectable. Amped Software reported in 2025 on published research detecting HEVC double encoding with B-frames, using per-frame features such as frame type, coding unit size, quantisation parameter and prediction mode. The dataset held 129 HEVC-compressed videos derived from 43 source sequences, expanded by augmentation, and the method reached 80.06% accuracy, which Amped frames as relevant to surveillance footage where B-frames and quality-preserving recompression are common.

Notice what that implies. “Re-encoded” cannot be read as “tampered”. Our sources do not characterise the specific chroma signatures of 8-to-10-bit HEVC conversion against splice artefacts, so any claimed signature should come from your own reference set.

For validation, SWGDE’s 2018 minimum requirements for testing digital and multimedia forensic tools state that the purpose of testing is to establish confidence that a tool or procedure performs correctly, reducing the risk of errors. Those requirements are general rather than HEVC-specific. Meeting them is good practice, and it does not guarantee that a court will accept a particular tool’s output.

How should you think about 10-bit HEVC in practice?

Treat it as a fidelity guarantee you have to enforce, not a camera setting. Making sure those ten bits reach a model trained to use them is where the engineering is.

When is it worth the decode and bandwidth cost for a security-operations pipeline? When detection quality in shadowed, backlit or night-time zones is where you are losing, when the decoders in the chain all have Main 10 in hardware, and when you are prepared to retrain or fine-tune on 10-bit data. When the model was trained on 8-bit footage and you have no plan to change that, or when the bottleneck is the model or post-processing rather than input fidelity, 10-bit buys little. Higher bit depth also has consequences for recording retention under fixed bitrate caps, and that deserves its own calculation before a fleet-wide switch.

The decode boundary is one stage. Instrumented properly, it is also one of the cheapest places to rule a failure in or out, which is what production AI reliability depends on: a log line saying yuv420p10le at the camera and nv12 at the model input locates the conversion without anyone having to look at the model.

FAQ

What is the difference between x265 and H.265?

H.265 is the video compression standard, also known as HEVC and MPEG-H Part 2. x265 is one software encoder that produces H.265 bitstreams, with options such as --output-depth that select 8, 10 or 12-bit output.