Know what a vendor's update changed
before your viewers
do
Your pipeline is software now, and a new version lands every other week. This runs the QC pass before air automatically on every one of them — so a regression is caught in pre-production instead of on screen.
What changes when the QC pass runs before air
The update goes in and nothing errors, so it goes to air. Whatever it changed surfaces later, as a viewer complaint. By then the moment has passed and nothing recorded it, so the first job is reproducing something you never saw.
The same update runs first against content you already know, and every result is recorded. You get the list of what changed and the recording it changed in, while the release is still in pre-production — so rolling it back is a decision someone makes calmly, before it ever reaches a viewer.
Every vendor update is paid for somewhere
Stay on the version you trust
It works, so you freeze it.
Paid in the features and security patches that ship after itPut people on every release
An afternoon of watching the output, per update, every couple of weeks.
Paid in the engineers you had planned other work forShip it and find out
A channel that stopped working. A picture that got worse. An ad break that stopped being inserted.
Paid in what your viewers getNobody picks the last one — it is what is left when you will not fall behind and cannot spare the people.
Known content in, recorded result out, compared two ways
It runs beside your pipeline, on its own infrastructure. Your vendors' products stay exactly as they are.
A test for the whole pipeline
An update can be correct on its own and still break your workflow. The only thing that catches that is exercising the whole chain, integrated.
It runs on machine time
So it can run on every release, including the routine ones that nobody thought to question.
Everything above is what this does. Below is how a run is put together, what it checks, and which parts arrive ready. See how a run works
The six things a run checks
Close to twenty ready-built instruments sit behind these. Which questions a run asks, and what counts as the same as before, is yours to set.
Picture quality — is the image still what it was?
Objective quality
VMAF on the same piece of content, against what it scored in the release before.
Logo and slate detection
The branding that has to be on screen is on screen, and the slate that should not be is not.
Audio and video in sync
Drift that a person only notices after a few seconds of watching, measured instead.
Standards conformance — read against the spec it claims to follow
Transport stream conformance
The stream checked against the specification it claims to follow.
HLS and DASH manifests
A tag that disappears, or comes back written differently. Most players tolerate it; the one that does not is a device family you cannot test by hand.
Signalling and subtitles
SCTE markers, subtitle PIDs, PTS restamping — the metadata a downstream system was built around.
Outputs and destinations — checked as delivered video
Stream presence
Every destination is actually delivering video, rather than holding an open socket and a healthy status page.
Manifest freshness
Across clusters, so a destination that quietly stopped updating is a test result and not a viewer complaint.
Control plane and state — what is really running after the upgrade
Configuration after an upgrade
Channel state read out of the system itself, rather than taken from the release notes.
Did the upgrade do what it claimed?
The version is one question. Whether the settings survived it is another.
Integration contracts — what your pipeline tells everything else
Events still produced
The messages your pipeline emits, still emitted — and still in the shape the consumer expects.
How the pieces fit together
A vendor improves an API and it does exactly what it says. Another piece of your pipeline was built around the old shape.
Behaviour under failure — on purpose, in pre-production
Fault injection
Platform workloads taken down while the content is playing, so behaviour under fault is a result rather than a surprise at 2am.
Recovery, measured
What the stream does while a component is gone, and what it does when it comes back.
The instrument behind each question is the part that travels. Building one takes knowledge of this domain — how an ABR ladder relates to its segment manifests, what a discontinuity implies for the device that meets it — which is why a general-purpose test framework has no way to phrase the question in the first place.
What arrives built, and what stays yours
- Arrives built
- Test orchestration on Kubernetes, picture quality measurement, stream and manifest probes, the evidence store that holds every recording and result, fault injection, and the content player and recorder.
- Built for you
- One adapter per component you want driven, with its test suites assembled from checks that already exist. Reference content taken from your own streams, some of it broken on purpose so the checks can be proven to catch it.
- Stays yours
- Your encoders, your playout, your contribution and edge, your stream control. A packager, an origin, a CDN or an ad insertion service is the same work to add, and nothing already built has to change.
Nothing else is built per installation. Everything else is configuration.
Which release goes in next?
Tell us what is in your pipeline and how often it changes. We will show you what a run would ask of it.
Talk to us