Video files with embedded chapters, full container tags, attached cover art and a SMPTE start timecode — each paired with a deliberately stripped twin, so you can tell a metadata reader that found nothing from one that was never given anything.
Four named chapters — Cold Open, Titles, Main Segment, Credits — on two-second boundaries. The clip burns the chapter name and a running timecode into the picture, so the chapter marks can be verified by eye against what the player's chapter menu claims. Matroska stores chapters as a proper EditionEntry structure with nanosecond timestamps and per-language names, and every desktop player exposes them. This is the reference case.
Four named chapters — Cold Open, Titles, Main Segment, Credits — on two-second boundaries. The clip burns the chapter name and a running timecode into the picture, so the chapter marks can be verified by eye against what the player's chapter menu claims. MP4 has no chapter box. FFmpeg writes them as a QuickTime chapter track — a hidden text track referenced by the video track — which QuickTime, VLC and most desktop players read and which browsers ignore completely. Remux this to MKV and back and the chapters usually survive; convert it with a tool that maps streams individually and they usually do not.
The same clip with the chapter marks explicitly removed. The control for this group, and the file that tells you whether a chapter reader returns an empty list or reports the whole-file duration as a single unnamed chapter — both are common, and they are not the same answer.
The XML dialect `mkvmerge` and `mkvpropedit` read to write chapters into a Matroska file without re-muxing it. Timestamps are nanosecond-precision `HH:MM:SS.nnnnnnnnn`, and each ChapterAtom carries a UID that must be stable across edits — the field most hand-written generators omit, which is why re-running them renumbers every chapter.
FFmpeg's own metadata format, and the one used to build the two embedded-chapter files in this group. START and END are integers in the declared TIMEBASE, which is the detail that trips people up: change TIMEBASE and every timestamp silently means something else. This is the exact file the MKV and MP4 chapter fixtures here were built from.
A WebVTT file intended for `<track kind="chapters">` rather than `kind="subtitles"`. Structurally it is an ordinary WebVTT file, which is the point — nothing inside it says 'chapters', so the same bytes behave as captions if the kind attribute is wrong, and the chapter titles are rendered over the video as subtitles. A common and very visible mistake.
The plain-text convention used in video descriptions: `M:SS Title`, one per line, first entry at zero. There is no specification, so every parser guesses — at leading zeros, at `HH:MM:SS` versus `M:SS`, at whether a dash or a dot separates the timestamp from the title. Useful for testing a scraper against the format people actually paste.
Eight container-level metadata fields written into the same eight-second clip, so a metadata reader can be checked against a file whose expected values are published rather than guessed. Every value is obviously sample data. MP4 stores these in an iTunes-style `moov/udta/meta/ilst` atom, with fixed four-character keys. Fields outside that vocabulary — `description` here — are written as freeform `----` atoms that many readers skip, so a tag can be present in the file and invisible to the tool you are testing.
Eight container-level metadata fields written into the same eight-second clip, so a metadata reader can be checked against a file whose expected values are published rather than guessed. Every value is obviously sample data. Matroska stores tags as arbitrary name/value SimpleTags scoped to a target level, so it has no fixed vocabulary and nothing is dropped. The same eight fields as the MP4 in this group: compare the two to see exactly which values survive a cross-container remux and which are quietly lost.
The same clip with every scrap of metadata removed — no tags, no creation time, not even the encoder string FFmpeg normally writes. The control for this group and the baseline for a privacy or scrubbing tool: if your stripper leaves anything this file does not have, it is not stripping enough. Getting to genuinely zero takes `-map_metadata -1` **and** `-fflags +bitexact` placed after the input, as an output option. `-map_metadata -1` alone still leaves the `encoder=Lavf…` tag behind, and putting the bitexact flag before `-i` applies it to the demuxer where it does nothing to the output — which is the usual reason a file someone believes they stripped still names the software that made it. What cannot be removed: `major_brand`, `minor_version` and `compatible_brands`. Probing tools list those alongside the tags, but they are fields of the `ftyp` box that define what the file is, not metadata about it.
Cover art embedded in an MP4 as a still JPEG carrying the `attached_pic` disposition. Note what that means structurally: the artwork is a *second video stream*, not a metadata field. That is the trap. A pipeline that maps 'the video stream' with `-map 0:v` picks up both and produces a file with a stray one-frame track; one that counts video streams to decide whether a file is a video reports two. Both are common, and neither shows up until a file with artwork arrives.
A Matroska attachment: a whole file carried inside the container alongside the media, with its own filename and MIME type. In the wild this is how fonts travel with styled ASS subtitles, so that a rendering machine lacking the typeface still gets the right result. Extract it with `ffmpeg -dump_attachment:t:0 out.txt -i …`. Unlike the MP4 cover art in this group, an attachment is not a media stream — it demuxes as `codec_type=attachment` and has no frames, which is why remuxing to any container without an attachment concept discards it silently. The filename here is deliberately not `cover.jpg`. Matroska's cover-art convention is simply an attachment named `cover.*`, and FFmpeg and most players special-case that name and promote it to an `attached_pic` video stream. So the same bytes attached under two different filenames produce two different stream lists — a genuinely surprising result if you are counting streams to decide what a file contains.
A start timecode of 01:00:00:00 — the broadcast convention of beginning programme material at hour one, so that bars, slates and pre-roll can live before it without going negative. FFmpeg writes it as a QuickTime `tmcd` track. The burned-in timecode in the picture deliberately starts at 00:00:00:00 instead. That one-hour disagreement is the whole point: an editor or QC tool that reads the timecode track shows 01:00:00:00 at the first frame, one that reads elapsed time shows zero, and a file where they agree cannot tell you which your tool is doing. Non-drop-frame, since 24 fps has no drop-frame variant.
A file with a known, fixed creation time — the field media libraries sort by, importers use to build folders, and forensic tools read first. Fixed rather than generated at build time, so re-running the generator produces byte-identical output and the published value never goes stale. Two behaviours worth testing against it. MP4 stores the `mvhd` timestamp in seconds since 1904 with no timezone, so anything that displays a local time is applying an assumption; and the stripped file in this group has no creation time at all, which is what a privacy-scrubbed file should look like.
Everything this phase covers in one file: two audio languages, three subtitle tracks including SDH, four chapters, an attached cover image and container tags — with every language tag and disposition set correctly. This is the integration test. The individual fixtures in the other groups isolate one variable each, which is what you want when something breaks; this is what you point a player, a track picker or a transcoder at first, because a pipeline that handles it handles all of them. Round-trip it through your tool and diff the track list: dropped dispositions, collapsed languages and vanished attachments all show up immediately.
The same package rebuilt inside MP4, which is the interesting part — MP4 cannot carry all of it. The SDH subtitle track is gone because MP4 has no hearing-impaired flag, the attachment becomes cover art as a second video stream, per-track titles have no home, and the subtitles are mov_text with the styling stripped. Diff this against the MKV in the same group and you have a concrete, byte-level answer to 'what do I lose converting to MP4?' — which is normally something people find out after shipping.
Eight subtitle tracks across four writing systems, including right-to-left Arabic, each with its own language tag and a track title in its own script. Two things break here that never break with two tracks. Track-picker UI: eight entries is where a fixed-height menu, a truncating label or a hardcoded array bound starts to show. And text rendering: the track titles themselves are non-Latin, so a picker that draws labels with a Latin-only font produces a menu of empty boxes even though every track is perfectly valid.
Three subtitle tracks and not one of them flagged default. Matroska permits this and players disagree completely about what to do: some pick the first track, some pick by system language, some show nothing at all and leave the viewer to find the menu. There is no right answer to assert here — the value is that the disagreement is reproducible. If your player picks a track, this file tells you which rule it is using.
Two subtitle tracks both carrying the default flag — which the specification does not forbid and which sloppy muxing produces constantly, usually by copying dispositions wholesale between files. First-wins and last-wins are both common implementations, so the same file starts in English on one player and Spanish on another with nothing visibly wrong. Hard to diagnose from a bug report, trivial to reproduce with this.
Two subtitle tracks whose language tags are swapped: the track tagged `fra` contains English cues and the one tagged `eng` contains French. Nothing about the file is malformed — every byte validates, every tag is a legal ISO 639-2 code. This is the failure no schema check can catch and no player can warn about. Selecting French gives you English, and the only way to detect it is to read the cue text and run language identification on it. If you are building QC for a subtitle library, this is the case worth having a fixture for, because it is common and it is invisible.
A second subtitle track that is properly declared, correctly language-tagged, and contains no cues at all. This is what an incomplete localisation looks like in a real library: the track exists so the menu offers Spanish, and choosing it produces silence. Track enumeration finds it. Language listing finds it. Only counting the cues finds the problem — which is why 'does this file have Spanish subtitles?' is the wrong question and 'does the Spanish track have any content?' is the right one.
We use Google Analytics and show ads via Adsterra and Infolinks. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
