HEVC (also called H.265) can deliver comparable perceived picture quality at a lower video bitrate than H.264, but the saving depends on the footage, encoder settings and the devices that can play it. To use it well, set a quality target, test a ladder of renditions against representative scenes, and retain compatible alternatives where your audience needs them.
That is a bandwidth trade-off, not a lossless conversion or a universal percentage reduction. A smaller stream can look worse, and a lower video bitrate does not by itself tell you the broadband speed a viewer needs: audio, delivery overhead and rate peaks matter too.
Understand the HEVC bitrate trade-off
HEVC compresses video differently from H.264/AVC. For a given source and intended viewing experience, an HEVC encode may need less bitrate, or it may preserve more detail at the same bitrate. Neither outcome is automatic. Motion, texture, grain, resolution, bit depth, encoder implementation and preset all affect the result.
Apple Developer described HEVC in a 2017 HLS technology talk as enabling higher-quality video at about 40 per cent lower bitrate than H.264. Treat that as Apple's published benchmark, not a promise for your channel, source file or encoder. Your own comparison may show a smaller saving, a different quality balance, or no useful reason to change codec.
A bitrate target is only one side of the decision. If you lower it too far, the encoder has less data with which to represent movement and fine detail. The picture may soften, block, band in gradients or lose texture. A still image of a devotional singer may look clean while a quick camera pan or a busy crowd exposes the compromise.
A useful goal is therefore not “use the lowest bitrate” but “meet a defined quality floor with the least data that reliably achieves it”. Keep the source, resolution and frame rate consistent when comparing codecs. Otherwise, a better-looking result could come from a different input or resolution rather than HEVC itself.
Check encoder and playback support
Before encoding a library, check both ends of the path. Your encoder must support an HEVC profile and settings appropriate to your material, and the player, browser or device must be able to decode the stream. Support is not universal, and it can vary by hardware, software version, profile and playback environment. Do not assume that because one phone plays a file, every television or browser used by viewers will do so.
For YouTube delivery, verify the current platform guidance for the live workflow you use rather than assuming that an HLS example ladder is a YouTube ingest preset. YouTube publishes its current live encoder settings; use that page to confirm accepted ingest requirements and configure your encoder accordingly. The ladder examples later in this article are Apple HLS authoring recommendations, not a claim about what to send to YouTube.
Think separately about encoding effort and playback coverage. HEVC encoding can call for different compute resources or take a different amount of time than AVC in your particular setup. Measure that locally: the available evidence here does not establish a general cost or speed advantage. If producing both codecs creates a cumbersome workflow, that operational cost belongs in the decision alongside bandwidth.
For a 24/7 channel, reliability is also part of the path. A codec test is no substitute for a stable ingest and a recoverable broadcast workflow. If your encoder runs at home, the practical risks in keeping a YouTube stream connected through Indian power fluctuations are worth considering separately from the quality of the encode.
Build a ladder, not a single preset
Adaptive streaming makes multiple renditions available so a compatible player can select a suitable stream as the viewer's available bandwidth changes. A ladder is a set of resolution-and-bitrate options, not just a full-quality file plus one low-quality fallback. The right rungs depend on the content and the playback devices you are serving.
Apple's HLS Authoring Specification for Apple Devices publishes possible HEVC SDR starting recommendations for 30 fps. The values below are useful reference points for an HLS ladder, not settings that will fit every title or every live platform.
| Resolution | Apple HEVC SDR example bitrate at 30 fps |
|---|---|
| 640×360 | 145 kb/s |
| 768×432 | 300 kb/s |
| 960×540 | 600 kb/s |
| 1280×720 | 2,400 kb/s |
| 1920×1080 | 4,500 kb/s |
| 2560×1440 | 8,100 kb/s |
| 3840×2160 | 11,600 kb/s |
Apple presents these as possible recommendations and says to assess them against the content and encoding workflow. Its guidance also notes that high-motion material may call for a different resolution and bitrate combination. The HDR ladder is separate and uses higher example values, so do not apply SDR values to HDR material as though the formats were interchangeable.
Use the table to choose a test range, not to copy a whole ladder blindly. If most viewers watch on phones and the source is a slow-moving illustrated prayer, the highest resolution may be less important than a dependable lower rung. A furniture showroom tour, with fine edges, shelves and camera movement, may need more data at a given resolution to keep detail stable. For a channel built from recorded room tours, the practical questions in making a furniture showroom loop from recorded video can help you think about the source material separately from the codec.
A ladder should also avoid pointless neighbouring rungs. If two renditions look alike and have similar bandwidth requirements, they may not give the player a meaningful choice. Conversely, a very large jump between the low and high option can leave a viewer with a poor experience when bandwidth fluctuates. Compare actual playback transitions, not just the spreadsheet.
Test scenes and encoding settings
Choose short samples that represent the channel rather than testing a single easy shot. Include fast movement, fine detail, smooth gradients, dark material, and grain or noise if those appear in the catalogue. For devotional content, that could mean a steady altar shot, a close view of embroidered fabric, incense smoke against a dark background, and a scene with a moving camera. For lofi or ambience, test subtle gradients, rain or foliage, and low-light footage.
Encode those samples at several bitrate points for both HEVC and H.264. Keep resolution, frame rate, source, and other relevant settings aligned, and record the encoder and preset used. When comparing rate-control settings such as CRF, note that the same numerical value does not necessarily give equivalent quality across codecs or encoders. The comparison that matters is the output you can play, at the quality level you intend to publish.
Watch each sample at its intended display size and on the playback routes that matter to your viewers. Inspect a television at normal viewing distance as well as a laptop or phone if those are common devices. Look for defects during movement and scene changes, not only on a paused frame. A file that looks acceptable on a desktop monitor may reveal banding on a large display or smeared detail on a fast pan.
Test the actual delivery format and codec signalling, not only a locally opened file. If the channel uses a playback workflow with multiple variants, verify that the player can choose a rendition and recover when bandwidth changes. If you are streaming a single file to a platform, follow that platform's current ingest and codec guidance; a locally successful encode does not prove the platform accepts or distributes it as intended.
Write down a pass condition before testing. For example, decide which visible defects are unacceptable for a particular programme type and whether you will trade a little texture for lower delivery bitrate. A written criterion prevents the team from choosing whichever encode happened to be watched most recently. It also makes a later re-test meaningful when the source, encoder or target devices change.
Measure quality and bandwidth together
Use more than one lens. Visual inspection catches defects that a single score can obscure; objective measures can help compare a set of encodes consistently. PSNR and VMAF are among the metrics used in video-quality work, but neither should be treated as a universal pass mark. Compare versions of the same source under the same measurement method, then decide whether the differences matter at the intended display conditions.
A 2024 study, “Explore Cross-Codec Quality-Rate Convex Hulls Relation for Adaptive Streaming”, examined H.264, H.265 and VP9 across its tested material and metrics. It reported that increasing CRF reduced bitrate along with PSNR and VMAF. This is a useful reminder that reducing bitrate can reduce measured quality; it is not a result that predicts exactly how your channel's clips will look.
For each test, log the codec, resolution, frame rate, encoder settings, output bitrate and quality observations. Record average and peak behaviour if your tools expose both. An average video bitrate is not the complete stream throughput: audio, container or segment overhead, and rate peaks add to what travels over the connection. Leave room for those parts when estimating delivery capacity, and do not tell viewers that a video's listed average bitrate is the exact internet speed they need.
Compare the bitrate-quality curve rather than one cherry-picked encode. If HEVC reaches your visual quality floor at a lower rate, it is helping on the trade-off you care about. If the encode takes too long to produce, has compatibility gaps, or looks no better at practical rates, the bandwidth result may not justify maintaining it. Keep notes so you can distinguish a codec improvement from a change in preset or source.
Roll out for the devices you actually serve
Make a playback matrix from the real audience you need to reach: television apps, phones, browsers, set-top devices or other common routes. Test the target combinations where possible and check current vendor documentation for support details. A broad device-by-device compatibility claim would quickly go stale, and the evidence here does not establish one universal support matrix.
Apple's HLS guidance recommends providing SDR streams for backward compatibility. It also says a client should not be required to switch codecs when multiple video streams are supplied. In practical terms, plan fallback variants when your audience's playback support calls for them, and make sure the player can select the appropriate rendition within the ecosystem you target. Check the current Apple HLS authoring guidance for its authoring requirements rather than inferring them from a bitrate table.
A staged rollout is less risky than replacing every rendition at once. Start with a representative programme or limited set of content, keep the established AVC path available where needed, and observe playback errors, buffering, and viewer feedback alongside delivery rates. If the audience reports a problem on a particular playback route, investigate that route before concluding that the encode is poor. Conversely, a clean test on your own device does not establish compatibility for everyone.
For a YouTube-first always-on channel, separate the file's encoding from the broadcast method. HEVC may be useful in a distribution workflow that supports it, but it does not remove the need to follow YouTube's current live ingest requirements. The ongoing task may be source preparation, reliable looping and recovery rather than running an encoder continuously on a local machine. If that local computer is itself the fragile part, alternatives to keeping a computer on for a 24/7 YouTube stream describe the separate operational decision; they do not determine which codec your audience can decode.
When a service turns an uploaded file into a continuous YouTube broadcast, it can remove the specific burden of leaving your own computer encoding and reconnecting all night; it does not make HEVC compatible with every viewer's device or replace testing of the source and playback path. StreamNeo is one way to avoid that overnight computer task when the channel is a prepared video loop, while the codec choice remains a separate delivery decision.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Will HEVC always use 40 per cent less bandwidth than H.264?
No. Apple Developer cited about 40 per cent lower bitrate in a 2017 HLS technology talk, but that is a benchmark, not a guarantee for a particular encode. Results depend on content, encoder, settings and the quality target.
Can I convert an H.264 file to HEVC without losing quality?
Do not treat a transcode as lossless. Re-encoding can discard detail, and lowering bitrate can make the loss more visible. Keep the original source and compare test encodes before replacing a published rendition.
Can I use Apple's example ladder for YouTube Live?
The figures in this article are Apple HLS HEVC SDR recommendations for 30 fps, not YouTube live ingest settings. Check YouTube's current encoder guidance for the workflow you use, and use Apple's table only as a test reference where HLS authoring is relevant.
How do I know whether to keep an H.264 fallback?
Test the playback devices and software versions your audience actually uses, then check the current platform or vendor documentation. Keep a fallback where coverage or authoring requirements call for it; do not assume every viewer can decode HEVC.