fundamentals · 5 min read
Video metadata explained
Every video file contains metadata: a description of how the picture and sound are stored, written by the camera, encoder or editing app that produced it. The container names the tracks and their timing; the codecs describe how each track is compressed.
Reading that metadata before converting or uploading a file separates problems you can fix from problems you cannot. Two files can look identical in a folder listing and still be encoded in completely different ways.
The two layers: container and codec
The container is the wrapper: MP4, MOV, WebM, Matroska and AVI all store video tracks, audio tracks, timestamps and an index inside a defined structure. The codec is the compression method used in a track, such as H.264, HEVC, VP9 or AV1 for video and AAC, Opus or AC-3 for audio. The file extension names the container, never the codec, which is why an .mp4 file can contain anything from a ten-year-old H.264 stream to a modern AV1 encode.
A player needs to understand the container and have decoders for every track it is asked to play. Metadata records both layers, so it tells you what a device has to support before you ever press play. It also tells you what the metadata does not: it does not measure how good the video looks. Quality comes from the resolution, bitrate, encoder settings and, above all, the source the file was made from.
The numbers that decide playback and file size
Resolution is the pixel grid, for example 1920 by 1080 or 3840 by 2160. Frame rate is how many frames are recorded each second, and it may be constant or variable; a variable frame rate from a phone screen recording can confuse editors that assume a fixed rate. Bitrate is how much data per second the encoder spends, usually reported as an average with a peak ceiling. Two files with the same resolution and duration can differ in size by an order of magnitude because of bitrate alone.
Color metadata is where compatibility problems hide. An 8-bit SDR file using the BT.709 primaries plays almost everywhere. A 10-bit HDR file using PQ or HLG transfer and BT.2020 primaries carries much more color information, but it needs a decoder and display that understand HDR; on a player that ignores the HDR metadata it can look washed out or oddly saturated. Audio metadata matters too: sample rate, channel count and codec decide whether a device can play the sound at all.
How a player decides what it can play
A player inspects the container first, then each track's codec and profile. H.264 has profiles such as Baseline, Main and High, and HEVC has Main and Main10; a decoder supports some profiles and not others, and the level field caps resolution and bitrate combinations. A file can therefore be an H.264 MP4 and still fail on an old device if it uses a profile or level that hardware cannot handle.
The player also checks the color pipeline and the audio. A television might decode HEVC 10-bit but have no HDR display, so the picture appears dim or flat. A laptop might play the video track but have no decoder for AC-3 audio, leaving a perfect picture with silence. For playback over a network, the location of the container index matters as well: an MP4 whose index sits at the end of the file has to download much further before it can start.
Why one file plays and an identical-looking one does not
The most common case is a matching container with a different codec. Two .mov files from two phones may both be QuickTime containers, while one holds H.264 and the other holds 10-bit HEVC; the second is the file that a Windows machine or an Android app refuses. MKV and WebM files hit the same wall from the other direction: desktop players and browsers are comfortable with them, while many televisions and upload forms are not.
Other differences come from settings rather than codecs. A high-profile encode may exceed an older decoder, an unusual audio track may be dropped, and HDR content may play with the wrong color if the player ignores its metadata. A truncated download leaves the index missing altogether, which looks like a codec failure but is really a broken file. The symptoms are similar; the metadata distinguishes them.
- Same extension, different codec: check the stream codec, not the file name.
- Plays but silent: check the audio codec and channel layout.
- Plays but looks wrong: check bit depth, color primaries and transfer characteristics.
- Fails everywhere: check that the file is complete and its index is intact.
Inspecting a file before converting or uploading
A media-info utility, a desktop player's properties panel, or the command line can all print a file's streams. With FFmpeg, running ffmpeg -i on the file summarizes the container, stream codecs, resolution, frame rate, bitrate, pixel format and color tags without re-encoding anything. A media-info app presents the same facts as a readable list, including duration and audio layout.
Read the report in order: container, video codec and profile, resolution and frame rate, bit depth and color tags, audio codec and channels, then duration and bitrate. From there the decision is usually obvious. A file whose codec is already widely supported only needs a container change. A 10-bit HDR phone clip destined for an unknown laptop needs a re-encode to 8-bit H.264. An enormous high-bitrate file for a size-limited upload form needs compression, not conversion. Knowing the metadata makes each of those choices deliberate instead of hopeful.