SRT lost to RTMP on a long international path

An SRT ingest from a remote production kept corrupting and freezing. The international path was long, with RTT around 183 ms.

I first raised SRT latency to 1000 ms. Then I suspected the server configuration. Both diagnoses were wrong: a larger recovery window cannot fix a path where transit networks filter or degrade UDP.

A protocol's reputation is irrelevant when the transit network will not let it work. The real path gets the final vote.

SRT is built for lossy links, but it has one prerequisite — UDP must pass. That prerequisite did not hold here.

RTMP over TCP took the exact same path cleanly. It had run for 22+ minutes without a freeze or corruption at the check, then held through the live production.

The standby that stayed idle

I also built a Mist relay on an existing Amsterdam VDS: SRT in, RTMP out. It took about an hour to configure and port-test.

We never activated it. The direct TCP path held, so another node in a healthy chain would only add a failure point. Insurance remains useful even when it stays unused.

Three rules survived the test:

→ transport fit beats transport fashion → viewers were never exposed to this problem; HLS runs over TCP → transport does not change mid-event; the decision happens before the first whistle