The file isn't broken, you just can't see it
Why VLC plays everything and your NLE doesn't. Containers vs codecs vs colour metadata, and what 'unsupported format' actually means.
The client sends you a file. You double-click it. QuickTime Player shows a black screen. You drag it into Premiere. “Unsupported format.” You open it in VLC. It plays fine. What’s going on?
The file isn’t broken. Your tools just have different ideas about what they’re willing to decode, and none of them are explaining the disagreement.
Containers vs codecs (for the last time)
A video file has two layers: the container and the codec. The container (.mov, .mp4, .mxf, .mkv) is the box. It holds video, audio, timecode, and metadata in an organised structure. The codec (H.264, ProRes, DNxHR, HEVC) is the language the video data is encoded in.
VLC plays everything because it ships every decoder ever written. It doesn’t care if the container is weird or the codec is obscure; it’ll try to decode whatever it finds.
Professional tools are pickier because they have to be correct, not just functional. Premiere won’t play a file if it can’t guarantee frame-accurate scrubbing. Resolve won’t import a container variant it hasn’t tested. These aren’t bugs; they’re different priorities.
Why VLC isn’t the answer
It’s tempting to think VLC is the better tool because it plays everything. But VLC’s tolerance is the flip side of its limitation: it will play a file that’s genuinely damaged, silently papering over missing frames, corrupted headers, or broken index tables. It’ll play an interlaced file progressively without telling you. It’ll interpret colour metadata however it pleases. For playback, for checking whether a file contains something, it’s fine. For verifying that a file is correct, it’s actively dangerous.
Professional tools reject files they can’t handle precisely because precision matters downstream. If Resolve imports a file, you can be confident that every frame is addressable, the timecode is readable, and the decode is bit-accurate. If it rejects a file, it’s telling you something useful, even if the error message is unhelpfully vague about what.
The colour metadata problem
Even when a tool can decode the video, it might display it wrong. The container can carry colour metadata (primaries, transfer function, matrix coefficients) but these fields are often missing, mislabelled, or ambiguous.
You need three pieces of information to display video correctly. What colour primaries define the gamut (Rec. 709? P3? Rec. 2020?). What transfer function maps between light and code values (gamma 2.4? PQ? Log-C?). What matrix converts between RGB and YCbCr (BT.601? BT.709? BT.2020?). Get any one of those wrong and the picture shifts, sometimes subtly, sometimes drastically.
Same file, different colour interpretation. The data hasn't changed, only the assumption about what it represents.
The common scenario: a camera records in Rec. 709 colour space but the file’s metadata tags are missing. Player A assumes Rec. 709 because that’s the sensible default. Player B assumes sRGB, which is nearly the same but not identical (the transfer function differs slightly). Player C assumes P3 because the file came from a modern camera and P3 is increasingly common. Three players, three different-looking images, zero errors in the decode. Every tool renders a different image from the same data. Every player is doing exactly what it thinks is right based on the information it has.
This is why Phosphor’s receipt system exists. It makes the colour interpretation explicit. Instead of guessing which assumptions your tools are making, you see the resolution chain: what the file said, what was inferred, what was assumed, and which rule won.
When the file actually is broken
Sometimes the file is genuinely damaged. But even then, “broken” usually means something specific and fixable:
Truncated file. The transfer was interrupted. The container’s index is incomplete. The video data is fine up to a point and then stops. Re-transferring fixes it. Re-encoding does not.
Corrupted header. The metadata at the start of the file is damaged, so players can’t find the video stream. The actual frames might be intact. Tools like FFprobe can often read past the damage and tell you what’s inside.
Mismatched container/codec combination. Someone muxed HEVC video into a .mov container using a tool that doesn’t write the sample description correctly. The video data is perfect. The container’s labelling is wrong. Re-wrapping into a clean container fixes it.
Missing codec. The file is perfectly valid, but your system doesn’t have the decoder installed. This is less common now than it was in the QuickTime-component era, but it still happens with proprietary camera codecs like CinemaDNG, REDCODE, and ARRIRAW. The file isn’t broken; your machine just doesn’t speak the language.
Re-wrap vs re-encode: knowing the difference saves hours
When you hit a compatibility problem, you have two tools. Re-wrapping changes the container without touching the video data. Re-encoding decodes the video and encodes it again in a different format. They solve different problems, and using the wrong one either wastes time or wastes quality.
Re-wrap when: the video codec is fine but the container is wrong. You have an H.264 stream in an .mkv and you need it in an .mp4. You have ProRes in a .mov with a corrupted header and you need a clean .mov. Re-wrapping takes seconds, produces an identical-quality result, and doesn’t require a render.
Re-encode when: the codec itself is the problem. Your NLE can’t decode the camera’s native format. The file is in a long-GOP codec and you need an intraframe codec for editing. The colour space is wrong and needs conversion, not just re-tagging. Re-encoding takes time and introduces a generation of compression, but it’s the only option when the actual video data needs to change.
The mistake people make is jumping straight to re-encoding because it feels more thorough. You get a file that doesn’t play in Premiere, so you transcode it to ProRes in Media Encoder, wait twenty minutes, and import the result. That works, but if the problem was a container incompatibility, you just spent twenty minutes doing something that FFmpeg could have done in three seconds, and you introduced an unnecessary quality loss in the process.
Practical diagnostic steps
When a file doesn’t behave, work through this sequence before you reach for the transcode button:
Step one: probe the file. Use FFprobe or MediaInfo to read the container structure and codec information. You’re looking for the codec name, the colour metadata tags, the frame rate, and whether the container index is intact. This takes two seconds and tells you more than any error dialogue will.
Step two: try a different player. If QuickTime won’t play it but VLC will, the problem is almost certainly a missing codec or an unusual container variant, not a broken file. If neither will play it, the file might genuinely be damaged.
Step three: check the colour tags. If the file plays but looks wrong (washed out, over-saturated, greenish) the colour metadata is probably missing or mislabelled. Compare what the file says (via FFprobe) with what your player is assuming. The gap between those two things is your problem.
Step four: try a re-wrap before a re-encode. If the codec is one your NLE supports but the container is the issue, a quick ffmpeg -i input.mkv -c copy output.mov might be all you need. No quality loss, no render time, no drama.
Step five: if you must re-encode, be deliberate. Choose a codec your pipeline trusts. Match the resolution, frame rate, and colour space of the original. Don’t let your encoding tool make assumptions; specify everything explicitly. The goal is to change the format without changing the content.
The file almost certainly isn’t broken. Your tools are just disagreeing about how to read it, and the path from “unsupported format” to a working file is usually shorter than you think, if you diagnose before you transcode.