H.264 or H.265? How to Choose in Practice

The short answer

Attribute	H.264 (AVC)	H.265 (HEVC)
Bitrate for equal quality	Baseline 100%	About 50-60% (rule of thumb; the busier the picture, the bigger the gap)
Encoding latency	Lower	Slightly higher; on hardware encoders still in the millisecond range
Decoder compatibility	Almost everything decodes it	Needs newer silicon or a software decoder; older gear may refuse it
4K and above	Possible, at high bitrate	Better suited to 4K thanks to higher compression
Licensing	Comparatively simple	Multiple patent pools; check export projects
Typical use	Low latency, legacy platforms, browser playback	Tight bandwidth, 4K, long-term storage, mobile links

How much bitrate is really saved

These are the starting ranges we use on real projects. They are not a standard — motion, noise and shadow detail all shift the answer. Start here, then measure on your own footage.

Resolution / frame rate	H.264 starting point	H.265 starting point	Notes
1080p30	4-6 Mbps	2-3 Mbps	Meetings, surveillance, lecture capture
1080p60	6-9 Mbps	3-4.5 Mbps	Sports and events: take the upper end
4K30	15-25 Mbps	8-12 Mbps	Useful when small text must stay readable
4K60	25-40 Mbps	12-20 Mbps	If upstream is short, drop frame rate before bitrate

One reminder: starve the bitrate and every codec looks bad. H.265 saves bandwidth at equal quality; it does not make a low bitrate look sharp.

Three costs of H.265 that get overlooked

• Higher decoder requirements: older decoders, set-top boxes and TVs may not support H.265 at all — you get a black screen or a format error. Confirm the far end before committing.
• Encoding load and latency: software H.265 encoding is far heavier than H.264. Hardware encoders narrow the gap, though latency is still usually a little higher at equal quality.
• Licensing: HEVC involves several patent pools, which matters for export projects. Raise this early, not the week before shipping.

Five cases where H.264 is the right call

• The decoders are five years old, or nobody can confirm what is at the far end
• End-to-end latency matters (live two-way, interactive teaching, remote guidance)
• The destination platform only accepts H.264 input
• The customer or the tender document specifies H.264
• One encoder must handle many channels, so compute belongs to concurrency, not compression

Five cases where H.265 wins

• 4K and above: H.264 at 4K eats upstream bandwidth quickly
• Constrained links: private lines, satellite, 4G/5G — halving bitrate decides whether it runs at all
• Long-term recording: lecture capture and surveillance accumulate by the year, and bitrate is disk cost
• Lossy networks: lower bitrate means less stutter at the same link quality
• Many channels: bandwidth is channels times bitrate, and four 4K channels in H.264 usually blows the budget

You do not have to choose: run both

The approach we use most often is to publish H.264 and H.265 simultaneously: H.264 for legacy platforms and browser playback, H.265 for bandwidth-constrained branches or recording. Multi-channel encoders accept one input and emit several independent streams. The ZY-EH1304 supports four independent streams per channel (16 in total), while the ZY-EH1301 outputs up to 2 x 4K@30 plus 2 x 1080p@30 at the same time.

It also means no hard cutover: legacy devices keep taking H.264 while new ones move to H.265.

Finally: measure on your own footage

Bitrate tables are only a starting point. The picture decides the rest, so record 30 minutes with a demo unit in your actual scene, then compare detail (text edges, moving objects, shadow noise) and the real bitrate curve.

We offer a 30-day free trial so you can test before you commit.