
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
Find files, editable templates and browser test targets by what you need to make or test. The directory below is cut by format; the two collections under it cut the same library by subject and by workflow.
Page 12 of 19; 24 results per page.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.