Are these full-length videos?

No — short 270p clips (a few seconds) covering scene cuts, freezes, black frames, hard captions, soft-sub twins, aspect ratios, rotate metadata, A/V mux, audio desync, and colour bars for QC tooling.

Do you ship HDR10 or ProRes masters?

No. Those stay out of scope. We do ship linear 16-bit TIFF ‘HDR-ish’ stills for high bit-depth pipelines.

Video — example & test files

3gp

3GP — Mobile H.264 Clip

The clip as 3GP — the 3GPP mobile container from the feature-phone era. For testing 3GP demuxing and conversion.

File: 3GP · 3gp · 480x270
Use case: Conversion testing

Ad Signalling

SCTE-35 — Splice Insert (Break End / Return to Network)

The matching return cue for the break-start splice_insert in this group: the same spliceEventId with outOfNetworkIndicator false, signalling the feed is coming back from the ad break. It carries no BreakDuration because the return is explicit rather than automatic. Pairing start and end cues by event id is exactly what an ad-insertion implementation has to get right, and this is the pair to test it on.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

SCTE-35 — Splice Insert (Break Start)

An SCTE-35 splice_insert as XML: the cue that tells a downstream packager a linear ad break starts. outOfNetworkIndicator marks entry into the break, ptsTime is 8 seconds on the 90 kHz PTS clock, and the 30-second break auto-returns. This is the signal a manifest manipulator converts into an HLS EXT-X-CUE-OUT or a new DASH period.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

SCTE-35 — Time Signal With Segmentation Descriptor

The modern SCTE-35 form: a time_signal command carrying a segmentation descriptor rather than a bare splice_insert. Type 34 marks a provider placement opportunity start, and the delivery restrictions declare that this break may not be filled for web delivery — the field that ad-insertion logic is supposed to honour and frequently ignores. Includes a base64 UPID identifying the content.

File: XML · Ad Signalling · 2700000 (30.0s)
Use case: Ad insertionStreaming manifests+1· Conversion set

VAST 3.0 — Linear Ad With Companion Banners

A VAST 3.0 response pairing a linear spot with two companion banners in the standard IAB sizes, at the older schema version many ad servers still emit. Companions render alongside the video rather than in it, so they exercise a separate slot-matching path — the player has to find a matching container or correctly ignore them when required is none. All URLs point at example.invalid.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

VAST 4.2 — Empty (No Ad) Response

A valid VAST document containing no Ad element — the correct response when an ad server has nothing to serve. It arrives as HTTP 200 with a well-formed body, so it is not an error condition, and a player must resume content immediately rather than waiting for a timeout. Frequently mishandled: players stall on the break or log a spurious failure. The smallest meaningful VAST document there is.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

VAST 4.2 — Inline Linear Ad Response

A complete VAST 4.2 inline response for a linear pre-roll: two progressive MP4 media files at different bitrates, quartile tracking, an impression beacon and a click-through. Every URL points at the reserved example.invalid domain, so nothing can ever be fetched and no real ad server is contacted. For testing VAST parsing and player integration without a live ad stack.

File: XML · Ad Signalling · 00:00:15
Use case: Ad insertionStreaming manifests+1· Conversion set

VAST 4.2 — Wrapper (Redirect) Response

A VAST wrapper — a response that carries no media of its own, only a VASTAdTagURI pointing at another VAST document plus its own tracking beacons that must be fired in addition to the resolved ad's. Wrapper chains are where real ad integrations break: unbounded redirect depth, timeouts, and tracking dropped part-way down the chain. Pairs with the inline response it nominally redirects to.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

VMAP 1.0 — Pre-, Mid- and Post-Roll Schedule

A VMAP playlist scheduling three linear ad breaks — pre-roll at start, mid-roll at eight seconds, and post-roll at end — each pointing at a VAST tag. VMAP describes WHEN breaks occur while VAST describes WHAT plays in them. The mid-roll offset lines up with the period boundary in the multi-period DASH manifest, so the two can be tested together.

File: XML · Ad Signalling
Use case: Ad insertionStreaming manifests+1· Conversion set

Alpha

Alpha Channel — Opaque VP9 Twin

The same codec and container with NO alpha plane, as the control for the alpha clip in this group. Useful for checking that alpha detection reads the pixel format rather than assuming every WebM is transparent — and for confirming a compositing bug is in the alpha handling rather than in the player.

File: WEBM · Alpha · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Alpha Channel — VP9 in WebM

Video with a real per-pixel alpha channel: VP9 yuva420p in WebM, the one alpha path browsers decode natively. Composite it over a page background and the transparency is genuine, not a chroma key. Roughly 90% of each frame is fully transparent. Two traps this file exists to expose. First, auto-alt-ref must be disabled at encode time or libvpx silently drops the alpha plane, producing a valid file with no transparency and no error. Second, WebM stores VP9 alpha in BlockAdditional and signals it with AlphaMode=1, so FFmpeg's NATIVE vp9 decoder reports pix_fmt yuv420p and decodes fully opaque — you must force `-c:v libvpx-vp9` to see the alpha at all. Probing this file with default settings and concluding it has no alpha is the expected mistake.

File: WEBM · Alpha · 480x270
Use case: Video codecsVideo matting+2· Conversion set

Aspect

MP4 — Landscape 16:9 Twin

Short 16:9 SAMPLE clip at 480x270 for aspect-ratio and social-crop tooling.

File: MP4 · Aspect · 480x270
Use case: Conversion testing· Conversion set

MP4 — Landscape Wide

Additional aspect SAMPLE (640x360) for social and player testing.

File: MP4 · Aspect · 640x360
Use case: Conversion testing· Conversion set

MP4 — Portrait 9:16

Short 9:16 SAMPLE clip at 270x480 for aspect-ratio and social-crop tooling.

File: MP4 · Aspect · 270x480
Use case: Conversion testing· Conversion set

MP4 — Portrait Soft

Additional aspect SAMPLE (360x640) for social and player testing.

File: MP4 · Aspect · 360x640
Use case: Conversion testing· Conversion set

MP4 — Square 1:1

Short 1:1 SAMPLE clip at 270x270 for aspect-ratio and social-crop tooling.

File: MP4 · Aspect · 270x270
Use case: Conversion testing· Conversion set

Audio Tracks

Multi-Track Audio — 5.1 Surround, One Tone per Channel (MKV)

A 5.1 track with a different pitch in every channel: an A-major triad across L, R and C, a 60 Hz rumble in the LFE, and two higher tones in the surrounds. Channel order is the standard L, R, C, LFE, Ls, Rs. This makes channel-mapping bugs audible instead of theoretical. Downmix it to stereo and you should hear the triad plus the surrounds; if the centre and the LFE swap — a classic WAV-to-container ordering mistake — the result is unmistakable. Most 5.1 test files play the same content everywhere and cannot detect that at all.

File: MKV · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — Audio Description (MKV)

A main audio track plus an audio-description track for blind and low-vision viewers, carrying the `visual_impaired` disposition. The description track is an octave and a bit below the main track, so selecting it is audible. Matroska has exactly one flag for this — there is no separate `descriptions` flag as there is in MP4 and in HTML's own track kinds — so a converter that maps `kind="descriptions"` onto Matroska has to pick this one, and a converter going the other way has to infer it. Both tracks are tagged `eng`, which is the realistic case and the awkward one: a picker that lists tracks by language shows two identical entries, and only the flags tell them apart. Broadcast and streaming compliance regimes increasingly require this track to be present and correctly flagged, and the flags are exactly what a naive `ffmpeg -c copy` remux drops.

File: MKV · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — Commentary Track (MKV)

A feature track and a commentary track, separated only by the `comment` disposition. The third member of this group's flag set alongside audio description and dual language, and the one that most often ends up auto-selected by mistake — a player that picks the last matching English track rather than the default one starts the film on the commentary.

File: MKV · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — Dual Language (MKV)

Two audio tracks with distinct language tags, and English flagged as the default. The two tracks are different pitches — 440 Hz and 659 Hz, a perfect fifth apart — so which track a player selected is audible immediately rather than something you have to inspect the file to determine. That is the whole design. Dual-language fixtures that carry the same tone on both tracks cannot distinguish 'switched correctly' from 'ignored the switch', which is the one thing you want to test.

File: MKV · Audio Tracks · 480x270
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — No Audio Track At All (MP4)

A video file with no audio track whatsoever. Pair it with the silent-track file in this group: the two sound identical and are structurally completely different. Code that asks 'does this have audio?' by reading a level meter says no to both. Code that asks the container says no to this one and yes to the other. Whichever answer your pipeline needs, you need both files to know which question it is actually asking.

File: MP4 · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — Present but Digitally Silent (MP4)

An audio track that exists, declares stereo, and contains nothing but zero samples. The twin of the no-audio-track file in this group, and the reason that file exists. This is the fixture that catches the false negative in every 'is the audio missing?' check built on a container probe: `ffprobe` reports a healthy AAC stereo track, the duration is right, the bitrate is plausible, and the viewer hears nothing. Detecting it requires decoding and measuring, not inspecting. The language is deliberately `und`, which is what encoders emit when nobody set one — another thing worth being able to reproduce.

File: MP4 · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Multi-Track Audio — Single Mono Track (MP4)

One mono audio track — the shape most phone recordings, voice notes and screen captures actually arrive in, and the one that catches pipelines that hardcode a stereo buffer or index channel 1 without checking that it exists.

File: MP4 · Audio Tracks · 8s
Use case: Media accessibilityVideo QA+2· Conversion set

Av

MP4 — A/V Mux with 440 Hz Tone

Video muxed with a 440 Hz sine tone — for A/V container and audio-track tests.

File: MP4 · Av · 480x270
Use case: Conversion testingAudio analysis· Conversion set

MP4 — A/V Mux with 880 Hz Tone

Video muxed with an 880 Hz tone — frequency twin for audio pipeline tests.

File: MP4 · Av · 480x270
Use case: Conversion testingAudio analysis· Conversion set

MP4 — Audio Desync 100ms

SAMPLE clip with audio delayed ~100 ms — for A/V sync detection tools.

File: MP4 · Av · 480x270
Use case: Conversion testingAudio analysis· Conversion set

MP4 — Audio Desync 250ms

SAMPLE clip with audio delayed ~250 ms — for A/V sync detection tools.

File: MP4 · Av · 480x270
Use case: Conversion testingAudio analysis· Conversion set

MP4 — Audio Desync 500ms

SAMPLE clip with audio delayed ~500 ms — for A/V sync detection tools.

File: MP4 · Av · 480x270
Use case: Conversion testingAudio analysis· Conversion set

Avi

AVI — DivX (MPEG-4 ASP) Clip

The clip as DivX-style MPEG-4 ASP in an AVI container — the codec that defined early desktop video. For testing MPEG-4 Part 2 decoding and AVI conversion.

File: AVI · Avi · 480x270
Use case: Conversion testing

AVI — Motion-JPEG Clip

The clip as Motion-JPEG in a classic AVI (RIFF) container — every frame an independent JPEG. For testing legacy AVI readers, MJPEG decoding, and AVI→modern-codec conversion.

File: AVI · Avi · 480x270
Use case: Conversion testing

Bars

MP4 — Colour Bars (Silent)

Silent colour-bar twin of the bars+tone clip — for audio-presence detectors.

File: MP4 · Bars · 480x270
Use case: Conversion testing· Paired fixture

MP4 — Colour Bars + 1 kHz Tone

SMPTE-ish colour bars with a 1 kHz reference tone — classic QC fixture.

File: MP4 · Bars · 480x270
Use case: Conversion testingAudio analysis· Paired fixture

Base Plates

Base Plate — Colour — 24-Patch Chart in Motion

A 24-patch chart drifting slowly so it is genuinely moving footage rather than a still. Patch values are fixed and documented, so colourisation and colour-management output can be measured per patch. The values are fictional and not a reproduction of any licensed reference chart. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video codecsVideo QA· Conversion set

Base Plate — Depth — Three Parallax Planes

Far, mid and near layers translating at 0.6, 2.4 and 6.0 pixels per frame. Relative depth is defined by the motion ratio rather than guessed from cues, which gives depth-from-video and optical-flow output something objective to be scored against. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Base Plate — Detail — Siemens Star and Frequency Wedges

A 36-spoke Siemens star under a slow zoom, plus bar-pair wedges from 16 pixels down to 2. Detail runs right down to the Nyquist limit, which is exactly where super-resolution and denoise either recover structure or invent it. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video upscalingVideo denoise+1· Conversion set

Base Plate — Gradient — Smooth Sky With Hue Drift

A smooth vertical gradient whose hue drifts across the clip, with one soft glow for structure. Almost no high-frequency detail, so it provokes banding and blocking in exactly the way flat skies do in real footage — the hardest case for a low-bitrate encoder. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video denoiseVideo codecs+1· Conversion set

Base Plate — Orbit — Hard-Edged Solids

A green disc and a red square orbiting the centre in antiphase over a grid. Hard edges and flat fills make the boundary unambiguous, so segmentation and tracking output can be scored against exact geometry rather than a judgement call. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video segmentationVideo matting+1· Conversion set

Base Plate — Pan — City Skyline

A skyline scrolling at a constant 3.5 pixels per frame: pure horizontal translation with no rotation or scale change. The lit windows give sparse high-contrast features to track, and the constant velocity means the correct answer for interpolation and optical flow is known exactly. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video stabilisationFrame interpolation+1· Conversion set

Base Plate — Subject on Chroma Field

An anti-aliased figure moving over a chroma-green field with a deliberate lighting falloff, so the key is not perfectly flat. Ships with a per-frame alpha ground truth, which is what makes matting output measurable instead of merely inspectable. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Base Plate — Text — Scrolling Terminal UI

Scrolling monospaced terminal output with a blinking cursor. Thin high-contrast glyph edges are what chroma subsampling and low bitrates destroy first, and legibility after processing is a pass/fail signal that needs no metric. One of eight shared base plates: every AI-video suite in this library degrades one of these rather than inventing its own footage, so results across suites are comparable. Encoded at CRF 14 — well above the house CRF 30 — because a reference compressed as hard as the material under test puts the measurement floor above the effect being measured.

File: MP4 · Base Plates · 640x360
Use case: Video codecsVideo QA· Conversion set

Bundle

Video Clips Archive (ZIP)

A ZIP bundling the MP4 and WebM test clips with a README — a 'video archive' for testing pipelines that unpack an archive and then transcode its contents. Stored (not re-compressed), since the clips are already compressed.

File: ZIP · Bundle · 3 members
Use case: Conversion testing

Captions Corrupt

SCC — Intentionally Corrupt: Wrong Parity Bytes

An intentionally corrupt SCC file whose first caption is valid but whose second carries byte pairs with the wrong parity. CEA-608 requires odd parity in bit 7 of every byte, and broadcast decoders use it to detect transmission errors. Tests whether a decoder checks parity at all, and whether it drops just the bad caption or the whole file.

File: SCC · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Intentionally Corrupt: End Before Start

An intentionally corrupt SubRip file whose first cue ends three seconds before it begins. Nothing is malformed at the text level, so parsers accept it and the problem only surfaces downstream — as a negative duration, a caption that never displays, or a sort that puts the timeline out of order.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Intentionally Corrupt: Invalid UTF-8 Byte Sequence

An intentionally corrupt SubRip file with a lone UTF-8 continuation byte appended — a byte that can never legally start a character. Both cues are otherwise fine. Exercises the difference between strict decoding, which raises, and lenient decoding, which substitutes a replacement character and continues.

File: SRT · Captions Corrupt · UTF-8 with one invalid sequence
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Intentionally Corrupt: Missing Timestamp Arrow

An intentionally corrupt SubRip file: the first cue's timing line is missing the --> separator, so it cannot be parsed as a time range. The second cue is well-formed, which is the point — a robust parser should report the bad cue and still return the good one rather than failing the whole file.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Intentionally Corrupt: Non-Numeric Cue Index

An intentionally corrupt SubRip file with two separate index problems: the first cue is numbered with a word, and index 2 is then used twice. SubRip indices are advisory rather than load-bearing, so this distinguishes parsers that key cues by index — and lose one to the collision — from those that do not.

File: SRT · Captions Corrupt · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Intentionally Corrupt: Truncated Mid-Cue

An intentionally corrupt SubRip file that stops in the middle of the third cue's timestamp, as a truncated download or an interrupted write would. There is no trailing newline. Tests whether a parser returns the two complete cues or discards everything because the tail is unparseable.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

TTML — Intentionally Corrupt: Unclosed Element

An intentionally corrupt TTML document with an unclosed p element, making it not well-formed XML. Any conforming XML parser must reject it outright — which is exactly the useful property, since it distinguishes real XML parsing from regex-based caption scraping that would happily extract both cues.

File: TTML · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

VTT — Intentionally Corrupt: Missing WEBVTT Header

An intentionally corrupt WebVTT file with the mandatory WEBVTT signature removed from the first line. The cues themselves are perfectly valid. The spec requires strict rejection, so a browser refuses it outright while many lenient parsers accept it — a useful disagreement to be able to reproduce.

File: VTT · Captions Corrupt · 2 cues
Use case: Subtitle parsingVideo QA· Conversion set

Captions Edge

ASS — Karaoke Timing and Override Tags

Advanced SubStation Alpha using the features that distinguish it from SubRip: per-syllable \k karaoke timings in centiseconds, a full V4+ style definition with primary and secondary colours, and an \an override that repositions a line. Converting this to SRT necessarily loses all of it, which makes it a good test of whether a converter warns about that or drops it silently.

File: ASS · Captions Edge · 640x360
Use case: Subtitle parsingConversion testing+1· Conversion set

LRC — Enhanced Word-Level Timing

Enhanced LRC with per-word timings in angle brackets alongside the usual per-line timestamps — the format karaoke and lyric-sync apps consume. Includes the standard metadata tags, an offset field, and a final empty timestamp that clears the display. Simple LRC parsers read only the line timings and silently render the word markers as visible text.

File: LRC · Captions Edge
Use case: Subtitle parsingConversion testing+1· Conversion set

SBV — YouTube Timing Without Cue Indices

SubViewer/SBV as YouTube exports it: no cue indices, a comma rather than an arrow between start and end, and single-digit hours. Superficially similar enough to SubRip that format detection by eye fails, which makes it a good test of sniffing logic — a parser that guesses SubRip from the timestamps then trips on the missing index.

File: SBV · Captions Edge · 4 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — 500-Cue Throughput File

Five hundred short sequential cues over four minutes. Small in bytes but long enough to expose quadratic parsing, per-cue DOM churn, and UI that re-renders the whole caption list on every cue change.

File: SRT · Captions Edge · 500 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Cue Text Containing the Timestamp Arrow

Cue text that contains the --> separator, and a second cue whose text looks exactly like a timing line. A parser that finds timing lines by searching for '-->' anywhere rather than by tracking cue structure splits these into extra phantom cues. Structurally valid SubRip throughout — the file is correct and the naive parser is wrong.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Cues Out of Chronological Order

Cue indices run 1, 2, 3 but the timestamps do not — the file is ordered 6.5s, 1.0s, 3.5s. The spec does not require chronological order, so a conforming parser must sort by start time rather than trusting file order. Parsers that stream cues straight to a renderer show them in the wrong sequence.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — HTML Entities and Angle Brackets in Cue Text

Cue text mixing escaped entities, raw ampersands, unescaped angle brackets used as maths, and one genuine italic tag. SubRip has no formal escaping rules, so every parser draws the line somewhere different. Shows immediately whether a tool decodes entities, passes them through, or mistakes '3 < 5' for an unclosed tag and swallows the rest of the line.

File: SRT · Captions Edge · 4 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Over-Long Caption Line

One caption line of 334 characters against a 32-column broadcast convention. Exercises wrapping, truncation and validation paths, and shows immediately whether a burn-in tool wraps text or lets it run off the frame.

File: SRT · Captions Edge · 2 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Overlapping Cues

Three cues whose time ranges deliberately overlap, so at 3.2 seconds all three are active at once. Legal in SubRip and common in multi-speaker transcripts, but plenty of renderers assume one cue at a time and either drop the extras or stack them off-screen.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Speaker Labels and Dialogue Dashes

The conventions captioners actually use — speaker names in caps, leading dashes for alternating dialogue, square brackets and parentheses for sound effects, and music notes around lyrics. None is part of the SubRip grammar, so tools that extract speaker names or strip non-speech cues have to pattern-match them. Useful for testing transcript extraction and caption-cleaning passes.

File: SRT · Captions Edge · 5 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT — Zero and Near-Zero Duration Cues

A cue whose start and end are identical, and one lasting a single millisecond. Both appear in machine-generated captions from forced-alignment tools. A renderer that computes a display duration and divides by it, or that filters out non-positive durations without saying so, mishandles these.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

TTML — IMSC Nested Spans and Regions

TTML using the features broadcast caption profiles rely on: two layout regions, named styles including a text outline, a declared frame rate and media time base, and spans nested two deep so styles cascade. Converting this to SubRip necessarily flattens all of it. Tests whether a TTML implementation resolves style inheritance or only reads the leaf text.

File: TTML · Captions Edge
Use case: Subtitle parsingConversion testing+1· Conversion set

VTT — Chapter Track

A WebVTT file used as a chapter track rather than captions: cue text is a chapter title and the cues tile the timeline with no gaps. Players surface these as seek-bar markers, so it exercises a different code path from subtitle rendering despite being the same file format.

File: VTT · Captions Edge
Use case: Subtitle parsingVideo QA· Conversion set

VTT — Metadata Track With JSON Payloads

A WebVTT metadata track whose cue payloads are JSON objects rather than text for display. This is how timed analysis output — scene changes, detections, speech segments — is carried alongside a video and read from JavaScript via the cue change event. Nothing here should ever be rendered on screen.

File: VTT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA+1· Conversion set

VTT — NOTE Blocks and Irregular Blank Lines

WebVTT with multi-line and single-line NOTE comment blocks, runs of up to five blank lines between cues, and trailing blank lines at end of file. All legal — the spec treats blank lines as separators, not as structure. Parsers that count blank lines to find cue boundaries, or that treat NOTE as a cue identifier, produce phantom cues or drop real ones.

File: VTT · Captions Edge · 2 cues
Use case: Subtitle parsingVideo QA· Conversion set

VTT — Positioned and Aligned Cues

WebVTT cues carrying the full positioning grammar — line, position, align and size — plus named cue identifiers instead of numbers. Captions are placed at four different points in the frame, which is what real subtitles do to avoid covering burned-in text. Parsers that treat everything after the timestamp as cue text will fold these settings into the visible caption.

File: VTT · Captions Edge · 4 cues
Use case: Subtitle parsingVideo QA+1· Conversion set

VTT — STYLE Blocks, Regions and Inline Markup

WebVTT exercising the parts of the format beyond plain text: a STYLE block with ::cue selectors, a named REGION, voice spans, cue classes, and inline bold/italic/underline/ruby markup. A parser that handles only timestamps and text will render the tag names as visible characters.

File: VTT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA+1· Conversion set

VTT — X-TIMESTAMP-MAP for HLS Sync

A WebVTT segment carrying X-TIMESTAMP-MAP, the header HLS uses to align caption times with the MPEG-TS presentation clock. Cue times are relative to the map rather than to the file, so a player that ignores the header renders every caption ten seconds early. Invisible in a text editor and a classic cause of 'captions are out of sync' reports.

File: VTT · Captions Edge · 2 cues
Use case: Subtitle parsingStreaming manifests+1· Conversion set

Captions Encoding

SRT — CJK (Japanese)

Japanese captions mixing kana, kanji and full-width punctuation. Full-width characters occupy two columns in a monospaced renderer, so line-length limits computed in code points under-count them.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — Cyrillic

Cyrillic captions — outside ASCII but still single-width and left-to-right, which isolates encoding handling from layout handling.

File: SRT · Captions Encoding · 2 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — Emoji and combining marks

Characters above the Basic Multilingual Plane, a composed/decomposed accent pair, and a zero-width-joiner sequence. Anything that measures caption length in UTF-16 code units rather than graphemes miscounts these.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — Mixed CRLF and LF Line Endings

One file with both line-ending conventions — CRLF for the opening cues and bare LF for the rest, the shape a caption file takes after being edited on two platforms or assembled from two sources. Parsers that detect the convention once from the first line and then apply it to the whole file mis-split everything after the switch.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — No Trailing Newline

Identical to the reference file except the final newline is missing, so the last cue is terminated by end-of-file rather than by a blank line. SubRip separates cues with a blank line, and parsers that split on a double newline and discard the remainder drop the final cue entirely — a bug that is invisible until a file happens to end this way.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — RTL (Arabic)

Right-to-left Arabic with joined letterforms, including a bidirectional line where Western digits sit inside RTL text. Exercises the bidi algorithm and any renderer that assumes left-to-right layout.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — RTL (Hebrew)

Right-to-left Hebrew without letter joining — a second RTL script, so a renderer cannot pass by special-casing Arabic shaping alone.

File: SRT · Captions Encoding · 2 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-16 BE with BOM

UTF-16 big-endian with a BOM — the byte order most decoders forget to handle, since little-endian dominates in practice. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-16 LE with BOM

UTF-16 little-endian with a BOM. Every second byte is NUL, so a parser that reads bytes as UTF-8 or ASCII sees a file that appears to start and end immediately. Tools must detect the BOM, not assume UTF-8. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-8 with BOM, CRLF

Both awkward properties at once — a BOM and CRLF endings — which is what a file saved by Notepad on Windows actually looks like. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-8 with BOM, LF

UTF-8 with a leading U+FEFF byte-order mark. Windows caption tools emit this constantly, and a parser that does not strip it sees the BOM as part of the first cue number and fails to match its index. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-8, CRLF

UTF-8 with Windows CRLF line endings. Parsers that split on a bare \n leave a trailing carriage return on every line, which usually surfaces as a stray box glyph at the end of each caption. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — UTF-8, LF

Plain UTF-8, no byte-order mark, Unix LF line endings. The reference member of this set — every other file here carries the same five cues, so a parser's output can be diffed against this one. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT — Windows-1252 (Legacy Code Page)

The same cues in Windows-1252, the legacy code page behind most real-world caption mojibake. Pure ASCII until the curly quotes and em dash, which encode as single bytes 0x93, 0x94 and 0x97 — none of which is valid UTF-8. A tool that assumes UTF-8 either raises or silently substitutes replacement characters exactly where the punctuation was. There is no BOM and no in-band signal, so correct handling requires either charset detection or being told.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

VTT — UTF-8 With BOM Before the Signature

WebVTT with a byte-order mark ahead of the mandatory WEBVTT signature. The spec explicitly allows this, and browsers accept it — but a naive check that the file literally starts with the six bytes 'WEBVTT' rejects a perfectly valid file. The mirror image of the missing-header corrupt fixture: one is valid and often refused, the other is invalid and often accepted.

File: VTT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

Captions Formats

DFXP — TTML Under Its Other Extension

Timed text as DFXP — byte-for-byte a TTML document, just under the extension Netflix, Adobe and older captioning tool-chains still use. Same tt root, same head/body/div/p structure, same styling and region attributes. It exists to check that a caption parser dispatches on document content rather than on the file extension: a parser that accepts .ttml but rejects an identical .dfxp is exactly the bug this catches.

File: DFXP · Captions Formats · 5 cues
Use case: Subtitle parsingConversion testing+1· Conversion set

JSON — Caption Cue List

The same five cues as a plain JSON array with float second timings — the shape most caption pipelines use internally between parsing one format and writing another. Handy as the expected intermediate when testing a converter, since it removes timestamp-formatting differences from the comparison.

File: JSON · Captions Formats · 5 cues
Use case: Subtitle parsingConversion testing+1· Conversion set

SCC — Broadcast CEA-608 Captions

Broadcast closed captions as Scenarist SCC: SMPTE timecodes followed by hexadecimal CEA-608 byte pairs, with odd parity set on every byte as the standard requires. Uses pop-on mode — RCL to load, ENM to clear non-displayed memory, a preamble address code for row 15, the character pairs, then EOC to display. This is the fixture that exposes decoders which treat captions as text: the parity bits, the two-byte control codes and the frame-accurate timecodes all have to be handled.

File: SCC · Captions Formats
Use case: Subtitle parsingCaption encoding+2· Conversion set

Chapters

Chapters — Embedded in Matroska (MKV)

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.

File: MKV · Chapters · 8s
Use case: Media metadataVideo QA+1· Conversion set

Chapters — Embedded in MP4

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.

File: MP4 · Chapters · 8s
Use case: Media metadataVideo QA+1· Conversion set

Chapters — FFMETADATA1 Chapter File

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.

File: TXT · Chapters
Use case: Media metadataVideo QA+1· Conversion set

Chapters — Matroska Chapter XML

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.

File: XML · Chapters
Use case: Media metadataVideo QA+1· Conversion set

Chapters — None (MKV Control)

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.

File: MKV · Chapters · 8s
Use case: Media metadataVideo QA+1· Conversion set

Chapters — Timestamp List in a Description

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.

File: TXT · Chapters
Use case: Media metadataVideo QA+1· Conversion set

Chapters — WebVTT Chapter Track

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.

File: VTT · Chapters
Use case: Media metadataVideo QA+1· Conversion set

Codecs

Codec — AV1

The shared pan-city base plate encoded with AV1 (libaom-av1). Royalty-free and now decoded by every current browser. Encoding is far slower than H.264, which is why this fixture uses a fast preset; the bitstream is standard regardless. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MP4 · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — FFV1 (Mathematically Lossless)

The shared pan-city base plate encoded with FFV1 level 3 (lossless). Mathematically lossless: decoding reproduces the source pixels bit for bit. Used for archival preservation, and the right reference when you need to prove a processing step, not a codec, caused a change. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MKV · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — H.264 / AVC

The shared pan-city base plate encoded with H.264 (libx264). The universal baseline — decodes everywhere, hardware-accelerated on essentially every device shipped this decade. If a pipeline handles only one codec, this is it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MP4 · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — HEVC / H.265

The shared pan-city base plate encoded with HEVC (libx265). Roughly half the bitrate of H.264 at the same quality, but patent licensing kept it out of browsers. Tagged hvc1 rather than hev1, which is what Safari and QuickTime require — the wrong tag is a common cause of a file that plays everywhere except on Apple hardware. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MP4 · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — Motion JPEG

The shared pan-city base plate encoded with MJPEG. Every frame is an independent JPEG, with no inter-frame prediction at all. Large, but it makes any frame a clean cut point, which is why cameras and capture cards still emit it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: AVI · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — MPEG-2

The shared pan-city base plate encoded with MPEG-2 (mpeg2video). The DVD and broadcast codec. Intra-heavy and inefficient by modern standards, but it is the format broadcast and archive workflows are still built around. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MPG · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — MPEG-4 Part 2

The shared pan-city base plate encoded with MPEG-4 Part 2 (DivX/Xvid-compatible). The DivX/Xvid era, tagged XVID in an AVI. Predates H.264 and is still what a great deal of archived material is stored as, so ingest pipelines meet it constantly. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: AVI · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — MS-MPEG-4 v3

The shared pan-city base plate encoded with MS-MPEG-4 v3 (msmpeg4v3). Microsoft's non-standard MPEG-4 Part 2 variant — the 'DivX 3' bitstream. Deliberately incompatible with the standard decoder, which makes it a sharp test of whether a pipeline identifies codecs from the bitstream or from the FourCC. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: AVI · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — ProRes-Compatible Mezzanine

The shared pan-city base plate encoded with FFmpeg prores_ks, profile 0 (proxy). An intra-only 10-bit 4:2:2 mezzanine written by FFmpeg's prores_ks encoder — the interchange shape editorial workflows expect. Described as ProRes-COMPATIBLE deliberately: this is FFmpeg's independent implementation, not Apple's encoder. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: MOV · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — Sorenson Spark (FLV1)

The shared pan-city base plate encoded with FLV1 / Sorenson Spark. The Flash video codec. Entirely historical for delivery, but FLV files persist throughout media archives and legacy CMS exports. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: FLV · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — Theora

The shared pan-city base plate encoded with Theora (libtheora). The original open web video codec, in an Ogg container. Largely historical, but still the fallback path in older HTML5 players and a good test of whether a pipeline's format detection is driven by content rather than by a hardcoded list. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: OGV · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — VP8

The shared pan-city base plate encoded with VP8 (libvpx). The first WebM codec, now legacy but still what MediaRecorder emits by default in several browsers — so it turns up in user-generated uploads far more often than its age suggests. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: WEBM · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — VP9

The shared pan-city base plate encoded with VP9 (libvpx-vp9). Google's royalty-free predecessor to AV1, and still the workhorse of WebM delivery. Plays natively in every major browser. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: WEBM · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Codec — Windows Media Video 8

The shared pan-city base plate encoded with WMV2. Windows Media in an ASF container. Long obsolete, but it is what a large amount of corporate and archival material was encoded as, and few non-FFmpeg tools read it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.

File: WMV · Codecs · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Colour

Colourisation Ground Truth — colour-patches

The full-colour reference for the colour-patches colourisation set. Every desaturated clip in this group was derived from these exact pixels with a documented luma transform, so a colouriser's output can be scored against the true colours — and on this plate the 24 patch values are fixed and published, so the comparison can be made per patch rather than as a whole-frame average.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Ground Truth — gradient-sky

The full-colour reference for the gradient-sky colourisation set. Every desaturated clip in this group was derived from these exact pixels with a documented luma transform, so a colouriser's output can be scored against the true colours.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Ground Truth — pan-city

The full-colour reference for the pan-city colourisation set. Every desaturated clip in this group was derived from these exact pixels with a documented luma transform, so a colouriser's output can be scored against the true colours.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — colour-patches, 50% Desaturated

The colour-patches plate with 50% of its saturation removed, leaving 50% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — colour-patches, 80% Desaturated

The colour-patches plate with 80% of its saturation removed, leaving 19% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — colour-patches, Rec. 601 luma

The colour-patches plate desaturated using Rec. 601 luma weights. Rec. 601 weights instead — the SD standard, and still the default in a surprising amount of software. The greys differ measurably from the 709 version, which is a good check on whether a pipeline knows which standard it is using.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — colour-patches, Rec. 709 luma

The colour-patches plate desaturated using Rec. 709 luma weights. Converted with Rec. 709 luma weights, the correct coefficients for HD material. All chroma is gone, so a colouriser has nothing to recover from and must infer it entirely.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — gradient-sky, 50% Desaturated

The gradient-sky plate with 50% of its saturation removed, leaving 50% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — gradient-sky, 80% Desaturated

The gradient-sky plate with 80% of its saturation removed, leaving 19% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — gradient-sky, Rec. 601 luma

The gradient-sky plate desaturated using Rec. 601 luma weights. Rec. 601 weights instead — the SD standard, and still the default in a surprising amount of software. The greys differ measurably from the 709 version, which is a good check on whether a pipeline knows which standard it is using.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — gradient-sky, Rec. 709 luma

The gradient-sky plate desaturated using Rec. 709 luma weights. Converted with Rec. 709 luma weights, the correct coefficients for HD material. All chroma is gone, so a colouriser has nothing to recover from and must infer it entirely.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — pan-city, 50% Desaturated

The pan-city plate with 50% of its saturation removed, leaving 50% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — pan-city, 80% Desaturated

The pan-city plate with 80% of its saturation removed, leaving 19% of the original chroma. This is the faded-archive case rather than the black-and-white one: some colour information survives, so the task is restoration rather than invention, and a model that ignores the residual chroma is throwing away the strongest signal it has.

File: MP4 · Colour · 640x360
Use case: Video colourisationCompression artefacts+1· Conversion set

Colourisation Input — pan-city, Rec. 601 luma

The pan-city plate desaturated using Rec. 601 luma weights. Rec. 601 weights instead — the SD standard, and still the default in a surprising amount of software. The greys differ measurably from the 709 version, which is a good check on whether a pipeline knows which standard it is using.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Colourisation Input — pan-city, Rec. 709 luma

The pan-city plate desaturated using Rec. 709 luma weights. Converted with Rec. 709 luma weights, the correct coefficients for HD material. All chroma is gone, so a colouriser has nothing to recover from and must infer it entirely.

File: MP4 · Colour · 640x360
Use case: Video colourisationVideo QA· Conversion set

Compress

Compression Input — detail-chart at CRF 28

The detail-chart plate at CRF 28 — mild artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the fine wedges collapse first, showing exactly which spatial frequencies the quantiser discarded.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — detail-chart at CRF 36

The detail-chart plate at CRF 36 — clearly visible artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the fine wedges collapse first, showing exactly which spatial frequencies the quantiser discarded.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — detail-chart at CRF 44

The detail-chart plate at CRF 44 — severe artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the fine wedges collapse first, showing exactly which spatial frequencies the quantiser discarded.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — detail-chart at CRF 51

The detail-chart plate at CRF 51 — extreme — the codec's limit artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the fine wedges collapse first, showing exactly which spatial frequencies the quantiser discarded.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — gradient-sky at CRF 28

The gradient-sky plate at CRF 28 — mild artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as banding across the smooth gradient, which is the artefact viewers notice first and metrics score most poorly.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — gradient-sky at CRF 36

The gradient-sky plate at CRF 36 — clearly visible artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as banding across the smooth gradient, which is the artefact viewers notice first and metrics score most poorly.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — gradient-sky at CRF 44

The gradient-sky plate at CRF 44 — severe artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as banding across the smooth gradient, which is the artefact viewers notice first and metrics score most poorly.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — gradient-sky at CRF 51

The gradient-sky plate at CRF 51 — extreme — the codec's limit artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as banding across the smooth gradient, which is the artefact viewers notice first and metrics score most poorly.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — text-motion at CRF 28

The text-motion plate at CRF 28 — mild artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as ringing around glyph edges, where legibility gives a pass/fail signal that needs no metric.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — text-motion at CRF 36

The text-motion plate at CRF 36 — clearly visible artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as ringing around glyph edges, where legibility gives a pass/fail signal that needs no metric.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — text-motion at CRF 44

The text-motion plate at CRF 44 — severe artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as ringing around glyph edges, where legibility gives a pass/fail signal that needs no metric.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Input — text-motion at CRF 51

The text-motion plate at CRF 51 — extreme — the codec's limit artefacts. Encoded from the original frames rather than transcoded from the reference, so it carries exactly one generation of loss and the comparison is clean. On this plate the damage shows as ringing around glyph edges, where legibility gives a pass/fail signal that needs no metric.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Reference — detail-chart at CRF 14

The high-quality reference for the detail-chart compression ladder, at CRF 14. Each clip in this group is the SAME source frames encoded at a progressively higher quantiser, so the only variable is the encoder setting. Useful both for artefact-removal models and for calibrating a quality metric against settings whose visual cost is already known.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Reference — gradient-sky at CRF 14

The high-quality reference for the gradient-sky compression ladder, at CRF 14. Each clip in this group is the SAME source frames encoded at a progressively higher quantiser, so the only variable is the encoder setting. Useful both for artefact-removal models and for calibrating a quality metric against settings whose visual cost is already known.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Compression Reference — text-motion at CRF 14

The high-quality reference for the text-motion compression ladder, at CRF 14. Each clip in this group is the SAME source frames encoded at a progressively higher quantiser, so the only variable is the encoder setting. Useful both for artefact-removal models and for calibrating a quality metric against settings whose visual cost is already known.

File: MP4 · Compress · 640x360
Use case: Compression artefactsVideo codecs+1· Conversion set

Containers

Container — 3GP

One H.264 elementary stream wrapped in 3GP. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The mobile profile of MP4, from the feature-phone era. Still emitted by some Android capture paths, so it turns up in user uploads.

File: 3GP · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — AVI

One H.264 elementary stream wrapped in AVI. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. Microsoft's 1992 container. No B-frame timestamp support and a 4 GB practical limit, but enormous amounts of archived material still live in it.

File: AVI · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — M4V

One H.264 elementary stream wrapped in M4V. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. MP4 under Apple's alternative extension. Byte-identical structure; the extension exists purely so iTunes could distinguish video, and it is a good test of extension-driven format detection.

File: M4V · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — Matroska

One H.264 elementary stream wrapped in Matroska. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The most permissive container in common use: any codec, unlimited tracks, chapters, attachments. Not natively playable in Safari, which is its main practical limitation.

File: MKV · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — MP4 (ISO BMFF)

One H.264 elementary stream wrapped in MP4 (ISO BMFF). Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The ISO base media format, and the default for web delivery. Supports faststart, which moves the index to the front so playback can begin before the file has finished downloading.

File: MP4 · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — MPEG Transport Stream

One H.264 elementary stream wrapped in MPEG Transport Stream. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The broadcast and HLS-segment container. Fixed 188-byte packets and no global index, so it can be cut at any packet boundary and still decode — which is exactly why streaming uses it.

File: TS · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Container — QuickTime

One H.264 elementary stream wrapped in QuickTime. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. Apple's container, and the direct ancestor of MP4 — the two share the same atom structure, which is why remuxing between them is nearly free.

File: MOV · Containers · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Containers Corrupt

Intentionally Corrupt — Matroska Bytes With an .mp4 Extension

An intentionally corrupt fixture of a different kind: the bytes are a perfectly valid Matroska file, and the extension says `.mp4`. Nothing is damaged — the file simply lies about what it is. Not a valid MP4 by design. This is what a user's 'converted' file usually turns out to be after a rename, and it separates two kinds of code cleanly. Anything that sniffs the first four bytes finds `1A 45 DF A3`, identifies EBML and plays it. Anything that dispatches on the extension hands it to an MP4 demuxer that immediately fails to find `ftyp`. Note the catalog records this entry's MIME as video/mp4, matching the extension rather than the content — deliberately, because that is precisely the mismatch being reproduced.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — Matroska Truncated Mid-Cluster

An intentionally corrupt Matroska file cut to 60% of its length, part way through a cluster. Not a valid file by design. Matroska degrades very differently from MP4, which is the reason to have both. Its header is at the front and its clusters are independently framed, so a truncated MKV usually plays right up to the cut and then simply ends — no index to contradict, because the Cues element that would have carried it was at the end and is gone. Duration is reported as unknown or estimated, and seeking past the cut behaves differently in every player.

File: MKV · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — MP4 Header Fragment Only

An intentionally corrupt MP4 cut off half way through its `moov` box: the `ftyp` header survives, the index does not, and there is no media data at all. Not a valid file by design. Just enough for content sniffing to succeed and everything after that to fail. A `file`-style magic check reports ISO Media, a MIME sniffer says video/mp4, and then the box walk runs off the end of the buffer part way through the index. Useful for testing the gap between format detection and format validation — and for the upload path, where the two are frequently the same check. Distinct from the two other truncations in this group: the mid-mdat file has a complete index and missing media, this one has a broken index and no media, and a length-based cut deep enough to matter is the only way to tell those code paths apart.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — MP4 Truncated Mid-mdat

An intentionally corrupt MP4, cut off at 55% of its length in the middle of the `mdat` box — the shape of an interrupted download or a copy from a failing disk. Not a valid file by design. The interesting property is that it opens perfectly. Because the file was written with faststart the `moov` index sits before the media data, so a probe reads a complete track list and a duration within a tenth of a second of the original, and only decoding reveals that most of the samples the index points to are not there. Tools that validate by probing pass it; tools that validate by decoding do not. The seek bar will happily let you scrub past the end of the data that exists.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — MP4 With Bit Rot in the Media Payload

An intentionally corrupt MP4 in which 48 individual bytes inside the `mdat` payload have been inverted, leaving every box header, the index and the file length exactly as they were. Not a valid file by design. Structurally this file is perfect — it will pass any container-level validation you throw at it — and the damage is entirely in the compressed bitstream. Expect the decoder to log errors and the picture to break up and then recover at the next keyframe, which is what makes it the right fixture for testing that a transcode pipeline actually surfaces decoder errors rather than shipping a corrupted output and reporting success. The corruption sites are fixed, so the file is reproducible byte for byte.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — MP4 With the moov Atom Removed

An intentionally corrupt MP4 with the entire `moov` box cut out and the surrounding bytes rejoined. The `ftyp` header and all of the compressed media in `mdat` are untouched. Not a valid file by design. This is the classic 'moov atom not found' failure, and in practice the most common way an MP4 dies: the index is written last, so any recording that stops without a clean finalise — a crashed encoder, a phone that ran out of battery mid-capture — ends up exactly like this. The media is all still there, which is why recovery tools can sometimes rebuild it, and this is the file to test one against. Contrast with the truncated file in this group, which has an index and no data.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — WebM Truncated Mid-Stream

An intentionally corrupt WebM, VP9 in Matroska, cut to 45% of its bytes. Not a valid file by design. The browser-facing member of this group. A truncated WebM starts playing in an HTML5 <video> element and then fires an `error` event mid-stream, which is a genuinely awkward state to handle: your player has already reported success, already hidden the spinner, and already told the user the duration. Use it to check that the error path is wired to something more useful than a frozen frame.

File: WEBM · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Intentionally Corrupt — Zero-Byte MP4

An intentionally corrupt MP4 containing nothing at all — zero bytes, with a `.mp4` extension. Not a valid file by design. The degenerate case, and one that reaches production more often than any other: a failed upload, a `touch`ed placeholder, a copy that never started. It is worth having because so much code divides by duration, reads the first N bytes without checking N, or reports 'unsupported format' for a file that has no format to support. Note that content sniffing cannot help here — there are no magic bytes — so anything that must classify this file has only the extension to go on.

File: MP4 · Containers Corrupt
Use case: Error handlingVideo QA+1· Conversion set

Deblur

Deblur Ground Truth — detail-chart, Sharp

The sharp reference for the detail-chart deblur set. Each blurred clip in this group applies a documented kernel to these exact pixels, so the deconvolution problem has a known answer — including which detail was destroyed outright and therefore cannot be recovered, only invented.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Ground Truth — text-motion, Sharp

The sharp reference for the text-motion deblur set. Each blurred clip in this group applies a documented kernel to these exact pixels, so the deconvolution problem has a known answer — including which detail was destroyed outright and therefore cannot be recovered, only invented.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — detail-chart, Defocus blur, radius 5

Defocus blur, radius 5 applied to the sharp detail-chart plate with a Gaussian kernel — a defocused lens. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — detail-chart, Horizontal motion blur, 21 px

Horizontal motion blur, 21 px applied to the sharp detail-chart plate with a uniform horizontal box kernel — a linear camera pan during exposure. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — detail-chart, Horizontal motion blur, 9 px

Horizontal motion blur, 9 px applied to the sharp detail-chart plate with a uniform horizontal box kernel — a linear camera pan during exposure. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — text-motion, Defocus blur, radius 5

Defocus blur, radius 5 applied to the sharp text-motion plate with a Gaussian kernel — a defocused lens. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — text-motion, Horizontal motion blur, 21 px

Horizontal motion blur, 21 px applied to the sharp text-motion plate with a uniform horizontal box kernel — a linear camera pan during exposure. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Deblur Input — text-motion, Horizontal motion blur, 9 px

Horizontal motion blur, 9 px applied to the sharp text-motion plate with a uniform horizontal box kernel — a linear camera pan during exposure. The kernel is documented, so this supports both blind and non-blind deconvolution: give the algorithm the kernel, or make it estimate one and compare.

File: MP4 · Deblur · 640x360
Use case: Video deblurVideo QA· Conversion set

Denoise

Denoise Ground Truth — detail-chart

The clean reference for the detail-chart denoise set — no noise added, encoded at CRF 14. Every noisy clip in this group was produced from these exact pixels, so PSNR, SSIM and LPIPS against this file are meaningful rather than approximate.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Ground Truth — gradient-sky

The clean reference for the gradient-sky denoise set — no noise added, encoded at CRF 14. Every noisy clip in this group was produced from these exact pixels, so PSNR, SSIM and LPIPS against this file are meaningful rather than approximate.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Ground Truth — pan-city

The clean reference for the pan-city denoise set — no noise added, encoded at CRF 14. Every noisy clip in this group was produced from these exact pixels, so PSNR, SSIM and LPIPS against this file are meaningful rather than approximate.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Gaussian σ=15

Gaussian σ=15 applied to the detail-chart base plate with seed 9017. Moderate Gaussian noise, roughly a mid-ISO handheld shot. The level most denoise benchmarks use. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Gaussian σ=30

Gaussian σ=30 applied to the detail-chart base plate with seed 9034. Heavy Gaussian noise where fine detail and noise overlap in amplitude, so recovery requires temporal information rather than spatial smoothing alone. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Gaussian σ=5

Gaussian σ=5 applied to the detail-chart base plate with seed 9000. Light sensor noise — the level a modern camera produces at base ISO. Subtle enough that an over-aggressive denoiser does more damage than the noise did. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Gaussian σ=50

Gaussian σ=50 applied to the detail-chart base plate with seed 9051. Severe noise approaching the signal level. Included as the failure case — most denoisers hallucinate structure here, which is exactly what the paired reference exposes. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Multiplicative speckle

Multiplicative speckle applied to the detail-chart base plate with seed 9102. Multiplicative rather than additive noise, so its amplitude scales with local brightness — the pattern seen in ultrasound and radar. Additive-noise models systematically under-correct highlights. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Poisson shot noise

Poisson shot noise applied to the detail-chart base plate with seed 9119. Photon shot noise, signal-dependent and the physically correct model for low-light capture. Dark regions are proportionally far noisier than bright ones. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Salt and pepper 2%

Salt and pepper 2% applied to the detail-chart base plate with seed 9068. Two per cent of pixels forced to pure black or white — impulse noise from sensor faults and transmission errors. Defeats Gaussian-assuming filters, which smear each spike instead of rejecting it. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — detail-chart, Salt and pepper 8%

Salt and pepper 8% applied to the detail-chart base plate with seed 9085. Dense impulse noise. A median filter handles this trivially and a Gaussian one cannot, so it separates the two families of denoiser immediately. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Gaussian σ=15

Gaussian σ=15 applied to the gradient-sky base plate with seed 9017. Moderate Gaussian noise, roughly a mid-ISO handheld shot. The level most denoise benchmarks use. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Gaussian σ=30

Gaussian σ=30 applied to the gradient-sky base plate with seed 9034. Heavy Gaussian noise where fine detail and noise overlap in amplitude, so recovery requires temporal information rather than spatial smoothing alone. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Gaussian σ=5

Gaussian σ=5 applied to the gradient-sky base plate with seed 9000. Light sensor noise — the level a modern camera produces at base ISO. Subtle enough that an over-aggressive denoiser does more damage than the noise did. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Gaussian σ=50

Gaussian σ=50 applied to the gradient-sky base plate with seed 9051. Severe noise approaching the signal level. Included as the failure case — most denoisers hallucinate structure here, which is exactly what the paired reference exposes. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Multiplicative speckle

Multiplicative speckle applied to the gradient-sky base plate with seed 9102. Multiplicative rather than additive noise, so its amplitude scales with local brightness — the pattern seen in ultrasound and radar. Additive-noise models systematically under-correct highlights. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Poisson shot noise

Poisson shot noise applied to the gradient-sky base plate with seed 9119. Photon shot noise, signal-dependent and the physically correct model for low-light capture. Dark regions are proportionally far noisier than bright ones. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Salt and pepper 2%

Salt and pepper 2% applied to the gradient-sky base plate with seed 9068. Two per cent of pixels forced to pure black or white — impulse noise from sensor faults and transmission errors. Defeats Gaussian-assuming filters, which smear each spike instead of rejecting it. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — gradient-sky, Salt and pepper 8%

Salt and pepper 8% applied to the gradient-sky base plate with seed 9085. Dense impulse noise. A median filter handles this trivially and a Gaussian one cannot, so it separates the two families of denoiser immediately. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Gaussian σ=15

Gaussian σ=15 applied to the pan-city base plate with seed 9017. Moderate Gaussian noise, roughly a mid-ISO handheld shot. The level most denoise benchmarks use. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Gaussian σ=30

Gaussian σ=30 applied to the pan-city base plate with seed 9034. Heavy Gaussian noise where fine detail and noise overlap in amplitude, so recovery requires temporal information rather than spatial smoothing alone. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Gaussian σ=5

Gaussian σ=5 applied to the pan-city base plate with seed 9000. Light sensor noise — the level a modern camera produces at base ISO. Subtle enough that an over-aggressive denoiser does more damage than the noise did. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Gaussian σ=50

Gaussian σ=50 applied to the pan-city base plate with seed 9051. Severe noise approaching the signal level. Included as the failure case — most denoisers hallucinate structure here, which is exactly what the paired reference exposes. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Multiplicative speckle

Multiplicative speckle applied to the pan-city base plate with seed 9102. Multiplicative rather than additive noise, so its amplitude scales with local brightness — the pattern seen in ultrasound and radar. Additive-noise models systematically under-correct highlights. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Poisson shot noise

Poisson shot noise applied to the pan-city base plate with seed 9119. Photon shot noise, signal-dependent and the physically correct model for low-light capture. Dark regions are proportionally far noisier than bright ones. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Salt and pepper 2%

Salt and pepper 2% applied to the pan-city base plate with seed 9068. Two per cent of pixels forced to pure black or white — impulse noise from sensor faults and transmission errors. Defeats Gaussian-assuming filters, which smear each spike instead of rejecting it. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 19, where the light noise could otherwise be confused with compression artefacts.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Denoise Input — pan-city, Salt and pepper 8%

Salt and pepper 8% applied to the pan-city base plate with seed 9085. Dense impulse noise. A median filter handles this trivially and a Gaussian one cannot, so it separates the two families of denoiser immediately. Paired with the clean ground truth in this group, so denoiser output can be scored numerically. Encoded at CRF 24 rather than 19: random noise is incompressible, and at this amplitude the codec's own artefacts sit far below the noise floor, so a coarser quantiser saves several megabytes without affecting any measurement.

File: MP4 · Denoise · 640x360
Use case: Video denoiseVideo QA· Conversion set

Depth

Depth Ground Truth — Layer Depth Map

The depth map for the parallax plate, encoded brighter-is-nearer across three layers. These values are not an estimate — they are derived from the layer velocities the generator used, so the depth ordering is exact by construction. Relative depth is what matters here: the layers move at 0.6, 2.4 and 6.0 pixels per frame, a 1 : 4 : 10 ratio.

File: MP4 · Depth · 640x360
Use case: Depth from videoVideo QA· Conversion set

Depth Input — Three-Layer Parallax Scene

Three planes translating at 0.6, 2.4 and 6.0 pixels per frame — a 1 : 4 : 10 velocity ratio that defines their relative depth by motion alone. There are no pictorial depth cues to fall back on: no perspective convergence, no shading, no familiar object sizes. A monocular depth model that has learned pictorial cues rather than motion parallax will do poorly here, which is precisely what makes the fixture informative.

File: MP4 · Depth · 640x360
Use case: Depth from videoFrame interpolation+1· Conversion set

Edges

MP4 — Black Flash Frames

Short black flash frames SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Black-Frame Insert

A clip with a short pure-black insert — for black-frame detectors and QC tools.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Burned-In Timecode

On-screen running timecode burned into frames — for OCR and slate tools.

File: MP4 · Edges · 480x270
Use case: Conversion testingOCR testing

MP4 — Colour Bars

A short colour-bar test pattern clip — for colour pipeline and player QC.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Countdown Digits

On-screen countdown digits burned into frames — for OCR and slate detection.

File: MP4 · Edges · 480x270
Use case: Conversion testingOCR testing

MP4 — Freeze Frame Segment

Motion, then a one-second frozen segment, then motion again — for freeze detection and VFR edge cases.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Hard Scene Cut

A short H.264 clip with an abrupt mid-point colour scene cut — for scene-detection and keyframe tooling.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Hard-Burned Caption

Video with a SAMPLE caption burned into the pixels (not a soft subtitle track) — for OCR/caption-burn detection.

File: MP4 · Edges · 480x270
Use case: Conversion testingOCR testing

MP4 — Letterbox Bars

Content framed with black letterbox bars — for autocrop and aspect-ratio tools.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Pillarbox Bars

Content with vertical pillarbox bars — for autocrop tools.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Solid Blue Field

Short solid blue field SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Solid Gray Field

Short solid gray field SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Solid Green Field

Short solid green field SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Solid Red Field

Short solid red field SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — Strobe / Flash Frames

Short strobe/flash pattern for photosensitivity QC and flash-frame detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

MP4 — White Flash Frames

Short white flash frames SAMPLE for colour and flash QC detectors.

File: MP4 · Edges · 480x270
Use case: Conversion testing

Flv

FLV — Flash Video Clip

The clip as Flash Video (.flv) with H.264 — the legacy web-streaming container. For testing FLV demuxing and conversion to MP4.

File: FLV · Flv · 480x270
Use case: Conversion testing

Formats

60 fps Clip (MP4)

A 60 frames-per-second clip with a smoothly sweeping marker — double the usual frame rate. A fixture for testing high-frame-rate playback, frame-rate detection, and fps conversion (60→30 decimation).

File: MP4 · Formats · 480x270
Use case: Conversion testing

Vertical 9:16 Clip (MP4, 270x480)

A portrait 9:16 (270×480) clip with a vertically-moving marker — the aspect ratio of phone and short-form video. A fixture for testing vertical-video handling, orientation, and letterboxing in players and thumbnailers.

File: MP4 · Formats · 270x480
Use case: Conversion testingResolution testing

Hdr

Colour Signalling — BT.2020 SDR (Wide Gamut)

Wide-gamut primaries with a conventional SDR transfer — wide colour without HDR. Frequently mishandled because tooling assumes BT.2020 always implies PQ or HLG. Every clip in this group carries the SAME picture and differs only in its colour signalling, so any difference in how a player renders them is entirely a metadata-handling difference.

File: MKV · Hdr · 640x360
Use case: Video codecsCompression artefacts+1· Conversion set

Colour Signalling — BT.601 (SD)

The standard-definition matrix. Decoding BT.601 content as BT.709 (or the reverse) shifts every colour subtly — greens and reds most visibly. It is the single most common colour bug in transcode pipelines, and this pair reproduces it on demand. Every clip in this group carries the SAME picture and differs only in its colour signalling, so any difference in how a player renders them is entirely a metadata-handling difference.

File: MKV · Hdr · 640x360
Use case: Video codecsCompression artefacts+1· Conversion set

Colour Signalling — BT.709 (HD SDR)

The HD standard, and what a player assumes when a file says nothing. The reference member of this group: every other clip carries identical pixels and different signalling. Every clip in this group carries the SAME picture and differs only in its colour signalling, so any difference in how a player renders them is entirely a metadata-handling difference.

File: MKV · Hdr · 640x360
Use case: Video codecsCompression artefacts+1· Conversion set

Colour Signalling — HDR10 (PQ, BT.2020, 10-bit)

HDR10 signalling: BT.2020 primaries with the SMPTE ST 2084 perceptual quantiser, 10-bit. Be clear about what this fixture is — the picture is ordinary SDR content TAGGED as HDR, so it is a test of metadata handling and tone-mapping paths, not a reference for HDR image quality. A player that ignores the transfer function will render it washed out and far too dark, which is precisely the failure worth reproducing. Every clip in this group carries the SAME picture and differs only in its colour signalling, so any difference in how a player renders them is entirely a metadata-handling difference.

File: MKV · Hdr · 640x360
Use case: Video codecsCompression artefacts+1· Conversion set

Colour Signalling — HLG (Hybrid Log-Gamma)

Hybrid Log-Gamma, the broadcast HDR transfer designed to stay watchable on an SDR display. As with the HDR10 fixture, the picture itself is SDR content carrying HLG signalling, so this tests transfer-function detection and the SDR fallback path rather than HDR rendering. Every clip in this group carries the SAME picture and differs only in its colour signalling, so any difference in how a player renders them is entirely a metadata-handling difference.

File: MKV · Hdr · 640x360
Use case: Video codecsCompression artefacts+1· Conversion set

Index

CSV — Cue Timing Report

Per-cue timings and text metrics for the shared cue list, as a caption QC tool would export them: start, end, duration, line count and character count. Useful as the expected output when testing a caption analyser, and as a quick way to check reading-rate calculations against known values.

File: CSV · Index · 5 rows
Use case: Subtitle parsingVideo QA+1

JSON — Timed-Text Suite Index

A machine-readable index of all 67 timed-text, streaming-manifest and ad-signalling fixtures in this wave, with id, format, path and byte size for each. Useful as a work-list when running a parser across the whole suite, and as a manifest to diff against after regenerating.

File: JSON · Index
Use case: Video QASubtitle parsing+1

Interp

Interpolation Ground Truth — depth-layers at 24 fps

The full-rate 24 fps reference for the depth-layers interpolation set. The decimated clips in this group drop frames from exactly this sequence, so every frame an interpolator is asked to synthesise has a true original to be scored against — which is the only way to tell invention from reconstruction.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Ground Truth — orbit-solid at 24 fps

The full-rate 24 fps reference for the orbit-solid interpolation set. The decimated clips in this group drop frames from exactly this sequence, so every frame an interpolator is asked to synthesise has a true original to be scored against — which is the only way to tell invention from reconstruction.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Ground Truth — pan-city at 24 fps

The full-rate 24 fps reference for the pan-city interpolation set. The decimated clips in this group drop frames from exactly this sequence, so every frame an interpolator is asked to synthesise has a true original to be scored against — which is the only way to tell invention from reconstruction.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — depth-layers at 12 fps

The depth-layers plate decimated to 12 fps by keeping every 2th frame, so 24 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — depth-layers at 6 fps

The depth-layers plate decimated to 6 fps by keeping every 4th frame, so 36 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — depth-layers at 8 fps

The depth-layers plate decimated to 8 fps by keeping every 3th frame, so 32 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — depth-layers, Motion-Blurred Decimation

Halved frame rate where each output frame is the AVERAGE of the two it replaces, rather than one of them — what a long shutter angle actually produces. Substantially harder than clean decimation, because the interpolator must undo motion blur as well as invent the missing instants, and no input frame matches any ground-truth frame exactly.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo deblur+1· Conversion set

Interpolation Input — orbit-solid at 12 fps

The orbit-solid plate decimated to 12 fps by keeping every 2th frame, so 24 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — orbit-solid at 6 fps

The orbit-solid plate decimated to 6 fps by keeping every 4th frame, so 36 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — orbit-solid at 8 fps

The orbit-solid plate decimated to 8 fps by keeping every 3th frame, so 32 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — orbit-solid, Motion-Blurred Decimation

Halved frame rate where each output frame is the AVERAGE of the two it replaces, rather than one of them — what a long shutter angle actually produces. Substantially harder than clean decimation, because the interpolator must undo motion blur as well as invent the missing instants, and no input frame matches any ground-truth frame exactly.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo deblur+1· Conversion set

Interpolation Input — pan-city at 12 fps

The pan-city plate decimated to 12 fps by keeping every 2th frame, so 24 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — pan-city at 6 fps

The pan-city plate decimated to 6 fps by keeping every 4th frame, so 36 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — pan-city at 8 fps

The pan-city plate decimated to 8 fps by keeping every 3th frame, so 32 of the original 48 frames are missing. Interpolate back to 24 fps and each synthesised frame has an exact counterpart in the ground truth. Larger gaps need genuine motion understanding rather than blending.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo QA· Conversion set

Interpolation Input — pan-city, Motion-Blurred Decimation

Halved frame rate where each output frame is the AVERAGE of the two it replaces, rather than one of them — what a long shutter angle actually produces. Substantially harder than clean decimation, because the interpolator must undo motion blur as well as invent the missing instants, and no input frame matches any ground-truth frame exactly.

File: MP4 · Interp · 640x360
Use case: Frame interpolationVideo deblur+1· Conversion set

M4v

M4V — iTunes H.264 Clip

The clip as M4V — Apple's MP4 variant used by iTunes. Browser-playable; for testing M4V handling and M4V↔MP4 conversion.

File: M4V · M4v · 480x270
Use case: Conversion testing

Matting

Matting Ground Truth — Per-Frame Alpha Matte

The exact per-frame alpha used to composite every clip in this group, as an 8-bit greyscale clip: white is opaque subject, black is background, and edges carry genuine intermediate values because the matte is anti-aliased rather than binary. This is what makes matting output measurable — compare a predicted alpha against this frame by frame instead of inspecting a composite and forming an opinion.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Matting Input — Subject on Busy patterned

The same subject and the same alpha, composited over busy patterned — no chroma screen, which is the case a general background-removal model actually has to handle. Score the predicted alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Matting Input — Subject on Chroma Green

The canonical keying setup: the subject over a chroma-green field carrying a deliberate vertical lighting falloff, because a perfectly flat key is unrealistically easy. Pull a key, then score the resulting alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo QA· Conversion set

Matting Input — Subject on Colour close to subject

The same subject and the same alpha, composited over colour close to subject — no chroma screen, which is the case a general background-removal model actually has to handle. The background colour deliberately sits close to the subject's own, so colour alone cannot separate them and the model must use shape and motion. Score the predicted alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Matting Input — Subject on Dark studio

The same subject and the same alpha, composited over dark studio — no chroma screen, which is the case a general background-removal model actually has to handle. Score the predicted alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Matting Input — Subject on Office interior

The same subject and the same alpha, composited over office interior — no chroma screen, which is the case a general background-removal model actually has to handle. Score the predicted alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Matting Input — Subject on Outdoor daylight

The same subject and the same alpha, composited over outdoor daylight — no chroma screen, which is the case a general background-removal model actually has to handle. Score the predicted alpha against the ground-truth matte in this group.

File: MP4 · Matting · 640x360
Use case: Video mattingVideo segmentation+1· Conversion set

Metadata

Embedded Metadata — Cover Art (MP4)

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.

File: MP4 · Metadata · 8s
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — File Attachment (MKV)

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.

File: MKV · Metadata · 8s
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — Fixed Creation Time (MP4)

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.

File: MP4 · Metadata · 8s
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — Full Container Tags (MKV)

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.

File: MKV · Metadata · 480x270
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — Full Container Tags (MP4)

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.

File: MP4 · Metadata · 480x270
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — SMPTE Start Timecode (MP4)

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.

File: MP4 · Metadata · 8s
Use case: Media metadataVideo QA+1· Conversion set

Embedded Metadata — Stripped (MP4 Control)

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.

File: MP4 · Metadata · 8s
Use case: Media metadataVideo QA+1· Conversion set

Mkv

MKV — Matroska H.264 Clip

The clip in a Matroska (MKV) container with H.264 video — the flexible open container used for rich multi-track media. For testing MKV demuxing and remux/conversion.

File: MKV · Mkv · 480x270
Use case: Conversion testing

Mov

MOV — QuickTime H.264 Clip

The clip in a QuickTime (MOV) container with H.264 video — Apple's container, common from cameras and editors. For testing MOV parsing and MOV→MP4 conversion.

File: MOV · Mov · 480x270
Use case: Conversion testing

Mp4

MP4 — H.264 Clip

A short H.264 test clip in an MP4 container (yuv420p, faststart) — the most widely supported web and mobile video format. Video-only and tiny; for testing players, thumbnailers, and MP4→other conversion.

File: MP4 · Mp4 · 480x270
Use case: Conversion testing

Mpg

MPEG — MPEG-1 Clip

The clip as MPEG-1 in an MPEG program stream (.mpg) — the VCD-era format. For testing legacy MPEG demuxing and conversion to modern codecs.

File: MPG · Mpg · 480x270
Use case: Conversion testing

Multi Track

Multi-Track — Complete Package (MKV)

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.

File: MKV · Multi Track · 480x270
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — Complete Package, MP4 Limits (MP4)

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.

File: MP4 · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — Declared but Empty Subtitle Track (MKV)

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.

File: MKV · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — Eight Subtitle Tracks (MKV)

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.

File: MKV · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — Language Tags Swapped (MKV)

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.

File: MKV · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — No Default Flag Anywhere (MKV)

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.

File: MKV · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Multi-Track — Two Tracks Both Flagged Default (MKV)

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.

File: MKV · Multi Track · 8s
Use case: Media accessibilityMedia metadata+2· Conversion set

Notes

JSON — Video QC Note 09

Video QC companion SAMPLE (av-sync-notes.json) for Wave G suites.

File: JSON · Notes
Use case: Conversion testing

SRT — Video QC Note 01

Video QC companion SAMPLE (desync-caption.srt) for Wave G suites.

File: SRT · Notes
Use case: Conversion testingSubtitle parsing

SRT — Video QC Note 03

Video QC companion SAMPLE (bars-caption.srt) for Wave G suites.

File: SRT · Notes
Use case: Conversion testingSubtitle parsing

SRT — Video QC Note 05

Video QC companion SAMPLE (portrait-caption.srt) for Wave G suites.

File: SRT · Notes
Use case: Conversion testingSubtitle parsing

SRT — Video QC Note 07

Video QC companion SAMPLE (square-caption.srt) for Wave G suites.

File: SRT · Notes
Use case: Conversion testingSubtitle parsing

TXT — Video QC Note 10

Video QC companion SAMPLE (video-qc-checklist.txt) for Wave G suites.

File: TXT · Notes
Use case: Conversion testing

VTT — Video QC Note 02

Video QC companion SAMPLE (desync-caption.vtt) for Wave G suites.

File: VTT · Notes
Use case: Conversion testingSubtitle parsing

VTT — Video QC Note 04

Video QC companion SAMPLE (bars-caption.vtt) for Wave G suites.

File: VTT · Notes
Use case: Conversion testingSubtitle parsing

VTT — Video QC Note 06

Video QC companion SAMPLE (portrait-caption.vtt) for Wave G suites.

File: VTT · Notes
Use case: Conversion testingSubtitle parsing

VTT — Video QC Note 08

Video QC companion SAMPLE (square-caption.vtt) for Wave G suites.

File: VTT · Notes
Use case: Conversion testingSubtitle parsing

Ogv

OGV — Ogg Theora Clip

The clip as Ogg Theora — a fully open, royalty-free format. Browser-playable; for testing Theora decoding and Ogg video conversion.

File: OGV · Ogv · 480x270
Use case: Conversion testing

P8 Convert

Convert v2 RealMedia Motion Source

RealMedia container with a short deterministic RealVideo motion pattern for download-only legacy demux and transcode coverage. Stable P8 artifact p8-convert-legacy-rm.

File: RM · P8 Convert · 160x128
Use case: Conversion testingVideo codecs

Pixel Format

Pixel Format — 10-bit 4:2:0

10-bit 4:2:0 HEVC. Ten bits per component gives 1024 levels instead of 256, which is what removes banding from smooth gradients. Now the norm for HDR and for high-quality SDR encodes. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 10-bit 4:2:2

10-bit 4:2:2 HEVC. The professional acquisition and mezzanine format — enough chroma for keying and enough bit depth for grading. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 10-bit 4:4:4

10-bit 4:4:4 HEVC. Full chroma at 10 bits. Effectively an intermediate format only; almost nothing decodes it in hardware. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 12-bit 4:2:0

12-bit 4:2:0 HEVC. Twelve bits, at the top of what HEVC's Main 12 profile supports. Cinema and scientific capture; included as the limit case that finds decoders which silently truncate to 8 bits. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 8-bit 4:2:0

8-bit 4:2:0 HEVC. The universal delivery format. Chroma is stored at quarter resolution, which is invisible on photographic content and very visible on saturated text and thin graphic edges. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 8-bit 4:2:2

8-bit 4:2:2 HEVC. Chroma at half horizontal resolution — the broadcast and mezzanine standard. Survives one round of chroma keying and colour correction far better than 4:2:0. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Pixel Format — 8-bit 4:4:4

8-bit 4:4:4 HEVC. No chroma subsampling at all. Necessary for screen content and graphics, and the only format where coloured text stays clean, but unsupported by most hardware decoders. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.

File: MKV · Pixel Format · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Rotate

MP4 — Rotate Metadata 180°

SAMPLE clip tagged/encoded for 180° rotation — for orientation-aware players.

File: MP4 · Rotate · 480x270
Use case: Conversion testing· Conversion set

MP4 — Rotate Metadata 270°

SAMPLE clip tagged/encoded for 270° rotation — for orientation-aware players.

File: MP4 · Rotate · 480x270
Use case: Conversion testing· Conversion set

MP4 — Rotate Metadata 90°

SAMPLE clip tagged/encoded for 90° rotation — for orientation-aware players.

File: MP4 · Rotate · 480x270
Use case: Conversion testing· Conversion set

Rotation

Rotation Metadata — 180°

A 180-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation — exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows it upside down. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.

File: MP4 · Rotation · H.264 (libx264)
Use case: Video codecsConversion testing+1· Conversion set

Rotation Metadata — 270°

A 270-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation — exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows this 270x480 clip as 480x270, on its side. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.

File: MP4 · Rotation · H.264 (libx264)
Use case: Video codecsConversion testing+1· Conversion set

Rotation Metadata — 90°

A 90-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation — exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows this 270x480 clip as 480x270, on its side. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.

File: MP4 · Rotation · H.264 (libx264)
Use case: Video codecsConversion testing+1· Conversion set

Scan

Scan — Interlaced, Bottom Field First

The same interlacing with the opposite field order, the DV and SD convention. Deinterlacing with the wrong field order makes motion jitter backwards — a subtle, very common bug that this pair makes reproducible. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player — combing artefacts are best judged from a still anyway.

File: MKV · Scan · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Scan — Interlaced, Top Field First

Alternate lines carry alternate instants, with the top field displayed first — the HD broadcast convention. Shown progressively it combs on every moving edge. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player — combing artefacts are best judged from a still anyway.

File: MKV · Scan · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Scan — Progressive

Whole frames, captured and displayed at once — the reference for this group and how essentially all modern video is shot. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player — combing artefacts are best judged from a still anyway.

File: MKV · Scan · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Screencast

Terminal Screencast Mock (MP4)

A screen-recording-style clip of a mock terminal — a window with traffic-light buttons and build output typing out line by line with a blinking cursor. A fixture for testing screen-capture pipelines, UI-motion thumbnails, and text-in-video OCR.

File: MP4 · Screencast · 480x300
Use case: Conversion testing

Segmentation

Segmentation Ground Truth — Instance Masks

Per-frame instance masks for the orbit plate, colour-coded so the three objects are separable: red is the disc, green the square, blue the centre marker, black the background. Instance identity is stable across frames, which is what makes this usable for video object segmentation and tracking rather than only per-frame segmentation. Note the mask is encoded lossily like every other clip here, so threshold rather than testing for exact equality.

File: MP4 · Segmentation · 640x360
Use case: Video segmentationVideo matting+1· Conversion set

Segmentation Input — Orbiting Solids

Two hard-edged objects orbiting in antiphase over a grid, plus a static centre marker. The objects cross in front of the grid and reach the frame edges, so occlusion and boundary handling both get exercised. Every frame has an exact mask in this group.

File: MP4 · Segmentation · 640x360
Use case: Video segmentationVideo QA· Conversion set

Segmentation Input — Trimap (Foreground / Unknown / Background)

A three-level trimap derived from the instance masks: definite foreground, definite background, and a nine-pixel unknown band around every boundary. This is the input interactive matting and rotoscoping tools actually take, and the band is where all the difficulty lives — a matte is only as good as its handling of that region.

File: MP4 · Segmentation · 640x360
Use case: Video segmentationVideo matting+1· Conversion set

Stab

Stabilisation Ground Truth — detail-chart, Locked Off

The locked-off reference for the detail-chart stabilisation set — any motion in this clip is subject motion, not camera motion. The shaky clips in this group are this footage with a recorded synthetic camera path applied, so residual motion after stabilisation can be measured against zero rather than eyeballed.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Ground Truth — pan-city, Locked Off

The locked-off reference for the pan-city stabilisation set — any motion in this clip is subject motion, not camera motion. The shaky clips in this group are this footage with a recorded synthetic camera path applied, so residual motion after stabilisation can be measured against zero rather than eyeballed.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Ground Truth — text-motion, Locked Off

The locked-off reference for the text-motion stabilisation set — any motion in this clip is subject motion, not camera motion. The shaky clips in this group are this footage with a recorded synthetic camera path applied, so residual motion after stabilisation can be measured against zero rather than eyeballed.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — detail-chart, Heavy handheld

Heavy handheld camera shake applied to the locked-off detail-chart plate: up to 12.0 px of translation at 6.5 Hz, seed 5131. Twelve-pixel excursions at a slower, larger cadence: running, or a long lens. Requires real trajectory smoothing rather than frame-to-frame alignment. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — detail-chart, High-frequency jitter

High-frequency jitter camera shake applied to the locked-off detail-chart plate: up to 2.5 px of translation and 0.5° of roll at 23.0 Hz, seed 5193. Small, fast jitter near the frame rate — vibration from a vehicle or a drone motor. Aliases against the sampling rate, so naive low-pass smoothing of the path leaves it almost untouched. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — detail-chart, Light handheld

Light handheld camera shake applied to the locked-off detail-chart plate: up to 3.0 px of translation at 11.0 Hz, seed 5100. Sub-pixel-to-3-pixel translation at walking cadence — the residual wobble left after in-body stabilisation. Easy to correct, and the case where over-correction visibly crops the frame for nothing. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — detail-chart, Rotational roll

Rotational roll camera shake applied to the locked-off detail-chart plate: up to 4.0 px of translation and 1.6° of roll at 8.0 Hz, seed 5162. Translation plus up to 1.6° of roll. Translation-only stabilisers cannot fix roll at all, so this immediately separates 2-DOF from full-affine implementations. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — pan-city, Heavy handheld

Heavy handheld camera shake applied to the locked-off pan-city plate: up to 12.0 px of translation at 6.5 Hz, seed 5131. Twelve-pixel excursions at a slower, larger cadence: running, or a long lens. Requires real trajectory smoothing rather than frame-to-frame alignment. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — pan-city, High-frequency jitter

High-frequency jitter camera shake applied to the locked-off pan-city plate: up to 2.5 px of translation and 0.5° of roll at 23.0 Hz, seed 5193. Small, fast jitter near the frame rate — vibration from a vehicle or a drone motor. Aliases against the sampling rate, so naive low-pass smoothing of the path leaves it almost untouched. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — pan-city, Light handheld

Light handheld camera shake applied to the locked-off pan-city plate: up to 3.0 px of translation at 11.0 Hz, seed 5100. Sub-pixel-to-3-pixel translation at walking cadence — the residual wobble left after in-body stabilisation. Easy to correct, and the case where over-correction visibly crops the frame for nothing. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — pan-city, Rotational roll

Rotational roll camera shake applied to the locked-off pan-city plate: up to 4.0 px of translation and 1.6° of roll at 8.0 Hz, seed 5162. Translation plus up to 1.6° of roll. Translation-only stabilisers cannot fix roll at all, so this immediately separates 2-DOF from full-affine implementations. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — text-motion, Heavy handheld

Heavy handheld camera shake applied to the locked-off text-motion plate: up to 12.0 px of translation at 6.5 Hz, seed 5131. Twelve-pixel excursions at a slower, larger cadence: running, or a long lens. Requires real trajectory smoothing rather than frame-to-frame alignment. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — text-motion, High-frequency jitter

High-frequency jitter camera shake applied to the locked-off text-motion plate: up to 2.5 px of translation and 0.5° of roll at 23.0 Hz, seed 5193. Small, fast jitter near the frame rate — vibration from a vehicle or a drone motor. Aliases against the sampling rate, so naive low-pass smoothing of the path leaves it almost untouched. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — text-motion, Light handheld

Light handheld camera shake applied to the locked-off text-motion plate: up to 3.0 px of translation at 11.0 Hz, seed 5100. Sub-pixel-to-3-pixel translation at walking cadence — the residual wobble left after in-body stabilisation. Easy to correct, and the case where over-correction visibly crops the frame for nothing. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stabilisation Input — text-motion, Rotational roll

Rotational roll camera shake applied to the locked-off text-motion plate: up to 4.0 px of translation and 1.6° of roll at 8.0 Hz, seed 5162. Translation plus up to 1.6° of roll. Translation-only stabilisers cannot fix roll at all, so this immediately separates 2-DOF from full-affine implementations. Uncovered edges are filled black rather than padded, so the crop a stabiliser needs is visible in the input.

File: MP4 · Stab · 640x360
Use case: Video stabilisationVideo QA· Conversion set

Stream

DASH — Dynamic (Live) Manifest With a Time-Shift Buffer

A live DASH manifest: type is dynamic, there is no total duration, and the client must compute which segment is currently available from availabilityStartTime, the wall clock, and the segment duration. Declares a one-minute time-shift buffer and an eight-second presentation delay. The timestamps are fixed so the fixture stays deterministic — a real client will compute a segment number far in the future, which is itself a useful edge case to handle gracefully.

File: MPD · Stream · unbounded — no mediaPresentationDuration
Use case: Streaming manifestsConversion testing+1· Conversion set

DASH — Explicit SegmentList Addressing

The same content addressed with an explicit SegmentList — every segment URL enumerated rather than derived from a template. Verbose, but it is what older packagers emit and it permits non-uniform segment naming. A DASH client must support both this and SegmentTemplate; the paired template manifest in this group is the direct contrast.

File: MPD · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

DASH — Multi-Period Manifest With a Mid-Roll Break

Three DASH periods — content, an ad break, then content again — each with its own initialisation segment. Period boundaries are where players most often break: the decoder must be reset, the buffer cannot span the discontinuity, and rendition selection restarts. Pairs with the VMAP and SCTE-35 fixtures, which describe the same break from the ad-signalling side.

File: MPD · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

DASH — Static MPD With a Segment Template

A DASH manifest with separate video and audio adaptation sets, three video representations, and $RepresentationID$/$Number$ segment-template addressing — the standard VOD packaging shape. Served inline as application/dash+xml with permissive CORS, so dash.js can load it cross-origin. A manifest-parsing fixture: it describes segment URLs rather than shipping the segments.

File: MPD · Stream · PT14.0S
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — Ad Break With Discontinuity Markers

A media playlist with a mid-roll spliced in: EXT-X-CUE-OUT opens the break, EXT-X-DISCONTINUITY marks each boundary, and a fresh EXT-X-MAP re-initialises the decoder on both sides. This is what a packager produces from the SCTE-35 splice_insert fixture in this wave. Discontinuities are where players most often stall, because the timeline and the decoder both have to be reset.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — Byte-Range Addressed Single File

Every segment is a byte range of one backing file rather than a separate download, which is how low-overhead VOD packaging avoids thousands of small objects. The /files/stream/ headers expose Content-Range and Accept-Ranges cross-origin precisely so a player can do this from another origin. Tests Range request construction and offset arithmetic.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — CMAF Media Playlist

A VOD media playlist in CMAF form: an EXT-X-MAP initialisation segment followed by four fragmented-MP4 segments and an explicit ENDLIST. The final segment is deliberately short, as a real encode's last segment usually is. Tests target-duration handling, init-segment fetching, and correct total-duration arithmetic. A manifest-parsing fixture — the segments themselves ship with the streaming phase.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — I-Frame Only Playlist for Trick Play

An I-frame-only playlist: each entry is a byte range covering a single keyframe inside the media file, which is how players render scrub previews and fast-forward without decoding every frame. Declared in a master playlist via EXT-X-I-FRAME-STREAM-INF. Tests that a parser distinguishes these from normal media playlists — playing one as ordinary media produces a stuttering slideshow.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — Low-Latency Partial Segments

A Low-Latency HLS playlist: half-second EXT-X-PART fragments published ahead of their parent segment, a preload hint for the part still being written, and EXT-X-SERVER-CONTROL advertising blocking playlist reload. There is deliberately no ENDLIST, because this is a live playlist. Tests parsers against the LL-HLS tags, which are frequently unimplemented and must at minimum be ignored safely.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — Master Playlist With a Three-Rung Ladder

An HLS master playlist declaring a three-rung bitrate ladder plus a subtitle rendition group, with the CODECS, RESOLUTION and FRAME-RATE attributes a player needs to choose a rung before fetching anything. Served inline with permissive CORS from /files/stream/, so a player on another origin can load it directly. This is a manifest-parsing fixture — it describes the ladder rather than shipping its segments.

File: M3U8 · Stream
Use case: Streaming manifestsConversion testing+1· Conversion set

HLS — Segmented WebVTT Caption Playlist

The subtitle rendition the master playlist references through EXT-X-MEDIA. Captions in HLS are segmented like media — each segment is a small WebVTT file covering its own time window, carrying X-TIMESTAMP-MAP to align with the MPEG-TS clock. Completes the master playlist's declared rendition group so a player can resolve the whole tree.

File: M3U8 · Stream · en
Use case: Streaming manifestsConversion testing+1· Conversion set

Stream Corrupt

DASH — Intentionally Corrupt: Malformed ISO 8601 Duration

An intentionally corrupt DASH manifest whose mediaPresentationDuration is the bare number 14.0 instead of the ISO 8601 form PT14.0S. The XML is well-formed, so it parses cleanly and only fails at schema validation — which most players skip. The usual result is a duration of zero or NaN and a seek bar that never populates, with no error anywhere.

File: MPD · Stream Corrupt
Use case: Streaming manifestsVideo QA· Conversion set

HLS — Intentionally Corrupt: Missing #EXTM3U Signature

An intentionally corrupt HLS playlist with the mandatory #EXTM3U signature removed. Everything else is valid. The specification requires the first line to be exactly #EXTM3U and that clients reject anything else, so this separates conforming parsers from lenient ones that sniff for EXT tags instead.

File: M3U8 · Stream Corrupt
Use case: Streaming manifestsVideo QA· Conversion set

VTT — Intentionally Corrupt: Malformed Cue Timestamp

An intentionally corrupt WebVTT file with timestamps that are not zero-padded — 00:00:3.000 and 00:1:03.000 where the grammar requires two digits. The third cue is well-formed. A strict parser drops the two bad cues; a lenient one accepts them; a regex-based one may match partially and produce a time that is wrong rather than rejected, which is the worst outcome of the three.

File: VTT · Stream Corrupt
Use case: Streaming manifestsVideo QA· Conversion set

Structure

Bitstream — All-Intra (Every Frame a Keyframe)

Every frame is an I-frame, so any frame is an independent cut point. Much larger, and the shape editing and frame-accurate seeking want. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Bitstream — Heavy B-Frames (8 Consecutive)

Eight consecutive B-frames with a B-pyramid, so decode order and display order diverge sharply and DTS runs well behind PTS. The case that breaks naive timestamp handling and any code that assumes frames arrive in display order. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Bitstream — Long GOP (24 Frames, One Per Second)

One keyframe per second — the delivery default, and the setting that determines HLS/DASH segment boundaries, since a segment must start on a keyframe. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Bitstream — No B-Frames

I and P frames only. Required by some low-latency and legacy decoders, and it removes the reordering that makes decode order differ from display order. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Bitstream — Short GOP (8 Frames)

A keyframe every 8 frames with scene-cut detection disabled, so the GOP length is exactly what it says. Short GOPs cost bitrate but bound seek latency — the trade-off streaming packagers make explicitly. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Bitstream — Single GOP (One Keyframe Only)

Exactly one keyframe, at the start. Maximally efficient and nearly unseekable: a player must decode from frame zero to reach any position, which is what makes long-GOP archives painful to scrub. Same picture and same codec as every other clip in this group — only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

MP4 Layout — Faststart (moov Atom First)

The moov index is relocated to the front of the file, so a player can begin playback after the first few kilobytes. Required for progressive download to work at all. Byte-for-byte the same encode as its twin in this group; only the atom order differs, which is why comparing the two is the clean way to demonstrate the effect.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

MP4 Layout — Fragmented (fMP4 / CMAF)

Fragmented MP4: an empty moov followed by independent moof/mdat fragment pairs, rather than one monolithic index. This is what CMAF streaming actually delivers, and what makes a segment playable without the rest of the file. Parsers written against progressive MP4 frequently fail here, because there is no sample table to read up front.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

MP4 Layout — moov Atom at End

The default MP4 layout, with the index written last. A progressive-download player must fetch the entire file before it can start — the classic 'video buffers forever' bug, and invisible unless you look at the atom order. Byte-for-byte the same encode as its twin in this group; only the atom order differs, which is why comparing the two is the clean way to demonstrate the effect.

File: MP4 · Structure · 480x270
Use case: Video codecsConversion testing+1· Conversion set

Subs

MP4 — Hard-Burned Caption (EN)

Hard-burned EN SAMPLE caption for OCR language tests.

File: MP4 · Subs · 480x270
Use case: Conversion testingOCR testing· Conversion set

MP4 — Hard-Burned Caption (ES)

Hard-burned ES SAMPLE caption for OCR language tests.

File: MP4 · Subs · 480x270
Use case: Conversion testingOCR testing· Conversion set

MP4 — Hard-Burned Caption Twin

Hard-burned caption twin of the soft-sub clip — for burn-in detection and OCR.

File: MP4 · Subs · 480x270
Use case: Conversion testingOCR testing· Paired fixture

MP4 — Soft Subtitle Track

Short clip with a SAMPLE soft subtitle track (mov_text) — twin to the hard-burned caption.

File: MP4 · Subs · 480x270
Use case: Conversion testingSubtitle parsing· Paired fixture

SRT — Soft-Sub Companion

Companion SRT for the soft-sub MP4 — same SAMPLE cue timings.

File: SRT · Subs
Use case: Subtitle parsingConversion testing· Conversion set

VTT — Soft-Sub Companion

Companion VTT for the soft-sub MP4 — same SAMPLE cue timings.

File: VTT · Subs
Use case: Subtitle parsingConversion testing· Conversion set

WebM — VP9 Short Clip

Short VP9 WebM SAMPLE companion for container conversion tests.

File: WEBM · Subs · 480x270
Use case: Conversion testing· Conversion set

Subtitle Tracks

Multi-Track Subtitles — Embedded WebVTT (WebM)

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.

File: WEBM · Subtitle Tracks · 8 cues
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — Forced Narrative (MKV)

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.

File: MKV · Subtitle Tracks · 8s
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — No Subtitle Track (MP4)

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.

File: MP4 · Subtitle Tracks · 8s
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — SDH and Standard (MKV)

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.

File: MKV · Subtitle Tracks · 8s
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — Styled ASS Track (MKV)

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.

File: MKV · Subtitle Tracks · 8s
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — Three Languages (MKV)

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.

File: MKV · Subtitle Tracks · 480x270
Use case: Media accessibilitySubtitle testing+2· Conversion set

Multi-Track Subtitles — Two mov_text Tracks (MP4)

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.

File: MP4 · Subtitle Tracks · 8s
Use case: Media accessibilitySubtitle testing+2· Conversion set

Subtitles

Soft Subtitles — MKV (SRT track)

A clip with a soft (muxed, toggleable) SRT subtitle track in a Matroska container — the subtitles are a separate stream, not burned in. A fixture for testing subtitle extraction, rendering, and toggling.

File: MKV · Subtitles · 480x270
Use case: Conversion testing· Conversion set

Soft Subtitles — MP4 (mov_text track)

The same clip with a soft subtitle track as MP4 mov_text (the MP4-native subtitle format) — the format twin of the MKV/SRT file, for testing subtitle handling across containers.

File: MP4 · Subtitles · 480x270
Use case: Conversion testing· Conversion set

Superres

Super-Resolution Ground Truth — detail-chart

The full-resolution reference for the detail-chart super-resolution set at 640x360. Every low-resolution input in this group was produced by downscaling these exact pixels with a recorded filter, so an upscaler's output can be compared against the true original instead of against another upscale.

File: MP4 · Superres · 640x360
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Ground Truth — pan-city

The full-resolution reference for the pan-city super-resolution set at 640x360. Every low-resolution input in this group was produced by downscaling these exact pixels with a recorded filter, so an upscaler's output can be compared against the true original instead of against another upscale.

File: MP4 · Superres · 640x360
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Ground Truth — text-motion

The full-resolution reference for the text-motion super-resolution set at 640x360. Every low-resolution input in this group was produced by downscaling these exact pixels with a recorded filter, so an upscaler's output can be compared against the true original instead of against another upscale.

File: MP4 · Superres · 640x360
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷2 Area / box

The detail-chart plate downscaled 2× to 320x180 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷2 Bicubic

The detail-chart plate downscaled 2× to 320x180 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷2 Nearest neighbour

The detail-chart plate downscaled 2× to 320x180 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷3 Area / box

The detail-chart plate downscaled 3× to 212x120 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷3 Bicubic

The detail-chart plate downscaled 3× to 212x120 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷3 Nearest neighbour

The detail-chart plate downscaled 3× to 212x120 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷4 Area / box

The detail-chart plate downscaled 4× to 160x90 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷4 Bicubic

The detail-chart plate downscaled 4× to 160x90 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — detail-chart, ÷4 Nearest neighbour

The detail-chart plate downscaled 4× to 160x90 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷2 Area / box

The pan-city plate downscaled 2× to 320x180 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷2 Bicubic

The pan-city plate downscaled 2× to 320x180 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷2 Nearest neighbour

The pan-city plate downscaled 2× to 320x180 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷3 Area / box

The pan-city plate downscaled 3× to 212x120 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷3 Bicubic

The pan-city plate downscaled 3× to 212x120 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷3 Nearest neighbour

The pan-city plate downscaled 3× to 212x120 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷4 Area / box

The pan-city plate downscaled 4× to 160x90 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷4 Bicubic

The pan-city plate downscaled 4× to 160x90 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — pan-city, ÷4 Nearest neighbour

The pan-city plate downscaled 4× to 160x90 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷2 Area / box

The text-motion plate downscaled 2× to 320x180 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷2 Bicubic

The text-motion plate downscaled 2× to 320x180 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷2 Nearest neighbour

The text-motion plate downscaled 2× to 320x180 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 320x180
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷3 Area / box

The text-motion plate downscaled 3× to 212x120 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷3 Bicubic

The text-motion plate downscaled 3× to 212x120 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷3 Nearest neighbour

The text-motion plate downscaled 3× to 212x120 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 212x120
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷4 Area / box

The text-motion plate downscaled 4× to 160x90 using a area / box filter. Simple pixel averaging, what a camera's binning path actually does. Softer than bicubic and not what most models saw in training, which makes it a fairer test. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷4 Bicubic

The text-motion plate downscaled 4× to 160x90 using a bicubic filter. The standard downscale in most benchmarks. Mild ringing at edges, and the filter most super-resolution models are trained to invert — so it flatters them. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Super-Resolution Input — text-motion, ÷4 Nearest neighbour

The text-motion plate downscaled 4× to 160x90 using a nearest neighbour filter. Point sampling with no filtering at all, so downscaling aliases hard. The Siemens star folds into moiré, and no amount of upscaling can recover what aliasing destroyed. Upscale it back to 640x360 and score against the ground truth in this group — the filter is recorded because which one was used changes the difficulty far more than the scale factor does.

File: MP4 · Superres · 160x90
Use case: Video upscalingVideo QA· Conversion set

Sync

A/V Sync — Beep + Flash (MP4, with audio)

A five-second clip that flashes white and plays a 1 kHz beep on every whole second — the first clip in the library WITH an audio track. A direct fixture for measuring and correcting audio/video sync (lip-sync) offset.

File: MP4 · Sync · 480x270
Use case: Conversion testingAudio analysis

Test Patterns

Countdown with Timecode (MP4)

A six-second countdown (5→0) with a sweeping second-arc, a burned-in SS:FF timecode, and a beep on each second — a slate/leader fixture for testing timecode reading, frame-accurate seeking, and sync.

File: MP4 · Test Patterns · 480x270
Use case: Conversion testing

SMPTE Colour Bars + 1 kHz Tone (MP4)

Standard SMPTE-style colour bars with a 1 kHz reference tone — the classic broadcast test pattern. A fixture for calibrating colour, testing decoders, and verifying audio alongside a known video signal.

File: MP4 · Test Patterns · 480x270
Use case: Conversion testingAudio analysis

Thumbnails Track

jpg

41.6 KB

Thumbnail Track — Sprite Sheet

A 6x2 sprite sheet of 160x90 scrub-preview thumbnails in a single JPEG. Players fetch one image rather than 12 separate requests, then crop each tile with a media fragment — which is why the WebVTT index in this group is the load-bearing half of the pair. Useless on its own; that is the point of shipping them together.

File: JPG · Thumbnails Track
Use case: Streaming manifestsVideo QA· Conversion set

Thumbnail Track — WebVTT Sprite Index

The WebVTT half of a scrub-preview pair: each cue covers a slice of the timeline and its payload is a media-fragment URL naming a rectangle of the sprite sheet. This is how seek-bar previews are delivered in practice, and the #xywh fragment syntax is the part players implement inconsistently — some resolve it relative to the VTT, others to the page, and some ignore the fragment entirely and show the whole sheet.

File: VTT · Thumbnails Track · 12 cues
Use case: Streaming manifestsSubtitle parsing+1· Conversion set

Ts

TS — MPEG-TS H.264 Clip

The clip as an MPEG transport stream (.ts) — the container behind HLS streaming and broadcast. For testing TS demuxing and HLS tooling.

File: TS · Ts · 480x270
Use case: Conversion testing

Vod Dash

DASH VOD — Init Segment (init-stream0.m4s)

A DASH initialisation segment carrying codec configuration for one representation. Named by the manifest's $RepresentationID$ template, so this file also exercises whether a client resolves template variables correctly rather than pattern-matching filenames.

File: M4S · Vod Dash
Use case: Streaming manifestsVideo codecs+1· Conversion set

DASH VOD — Init Segment (init-stream1.m4s)

A DASH initialisation segment carrying codec configuration for one representation. Named by the manifest's $RepresentationID$ template, so this file also exercises whether a client resolves template variables correctly rather than pattern-matching filenames.

File: M4S · Vod Dash
Use case: Streaming manifestsVideo codecs+1· Conversion set

DASH VOD — Init Segment (init-stream2.m4s)

A DASH initialisation segment carrying codec configuration for one representation. Named by the manifest's $RepresentationID$ template, so this file also exercises whether a client resolves template variables correctly rather than pattern-matching filenames.

File: M4S · Vod Dash
Use case: Streaming manifestsVideo codecs+1· Conversion set

DASH VOD — Manifest (Playable Package)

A complete, playable MPEG-DASH manifest for the same 320x180 at 300 kbps, 480x270 at 700 kbps, 640x360 at 1400 kbps ladder as the HLS package, produced from the same encoder run — so the two can be compared directly as packaging rather than as content. Every segment it references exists in this group. Served inline as application/dash+xml with permissive CORS, so dash.js can load it cross-origin.

File: MPD · Vod Dash
Use case: Streaming manifestsVideo codecs+1· Conversion set