Reference Glossary
Container format
A file 'wrapper' — such as MP4, MOV, or MXF — that bundles video, audio, subtitle, and metadata tracks together, without itself determining picture or sound quality; that's the codec's job.
Why it matters in a DAM
A DAM's ingest and transcoding logic needs to treat container and codec as two separate fields, because the same MP4 container can hold very different codecs — H.264 for web delivery or a much heavier editorial codec — with very different quality and file size, so filtering assets by extension alone tells a user nothing about whether a file is web-ready or edit-ready. Broadcast and post-production teams frequently require a specific container (MXF) independent of the codec inside it, so technical metadata needs to capture both attributes on their own.
A worked example
Common mistake
Assuming every .mov file is functionally the same 'type' of asset for routing or transcoding, when a .mov could wrap anything from a heavy ProRes 4444 editorial master to a small H.264 proxy — the extension alone doesn't say what's actually inside.
A container format is the outer box: it organizes video, audio, subtitle, and metadata tracks into one file and defines how a player finds and synchronizes them, but it doesn’t compress the audio or video itself. That job belongs to the codec inside it. MOV, developed by Apple for QuickTime, and MP4, standardized by ISO as a universal format, are both containers — either one can hold identical picture quality if it wraps the same codec at the same settings.
This separation matters for how a DAM’s technical metadata is structured. A single ‘file type’ field that only records the extension conflates two independent decisions — what the file is wrapped in, and what’s compressing the data inside it — and loses information a transcoding pipeline or editorial handoff actually needs. Recording container and codec as distinct fields lets a DAM answer ‘is this edit-ready’ and ‘is this web-ready’ as two different, accurate questions instead of one ambiguous guess based on the file extension.
Frequently asked
What is a container format?
A container format is a file "wrapper" — MP4, MOV, or MXF — that bundles video, audio, subtitle, and metadata tracks into one file, the way a shipping box holds separately packaged items. The container itself doesn't compress or decompress anything; it just organizes tracks. Quality comes from the codec sealed inside, not from the wrapper's file extension.
What actually determines a video file's quality if not the container?
Quality is set by the codec doing the actual compression — H.264, H.265/HEVC, or ProRes — combined with the bitrate and resolution chosen at encode time, not by the container wrapping the file. Two .mp4 files can look identical in a file browser yet be a heavily compressed web proxy and a near-lossless master, purely because their codec and bitrate settings differ.
Why can't a DAM tell if a file is web-ready just from its extension?
Because the file extension only names the container, not what's compressed inside it. A .mov file could wrap a heavy ProRes 4444 editorial master meant for an edit suite, or a small H.264 proxy meant for the web — both carry the same .mov extension. Without reading the actual codec, bitrate, and resolution in the file's technical metadata, a DAM has no way to distinguish an edit-ready master from a web-ready delivery file.
Why do broadcast workflows specifically require MXF?
Broadcast and post-production pipelines standardize on MXF because it's built, per SMPTE 377M, as a wrapper for both audiovisual essence and rich descriptive metadata — timecode, production, and technical details — that broadcast systems from different vendors need to read consistently. MXF can carry various codecs, such as DNxHD or XDCAM, without changing the wrapper, so equipment and software from different manufacturers can exchange files reliably across a broadcast chain.
What's the DAM metadata mistake around container and codec?
Recording only a single "file type" field based on the extension conflates two independent decisions, what the file is wrapped in and what's compressing the data inside, losing information a transcoding pipeline or editorial handoff needs.
How should container and codec be tracked in a DAM?
As two separate metadata fields rather than one file-type label lumped together. The container field records the wrapper (MP4, MOV, MXF); a distinct codec field records what actually compressed the video and audio inside it (H.264, ProRes, DNxHD, and so on), ideally alongside bitrate and resolution. Keeping them apart lets a DAM answer "is this edit-ready" and "is this web-ready" as separate, accurate questions instead of guessing from the extension.
Sources
- A container holds video, audio, and metadata tracks; the codec inside it is what actually compresses and decompresses the data, and the same codec can be wrapped in different containers. checked 2026-08-07 — Cloudflare