SubRip and WebVTT sidecars plus multi-track containers — forced-narrative, SDH and styled tracks in one file — for testing track selection, default flags and caption rendering in players.
A SubRip (SRT) subtitle track with three timed cues — the most common subtitle format. Paired with the WebVTT twin for testing subtitle parsers and SRT↔VTT conversion.
A WebVTT subtitle track with three timed cues — the HTML5 <track> subtitle format. Paired with the SRT twin for testing subtitle parsers and VTT↔SRT conversion.
One MKV carrying three soft subtitle tracks — English, Spanish and Japanese — each with a real ISO 639-2 language tag and a human track title, and English flagged as the default. Every cue names its own second and its own chapter, and the picture burns in a matching timecode, so you can confirm the right track is displaying without trusting the player's own menu labels. Single-track sample files never exercise the code that actually breaks: track enumeration, language-tag mapping and default selection. This is the smallest file that does.
Two English subtitle tracks in one file: the full dialogue track, and a forced-narrative track that carries only the two moments where on-screen text needs translating. The second track sets the `forced` disposition, which tells a player to display it even when the viewer has subtitles switched off. The forced track is deliberately two cues, not eight. A forced track that repeats the full dialogue is the most common way this feature is got wrong in the wild, and a fixture that reproduced that mistake could not be used to detect it. Useful for checking that a player reads the flag rather than the track order, and that a transcoder preserves it — many drop the disposition silently and the file still looks fine until a viewer turns subtitles off.
Standard subtitles and SDH (Subtitles for the Deaf and Hard of Hearing) as two separate English tracks, distinguished only by the `hearing_impaired` disposition. The SDH track adds the non-speech information a deaf viewer would otherwise lose — the tone that is playing, the marker that is moving — in square brackets above each line. Because both tracks are tagged `eng`, any picker that keys on language alone shows two identical-looking entries. That is exactly the bug this file exists to surface: the flag is the only thing that separates them, and it is the thing most often dropped in a remux.
An ASS subtitle track that carries its own styling — two named styles, alternating cue by cue, one bottom-centred and one top-centred in italic teal. ASS is the only widely-used soft subtitle format that survives a remux with its positioning and colour intact. The useful test is what happens on the way out. Convert this to SubRip or to WebVTT and the styling is silently discarded — the cues remain, so the conversion reports success while half the information is gone. Converting to MP4 is worse still: mov_text keeps neither the styles nor the positions.
Two soft subtitle tracks inside an MP4, in mov_text — the 3GPP Timed Text format that is the only subtitle codec MP4 officially carries. Safari and QuickTime read these natively; most other browsers ignore them entirely and expect a sidecar WebVTT track instead, which is the single most common reason subtitles appear on an iPhone and nowhere else. Compare with the MKV in this group: the cue text is identical, but mov_text drops all styling and positioning, so this is also the file to test a lossy subtitle conversion against.
WebVTT muxed inside a WebM container, which the Matroska specification allows and almost nothing consumes. No browser surfaces an embedded WebVTT track through the HTML TextTrack API — the web platform expects a separate <track> element pointing at a sidecar file — so this is the fixture for the gap between what a container is permitted to hold and what a player will actually give you. One caveat about this file specifically. Every other fixture in this phase carries byte-identical H.264 video, but the WebM muxer accepts only VP8, VP9 or AV1 video and WebVTT subtitles — that restriction is the container's definition, not a limitation of the tooling — so the picture here is re-encoded to VP9 from the same source frames. Same content, different bytes.
The control for this group: the same picture with no subtitle track at all. Every other file here differs from this one only by what was muxed in. Worth more than it looks. A track enumerator that returns an empty list, one that returns a single null entry and one that throws are three different behaviours, and none of them can be told apart using a file that has subtitles.
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.
Download-only WebVTT caption sidecar 01 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-01.
Download-only WebVTT caption sidecar 02 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-02.
Download-only WebVTT caption sidecar 03 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-03.
Download-only WebVTT caption sidecar 04 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-04.
Download-only WebVTT caption sidecar 05 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-05.
Download-only WebVTT caption sidecar 06 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-06.
Download-only WebVTT caption sidecar 07 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-07.
Download-only WebVTT caption sidecar 08 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-08.
Download-only WebVTT caption sidecar 09 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-09.
Download-only WebVTT caption sidecar 10 with one sub-second cue for timing and attachment checks. Stable P8 artifact p8-video-caption-vtt-10.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
