The Same Video Plays on Your Mac but Not on Your Phone: A Layer-by-Layer Checklist, With Real Readings

When a file opens on one device and refuses on another, the cause is usually not picture quality, and it is usually not a broken file. Before a single frame is drawn, four layers each get their own verdict, and any one of them being wrong produces the same visible result: "it won’t open". So the first move is not to re-run the file through a different tool. It is to read the file and find out which layer stopped you.

1. Four verdicts land before the first frame appears

• The container. Whether the device is willing to open the file at all. It decides "does it open", not "does it look good".
• The label on the video track. One and the same HEVC picture can be announced in two different ways inside the MP4 family of containers. Two files whose video is byte-for-byte identical can behave in opposite ways.
• The audio tracks. A file with a perfect picture can still be rejected, or open in silence, because of one audio track.
• The subtitle tracks. Text subtitles and image subtitles are two kinds of data, and an MP4 subtitle track is built around text.

The four layers are judged separately, so the symptoms are separate too: wrong container and the file never opens; wrong label and it opens but the picture does not move; wrong audio and it opens with no sound; wrong subtitle and the film is fine while the subtitles are gone. Collapsing those four into "this tool does not work" is the most common misdiagnosis in the whole category.

2. Read the file first; do not swap tools

Go layer by layer. Any inspection tool that lists a file’s internal structure will separate the container, the encoding name of each track, the track label, the bit depth, the pixel format, the duration and the byte count. That step costs a few minutes and replaces hours of trial and error.

Every reading below was taken on one machine in one pass; the environment is stated in section 8.

Both files come from the same two-minute piece of picture, with not one frame re-encoded, and their byte counts are identical. The only difference between them is that four-character track label.

Renaming the file changes none of the four layers. Re-encoding the picture at a high bitrate does not change the layer that is blocking you either. Locate first, then act.

3. The label layer: one picture, two ways to write it

Inside the MP4 family an HEVC stream is announced as hvc1 or hev1. The difference is where the decoder configuration lives. hvc1 places it in the track’s sample description, so a reader can configure the decoder before it touches the first frame; hev1 allows that data to travel inside the stream instead. A reader that needs the configuration up front will not wait for it to turn up halfway.

This layer does not require re-compressing a single frame: the picture is carried over as a copy and only the track label is rewritten. That pair of samples above came from exactly that — the same picture written twice, the outputs the same size to the byte.

What is worth remembering about this layer is its cost: it is a copy operation, not a re-encode. Anything that can be resolved at this layer should never be attempted with a fresh compression.

4. The audio layer: a flawless picture can still be held hostage

Once the picture has been accepted, the only thing left deciding "plays or does not, sound or silence" is the audio. The real inventory in this area is wider than most people assume: one and the same batch of material has been seen carrying TrueHD, E-AC3, AC-3, Opus, FLAC, MP2, MP3, DTS and PCM.

In both runs the picture was never re-compressed; the whole difference sits in the sound — one format had to be rewritten, the other travelled as it was. There is a second lesson that only appears when you count the tracks one by one: a job that inspects only the first audio track is exactly how you end up with a file that opens in silence. On a multi-language title, the language you want is often sitting on track two.

5. The subtitle layer: text and images are different data

The text kind (SRT, ASS) arrives in the destination container still as text, and the font size and colour remain yours to change. The image kind — the Blu-ray style subtitles stored as pages of pictures, and the versions carried by DVDs and set-top box recordings — are literally photographs of subtitles. An MP4 subtitle track is built around text, and there is no slot in it shaped like a picture.

Two routes exist: read the words back out of the pictures and carry the resulting text, or lose that subtitle. Reading is a capability, not a guarantee — recognised text can contain mistakes, so it should be checked before delivery. Neither route touches the picture: not one pixel moves, and burning words into the frame is a different product, because it creates a new video track instead of giving you back your own file.

Asking "do you support subtitles" is meaningless. The question is: is this track mine text or a picture, and after conversion is it still the same kind of thing?

6. A file can be read; a device cannot

This checklist walks you as far as "which layer needs to change". It will not decide whether one particular machine accepts the result: bit depth and profile, colour metadata, frame rate, 4:2:2 chroma and long GOP structures only get answered on a device. The same batch of samples contains both Main 10 and Main 8, some with colour metadata and some without — those differences are readable in the file and decidable only in playback.

• "It is HEVC" is not an answer. Reading the label, the bit depth, the audio and the subtitles is what narrows the problem down to one or two layers.
• The same picture running fine in one container does not mean this container has been proven — the box and the encoding are two separate variables.
• Short samples prove structure. They do not prove behaviour around size or quality; those conclusions come from long features and real devices.
• No compatibility table deserves blind trust, including this page. Playing your own file on the device in question is the only acceptance test that counts. The containers and encodings that have been verified on real devices are listed here.

7. The order to work through

1. Read the inside. Container, video-track label, every audio track, every subtitle track — one pass, all of it listed.
2. Container. If the file is not in a container family the target device opens, that alone explains "it never opens", however perfect the picture inside is.
3. Track label. Right container, HEVC video, but the reader never gets its configuration: fix the label. This is a copy, not a re-encode.
4. Audio. List every track, not just the first. Deciding which language should end up in front is a deliberate choice, not a coincidence.
5. Subtitles. Text travels; images can only be recognised or dropped.
6. Only then consider re-making the picture. The class of problem a label cannot fix needs fresh encoding, which is a slower job with its own size limits.

Get the order wrong and a person will perform the same mistake three times on the same machine.

8. Where these readings come from, and what we build

Every figure above came from one pass on one machine: Apple M2, macOS 27.2, command-line inspection tool 9.0.2. The samples come from our own test pack. B and C were written from the same in-house clip: the source is a two-minute file we produced ourselves (HEVC Main 10, 1920×1080, yuv420p10le, one AAC audio track, reading 14,956,756 bytes), and B and C copy its video into two MP4 files with nothing re-compressed, changing only the track label — their byte counts are in the table above; G through L were built around disc-era audio and subtitle formats. No sample file is redistributed on this page — every structure discussed here can be rebuilt from material you already own.

We build one product for iPhone, iPad and Mac, and its output is one container: MP4. There are no bitrate, encoder or resolution knobs; the decision taken on your behalf is a choice of three routes — change the container, change the container and rewrite the audio, or re-encode the picture. A file that already plays is not a conversion: the app does not create a second copy of it and does not count it. The payment shape is a one-time purchase (called Opus inside the product), and it changes only how many conversions you can make afterwards — that is spelled out here.

• Content protected by DRM is not handled, including titles rented or bought from a store.
• Subtitles that were never text can be recognised into text; recognition makes mistakes, the picture is untouched, and nothing is burned into the frame.
• When a subtitle is rebuilt, the distinction between Simplified and Traditional Chinese is lost.
• On the route where the picture is re-made, a result that would come out larger than the source is stopped rather than delivered.
• The work happens on your device, so the file itself does not need to be handed anywhere else; and the Mac version is not the iPhone version — we do not pretend otherwise.

Frequently asked questions

Can I just rename .mkv to .mp4?

No, and this step has never been a shortcut. The extension is a label; renaming it rewrites neither the structure inside the container nor the picture encoding. A device reads the structure when it opens the file, not the filename. All a rename buys you is the loss of the ability to tell which layer failed.

If only the label changes, does anything else change in the file?

No. That pair of samples reads back with exactly the same byte count (12,973,400 both), with not one frame re-encoded. That is precisely the value of this layer: a problem that can be closed with a copy should not be attacked with a re-compression.

My film has five audio tracks — will four of them disappear?

Tracks are judged one by one, not file by file. The ones that can travel do travel; the one that cannot gets re-encoded. What actually produces "only one track left" is a job that looks exclusively at the first track. Before you start, count which position holds the language you want.

Can an image subtitle go into an MP4 unchanged?

No. An MP4 subtitle track is built around text, and an image has no matching slot. The only two options are recognising it into text and carrying that (with mistakes to check), or leaving that subtitle behind. There is no third method that preserves the original graphics and still lands in a text track.

Can these readings be reproduced on my machine?

The inside of a file is readable anywhere — whatever inspection tool you use lists the same structure. What cannot be reproduced from a page is the second half: whether a given device accepts the result, which only one real playback can tell you. This page hands you an order of judgement, not a table to trust.

Axiom One LLC — CineX