Introducing Evrideo StreamCheck: A Free SRT Diagnostic Tool for Broadcast Engineers

Live video contribution has a habit of making small uncertainties feel very large. A stream that worked perfectly in the office can behave differently from a venue, a hotel network, a temporary uplink, or a production laptop that has never been tested against the actual cloud region receiving the feed.

That is why we built Evrideo StreamCheck: a free SRT diagnostic tool that lets engineers and production teams run a quick, structured test before a live workflow depends on it.

StreamCheck creates a temporary SRT ingest URL, captures a short diagnostic window, analyses the incoming transport stream, and returns a readable report. It is designed to answer a simple question before it becomes an expensive one: is this contribution path healthy enough to trust?

The Problem StreamCheck Solves

SRT is an excellent protocol for moving live video over unpredictable networks, but the real world still matters. Firewalls, NAT behaviour, packet loss, jitter, incorrect latency buffers, encoder settings, PID errors, SCTE-35 expectations and transport stream continuity can all affect whether a feed behaves reliably.

Most teams have a familiar pattern: open the encoder, paste in an SRT URL, start sending, and hope the far end sees something useful. If the stream fails, the troubleshooting process can quickly become subjective. Is the problem the encoder, the network path, the SRT configuration, the media payload, the cloud ingest, or the MPEG transport stream itself?

StreamCheck gives that process a fixed diagnostic shape. Instead of guessing, you get evidence.

How It Works

When you start a diagnostic, StreamCheck allocates a temporary SRT endpoint on one of the available test nodes. You send your stream to that endpoint for the diagnostic window, and StreamCheck records the result as a structured report.

The current diagnostic flow focuses on practical pre-flight checks:

• SRT connection state: whether a caller connected successfully to the generated ingest URL.
• SRT latency buffer: whether the configured latency appears conservative, appropriate, or potentially reducible based on observed network behaviour.
• Network telemetry: round-trip timing, estimated jitter, packet loss, retransmits and dropped packet counters where available.
• Transport stream evidence: packet size, sync byte health, continuity loss and other MPEG-TS signals.
• TR 101 290-style checks: deterministic transport stream checks using TSDuck-based analysis.
• SCTE-35 detection: whether a cue stream PID and marker packets were detected in the captured PMT.
• Timing information: PCR and PTS observations that help engineers understand whether the stream timing looks stable.
• Media inspection: codec, resolution, frame rate and bitrate information for the received payload.

The result is not just a green or red light. StreamCheck produces a report that is useful to a broadcast engineer, but it also explains the results in plain language for less technical users.

Designed for Real Contribution Workflows

A useful diagnostic tool needs to feel close to the conditions of a real workflow. StreamCheck can be deployed as independent regional nodes, so a user can test against the geography that matters to the job. For example, an engineer in Europe may want to test against the London node, while a US production team may want to test against a US East node.

That matters because an SRT test is not only a test of the encoder. It is a test of the path between the encoder and the destination. A stream that is perfect to one cloud region may have a different round-trip profile, jitter pattern or loss behaviour to another.

This also helps teams make better latency decisions. SRT latency is a buffer, not a badge of honour. Set it too low and you may expose viewers or downstream systems to instability. Set it too high and you add delay that may not be necessary. StreamCheck gives a recommendation based on the observed diagnostic, so users can decide whether to keep the current buffer or carefully try a lower one.

Why We Include TR 101 290 and SCTE-35 Evidence

Connectivity alone is not enough. A stream can connect successfully and still carry transport-level issues that cause problems downstream. That is why StreamCheck looks beyond basic reachability.

TR 101 290 checks help identify MPEG transport stream problems such as sync loss, continuity count errors, PAT and PMT issues, transport errors and PCR-related timing concerns. These are the kinds of details that matter when a feed is going into a broadcast chain rather than a casual player.

SCTE-35 matters for a different reason. Many live and linear workflows depend on ad markers, programme boundaries or downstream signalling. StreamCheck does not try to replace a full compliance system, but it can quickly tell you whether SCTE-35 signalling appears to be present in the stream under test.

Privacy by Design

StreamCheck is a diagnostic tool, not a media storage product. Evrideo does not retain processed video or logs of any kind. Temporary captures and diagnostic logs are permanently deleted as soon as analysis is complete.

That principle is important. Engineers should be able to test contribution paths without creating a new content retention problem or accidentally storing production material in yet another system.

What StreamCheck Is Not

StreamCheck is intentionally lightweight. It is not a replacement for continuous production monitoring, a full compliance recording platform, or a permanent QoS system. It is a fast, practical pre-flight test for SRT contribution.

That focus is deliberate. The point is to make it easy to answer the questions teams ask before a live event, a contribution feed, a remote production test, or a new encoder setup:

• Can the stream connect?
• Is the SRT path stable?
• Is the latency buffer sensible?
• Does the transport stream look clean?
• Are the expected markers and timing signals present?
• Can I share a report with the rest of the team?

Try It

You can launch StreamCheck from the Evrideo tools page. Choose the test node closest to the workflow you want to validate, start a diagnostic, send your SRT stream to the generated URL, and review the report after the diagnostic window completes.

For teams building cloud-native broadcast workflows, this is exactly the kind of practical tooling we believe should exist: simple to launch, technically honest, and useful before something goes live.