Delivery pre-flight

Catch the obvious mismatches before you upload.

Pick a delivery spec, drop in a file, and see how its header stacks up: container, resolution, frame rate, scan type, bit depth, chroma and audio layout, checked against the real broadcaster profile. The file is read in your browser; nothing is uploaded.

Drop a file, or click to choose

MOV, MP4 or MXF OP1a. Only the header is read. Nothing is uploaded.

What a header check can’t tell you

This reads container metadata only. These need a full decode:

  • Loudness (LUFS) & true peak: Requires decoding and measuring the full audio.
  • PSE / flash & pattern risk: Frame-by-frame luminance analysis; not in the header.
  • GOP structure & compliance: Needs bitstream inspection, not container metadata.
  • Subtitle timing & reading speed: Depends on the caption payload, not the wrapper.
  • Package & structure (AS-11 DM, sidecars, checksums): Whole-deliverable checks beyond a single file’s header.
  • Actual colour vs signalled: Flags may be present but wrong. Only measurement confirms.
  • Blanking, AFD, freeze/black frames: Pixel-level checks that a header can’t see.

A header check is a first pass, not a QC

Reading a file’s container tells you the structural facts quickly and for free, and catches the errors that cause most rejections: wrong resolution, an interlaced master where progressive was asked for, 8-bit instead of 10, a stereo pair where 4+ tracks were required. But a header can be wrong (colour flags that don’t match the pixels) and it says nothing about what’s actually in the frames or the audio.

Loudness, true peak, PSE/flash risk, GOP structure, subtitle timing and whole-package structure all need the file decoded and measured, which no header can stand in for. Use this to fail fast; use a full QC to sign off. Codec is shown for reference only. A header can’t confirm the exact profile, level or bitrate a spec demands.

Header parsing by MediaInfo (BSD), compiled to WebAssembly and running entirely client-side.