Why a file refuses to play
Almost everyone has hit the same wall. A video arrives — a recording from a relative, an episode saved for a flight — and the player already on the machine simply shrugs.
Sometimes there is an error message, sometimes a black rectangle, and sometimes — most confusingly — the picture runs perfectly while the sound never arrives. Video and audio are decoded separately, so a player can draw H.264 frames beautifully and still have no idea what to do with the Dolby Digital stream beside them. The instinct is to blame the file. Usually the file is fine, and what has gone wrong is a mismatch between what the file contains and what the player knows how to read.
Before you re-download anything: none of these symptoms reliably indicates a corrupt file. Try a player with a broader decoder library first.
Containers and codecs, plainly
Think of a video file as a lunchbox. The lunchbox is the container: MP4, MKV, AVI, MOV, WebM. Its job is to keep the picture and the sound in step. It does not tell you what is inside.
The codec is what is inside — the method used to squeeze picture and sound down to a sensible size. H.264 is the long-standing default and plays almost everywhere; HEVC does the same work in roughly half the space, which is why 4K phone recordings use it; AV1 is newer and common on streaming platforms. For audio, AAC, MP3 and AC-3.
So two files can both end in .mp4 and behave completely differently: the
extension describes the lunchbox, not the sandwich. An .mkv is not a type of
video but a flexible container, favoured by people who want several audio and subtitle
tracks in one file.
Subtitles: formats, sync and where they live
Subtitles arrive in three arrangements. Burned in means the words are
painted into the frames themselves, so nothing can turn them off or restyle them.
Muxed means the track lives inside the container as its own stream —
normal in MKV, switchable from the player. Sidecar means a separate file,
usually .srt, beside the video with a matching name: put
episode.mkv and episode.srt in one folder and a competent player
loads both.
Sync is a separate problem. Subtitles carry timestamps, and if those were written for a release with different opening credits the text drifts; a player worth using puts a delay control on a keyboard shortcut. If the gap stays constant, a fixed offset fixes it. If it grows as the film goes on, the file was timed for a different frame rate and needs a speed adjustment instead.
Audio tracks and dialogue clarity
A single file can carry several audio streams: an original-language mix, a dub, a commentary, an audio-description track. Whether you can reach them depends entirely on the player — plenty quietly take the first and give no sign the others exist.
Channel layout matters just as much. A 5.1 mix played through headphones has to be folded down into two channels, and a careless downmix is exactly what makes dialogue sound distant while explosions feel enormous: the centre channel, where almost all speech lives, gets buried.
Hardware decoding, and the local-file trade
Every modern processor and graphics chip contains fixed-function blocks built to decode particular codecs — H.264 almost universally, HEVC widely, AV1 on recent hardware. Decoding there is far more efficient than general-purpose arithmetic on the same chip, which is why one player runs a 4K file coolly while another turns a laptop into a hairdryer.
Acceleration is codec- and generation-specific, though, and hardware decoders are stricter than CPU-based ones, so a few unusual files play correctly only with it switched off — which is why the setting matters as much as the capability.
That is the local-file trade. A streaming service knows what your device can decode and adjusts as your connection wobbles; a local file makes none of those adjustments. It needs no network and keeps every track it was built with — in exchange you take on the decoding, which is why dedicated player apps exist.