Hakari

What is RTMP?

RTMP (Real-Time Messaging Protocol) is a TCP-based protocol for pushing live audio and video from an encoder (OBS, FFmpeg, a hardware encoder) to an ingest server. Originally Adobe's proprietary protocol for Flash, the spec was published in 2012 and RTMP became the de-facto standard for live contribution.

Flash is dead, but RTMP isn't — because every consumer streaming tool speaks it and no single replacement took over.

How it works

RTMP wraps a single TCP connection around a multiplexed message stream:

  1. Handshake — a 3-step C0/C1/S0/S1/S2/C2 exchange confirms both sides agree on the protocol.
  2. Connect — the client sends a connect command with the app name (app in most configs) and authentication if the server requires it.
  3. Create stream + publish — the client requests a stream id, then sends publish with the stream key identifying what to broadcast.
  4. Data stream — audio packets (AAC) and video packets (H.264, sometimes H.265) are interleaved as AMF-encoded messages over the TCP connection.

A push URL looks like:

rtmp://user:pass@ingest.example.com:1935/app/STREAM_KEY
  • user:pass@ — per-stream credentials checked by the server on publish.
  • /app/ — the application name the server is configured to accept.
  • /STREAM_KEY — unique identifier for this push.

Why RTMP is still everywhere

  • Tooling. OBS, Wirecast, vMix, FFmpeg, hardware encoders from Teradek/Magewell/Epiphan, mobile encoders, NDI bridges — they all speak RTMP out of the box.
  • Simple. One TCP connection, one process, easy to firewall (port 1935 is well-known).
  • "Good enough" for upload. Most broadcasters have enough uplink that TCP retransmits aren't a dealbreaker.

Where RTMP hurts

  • TCP head-of-line blocking. A single dropped packet stalls the whole stream until retransmission catches up. On long-haul links with loss, RTMP's latency balloons.
  • No native codec support for modern formats. H.265, AV1, Opus — either extended with non-standard mechanisms (Enhanced RTMP) or not at all.
  • Not a playback protocol. Modern clients consume HLS, LLHLS, DASH, or WebRTC. Nobody plays RTMP to browsers anymore.

For contribution over lossy networks, SRT is the modern answer.

RTMP on Hakari

Hakari accepts RTMP on every live stream. In the dashboard, the stream detail page shows:

  • Ingest server URL — rtmp://ingest-<region>.hakari.cloud:<port>/app
  • Stream key
  • Username + password — per-stream, rotate anytime

Paste the ingest URL into OBS → Settings → Stream → Server, the stream key into Stream Key, tick Use authentication, paste username + password. Hit Start Streaming — the stream status flips to live within a second.

With FFmpeg

ffmpeg -re -i source.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -c:a aac -b:a 128k \
  -f flv "rtmp://USER:PASS@ingest-in-mum-1.hakari.cloud:11935/app/hkr_abc123"

Security

  • Pushes are authenticated against per-stream credentials on every connect — not a global password.
  • The ingest port is also verified; mistyping and landing on another container's port is rejected, not silently accepted.
  • Credentials rotate from the dashboard; in-flight sessions keep going, new connects require the new creds.

See the Streams guide for the full push-auth + rotation story.

  • SRT — modern contribution protocol for lossy networks.
  • HLS / LLHLS — what viewers actually play.
  • Getting started — end-to-end: create a stream, push RTMP, play in the browser.