Choose between SRT and RTMP for a live contribution feed and configure FFmpeg SRT caller/listener ingest

Steps

1. Compare protocol properties before choosing: SRT runs over UDP with its own retransmission/error correction and typically achieves around one second of latency with built-in AES-128/192/256 encryption, while RTMP runs over TCP with higher typical latency (roughly two to five seconds) from head-of-line blocking and has no native encryption unless wrapped as RTMPS
2. For contribution links over unpredictable public internet (e.g., a remote camera or venue back to a studio), prefer SRT for its packet-loss recovery on lossy or variable networks
3. Pick an SRT connection mode based on network topology: caller mode (the encoder initiates the connection to a fixed, publicly reachable listener) is the standard production pattern; listener mode (the encoder waits passively) suits pull-based ingest; rendezvous mode (both sides connect simultaneously) can help when both endpoints are behind NAT but requires each side to know the other's address and is less common in production
4. In FFmpeg, ingest with a URL like srt://host:port?mode=caller&latency=<ms>&passphrase=<key>, tuning the latency parameter to the link's actual round-trip and jitter characteristics
5. Use FFmpeg to remux between SRT's MPEG-TS container and RTMP's FLV container at a gateway if a downstream service only accepts RTMP ingest
6. Confirm the downstream platform or CDN actually accepts SRT ingest before committing to it as the sole contribution protocol, since not every ingest endpoint supports it yet