H.265 has a reputation problem. For years, turning it on meant losing a chunk of the cameras a server could run, so plenty of integrators still leave it off by default. That reputation is only half true anymore. The camera-count hit is real on 6th Gen Intel Xeon hardware, where H.265’s heavier math still bogs the CPU down. On AMD’s Zen 5 architecture, the same switch costs nothing and saves real storage. Same codec, opposite outcome, entirely down to what CPU is decoding it.
That gap, plus a second shift most integrators haven’t caught up to yet, adding a GPU no longer helps and can actively hurt, adds up to a real change in how a video surveillance server should be spec’d. Here’s what’s actually happening under the hood.
Why H.265 Got a Reputation for Killing Camera Count
H.265 delivers roughly 40-50% less bitrate than H.264 at the same image quality, which is exactly why every integrator wants it turned on. The catch is how it gets there. H.265 achieves that compression through far more complex math than H.264 ever used: up to 35 intra prediction modes instead of 9, coding tree units as large as 64×64 instead of fixed 16×16 macroblocks, variable block partitioning, and heavier motion vector prediction. Decoding that stream for recording, and running motion detection on top of it, asks a CPU to do significantly more work per frame than H.264 ever did.
On older hardware, and on current 6th Gen Intel Xeon chips, that extra math shows up as a direct hit to camera count. Switch a server from H.264 to H.265 and the number of streams it can reliably run drops, often by 40-50%. That’s not a myth or an outdated rumor. It’s a real, current limitation, and it’s why so many integrators still quote H.264 by default even though H.265 would cut their customer’s storage bill by half.
The Real Bottleneck Was Never H.265, It Was the CPU
The mistake is blaming the codec instead of the hardware running it. H.265’s math is heavier, but heavier math is exactly what a CPU with the right architecture should be able to absorb without flinching. The camera-count penalty isn’t a property of H.265 itself, it’s a property of asking the wrong CPU to do it.
AMD’s Zen 5 architecture changes the equation. All-core turbo performance runs 20-40% higher than 6th Gen and 5th Gen Intel Xeon chips, and Zen 5 pairs that with a true native 512-bit AVX data path, re-engineered integer and floating-point execution, and a chiplet design that keeps compute cores fed with wide, fast memory bandwidth instead of bottlenecking on a single monolithic die. Every one of those pieces maps directly onto what H.265 decode actually demands: heavy SIMD math, high memory throughput, and enough parallel headroom to run motion detection and decode at the same time across dozens or hundreds of streams.
The result is that Zen 5 doesn’t just tolerate H.265’s extra math, it absorbs it with headroom left over. That’s the difference between a codec that costs you cameras and one that doesn’t cost you anything at all.
PassMark Says One Thing. Real Surveillance Workloads Say Another.
General-purpose CPU benchmarks don’t always agree with this, and that’s worth addressing directly, because it’s the first place a skeptical buyer will look. Run a generic multi-core benchmark and a 6th Gen Intel Xeon can post a higher score than a comparable Zen 5 chip, sometimes by a meaningful margin. If a server were sized off that number alone, Intel would look like the right call.
The problem is what that benchmark actually measures. A general CPU Mark score is a blended average across integer math, floating point calculations, string sorting, data encryption, and compression, none of which is H.265 decode or motion detection specifically. It’s a fair proxy for general-purpose computing. It has nothing to do with what a recording server spends its day doing.
We ran 6th Gen Intel Xeon and AMD Zen 5 side by side, at the same time, on identical Milestone XProtect workloads, sweeping every resolution and frame rate combination rather than cherry-picking one favorable config. The reference scene we anchor to is 4MP at 15 FPS with motion detection active, roughly 5Mb/s of high-motion video, the same baseline integrators actually size real projects around. Under that testing, Zen 5 delivered up to 2.3x the H.265 stream processing throughput of 6th Gen Intel, up to 33% more overall high-resolution stream capacity, and up to 50% more H.265 camera streams per server. The same gap holds on Genetec and Avigilon, so this isn’t a Milestone quirk, it’s the platform.
A general benchmark and a real workload can point in opposite directions, and when they do, the workload is the number worth trusting.
Why You Don’t Need a GPU Anymore
The instinct when a server needs more decode headroom is to add a GPU. That instinct made sense on older CPU generations that actually needed the help, and it’s exactly the instinct Zen 5 makes obsolete for this workload.
A GPU’s actual contribution to video decode and motion detection comes down to its dedicated decode engines, and that’s a hard ceiling, typically one or two engines per card regardless of how powerful the GPU is otherwise. Zen 5’s native 512-bit AVX data path and chiplet cache architecture already deliver more decode and motion-detection throughput across the full CPU than that ceiling allows. Add a GPU to a server built on that foundation, and most VMS platforms will still try to offload streams to it by default, on the old assumption that GPU offload always helps. On current-generation hardware, that assumption routes work to the weaker resource, and total stream capacity drops instead of rising.
Real AI-driven analytics, object classification, license plate recognition, behavior modeling, is a different question and still benefits from dedicated accelerator hardware built for that purpose. But for the decode and motion-detection work every recording server does regardless of what analytics run on top of it, adding a GPU is no longer the upgrade it used to be.
The Exception: When You Still Need Extra Hardware
None of this is a blanket argument against accelerator hardware everywhere. Heavy, model-based video analytics, the kind doing real object classification or behavioral analysis rather than simple motion detection, still benefits from purpose-built GPU or accelerator hardware, and that’s a separate decision from how the recording server handles decode and motion detection. The two workloads get confused constantly, and treating them as one decision is what leads integrators to add a GPU for the wrong reason.
What This Means for Speccing Your Next Server
Put these pieces together and it’s a real shift in how a video surveillance server should be spec’d, not an incremental tweak:
- H.265 no longer costs camera density on the right CPU architecture, so there’s no longer a tradeoff to accept in exchange for the storage savings.
- A generic CPU benchmark score can point at the wrong chip entirely for this specific workload.
- Adding a GPU for decode and motion detection is very likely a step backward rather than forward on current-generation CPUs.
- The variable that actually matters is CPU architecture, native wide SIMD execution, chiplet memory bandwidth, and all-core sustained clock speed, not core count, not a spec sheet benchmark, and not whether a GPU is present.
Frequently Asked Questions
Does H.265 still slow down NVR and VMS recording servers?
It depends entirely on the CPU. On 6th Gen Intel Xeon hardware, switching to H.265 still costs a real camera-count penalty, often 40-50%, because the CPU’s decode math can’t keep pace with H.265’s heavier compression algorithm. On AMD Zen 5 architecture, that penalty disappears, since Zen 5’s native 512-bit AVX data path and chiplet design were built to absorb exactly that kind of workload.
Do you need a GPU for video surveillance servers?
Not for decode and motion detection on a modern Zen 5 server, and adding one can actually reduce stream capacity, since most VMS platforms will offload decode to the GPU’s limited decode engines instead of the CPU that’s already outperforming it. A GPU still matters for heavier, model-based AI analytics like object classification or license plate recognition, which is a separate workload from basic recording and motion detection.
Why is Intel slower than AMD at H.265 decoding?
H.265 decode is a heavily math-intensive workload built around wide SIMD execution, large coding tree units, and complex motion vector prediction. AMD’s Zen 5 architecture pairs a true native 512-bit AVX data path with a chiplet design that keeps compute cores fed with high memory bandwidth, both of which map directly onto what H.265 demands. 6th Gen Intel Xeon chips lack that same combination, which is why they lose meaningful stream capacity when H.265 is turned on.
Does a higher PassMark score mean a CPU is better for video surveillance?
No. General CPU benchmarks average performance across tasks like integer math, encryption, and compression, none of which represents H.265 decode or motion detection specifically. A CPU can score higher on a generic benchmark and still process significantly fewer real H.265 surveillance streams than a competitor with a lower general score.
Does this hold across different VMS platforms?
Yes. The performance gap between 6th Gen Intel Xeon and AMD Zen 5 on H.265 decode and motion detection holds consistently across Milestone XProtect, Genetec, and Avigilon, since the bottleneck is CPU architecture rather than any single VMS vendor’s software.
