Probe receives a stream, analyses it and reports — and passes nothing on, so it can sit beside a live path without becoming part of it. Launched by norsk-ctl from a template you describe in config, with an operator dashboard of its own. Two ways in: by what you want to do, or by a worked deployment.

One screen: the stream analysed, the quality snapshot updating, alerts quiet on a clean source, and the probe's own low-latency preview beside them.

A tap probe sits beside the stream: it receives, analyses and reports, and passes nothing on. Nothing downstream depends on it, so it can be added to a live path and taken away again without the path changing shape.

1. 01

   Described in config

   A tap is a product template — a transport, a port, a stream id — stored beside the multi-source wall that probe publishes by default. The web form and the JSON file describe the same thing, so a template can be built either way.

   
2. 02

   Launched and waiting

   The launched probe, healthy, listening on the transport its template named, with nothing to analyse yet. Healthy is not the same as running a workflow: the probe's own API is the surface that knows.

   
3. 03

   It picks the stream up

   Point a stream at it and the probe starts analysing. Stop the stream and it notices the source go away — it is watching, not latching.

   

A probe instance is not only a source of readings for something else to draw: it serves an operator dashboard of its own, and norsk-ctl proxies it at /instance/<id>/dashboard/workflow/. One screen, no tabs — what the stream is, how good it is, what the transport is doing, and what has happened.

1. 01

   Analysing a live stream

   The dashboard on a real deployment, with the probe's own low-latency preview playing beside the readings. Every number on the page arrives over the dashboard's own data feed.

   
2. 02

   Two scores, not one

   MQA grades video and audio independently on 0-100, because they fail independently: a frozen picture with clean sound and a clean picture with dead sound are different faults. Each axis carries its own threshold profile, switched live — the grading changes without restarting the probe.

   
3. 03

   The detectors behind the audio score

   Loudness and true peak against the R128 target, plus what a loudness meter cannot catch: silence, clipping, DC offset, phase, tone, noise and mains hum. A greyed row is a detector with no live reading — not a healthy one.

   
4. 04

   And the transport underneath

   TR 101 290 priority 1 and 2 counters, cumulative since the stream started. This is the layer that says whether a picture fault is really a delivery fault.

   
5. 05

   What has already happened

   The event log is durable and filterable by kind, so an operator arriving after the fact sees what the probe saw rather than only what is true now.

   

The reason to run a probe. These are the same panels in the same places — an operator does not re-learn the screen under pressure — reading a stream whose picture has gone black and whose audio has died.

1. 01

   The screen changes colour, not shape

   Scores collapse, the alert panel fills, the header says degraded. Nothing has moved.

   
2. 02

   What is wrong, and since when

   Active alerts carry severity and the moment they were raised, so the panel answers both questions an operator has: what is failing, and whether it started just now or ten minutes ago.

   
3. 03

   Scored, not just flagged

   An alert says a threshold was crossed; the score says how badly. Video has collapsed while audio is merely poor — the difference between a dead feed and a feed with a problem.

   
4. 04

   Is the probe itself keeping up?

   Analysis health says whether to trust the rest. Here analysis is running behind its latency budget, which is a fact about the probe and not about the stream — the dashboard never lets the two look alike.

   
5. 05

   The order it happened in

   The event log puts the alerts in sequence against everything else the probe saw, so the picture failing before the sound is visible rather than inferred.

   

A wall instance watches other probes rather than a stream: it reads each one's own probe-api and draws them together. It aggregates, it does not re-analyse — every reading on a tile is the reading that probe published.

1. 01

   The monitor wall

   Six probes, mixed health, in an authored layout so the channel that matters holds the big tile. The tiles carry no picture in these captures because they are made with no engine behind them; on a real wall each one plays that probe's low-latency preview.

   
2. 02

   Or only the ones in trouble

   The penalty box reads the same probes the other way round: healthy ones collapse to a roster along the bottom and only the failing ones take screen space, worst first. On a wall of forty channels that is the difference between a screen you scan and a screen you search.

   

More of this walkthrough is coming — this deployment shape has one screen captured so far.

Probe is a norsk-ctl product: registering it pulls the image, reads its manifest and stores the templates it publishes. Everything after that — launching, reaching the instance, feeding it a test stream — is the platform's, not probe's.

1. 01

   Behind an authenticating proxy

   norsk-ctl is served through a proxy, so the first request lands on a sign-in form backed by the user configured during init. There is no unauthenticated surface to reach past.

   
2. 02

   One product, one instance

   Signing in lands on the dashboard: the registered product, the running instance, and the sidebar the rest of the platform hangs off.

   
3. 03

   Something to watch

   norsk-ctl ships sample sources for exactly this moment. Developer -> Sources lists them; starting one pushes it into the instance you pick, over the transport that instance is listening on.

   

The whole journey, from an empty machine to a probe analysing a live stream: initialise norsk-ctl, register probe with a license, build a tap template, launch it, and give it something to watch. Nothing here is pre-seeded.

1. 01

   Sign in

   init has written the config and the first proxy user; the browser lands on the sign-in form that user backs.

   
2. 02

   The platform, with probe registered

   Registration pulled the image, read the manifest and stored the templates probe publishes by default.

   
3. 03

   Two templates

   The wall registration published, and the tap probe just built — an SRT listener on port 5001 for stream id camera1.

   
4. 04

   Launch it

   Launching starts the instance's containers. The probe comes up healthy and listens, with no stream on the port yet.

   
5. 05

   Pick a source

   The Sources page, with this probe chosen as the target. The sample source pushes over the transport the template declared.

   
6. 06

   The stream arrives

   The source reports running, and so does the probe: the row and the probe's API agree that a stream is being analysed.

   
7. 07

   Read it

   The probe's own dashboard, analysing the live stream. Stopping the source is enough to see it notice; deleting the instance stops its containers and frees its ports.