Rtmp

What it means (definitions and thresholds)

Short definitions and latency thresholds you can apply immediately:

• RTMP (Real Time Messaging Protocol): legacy TCP-based ingest protocol used by OBS, hardware encoders, and many CDNs. RTMP itself has low protocol overhead, but TCP transport makes it sensitive to head-of-line blocking in lossy networks. RTMP is ideal for wide encoder compatibility and simple push workflows.
• SRT (Secure Reliable Transport): UDP-based backhaul with packet retransmission (ARQ), jitter buffer control, and tunable latency. SRT improves reliability over lossy networks and enables smaller jitter buffers than TCP in many cases.
• WebRTC: browser-native, sub-second interactive transport using RTP/SRTP and adaptive congestion control. Use for sub-500 ms two-way interactivity.
• Low-latency HLS / CMAF chunked (LL-HLS): HTTP-based delivery that can reach ~1–3 s player latency when parts are small (200–400 ms) and the chain is optimized.

Latency bands (apply these as guidelines):

• Ultra-low: <500 ms — interactive video calls, auctions. Usually WebRTC.
• Low: 500 ms–2 s — near real-time sports or live auctions (possible with optimized SRT+edge or LL-HLS).
• Near-real-time: 2–6 s — common target when using chunked CMAF or well-optimized RTMP→HLS pipelines.
• Standard live: 6–30 s — legacy HLS with 6 s segments or many transcoder/CDN queues.

Decision guide

Quick decision steps for choosing RTMP vs SRT vs WebRTC for ingest/backhaul:

1. Inventory encoders: If >95% of encoders only support RTMP and replacing them is expensive, keep RTMP ingest and optimize downstream packaging and CDN. Map to a Video API that supports RTMP ingest: https://callaba.io/products/video-api.
2. Network conditions: If encoders run across unreliable consumer networks (high jitter or packet loss >1%), prefer SRT backhaul. Convert RTMP->SRT at the edge or ask encoders to push SRT directly. See architecture notes below and docs: https://callaba.io/docs/rtmp-ingest.
3. Latency requirement: If you need <500 ms, use WebRTC for delivery. If you need 500 ms–3 s, aim for SRT backhaul + LL-HLS or WebRTC bridging at the origin.
4. Social re-streaming: If you must push to third-party platforms while maintaining a single ingest, keep RTMP for encoder compatibility and use a re-stream product to fan‑out outputs: https://callaba.io/products/re-stream-to-socials.
5. Global scale: If you need consistent distribution and regional peering, pair your ingest path with a worldwide CDN and multi-region ingest endpoints: https://callaba.io/products/worldwide-video-cdn.

Latency budget / architecture budget

A latency budget splits end-to-end latency into stages. Make targets explicit and measure.

• Capture & encoder: 50–400 ms
  • Camera capture + OS buffering: 20–100 ms
  • Encoder latency (x264/x265, hardware): 30–300 ms depending on preset and tune
• Network (encoder→ingest): 20–500 ms (local edge vs global)
• Ingest processing & queueing: 10–500 ms
• Transcoding / packaging: 100–1,500 ms (CPU vs GPU; single-pass vs multi-pass)
• Packaging into target protocol: 200–2,000 ms (e.g., LL-HLS part creation, CMAF chunking)
• CDN edge propagation: 50–500 ms depending on topology
• Player startup buffer: 200–1,500 ms (depends on parts used & player strategy)

Example budgets for two targets:

• Target: ~2 s end-to-end
  • Encoder: 200 ms
  • Network to edge: 200 ms
  • Transcode+packaging: 300 ms
  • CDN: 200 ms
  • Player buffer: 100–300 ms
  • Total: ~1.0–1.2 s baseline; allow operational headroom ≈ 2 s
• Target: <500 ms (interactive)
  • Use WebRTC — eliminate chunking/segmenting. Architect for <50–150 ms encoder+network, <150 ms server processing, <150 ms player jitter buffer.

Practical recipes

Three operational recipes you can test today. Replace endpoints with your own keys and hostnames. Each recipe includes measurable targets.

Recipe A — Legacy encoder (OBS) → RTMP ingest → chunked CMAF (LL-HLS) → CDN

Goal: support existing encoders while targeting 2–4 s viewer latency.

1. Encoder settings (OBS or hardware):
   • Codec: H.264 (libx264 or hardware)
   • Preset: veryfast or hardware equivalent
   • Tune: zerolatency
   • GOP / keyframe interval: 2 s → For 30 fps set -g 60 (keyint = fps * 2)
   • B-frames: disable (use 0) for lowest encoding latency
   • Audio: AAC, 48 kHz, 128 kbps
   • Bitrate targets: see configuration targets section below
2. Push RTMP from encoder to ingest endpoint. Example FFmpeg push (from a farm or relay):

   ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -tune zerolatency -g 60 -keyint_min 60 -b:v 4500k -maxrate 5000k -bufsize 9000k -c:a aac -b:a 128k -ar 48000 -f flv rtmp://ingest.callaba.io/live/STREAMKEY

3. At origin: transcode to CMAF chunked fMP4 with part size 200–400 ms and segment length 2 s, publish LL-HLS manifest to CDN. Aim for player buffer of 1–3 parts.
4. Verify: target end‑to‑end 2–4 s from camera to player on a clean connection. Docs: https://callaba.io/docs/rtmp-ingest and packaging guidance: https://callaba.io/docs/latency-budget.

Recipe B — RTMP edge relay → SRT backhaul → origin transcoder → multi-protocol outputs

Goal: retain RTMP at the site (e.g., legacy encoder) but get the benefits of SRT for backbone transport to the origin. Useful across mobile/poor links.

1. Run an edge relay (small VM or container) in the region close to the encoder. The relay accepts RTMP and outputs SRT to origin.
2. Edge relay example (FFmpeg):

   ffmpeg -i rtmp://localhost/live/STREAMKEY -c:v copy -c:a copy -f mpegts "srt://origin.callaba.io:8888?pkt_size=1316&latency=200"
   

   • pkt_size=1316 reduces system calls; latency=200 sets ~200 ms jitter buffer for retransmission.
3. Origin accepts SRT and performs transcode/packaging to targets (HLS, WebRTC, DASH). SRT reduces packet loss and allows you to keep encoder-side RTMP without sacrificing backbone reliability.
4. Measure: expect backbone jitter/tail latency <200–400 ms if ARQ is effective. See product-level integration: https://callaba.io/products/video-api and docs: https://callaba.io/docs/latency-budget.

Recipe C — RTMP ingest with re-stream to social platforms and fallback

Goal: single ingest from encoder with managed fan-out to YouTube, Facebook Live, Twitch, while maintaining your branded CDN output.

1. Push RTMP into your origin (Video API). At origin, create per-platform output profiles and maintain RTMP or RTMPS outbound streams to social endpoints to match each platform's bitrate rules.
2. Typical per-platform bitrate/keyframe targets:
   • Facebook Live 720p30: 2,500 kbps, keyframe interval 2 s
   • YouTube 1080p30: 4,500–6,000 kbps, keyframe interval 2 s
   • Twitch 720p60: 6,000 kbps (where allowed), keyframe interval 2 s
3. Use a re-stream engine that can programmatically rotate keys and handle platform rate limits: https://callaba.io/products/re-stream-to-socials. Ensure the same ingest is packaged to your CDN (https://callaba.io/products/worldwide-video-cdn).

Practical configuration targets

Concrete encoder and packaging numbers you can use as defaults. Adjust for content type and motion.

• Video codec: H.264 (baseline for maximum compatibility). For higher efficiency use H.265 where supported.
• Recommended keyframe / GOP:
• Keyframe interval: 2 s (keyint = FPS * 2). Example: 30 fps → -g 60.
• B-frames: 0 (set -bf 0) for lowest latency.
• Bitrate examples (target output bitrate):
  • 480p30: 800–1,500 kbps (use 1,200 kbps target)
  • 720p30: 1,500–3,000 kbps (use 2,500 kbps target)
  • 1080p30: 3,500–6,000 kbps (use 4,500 kbps target)
  • 4K30: 12,000–25,000 kbps (use 15,000–20,000 kbps depending on motion)
• Encoder rate-control and buffer:
  • For CBR-like behaviour: -b:v [target], -maxrate 1.05x target, -bufsize 1.5–3x maxrate. Example: -b:v 4500k -maxrate 5000k -bufsize 9000k.
• LL-HLS / CMAF packaging targets:
  • Part size: 200–400 ms
  • Segment length: 1.5–4 s (2 s common)
  • Player buffer: 1–3 parts + active part (target 600–1,200 ms for low-latency)
• SRT backhaul: latency parameter 100–400 ms depending on jitter; set pkt_size=1316 for MPEG-TS or 1316–8192 for TS/MP4 transports where supported. Keep retransmission latency budget within your end‑to‑end target.

Limitations and trade-offs

Be explicit about what you gain and what you lose when selecting RTMP vs SRT vs WebRTC:

• RTMP
  • Pros: universal support on legacy encoders and simple push workflows.
  • Cons: TCP head-of-line blocking, limited reliability optimizations, not ideal for public internet routes with packet loss.
• SRT
  • Pros: tuned for lossy networks, retransmission (ARQ), jitter buffers, lower effective end‑to‑end jitter.
  • Cons: requires encoder or relay support; slightly more complex to deploy; latency setting trades reliability for freshness.
• WebRTC
  • Pros: sub-second latency and built-in browser support for interactive use cases.
  • Cons: limited to endpoints that support WebRTC; server-side scaling and recording requires additional components.
• Packaging & CDN: Small LL-HLS parts increase manifest churn and push more requests to CDN edges; ensure your CDN and origin can handle higher manifest/part rates.
• Transcoding cost: lower latency often requires more CPU/GPU to avoid long GOPs, reduce VBV and use faster presets — factor cost vs latency in planning.

Common mistakes and fixes

1. Mistake: Keyframe interval does not match segment boundaries → players wait for next keyframe and latency spikes.
   • Fix: Set keyframe interval to 2 s and keep it stable (-g 60 for 30 fps). Ensure transcoders and packagers respect encoder keyframes.
2. Mistake: Using B-frames in low-latency chains.
   • Fix: Disable B-frames (-bf 0), or accept the extra decode latency introduced by B-frames.
3. Mistake: Insufficient uplink headroom at encoder.
   • Fix: Always provision 20–40% more than the target bitrate. For a 4.5 Mbps stream, require 6 Mbps uplink minimum.
4. Mistake: Using RTMP across a lossy mobile link without retransmission.
   • Fix: Add an RTMP→SRT edge relay, or move encoders to SRT-capable clients where possible.
5. Mistake: Packaging with part sizes that are too large for the latency target.
   • Fix: For <3 s targets, use part sizes of 200–400 ms and keep segment length ≤ 2 s where possible.

Rollout checklist

Use this checklist when deploying or migrating an RTMP-based workflow.

1. Inventory encoders and estimate replacement effort.
2. Choose ingest endpoints per-region and provision TLS/RTMPS if required.
3. Define latency SLA (e.g., 2 s median, P95 < 4 s).
4. Set encoder templates (keyframe=2 s, B-frames=0, bitrate targets, buffer sizes).
5. Deploy edge relays for RTMP→SRT conversion where network quality is poor.
6. Configure origin transcoders with GPU nodes for lower processing latency where needed.
7. Configure packaging for LL-HLS (part size 200–400 ms) or WebRTC bridge for interactive sessions.
8. Smoke tests: 10 concurrent viewers in the target regions; measure camera→player latency and packet loss.
9. Scale tests: load tests for manifest churn and part QPS at CDN edge.
10. Monitoring: ingest FPS, encoder CPU, origin transcode latency, CDN edge latency, player buffer levels. Document runbooks for alarm thresholds.
11. Failover: setup secondary ingest endpoints and ensure automatic failover of stream keys and DNS for endpoints.

Example architectures

Three example architectures with expected outcomes and product mapping.

Example 1 — Simple (compatibility-first)

Architecture: Encoder (OBS) → RTMP → Origin Transcoder → HLS → CDN → Player

Use when: you must keep legacy encoder compatibility and can accept 6–15 s latency. Map to: https://callaba.io/products/video-api + https://callaba.io/products/worldwide-video-cdn

Example 2 — Resilient low-latency

Architecture: Encoder (OBS or relay) → RTMP to Edge Relay → Edge converts to SRT → Origin SRT ingest → GPU transcode → CMAF chunked (parts 200–400 ms) + WebRTC bridge → Multi-CDN

Use when: you need 1–3 s viewer latency with better reliability across lossy links. Map to: https://callaba.io/products/video-api and low-latency docs: https://callaba.io/docs/latency-budget

Example 3 — Interactive & social fan-out

Architecture: Encoder → RTMP ingest → Origin pairs WebRTC for interactive rooms + LL-HLS for broadcast viewers → Simultaneous RTMP outputs to social platforms

Use when: you require interactivity for a subset of viewers and broad reach for passive viewers. Map to: https://callaba.io/products/video-api, https://callaba.io/products/re-stream-to-socials

Troubleshooting quick wins

Fast checks you can run right now to reduce latency or fix unstable streams.

1. Confirm keyframes: check encoder logs or ffprobe and validate regular keyframes every 2 s.
2. Disable B-frames: ensure -bf 0 or equivalent on hardware encoders.
3. Increase encoder uplink headroom: add 20–40% margin to target bitrate and test with iperf or upload speed tests.
4. Check RTMP path jitter: if packet loss >1% consider SRT backhaul or an edge relay.
5. Reduce encoder buffer: lower -bufsize to tighten VBV when upstream is stable; increase when upstream is bursty.
6. Review transcode queue depth: ensure origin has GPU/CPU headroom; drop extra outputs during peak if queueing delays rise >300 ms.
7. Verify CDN config: confirm short TTL on LL-HLS manifests and ensure edges support chunked media; use multi-region tests for P95.
8. On SRT links: tune latency to balance retransmissions vs freshness. Start with 200 ms and test packet loss conditions.
9. Inspect client buffer settings: reduce player initial buffer to match parts+segments; set reconnection logic to avoid long cold starts.
10. Collect metrics: ingest bitrate stability, frame drop rate, encoder CPU load, network RTT, and CDN edge hit ratios — iterate on the highest offenders.

Next step (product mapping and CTA)

If you need a concrete next step, pick one of the flows below and follow the linked docs to start a trial or integration:

• Compatibility-first, single ingest: use the Video API for RTMP ingest and packaging. Start here: https://callaba.io/products/video-api. Read the RTMP ingest guide: https://callaba.io/docs/rtmp-ingest.
• Reliability over lossy networks: deploy RTMP→SRT edge relays or push SRT directly into the Video API. See latency tuning: https://callaba.io/docs/latency-budget.
• Global distribution and social fan-out: combine Video API with the worldwide CDN and managed re-stream to social: https://callaba.io/products/worldwide-video-cdn and https://callaba.io/products/re-stream-to-socials. For operational troubleshooting see: https://callaba.io/docs/troubleshooting.

Ready to test? Provision a test ingest, push a 10-minute stream with the recommended encoder template above, and run the smoke test list in the rollout checklist. If you want help mapping your existing RTMP streams to SRT or WebRTC outputs, contact us through the product pages above and open a support ticket with your encoder logs and a short sample capture — we can turn that into a reproducible integration runbook.