Wowza

What it means (definitions and thresholds)

Terminology matters when you engineer low-latency live streaming with Wowza and SRT. Below are operational definitions and conservative thresholds you can use to classify latency targets and make choices.

• Contribution transport (SRT): SRT is a packet-reliable UDP transport tuned for lossy WANs. For protocol basics see what is SRT and a practical comparison at SRT vs RTMP. In practice you tune a single latency parameter (milliseconds) that controls the jitter/retransmit window.
• Glass-to-glass latency: end-to-end latency from camera capture to decoded frame on the viewer. Use these ranges as decision thresholds:
  • Ultra low: < 500 ms — requires WebRTC or purpose-built point-to-point systems; hard to reach through standard CDNs.
  • Low: 500 ms to 2 s — achievable with SRT contribution, fast packagers (CMAF/LL-HLS) and tuned players.
  • Standard: 2 s to 10 s — typical segmented HLS/DASH workflows.
• GOP / Keyframe interval: keyframes govern segment boundaries. Practical targets: keyframe interval = 1–2 s (for 30 fps that is GOP = 30–60). If your keyframes are longer than segment duration the packager will wait for the next keyframe and add segmentization delay.
• Part size / segmentization (LL-HLS / CMAF): for low-latency HLS use parts (CMAF fragments) of 150–400 ms and segment targets of 2 s. Smaller parts reduce latency but increase I/O and CPU on packagers/players.
• Receiver buffer and SRT latency (ms): the SRT latency parameter controls the jitter buffer. Typical settings:
  • Local/stable networks: 200–600 ms
  • Cross-continental or lossy links: 800–2000 ms
• Bitrate sizing: choose bitrate for target resolution and encoder preset. Examples:
  • 720p30: 1.5–4 Mbps
  • 1080p30/60: 3–6 Mbps (up to 8 Mbps for high-motion)
  • 4K: 12–25 Mbps
• When to use Wowza: use Wowza when you need a field-proven media engine for ingest, live transcoding, and on-prem or cloud edge control — especially if you already have Wowza in your stack and want to keep contribution using SRT. For converting SRT to WebRTC or integrating into a SaaS orchestration layer, map flows to Callaba's Video API or Video Conferencing products depending on interactive needs.

Decision guide

Pick a path based on audience size, interactivity and operational control. Below are practical decision buckets and Callaba product mappings you can use to finalize architecture quickly.

• Small interactive audience (meetings, Q&A):
  • Goal: sub-second to 2 s. Prefer WebRTC for viewers. Convert SRT contribution at gateway into WebRTC. Recommended mapping: Video Conferencing or Video API with WebRTC egress.
• Large broadcast audience (thousands+):
  • Goal: 0.5–5 s. Use SRT for contribution and transcode+segment at the edge to LL-HLS/CMAF or HLS for CDN distribution. Recommended mapping: Continuous Streaming or Multi-Streaming for destinations.
• Monetized events:
  • Goal: integrate DRM, paywall, analytics. Keep SRT for reliable ingest, then package for VOD and PPV workflows. Mapping: Pay-per-view Streaming + Video on Demand.
• Existing Wowza operators:
  • Keep Wowza for ingest/transcoding when it lowers operational risk. Use Callaba for orchestration, multi-destination fanout, and packaging where you want SaaS-managed scaling: tie Wowza outputs into Video API endpoints or to Multi-Streaming for social restreams.

Latency budget / architecture budget

Break your glass-to-glass latency goal into measurable stages. Below are example budgets you can adapt to your constraints. All numbers are conservative starting points — measure and iterate.

• Capture + encode (camera & encoder): 50–300 ms
  • Camera buffer/capture: 10–50 ms
  • Encoder lookahead and GPU/CPU encoding: 40–250 ms depending on preset (ultrafast presets are lower latency; slower presets save bits but add 100–400 ms).
• SRT contribution transit (network RTT): 20–300+ ms
  • Same-region: 20–80 ms RTT; long-haul: 100–250 ms RTT. Retransmits increase effective delay according to the SRT latency setting.
• SRT jitter buffer (configurable): 200–1500 ms
  • If you set SRT latency to 600 ms then the retransmit window and jitter buffer target that time; larger values increase reliability at the cost of latency.
• Server processing (transcode / transmux): 30–300 ms
  • Transcoding is the most variable. Single-pass hardware accelerated transcodes can be 50–200 ms; software CPU transcodes are slower.
• Packager / CDN + player buffer:
  • LL-HLS/CMAF packager work: 100–500 ms depending on part sizes and I/O.
  • Player startup buffer: 200–2000 ms depending on target. For a 2 s latency goal, aim player buffer < 1 s (e.g., 3 parts of 250 ms each = 750 ms).
• Example total budgets:
  • Conservative low-latency target (approx): Capture 100 + SRT 200 + jitter 400 + transcode 100 + packager 500 + player 800 = ~2.1 s.
  • Aggressive low-latency target (if using WebRTC egress): Capture 80 + SRT 200 + jitter 300 + transcode 70 + conversion 150 + player 200 = ~1.0–1.2 s.

Use the numbers above to create a measurable SLA for each stage. If any stage exceeds its budget, raise the flag and reduce complexity (e.g., turn off transcode, shorten part size, or move packager closer to ingest).

Practical recipes

Recipe 1 — Reliable SRT contribution to LL-HLS (for broadcast audiences)

1. Encoder: set H.264, keyframe interval = 1 s (or 2 s max). Target bitrate for 1080p = 4–6 Mbps. Use a hardware encoder or x264 ultrafast preset to keep encode latency < 150 ms.
2. SRT: on encoder set latency=600 ms initially. Use AES encryption if required. Test packet loss and increase to 800–1200 ms only if retransmits are frequent.
3. Wowza: receive SRT, transmux to CMAF/LL-HLS with part size = 200–300 ms and segment target = 2 s. Ensure the packager writes parts as soon as keyframes arrive.
4. CDN/player: use players that support LL-HLS with part prefetch (player buffer = 3 parts or < 1 s). Validate end-to-end under load.
5. Callaba mapping: use Continuous Streaming to operate persistent channels and Multi-Streaming for social destinations; use adaptive player patterns on the viewer-side.

Recipe 2 — Regional SRT fanout via Wowza and Callaba edges

1. Central site receives high-quality SRT contribution from field (latency 800–1200 ms if long haul).
2. Central Wowza or a Callaba edge converts to SRT egress to regional edge servers (set SRT latency per region: 200–500 ms for same-region).
3. Regional edge performs light transcode or transmux and hands off to CDN or LL-HLS packager.
4. Callaba mapping: configure Multi-Streaming for replication and Callaba Engine to automate failover and metrics.

Recipe 3 — SRT contribution to WebRTC for interactive viewers

1. Capture and send SRT to your ingest point. Set SRT latency = 300–800 ms depending on network quality.
2. At the ingest gateway, convert SRT stream into a low-latency WebRTC track. See implementation patterns at Stream SRT as WebRTC.
3. Use Video Conferencing or Video API to manage RTP/WebRTC endpoints and to scale signaling and TURN/ICE.
   • Keep the transcoding path minimal: avoid full re-encode if the viewer can handle the source profile.

Practical configuration targets

The lists below are direct, tested starting points. Validate in lab before production and increase tolerances for the real network conditions you'll see in the field.

• Encoder (H.264) baseline:
  • Profile: High; Level: 4.1 (1080p) / 5.1 (4K)
  • Keyframe interval: 1–2 s (GOP = fps * 1..2)
  • B-frames: 0–1 (0 for the lowest latency)
  • Rate control: CBR for contribution; VBR is acceptable if buffer sizes are bounded
  • Buffer-size: 1.0–1.5 × bitrate (encoder VBV or buffer in ms if supported)
• SRT settings (encoder output):
  • latency: start 600 ms for mixed networks; 200–400 ms for LAN
  • Encryption: AES-128 or AES-256 if required (costs CPU during handshake/crypt)
  • Packet size: leave default (SRT handles fragmentation). If you control MTU, avoid fragmentation: use 1350–1400 bytes safe MTU.
• Packager / transcode:
  • LL-HLS/CMAF part size: 150–400 ms
  • Segment target: 2 s
  • ABR ladder: use 3–5 variants (e.g., 1080p/720p/540p/360p/240p) with headroom of 20–30% above typical bitrate
• Player:
  • Startup buffer: 2–4 parts for LL-HLS (e.g., 600–1200 ms total)
  • Rebuffer policy: aggressive rebuffer suppression — prefer short stalls to long stalls; most low-latency players will drop to a lower ABR rung instead of growing buffer.

Limitations and trade-offs

Low-latency introduces direct trade-offs. Call these out and make the operational trade-offs explicit before launch.

• SRT is point-to-point: it is excellent for contribution and edge-to-edge reliability, but not a viewer-facing CDN. You must transmux to HLS/LL-HLS, DASH or WebRTC for scale.
• Lower latency increases error sensitivity: smaller buffers mean retransmits or packet loss cause frame drops or stalls more frequently. Use higher bitrate margins and monitor packet loss closely.
• CPU & I/O: smaller part sizes and more frequent segments increase I/O and CPU on packagers and storage. Expect 2–4× increased IOPS for LL-HLS vs classic 6 s segments.
• Transcoding adds latency: each full transcode adds 50–300 ms; hardware acceleration reduces CPU but adds complexity and license costs.

Common mistakes and fixes

These are the issues we see repeatedly; each item has a quick fix you can validate in a staging run.

• Mismatch of keyframe and segment boundary: symptom: unexpectedly long segmentization delay. Fix: set encoder keyframe interval to equal or divide your segment duration (e.g., 1 s keyframes for 2 s segments).
• SRT latency too small for path loss: symptom: frequent retransmit-induced stalls. Fix: increase SRT latency by 200–400 ms and re-measure packet loss and RTT.
• Using SRT directly to viewers: symptom: low-latency achieved for a very small audience only. Fix: use SRT for contribution and convert to WebRTC/HLS at an edge for scale; map to Multi-Streaming or Video API.
• Ignoring player capabilities: symptom: server-side is low-latency but viewers see high startup times. Fix: ensure the player supports LL-HLS/CMAF or WebRTC and configure player buffer to target latency; review adaptive player settings.

Rollout checklist

Before you promote to production, run through this checklist and assign owners to each line item.

1. End-to-end lab test with representative RTTs and packet loss (simulate 1–3% loss and 80–200 ms jitter).
2. Encoder verification: keyframes at target interval, bitrate stability, CPU headroom < 70% under load.
3. SRT sanity: validate latency, encryption handshakes, and retransmit counts under transient loss.
4. Packager load test: ensure LL-HLS part handling at target QPS (measure CPU and I/O).
5. Player compatibility: verify LL-HLS or WebRTC behavior across browser and mobile variants.
6. Monitoring: instrument SRT stats, packet loss, retransmits, jitter (see SRT statistics) and application metrics in real-time dashboards.
7. Failover plan: have an alternate ingest and a cold spare packager; automations via Callaba Engine can perform scripted failovers.

Example architectures

Architecture A — Single-region low-latency broadcast

Camera -> Hardware encoder (SRT) -> Wowza ingest -> Transcode & LL-HLS packager -> CDN -> Viewer (LL-HLS player). Use Continuous Streaming to operate the channel persistently and Multi-Streaming if you need social destinations in parallel.

Architecture B — Global audience with regional edges

Camera -> Encoder (SRT) -> Central ingest -> Fan-out SRT to regional edges -> Regional packager -> Regional CDN POP -> Viewer. Use Multi-Streaming or Callaba edge automation (API) to orchestrate edge creation and health checks.

Architecture C — Interactive with many viewers

Camera -> Encoder (SRT) -> Gateway converts SRT to WebRTC -> Scaled WebRTC gateway (TURN + SFU) -> Viewers (WebRTC). Map state and signaling via Video Conferencing or Video API. See the conversion pattern at stream SRT as WebRTC.

Troubleshooting quick wins

If you are seeing higher-than-expected latency or poor quality, try these quick wins in order of speed-to-validate.

• Increase SRT latency in 200 ms steps until retransmits drop and playback stabilizes. Record retransmit counts and packet loss.
• Reduce encoder preset complexity (use ultrafast or hardware encode) to drop encode latency by 50–200 ms.
• Shorten LL-HLS part size only if your packager CPU can handle the extra I/O. Move from 400 ms to 200 ms parts and re-run load tests.
• Temporarily lower bitrate to rule out bandwidth congestion — drop 20–30% and see if stalls reduce.
• Check MTU and fragmentation — fragmented packets induce more retransmits on some networks; keep safe MTU around 1350–1400 bytes if you control the path.

Next step

If you have an existing Wowza deployment and want a migration or hybrid plan, map your uses to Callaba products and run a staged test:

• For API-driven packaging and edge orchestration, start with Video API and consult video API explained.
• For scale and multi-destination delivery, evaluate Multi-Streaming.
• For persistent, always-on channel operations, review Continuous Streaming and the Callaba Engine documentation for automation recipes.
• For VOD and monetization, map outputs to Video on Demand and Pay-per-view Streaming.

Want help building the exact Wowza + SRT architecture for your event or channel? Start a trial or request a technical onboarding via the product pages above; we can produce a runbook with parameterized values for your exact network RTTs, encoder fleet and expected viewer scale.