The same footage across codecs, containers, and pixel formats

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 — 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 — 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

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 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 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

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 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

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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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

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 — 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

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 — 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 — 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

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 — 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 — 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 — 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

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

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

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 — 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 — 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 — 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

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 — 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

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 — 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

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

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

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 — 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

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

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

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

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

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 — 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.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 — 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

HLS VOD — CMAF Init Segment (init_0.m4s)

A CMAF initialisation segment: the moov box carrying codec configuration and track metadata, with no media samples. A player must fetch this before any media segment of the same rendition, and switching renditions mid-stream means fetching the new rendition's init first — the step ABR implementations most often get wrong.

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

HLS VOD — CMAF Init Segment (init_1.m4s)

A CMAF initialisation segment: the moov box carrying codec configuration and track metadata, with no media samples. A player must fetch this before any media segment of the same rendition, and switching renditions mid-stream means fetching the new rendition's init first — the step ABR implementations most often get wrong.

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

HLS VOD — CMAF Init Segment (init_2.m4s)

A CMAF initialisation segment: the moov box carrying codec configuration and track metadata, with no media samples. A player must fetch this before any media segment of the same rendition, and switching renditions mid-stream means fetching the new rendition's init first — the step ABR implementations most often get wrong.

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

HLS VOD — Master Playlist (Playable Package)

The entry point to a COMPLETE and genuinely playable HLS package: a 3-rung ladder (320x180 at 300 kbps, 480x270 at 700 kbps, 640x360 at 1400 kbps) with real CMAF segments alongside it in this group. Point hls.js or Safari at this URL and it plays — it is served inline with permissive CORS from /files/stream/, so it works cross-origin without re-hosting. Unlike the hand-authored HLS fixtures elsewhere in the catalog, which are parser tests that reference placeholder segment names on purpose, everything this playlist references actually exists.

File: M3U8 · Vod Hls
Use case: Streaming manifestsVideo codecs+1· Conversion set

HLS VOD — Media Segment (seg-0-000.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Segment (seg-0-001.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Segment (seg-1-000.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Segment (seg-1-001.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Segment (seg-2-000.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Segment (seg-2-001.m4s)

A one-second fragmented-MP4 media segment (moof + mdat) from the playable ladder. It starts on a keyframe, so it decodes independently once the matching init segment has been loaded — which is what makes mid-stream quality switching possible at all.

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

HLS VOD — Media Playlist (0)

One rendition of the playable HLS ladder, listing its own CMAF init segment and media segments. Referenced by the master playlist in this group. Generated by ffmpeg's own HLS muxer, so the segment durations, the EXT-X-MAP and the ENDLIST are exactly what a real packager emits rather than what a human thinks one emits.

File: M3U8 · Vod Hls
Use case: Streaming manifestsVideo codecs+1· Conversion set

HLS VOD — Media Playlist (1)

One rendition of the playable HLS ladder, listing its own CMAF init segment and media segments. Referenced by the master playlist in this group. Generated by ffmpeg's own HLS muxer, so the segment durations, the EXT-X-MAP and the ENDLIST are exactly what a real packager emits rather than what a human thinks one emits.

File: M3U8 · Vod Hls
Use case: Streaming manifestsVideo codecs+1· Conversion set

HLS VOD — Media Playlist (2)

One rendition of the playable HLS ladder, listing its own CMAF init segment and media segments. Referenced by the master playlist in this group. Generated by ffmpeg's own HLS muxer, so the segment durations, the EXT-X-MAP and the ENDLIST are exactly what a real packager emits rather than what a human thinks one emits.

File: M3U8 · Vod Hls
Use case: Streaming manifestsVideo codecs+1· Conversion set