testsrc

Video files that break players

Generated test files for players, upload pipelines and transcoders. Every frame is numbered, every second beeps, and each file comes with a fact sheet your tests can assert against.

The facts behind the file

The clip above is one file from the catalog. Its fact sheet says what it contains and what a correct player shows, measured with ffprobe and checked by a second decoder. Your test asserts against it.


      

Changes with the file you pick above.

Built on a known player?

If your app plays video through libvlc, FFmpeg, GStreamer or mpv, every case runs through it out of the box. The runner plays each case in its own process and checks what the player shows, frame by frame, against the fact sheet. A crash or a hang is a result, not the end of the run.

$ testsrc run --player libvlc

Custom player stack?

Your own player, a fork, a set-top box app or a web player. Wrap its command line and every case runs through it, with a JUnit report for CI. Native and browser players can also hand their frames to the testsrc checker, which is coming soon.

$ testsrc run --player cmd --command "myplayer {file}" --junit report.xml

Same files, same checks, same report, whichever player you test.

Real edge cases that broke players

Browse the library
A television master control room: a wall of monitors above rows of desks with operators
A broadcast control room, Toronto, 2012. Every one of those screens is a player.

First, pick a case.

Browse the catalog by container, codec or what it breaks. Every case page says why the file exists.

  1. Pick a case
  2. Fetch it
  3. Assert the facts
  4. Run your player

Check it by eye

A real file, playingedge/mpeg-ps-mpeg1-video.mpg, 150 frames
A number on every frameDropped, held or reordered frames show in a screenshot.
Burned-in timecode
A flash and a beepOn the same frame, once a second.
Damage on purposeThe index says 180 frames; the bytes end after frame 143.
The bottom of a real testsrc frame: a row of colour patches and two rows of black and white blocks that encode the frame number
A code a machine can readColour patches and the frame number in blocks, on every frame.

Fetch with a token, from CI.

Open-source projects

For open-source players, decoders, transcoders and frameworks: CI, bug-report templates, regression tests.

Free

token on request
Ask for a token

Companies

Tokens for CI, scripts and agents. Pinned snapshots, full fact sheets and expected outcomes. On request: the files on your own servers, custom cases. Evaluate it for 14 days first.

From

$6,000

a year per organisation
Ask for an evaluation

Usage is metered per token. Tokens used to mirror or resell the catalog without an agreement are revoked.

Questions engineers ask

Can I use the files commercially?

Yes. Test, modify, commit them to your repo, ship them in your test suite and attach them to bug reports. Credit “Test media by testsrc.com”.

What can't I do with them?

Host them as a collection or sample library, resell them, or put them in a public dataset, AI training sets included.

Which players does it work with?

libvlc, FFmpeg, GStreamer and mpv are built in. Any other player, including your own, runs through its command line.

Where do the files come from?

Every file is generated from a recipe. All picture and sound is synthetic, so there's no third-party footage in any of them.

How do you know the facts are right?

Each file is measured with ffprobe and decoded by a second decoder before it's published. A file that doesn't match its recipe isn't published.

Is it free for open-source projects?

Yes. Ask for a token with the form below and say what you'll test. Tokens are rate-limited, and honest use is welcome.

Can you help with a bug a test file doesn't solve?

Yes. Describe it in the form below.

Hitting a media bug you can't crack?

Some bugs live in the bitstream, a muxer's quirk or a decoder's corner case. Tell us what breaks, or what you'd test, and get early access.

Built by Martin Finkel, VLC developer.