How to Encode H.265 Video with FFmpeg (CRF + Preset Guide)

Originally published at ffmpeg-micro.com

H.265 (HEVC) produces files 30-50% smaller than H.264 at the same visual quality. The trade-off is encoding time. Getting the right CRF and preset combination for your use case is the difference between a file that's too big and an encode that takes all night.

What CRF and Preset Actually Control

CRF (Constant Rate Factor) sets your quality target. Lower numbers mean higher quality and larger files. The libx265 default is 28, which is roughly equivalent to CRF 23 in H.264.

Preset controls how hard the encoder works to hit that quality target. Slower presets find better compression at the same CRF, producing smaller files without losing quality. The trade-off is encode time.

The two settings are independent. CRF picks the quality. Preset picks how efficiently the encoder reaches that quality.

The Basic libx265 Command

ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k -tag:v hvc1 output.mp4

Flag breakdown:

• -c:v libx265 selects the H.265/HEVC encoder
• -crf 28 sets quality (lower = better quality, larger file)
• -preset medium balances speed and compression (default)
• -c:a aac -b:a 128k re-encodes audio to AAC at 128kbps
• -tag:v hvc1 marks the stream for Apple/browser playback compatibility

That -tag:v hvc1 flag is one people miss. Without it, Safari and iOS won't play the file. QuickTime will refuse to open it. If you're encoding for web delivery, always include it.

Which CRF Value for Which Use Case

Use Case	CRF Range	Why
Archival / master copy	18-22	Visually lossless. Large files, but you keep everything.
Streaming / web delivery	23-28	Good quality at reasonable file sizes. CRF 26 is the sweet spot for most web video.
Social media / batch processing	28-32	Smaller files, acceptable quality for short-form content where compression artifacts are less noticeable.
Preview / thumbnail generation	32-38	Low quality is fine. You're optimizing for speed and small size.

Start at CRF 28 and adjust. Encode a 30-second sample, check the output, then move the CRF up or down by 2-3 points until you hit your target file size and quality.

Preset Speed vs Compression

Preset	Relative Speed	File Size (same CRF)	Best For
ultrafast	10x	~40% larger	Testing, previews
fast	4x	~15% larger	Real-time or near-real-time
medium	1x (baseline)	baseline	General use
slow	0.4x	~5-10% smaller	Final renders, overnight batches
veryslow	0.1x	~10-15% smaller	Archival. Only worth it for content you'll serve thousands of times.

For most developers building automation pipelines, medium or slow is the right answer. veryslow gives diminishing returns that don't justify 10x the encode time unless you're Netflix.

Running H.265 Encodes via API (No libx265 Install)

Installing libx265 means compiling FFmpeg from source on most Linux distros, managing codec dependencies, and dealing with version mismatches. If you're building an automation pipeline, you can skip all of that.

The FFmpeg Micro API accepts raw FFmpeg options. Same flags, no local install:

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{"url": "https://storage.example.com/input.mp4"}],
    "outputFormat": "mp4",
    "options": [
      {"option": "-c:v", "argument": "libx265"},
      {"option": "-crf", "argument": "28"},
      {"option": "-preset", "argument": "medium"},
      {"option": "-tag:v", "argument": "hvc1"}
    ]
  }'

The response comes back immediately with a job ID:

{
  "id": "trc_abc123",
  "status": "queued",
  "outputFormat": "mp4",
  "createdAt": "2026-05-17T10:00:00.000Z"
}

Poll GET /v1/transcodes/trc_abc123 until status is completed, then grab the output from GET /v1/transcodes/trc_abc123/download.

For high-quality archival encodes, just change the CRF and preset:

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": [{"url": "https://storage.example.com/input.mp4"}],
    "outputFormat": "mp4",
    "options": [
      {"option": "-c:v", "argument": "libx265"},
      {"option": "-crf", "argument": "22"},
      {"option": "-preset", "argument": "slow"},
      {"option": "-tag:v", "argument": "hvc1"}
    ]
  }'

Same two-line change you'd make in the CLI command, but no server to maintain.

Common Pitfalls

Forgetting -tag:v hvc1 for web delivery. Apple devices and most browsers need the hvc1 tag to recognize the HEVC stream. Without it, the file plays fine in VLC but fails in Safari, iOS, and many HTML5 video players.

Using H.264 CRF values with libx265. CRF 23 in H.264 and CRF 23 in H.265 are not the same quality. H.265's CRF 28 matches H.264's CRF 23. If you copy your H.264 settings directly, you'll get unnecessarily large files.

Choosing veryslow for batch pipelines. The compression gain from slow to veryslow is 3-5% smaller files. The time cost is 3-5x longer encodes. For automated pipelines processing hundreds of videos, medium or slow is almost always the right trade-off.

Not specifying audio codec explicitly. If your input has audio in a format incompatible with the MP4 container (like Vorbis), FFmpeg will fail silently or produce a broken file. Always set -c:a aac or -c:a copy (if the source audio is already AAC).

Expecting hardware encoders to support CRF. NVENC, VideoToolbox, and QSV don't support FFmpeg's -crf flag. They use -qp or -b:v instead. If you're running on GPU, the libx265 CRF workflow doesn't apply.

FAQ

Is H.265 always better than H.264?
For file size at the same quality, yes. But H.265 encoding is 2-5x slower, and some older devices can't decode it. If your audience is on modern browsers and mobile devices (2020+), H.265 is the better choice. For maximum compatibility with legacy players, stick with H.264.

What's the difference between CRF and two-pass encoding?
CRF targets constant quality (file size varies). Two-pass targets a specific bitrate (quality varies). Use CRF when you care about quality and can tolerate variable file sizes. Use two-pass when you have a strict file size budget, like streaming with a fixed bitrate cap.

Can I use CRF with the FFmpeg Micro API?
Yes. Pass -crf and -preset as options in the API request. The API runs the same FFmpeg binary with the same flags. No difference in output quality or behavior.

What CRF value gives "visually lossless" H.265?
CRF 18-20 with preset slow or veryslow. At these settings, most viewers can't distinguish the encode from the source in an A/B comparison. File sizes will be 60-70% smaller than the raw source, compared to 80-90% smaller at CRF 28.

Does preset affect quality or just file size?
At the same CRF, slower presets produce smaller files at the same quality. They don't improve quality. They improve compression efficiency. Think of it as: same visual result, less wasted bits.

Last verified: 2026-05-17 against FFmpeg 7.x and FFmpeg Micro API v1