HEVC (H.265) saves space, but it refuses to play in plenty of places: older TVs and media players, some video editors, and a surprising number of Windows setups without the HEVC codec installed. The cure is to re-encode the video stream to H.264 (libx264) — the most universally supported codec there is. This guide shows the exact commands, explains the quality/size trade-off, and covers the 10-bit pitfall that trips up most people. Estimated time: 10 minutes.

Tested with: FFmpeg 8.1

This is different from chasing a specific error message — if FFmpeg is throwing libx265/hvc1 errors during encoding, see FFmpeg H.265/HEVC Errors instead. This article is about deliberately downgrading HEVC to H.264 for compatibility.


What You’ll Learn

  1. Why H.264 plays where HEVC won’t
  2. The one-line HEVC → H.264 conversion
  3. How CRF controls quality and file size
  4. How -preset trades speed for compression
  5. The 10-bit HEVC trap (and the yuv420p fix)
  6. Keeping the original audio untouched
  7. Troubleshooting
  8. FAQ

1. Why Convert HEVC to H.264?

HEVC is often more efficient than H.264 (a figure of roughly 30–50% smaller at the same quality is frequently cited, but it varies with the footage and settings), so it is great for storage. The catch is decoding support:

TargetHEVC (H.265)H.264
Old TVs / media playersOften unsupportedAlmost always works
Windows (no HEVC codec)“Can’t play” / no videoPlays out of the box
Older video editorsImport fails / no previewImports cleanly
Web <video> in older browsersSpottyUniversal
Phones (5+ years old)Hit or missReliable

When a file must play everywhere, H.264 is the safe choice. The downside: converting re-encodes the video (it is lossy and takes real CPU time), and the H.264 file is usually larger than the HEVC original.

You cannot do this with -c:v copy. Copy only changes the container, not the codec. See Copy vs Re-encode for why HEVC → H.264 always means re-encoding.


2. The Basic Conversion

This is the whole command for a standard 8-bit HEVC file.

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -preset medium -c:a aac output.mp4
  • -c:v libx264 … encode the video stream as H.264
  • -crf 20 … constant quality target (lower = better quality, bigger file)
  • -preset medium … balance between encode speed and compression
  • -c:a aac … re-encode audio to AAC (broadly compatible)

-crf 20 is visually near-transparent for most footage. The output container stays .mp4, which is exactly what old players expect.


3. CRF — Quality vs Size

CRF (Constant Rate Factor) is the single most important knob. libx264 accepts 0–51; lower numbers mean higher quality and larger files.

CRFVisual resultTypical use
18Visually lossless to most eyesArchival, big screens
20Excellent, hard to tell apartRecommended default
23Good (libx264 default)General sharing
26Noticeable softening on detailSmall files, quick clips
28Visible compressionAggressive size cutting

A few CRF points changes file size and quality noticeably, but the exact ratio depends entirely on the footage — there’s no fixed “X points = half the size” rule. If your goal is a target file size rather than a quality level, use two-pass encoding instead; see Two-Pass Encoding. If you mainly want a smaller file, Compress Video covers CRF, scaling, and bitrate together.


4. Preset — Speed vs Compression

-preset controls how hard the encoder works. Slower presets squeeze the same quality into a smaller file but take longer; they do not change the visual quality target (CRF does that).

PresetSpeedFile size at same CRF
ultrafastFastestLargest
veryfastFastLarger
mediumDefaultBaseline
slowSlowerSmaller
veryslowSlowestSmallest

If you have time, -preset slow is a free win on file size. For a quick one-off, medium is fine.


5. The 10-bit HEVC Trap (Force 8-bit yuv420p)

A lot of HEVC comes from phones, cameras, and HDR sources in 10-bit color (yuv420p10le). If you feed that straight into libx264, the output may end up as High 10 H.264 — which many of the old players you are targeting still cannot decode. Force standard 8-bit yuv420p for maximum compatibility:

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -pix_fmt yuv420p -c:a aac output.mp4
  • -pix_fmt yuv420p … force 8-bit 4:2:0, the most widely supported pixel format

This is the safest all-around command. If a converted file plays audio but shows a black or garbled picture on an old device, a missing -pix_fmt yuv420p is the usual culprit.

Note on HDR: Converting a 10-bit HDR source to 8-bit yuv420p only changes the bit depth — it does not tone-map HDR to SDR by itself, so the colors can look washed out, dull, or otherwise off. If your source is HDR and you want correct SDR colors, you need a proper tone-mapping step: see HDR to SDR.


6. Keep the Audio As-Is

If the source audio is already AAC (very common in HEVC MP4s), there is no reason to re-encode it. Copy it through to save time and avoid a second lossy pass:

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -c:a copy output.mp4
  • -c:a copy … pass the audio stream through unchanged (instant, lossless)

If the player still rejects the audio (rare formats like DTS or Opus in an MP4), switch back to -c:a aac.


7. Troubleshooting

Picture is black or scrambled on an old TV/player

Cause: The output is 10-bit (High 10 profile) H.264. Fix: Add -pix_fmt yuv420p to force 8-bit (Section 5).

Conversion is extremely slow

Cause: A slow preset on a long, high-resolution file. Fix: Use -preset medium or -preset veryfast. Encoding is CPU-bound; this is expected for software H.264.

File got bigger than the HEVC original

Cause: That is normal — H.264 is less efficient than HEVC. Fix: Raise CRF (e.g. -crf 23) or downscale resolution. See Compress Video.

Audio is missing after conversion

Cause: The source audio was a format the MP4 container or your player rejects. Fix: Re-encode with -c:a aac instead of -c:a copy.

iPhone HEVC won’t play on Windows even after this

Cause: A separate metadata/rotation issue specific to iPhone footage. Fix: See Play iPhone Video on Windows.


FAQ

Q1. Does converting HEVC to H.264 lose quality? A. Yes — it is a lossy re-encode. With -crf 1820 the loss is hard to see, but it is not lossless. Container-only remuxing (-c copy) cannot change the codec.

Q2. Will the H.264 file be larger than the HEVC? A. Usually, yes. H.264 needs more bits for the same quality. That is the price of universal compatibility.

Q3. Which CRF should I use? A. Start at -crf 20. Drop to 18 if you want archival quality, raise to 23–26 if you want a smaller file.

Q4. How do I know if my file is 10-bit? A. Run ffprobe input.mp4 and look for yuv420p10le in the video stream line. If you see it, use the -pix_fmt yuv420p command in Section 5.

Q5. Can I keep HEVC but just make it play on more devices? A. Sometimes adding the hvc1 tag helps on Apple devices — but for genuinely old players, only converting to H.264 reliably works. See FFmpeg H.265/HEVC Errors.



Tested with FFmpeg 8.1 — verified with our command-check script Primary sources: ffmpeg.org/ffmpeg.html / trac.ffmpeg.org/wiki/Encode/H.264