H.264 vs H.265 (HEVC): which codec to choose for a video

When you export an animation, an edit or a screen recording, the same question comes up: H.264 or H.265? Both names refer to codecs, that is, video compression methods. They say nothing about the file type: the same codec can be stored in an MP4, MKV or MOV container. This guide explains what sets them apart, which one to choose for each use, and how to set them up in Blender and with FFmpeg.

H.264 and H.265 in brief

H.264, also called AVC (Advanced Video Coding), is the standard published in 2003 by the ITU and ISO. It is the format of web video, Blu-ray discs, smartphones and most cameras. Almost every device can decode it, most often with a dedicated circuit in the graphics card or the processor.

H.265, or HEVC (High Efficiency Video Coding), succeeded it in 2013. It was designed to roughly halve the bitrate needed for the same perceived quality, especially for 4K and for 10-bit and HDR video. It achieves this with finer compression tools: variable block sizes up to 64 × 64 pixels instead of 16 × 16, and more accurate prediction of motion and textures.

The names x264 and x265, which you come across in settings, refer to free encoders that produce these formats. When Blender or FFmpeg encodes to H.264, it is most often x264 (libx264) that does the work.

The differences that matter

Compression. This is the advantage of H.265: for the same visual quality, the file is noticeably smaller, especially at high resolution. On a 4K animation several minutes long, the difference is counted in gigabytes.

Compatibility. This is the advantage of H.264. An MP4 in H.264 opens on an old laptop, in every browser, in an email or on a television. H.265 plays on recent devices, but not always in a browser, and Windows may ask for an extension to decode it. For a video sent to a client whose equipment you do not know, H.264 avoids unpleasant surprises.

Encoding time. The finer tools of H.265 require more computation. With the same speed settings, encoding takes longer than with H.264. The hardware encoders of recent graphics cards greatly reduce this gap, at the cost of slightly less efficient compression.

Which codec for which use

• Website, social networks, client preview: MP4 in H.264. YouTube and social networks re-encode the video anyway: upload it with a generous bitrate.
• Archive, 4K render, 10-bit: H.265 in MP4 or MKV, for a file roughly half the size.
• Editing and grading: neither. Editing codecs such as ProRes or DNxHD, both offered by Blender, are heavier but decode effortlessly frame by frame.
• Video with transparency: a PNG or OpenEXR image sequence or, in Blender, the PNG, FFV1, QuickTime Animation or VP9 in WebM codecs.
• Maximum compression: AV1, also offered by Blender, compresses even better than H.265, but encodes more slowly and plays on fewer older devices.

Exporting to H.264 or H.265 in Blender

In Output Properties, Output panel, set Media Type to Video; in older versions of Blender, the same choice is made by setting File Format to FFmpeg Video. The Encoding panel then appears.

1. Container: MPEG-4 for an .mp4 that plays everywhere, Matroska for an .mkv, QuickTime for a .mov.
2. Video Codec: H.264 or H.265 / HEVC.
3. Output Quality: a quality preset, or a custom CRF value. CRF ranges from 0 to 51 for H.264 and H.265: the lower it is, the better the quality and the larger the file, and 0 gives lossless encoding.
4. Encoding Speed: slower encoding compresses better; fast encoding produces a larger file.
5. Color Depth: 10-bit is available in H.264, H.265 and AV1, and 12-bit in H.265 and AV1. It is useful for limiting banding in sky or background gradients.
6. Audio: if the scene contains sound, choose AAC in the Audio panel, otherwise the video comes out silent.

The Keyframe Interval and Max B-frames settings generally stay at their default values. An interval of 0 uses only complete (intra) frames, which makes editing easier but makes the file much heavier.

Good practice: render to images, encode afterwards

The Blender manual advises against rendering an animation directly to video. If the render stops at frame 800, a video file is lost or unusable, whereas a PNG or OpenEXR image sequence picks up where it left off. Rendering to images also lets you try several encodings, H.264 for the client and H.265 for the archive, without running the render again. In Blender, the sequence is added as an Image Strip in the Video Sequencer, which encodes it with the settings above.

With FFmpeg on the command line, from a numbered sequence at 24 frames per second:

# H.264, plays everywhere
ffmpeg -framerate 24 -i image_%04d.png -c:v libx264 -crf 18 -pix_fmt yuv420p video_h264.mp4

# H.265, smaller, tagged for Apple players
ffmpeg -framerate 24 -i image_%04d.png -c:v libx265 -crf 22 -pix_fmt yuv420p -tag:v hvc1 video_h265.mp4

The -pix_fmt yuv420p option ensures a chroma subsampling that every player accepts. CRF values cannot be compared from one codec to the other: a CRF of 22 in H.265 gives roughly the quality of a slightly lower CRF in H.264. Run a short test on a representative sequence before encoding the whole film.

For the output itself, the guide on how to render in Blender covers the output folder and image formats, and the entry on multilayer OpenEXR (in French) explains when to keep all the passes.