Hakari

What is SRT?

SRT (Secure Reliable Transport) is an open-source UDP-based protocol for live video contribution, created at Haivision and adopted industry-wide. It exists to solve the problems RTMP has over the public internet: packet loss, jitter, and no built-in encryption.

SRT became the preferred contribution protocol for broadcasters running live video across lossy long-haul links — regional event coverage, field productions, cross-continent news feeds.

Why SRT over RTMP?

| | RTMP | SRT | | --- | --- | --- | | Transport | TCP | UDP + custom reliability layer | | Packet loss behavior | Head-of-line blocks entire stream | Selective retransmission, no blocking | | Encryption | None (add TLS manually) | AES-128/256 built-in | | Latency | Variable; grows with loss | Configurable, bounded | | Codecs | H.264 + AAC (Enhanced RTMP adds more, patchily) | Codec-agnostic — carries any MPEG-TS payload | | Typical use | Consumer encoders | Broadcast contribution |

The core trick: UDP means a dropped packet doesn't block the ones behind it. SRT layers its own ARQ (Automatic Repeat reQuest) on top — the receiver tells the sender which packets it missed, and the sender retransmits just those before the configured latency budget runs out. If retransmission doesn't fit, the packet is dropped and playback continues. TCP can't do this — it has to deliver every byte in order.

How a connection works

  1. Handshake — caller and listener exchange HSv5 packets, negotiate latency, encryption keys.
  2. AES key exchange — if the passphrase is set, a 128/256-bit session key is derived (the passphrase itself never goes on the wire).
  3. Data stream — MPEG-TS packets flow in a stream, each tagged with a sequence number.
  4. ACK/NAK loop — the receiver sends periodic ACKs; when a gap is detected, a NAK requests retransmission.
  5. Close — either side initiates a teardown.

An SRT URL:

srt://ingest.example.com:9000?streamid=hkr_abc123&passphrase=super_secret
  • streamid — identifier for the stream (Hakari uses your stream key here).
  • passphrase — pre-shared AES key material. Required if the server has encryption enabled.
  • Optional: latency=200 (ms), pbkeylen=16 (AES-128) or 32 (AES-256), mode=caller / listener.

When to use SRT

  • Field-to-studio contribution. Unreliable mobile / satellite uplinks.
  • Regulated content. You need encryption on the wire.
  • Multi-site production. You're sending contribution feeds across the internet, not LANs.
  • Codec flexibility. You want H.265, AV1, or HDR metadata in the stream.

For a local streamer on a reliable fiber connection, RTMP is fine. For a crew shooting on 5G at a beachfront with flaky coverage, SRT will look dramatically better.

SRT on Hakari

Every stream exposes both RTMP and SRT ingest URLs. Enable encryption on the stream and Hakari will provision a passphrase; include it in your SRT URL query string.

Example with FFmpeg:

ffmpeg -re -i source.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -c:a aac -b:a 128k \
  -f mpegts "srt://ingest-in-mum-1.hakari.cloud:9000?streamid=hkr_abc123&passphrase=${HAKARI_SRT_PASSPHRASE}"

The rest of the pipeline is identical to RTMP — same playback URLs, same recording, same DVR, same signed-playback rules. SRT just gets your bytes in more reliably when the network misbehaves.

  • RTMP — the ubiquitous alternative.
  • Streams — the full ingest + playback guide.
  • Signed playback — gate playback URLs regardless of ingest protocol.