SRT streaming for reliable contribution when the network is unpredictable.

SRT streaming uses the Secure Reliable Transport protocol to send live video across public networks with error recovery and optional encryption. It is designed for resilient, low-latency contribution, which makes it popular for remote production and broadcast backhaul. Castr supports SRT ingest on all plans.

RTMP is a long-established, widely supported protocol for straightforward encoder publishing. SRT is often chosen when the network is unreliable, because it recovers from packet loss and can encrypt the feed. Castr accepts both, so you can match the protocol to the production.

An SRT server, also called an SRT live server, accepts an incoming SRT stream, or serves one for pull, and hands it to a delivery workflow. Castr runs managed SRT ingest at 40+ locations worldwide, so you send an SRT feed to a nearby point without configuring and maintaining your own server.

SRT streaming software is any tool that sends or receives video over the SRT protocol, from encoder software like OBS Studio or vMix on the sending side to a platform like Castr on the receiving side. Castr's managed SRT service receives your feed, transcodes it, and handles playback, recording, and multistreaming without server software to run.

SRT runs over UDP, not TCP. There is no single fixed port. You choose a UDP port for the SRT stream and make sure it is open on both ends. A firewall that only allows TCP will block SRT, so confirm UDP is permitted on the port you configure.

The passphrase enables SRT's built-in encryption, so only endpoints with the matching passphrase can decrypt the feed. The stream ID (streamid) identifies which stream you are connecting to on the server, which lets one ingest endpoint route multiple streams. Set both to match what the ingest expects.

In caller mode the encoder initiates the connection to a listening server, and in listener mode the device waits for an incoming connection. In rendezvous mode both sides connect to each other, which helps when both are behind firewalls. Pick the mode that matches how your encoder and the ingest are set up.

SRT uses a latency buffer, usually set in milliseconds, that trades delay for resilience: a higher value recovers more lost packets on a poor network, while a lower value reduces contribution delay. Set it based on your network quality, and remember it affects contribution, not final viewer latency.

Choose SRT when the path between your encoder and the server crosses unreliable links such as the public internet, cellular, or long-haul connections, or when you need the feed encrypted in transit. If your network is solid and your gear is RTMP-first, RTMP is still a dependable choice, and Castr accepts both.

Yes. Castr can pull from an SRT source (acting as caller to your listener) as well as accept pushed SRT feeds. Availability of pull workflows varies by plan. Either way, confirm the mode, host, and port on both ends.

No. SRT settings control contribution latency, the leg from your encoder to Castr. What viewers experience also depends on transcoding, the delivery protocol, the player, and audience scale.

Yes. Castr’s video team will walk through your current setup, from sources and destinations to audience scale, security, and monetization, and confirm the fit before you migrate.