iPhone HEVC Video Won't Play? Converting a 113 MB H.265 .MOV to an 11.3 MB H.264 MP4, and What Compatibility Costs

Originally published on Blogger — tested with VidSmaller.

You film something on your phone, send it to a friend or drop it into a shared folder, and the reply is "it's just sound and a black box". Nothing is wrong with the video. Most modern phones record in HEVC (H.265) by default, and plenty of players still can't decode it: desktop Chrome on Linux, older Windows PCs without the paid HEVC extension, some older TVs and web upload widgets. The fix is boring: turn it into an H.264 MP4, which plays almost everywhere, and make it smaller while you're at it.

The question I actually wanted answered: what does that compatibility cost? HEVC is the more efficient codec, so an H.264 file at the same size should look worse. How much worse, and how much bigger does H.264 need to be to catch up? I ran one real 4K phone-style clip through VidSmaller, the online video compressor I build (so weigh my opinions accordingly), and measured everything afterwards with ffprobe and VMAF. All byte counts below come from the actual files.

The short answer (measured)

File	Codec	Size	vs original	VMAF (4K model)	Plays in Chrome on Linux?
Phone-style original (.mov)	HEVC	118,010,054 B	—	reference	No (audio only)
VidSmaller, typed 12 MB	H.264	11,887,672 B	−89.9%	52.1	Yes
Local x265, same bitrate (for comparison)	HEVC	12,128,323 B	−89.7%	69.7	No
Local x264, about 2× the bytes (for comparison)	H.264	24,353,697 B	−79.4%	69.5	Yes

So: one upload took the clip from 113 MB to 11.3 MB, under the size I typed, and the result plays. The cost of choosing H.264 is real, though. On this busy 4K garden scene, H.264 needed about twice the bytes (24.4 MB vs 12.1 MB) to match HEVC's quality. If you only need it to play, 12 MB is fine for a phone screen. If you'll watch it full-screen on a big monitor, give H.264 a bigger target.

The test clip

I wanted something that looks like what phones actually produce: 4K, 30 fps, handheld, lots of leaves and grass (the hardest kind of detail to compress). I took 40 seconds of a 4K walk through a Suzhou garden (Walking China, CC BY 3.0) and re-encoded it the way an iPhone with HDR turned off would save it: HEVC Main, 3840×2160, 30 fps, about 23.4 Mbps, tagged hvc1, in a .mov with AAC audio. The result was 118,010,054 bytes for 40 seconds.

Step 1: Check which codec your phone used

Before converting anything, confirm it's actually HEVC. On a computer, ffprobe shows it in one line. On an iPhone, the Photos info panel shows "HEVC" next to the resolution. On Android, check the camera's video format setting ("HEVC" or "H.265" vs "H.264").

codec_name=hevc with codec_tag_string=hvc1 is the tell. If it says h264, your problem is something else (usually just size, so jump to Step 4).

Step 2: See what "won't play" looks like

I made a small test page with two <video> tags and opened it in Chrome 156 on Linux: the original phone file on the right, the converted file on the left.

The HEVC file doesn't error out. Chrome reports canPlayType: "", plays the AAC audio and leaves the picture at 0×0. That's exactly the "sound but black screen" your recipient describes. The H.264 file decodes at full 3840×2160.

Step 3: Load the phone file into VidSmaller

Open the compressor's home page and drop the .mov in. No sign-up is needed for a first try. Right now the signed-out limit is up to 3 minutes and 200 MB, which this clip fits. It read the file as 113 MB · 0:40 · 3840×2160 and suggested 67.5 MB by default.

Note the preview on the left: it's the same audio-only player, because the preview runs on the same browser decoder that can't do HEVC. The upload and conversion happen in the cloud, so it doesn't matter. (The site writes sizes in binary MB, so 118,010,054 bytes shows as 113 MB.)

Step 4: Leave the output codec on H.264

Under Advanced Compression, the Video Codec menu has H.264 and H.265. H.265 output is locked unless you're on a paid plan. For this job that doesn't matter: H.264 is the whole point, because it's the codec everything can play. H.264 is the safe choice; H.265 (HEVC) is the efficient one.

I switched back to Basic Compression for the actual run, since all I wanted to set was a size.

Step 5: Type a target size

The basic view is one number: the output file size. There are chips for common limits (Discord 19 MB, WhatsApp 15 MB, Email 18 MB, Reddit 100 MB; Discord's free upload limit is 20 MB, so the chip leaves a little margin). I typed 12 to make the gap obvious. The estimate updated to 12.0 MB.

Step 6: Start, wait, download

Click Start Compression. The 113 MB upload went first, then the encode. From click to "ready" took 79 seconds.

The result card read 113 MB → 11.3 MB, −89.9%.

Step 7: Verify the download

Don't trust the card, check the file:

H.264 High profile, avc1 tag, still 3840×2160 at 30 fps, same 40.007 s duration, 11,887,672 bytes. That's under the 12 MB (12,582,912-byte) target and 89.9% smaller than the 118,010,054-byte original, about 9.9× smaller. It plays in Chrome on the same machine that showed a black box for the original.

What compatibility cost: same size, different codec

To see the price of H.264, I encoded the same phone file locally with x265 (HEVC) at the same 2.24 Mbps video bitrate VidSmaller used, then with x264 (H.264) at higher bitrates until it caught up. I scored every file against the original with VMAF (ffmpeg 8.1, vmaf_4k_v0.6.1 model, all 1,200 frames). The VidSmaller output scored 52.1. A local x264 encode at the same bitrate and speed preset scored 52.2, so the service isn't doing anything worse than plain x264. This is just what H.264 can do at 2.2 Mbps on 4K foliage.

Encode	Bytes	VMAF mean	VMAF 5th pct	SSIM
VidSmaller H.264, 12 MB target	11,887,672	52.1	38.3	0.751
Local x264 faster, 2240k	12,754,320	52.2	38.4	0.753
Local x264 faster, 4000k	22,044,548	66.2	54.3	0.919
Local x264 faster, 4500k	24,353,697	69.5	58.2	0.941
Local x264 faster, 6500k	34,149,879	79.1	69.3	0.974
Local x265 faster, 1000k	6,126,777	58.0	45.6	0.862
Local x265 faster, 1400k	7,918,221	62.9	52.9	0.908
Local x265 faster, 2240k	12,128,323	69.7	60.2	0.945

Two things stand out. HEVC at about 6.1 MB already beats H.264 at 12 MB (58.0 vs 52.1). And H.264 needs about 24.4 MB to match what HEVC does in 12.1 MB. On this clip, compatibility costs roughly 2× the file size at equal quality. Here's what that looks like at 100% (frame 360, a 420×420 crop of the 4K frame):

At 12 MB the H.264 copy breaks the grass and paving into blocks. The HEVC copy at the same size and the H.264 copy at twice the size both hold the fence and stones. Scaled to a phone screen, the 12 MB version looks fine. Full-screen on a 27-inch monitor, you'd notice. If you're not sure how big a target you can afford, the video size calculator turns minutes and a target into a bitrate, and the upload limits page lists the caps per platform.

When to convert HEVC to H.264, and when to keep it

• Convert to H.264 when someone reports audio but no picture, when a web form or LMS rejects the file, when it's going to an older Windows PC or TV, or when you don't know what the recipient will open it with.
• Pick a bigger target for H.264 than you would for HEVC: on detailed 4K footage, about twice the size for the same look. Still far smaller than the phone original (24.4 MB was −79.4% here).
• Keep HEVC when it only goes between Apple devices, recent Android phones, or Windows machines with HEVC support, and the smallest file matters more than playing everywhere.
• Don't convert just to compress. If the file already plays everywhere it needs to, shrinking it as HEVC keeps more quality per megabyte.

If you'd rather the video never leaves your machine, videocompress.dev is a sister tool that compresses in the browser instead.

Method notes

• One real run on vidsmaller.com on 28 Oct 2026, signed out (the free no-sign-up credit), headless Chrome 156 on Linux. Everything else is local and labelled as such.
• The test clip is a 40 s cut from "Walking China - A Stroll in a Classic Chinese Garden in Suzhou City - Xiyuan Temple Garden (4K)" by Walking China, CC BY 3.0, via Wikimedia Commons. The original is HDR VP9; I tone-mapped it to SDR BT.709 and re-encoded it with x265 as a 4K 30 fps HEVC .mov to imitate a phone recording. That re-encode is the "original" all scores are measured against.
• Local encodes: ffmpeg 7.1, libx264/libx265 preset faster, two-pass at the listed bitrates, audio copied. VMAF/SSIM: ffmpeg 8.1 libvmaf, 4K model, every frame, aligned frame by frame.
• The VidSmaller encode reported x264 two-pass at 2207 kb/s with settings matching the "faster" preset (ref=2, subme=4), which is why my local x264 run lands within 0.1 VMAF of it.
• One clip is one clip. Static or low-detail footage will show a smaller gap between the codecs. Leafy handheld 4K is close to the worst case.

Related: the same H.264 vs H.265 question from other angles — when the size target still fails (DEV.to), when the file still won't fit (Medium), and measured before you pay for H.265 (Hashnode).