Tutorials Developer

Why Your Video Won't Play on Some Devices

By Infinite Creation · Intermediate · ~14 min

A 1960s mid-century comic book style editorial illustration showing two engineers at terminals in a machine room, with code on a terminal screen, a rack of servers, a job queue board visible in the frame.

Overview

A video file that plays fine on one device or piece of software but fails or looks wrong on another almost always comes down to a codec or container compatibility mismatch, and checking the specific codec and container combination against the failing device's supported formats is more useful than assuming the file itself is corrupted.

What You Need

Whatever gear produced the problem. This is a diagnostic guide, not a gear-buying tutorial

Steps

Check the video's codec and container format

A video file's container (like .mp4 or .mov) and the actual codec used to compress the video inside it (like H.264 or H.265) are two separate things, and a device or piece of software can support a container format while lacking decoding support for the specific codec inside it. Use a media info tool to check exactly what codec and container your file actually uses, rather than assuming from the file extension alone.

Check whether the failing device supports that specific codec

Older devices or software frequently lack hardware or software decoding support for newer, more efficient codecs (H.265/HEVC or AV1, for example) even when they handle the older, more universally-supported H.264 codec without issue. Check the failing device's specifications or software version against your file's specific codec requirements.

Check for an unusual or incompatible container feature

Some container-level features (variable frame rate recording, unusual audio codec pairings, or non-standard metadata) can cause playback problems even when the core video codec is widely supported: re-exporting or re-muxing the file into a more standard, widely-compatible container and codec combination (like H.264 in an .mp4 container) often resolves these edge-case compatibility issues.

The reliable fix: re-encode to a widely-supported baseline format

When compatibility across many unknown devices matters more than maximum quality or efficiency, re-encoding to H.264 video in an .mp4 container remains the most broadly compatible combination across the widest range of devices and software, even though it isn't the newest or most efficient codec available, a deliberate compatibility-over-efficiency tradeoff worth making for widely-distributed files. Set the pixel format as well: 8-bit 4:2:0, which is -pix_fmt yuv420p in FFmpeg. In the test below, re-encoding a 4:4:4 master without it kept 4:4:4, and Firefox refused the result.

Tested: ten files, four players, one Mac

We tested steps 1 to 4 on 2026-09-25 with FFmpeg 8.1.2, on a Mac with an Apple M1 Max chip running macOS 26.6.2. We made the ten files in the table, each ending in .mp4 or .mov and holding the same three-second 720p test pattern and a tone, and read each one with ffprobe. Then we tried to play every file four ways: through AVFoundation, the media framework built into macOS, and in a video element in Safari, Google Chrome and Firefox. We also asked the Mac's hardware video decoder to decode every frame of each file on its own.

File	What ffprobe reported	macOS (AVFoundation)	Safari 26	Chrome 153	Firefox 156
H.264 and AAC in .mp4	MP4/MOV: h264 (High), yuv420p, aac	Played, in hardware	Played	Played	Played
HEVC in .mp4, as FFmpeg tags it	MP4/MOV: hevc (Main), tag hev1, yuv420p, aac	Would not decode	Refused	Played	Played
The same HEVC, copied with -tag:v hvc1	MP4/MOV: hevc (Main), tag hvc1, yuv420p, aac	Played, in hardware	Played	Played	Played
AV1 and AAC in .mp4	MP4/MOV: av1 (Main), yuv420p, aac	Would not decode	Refused	Played	Played
VP9 and Opus in .mp4	MP4/MOV: vp9 (Profile 0), yuv420p, opus	Would not decode	Played	Played	Played
H.264 with Opus audio in .mp4	MP4/MOV: h264 (High), yuv420p, opus	Played, in hardware	Played	Played	Played
A Matroska file named .mp4	Matroska: h264 (High), yuv420p, aac	Would not open	Refused	Played	Played
ProRes 422 HQ edit master in .mov	MP4/MOV: prores (HQ), yuv422p10le, pcm_s16le	Played, in hardware	Played	No picture in 8 seconds	Refused
ProRes 4444 master re-encoded to H.264 .mp4, nothing else set	MP4/MOV: h264 (High 4:4:4 Predictive), yuv444p10le, aac	Played, in hardware	Played	Played	Refused
The same, with -pix_fmt yuv420p added	MP4/MOV: h264 (High), yuv420p, aac	Played, in hardware	Played	Played	Played

ffprobe named the container correctly every time, including the Matroska file named .mp4. macOS would not open that file at all, and Safari refused it. Chrome and Firefox played it anyway. The extension told us nothing that ffprobe did not, which is step 1's point.

AV1 and VP9 are step 2 on a single machine. This Mac's hardware decoder took neither, and AVFoundation would not decode either. Safari refused the AV1 file but played the VP9 one, and Chrome and Firefox played both. The same file can play in one app and fail in another on one computer, even in two apps from the same company, so "it plays on my machine" depends on which player you mean.

The two HEVC rows hold the same encoded video: their video streams have the same MD5. Only the four-letter code the container stores for the stream differs. FFmpeg wrote hev1 by default, and neither AVFoundation nor Safari would play it. Copying the file with ffmpeg -i input.mp4 -c copy -tag:v hvc1 output.mp4, which does not re-encode anything, made it play in both, in hardware in AVFoundation. This is step 3's container problem at its smallest.

Step 4 needs one more setting than it names. Re-encoding a ProRes 4444 master to H.264 in .mp4 with nothing else set kept the master's 4:4:4 colour sampling. FFmpeg wrote 10-bit 4:4:4 video (yuv444p10le) in the H.264 profile called High 4:4:4 Predictive. Firefox refused it, reporting that its decoder may not handle 4:4:4. Adding -pix_fmt yuv420p gave the ordinary High profile, and every player took it. We re-encoded the ProRes 422 HQ master the same way. It came out as High 4:2:2, yuv422p10le, which all four players here accepted. A device specification that lists H.264 High Profile does not cover either, because each is a separate profile.

Opus audio in .mp4, the kind of unusual audio pairing step 3 warns about, gave no trouble here. It played in all four players, and AVFoundation decoded its sound. The ProRes .mov, as it might come straight from an edit, played in AVFoundation and Safari. Chrome showed no picture within 8 seconds and Firefox refused it.

The step 4 re-encode with the missing setting, as we ran it: ffmpeg -i master.mov -c:v libx264 -pix_fmt yuv420p -c:a aac output.mp4

Validated. Measured 2026-09-25 with FFmpeg and ffprobe 8.1.2 on an Apple M1 Max Mac running macOS 26.6.2, with Safari 26.6.2, and with Google Chrome 153.0.8010.54 and Firefox 156.0.1 run headless. "Played" means the player decoded video frames from the file. Safari under automation would only play after a click, so there the test clicked play and checked that playback moved on and that a frame drawn from the video was not blank. A Safari file that failed to start was tried up to three times. A file Safari rejected as unsupported was not retried. No file needed a second try in this run. "In hardware" means VideoToolbox decoded every frame with hardware required. These results are for this Mac only. We did not test phones, televisions, games consoles or Windows, and other Macs may have hardware decoders this one lacks.

Pro Tips

Use a media info tool to check your file's actual codec and container, rather than assuming from the file extension. A .mp4 file can contain several different codecs with very different compatibility levels.
If a file needs to play reliably across many unknown devices, re-encode to H.264 in an .mp4 container as a safe, broadly compatible baseline rather than assuming a newer codec will be universally supported.
Check the specific failing device's specifications or software version against your file's codec requirements before assuming the file itself is corrupted.

Knowledge Base

What You'll Learn

Video files that play on some devices but not others almost always come down to a codec or container compatibility mismatch rather than file corruption, and re-encoding to a widely-supported baseline format (H.264 in .mp4) resolves the vast majority of these compatibility issues.

Quick Diagnostic Checklist

What specific codec and container does the file actually use (checked with a media info tool, not assumed from the extension)?
Does the failing device or software have documented support for that specific codec?
Does the file use any unusual container features (variable frame rate, uncommon audio pairing)?
Would re-encoding to H.264/.mp4 resolve the compatibility issue as a broadly-supported baseline?

When to Escalate

If a file still won't play correctly after re-encoding to a widely-supported baseline format, consider whether the file itself has actual corruption (try re-exporting from the original source project rather than the already-exported file) or whether the failing device has a more fundamental hardware limitation.

Where This Fits

Codec and container mismatches are one of the failures Building Media Applications explains in the context of a whole application.

FAQ

Q: Why does my video play on my computer but not on someone else's device?
A: This is almost always a codec or container compatibility mismatch. The video may use a codec (like H.265/HEVC or AV1) that the other device lacks decoding support for, even though your own computer or software handles it fine. Checking the file's actual codec with a media info tool is the first diagnostic step.

Q: What's the safest video format to use if I need it to play on almost any device?
A: H.264 video in an .mp4 container remains the most broadly compatible combination across the widest range of devices and software, even though newer codecs like H.265 or AV1 are more efficient. It's a deliberate compatibility-over-efficiency tradeoff worth making when reaching unknown or older devices matters. Set 8-bit 4:2:0 as the pixel format too (-pix_fmt yuv420p in FFmpeg). In the test on this page, FFmpeg kept a 4:4:4 master's colour sampling when re-encoding without it, and Firefox refused that file.