Alternatives To Zoom

What it means (definitions and thresholds)

When we say "low latency" in a production streaming context we mean predictable, measurable latency from capture to render with operational SLAs. Define targets first — the architecture follows. Use these thresholds as engineering shorthand: For an implementation variant, compare the approach in Zoom Alternatives.

• Sub-second (≤500 ms): true interactive feel for remote control, musical collaboration, auctions, gaming. Typically achieved with WebRTC or optimized UDP-based transport inside a single region.
• Near-real-time (500 ms–2 s): low-latency webinars, chat-driven events where sub-second isn't required but interactivity matters. Achievable with SRT (contribution) + edge processing or LL-HLS/CMAF with 200–500 ms parts.
• Broadcast/Live (2–10 s): large-audience streaming where scalability and CDN caching are important. LL-HLS or DASH with CMAF parts tuned to 1–3 s, or classic HLS with 6–30 s segment durations for max compatibility.
• High-latency (10+ s): DVR-style VOD or highly distributed multi-CDN caching where latency is not a priority.

Also define these internal latency contributors (the "latency budget" items we tune later): capture, encode, packaging/segmenting, transport, CDN/edge buffering, and decode/render. If you need a deeper operational checklist, use What Is Tcp And Udp.

Decision guide

Choose technology by use case and scale. Below are practical mappings and why they matter. A related implementation reference is Low Latency.

• 1:1 or small group interactive calls (sub-second)
  • Primary tech: WebRTC (SFU) — sub-500 ms end-to-end in good networks.
  • When to pick: real-time collaboration, remote PTZ camera control, instrument jamming, low-latency Q&A.
  • Trade-offs: CPU on SFU for multiple high-resolution streams; TURN may be necessary for restrictive NATs.
  • Callaba product fit: use /products/video-api to build hosted or embedded WebRTC sessions.
• Remote studio contribution (reliable, moderate-latency)
  • Primary tech: SRT — robust over lossy links, configurable latency buffer (ms).
  • When to pick: studio-to-cloud, OB vans, remote presenters where packet recovery and stable bitrate matter.
  • Trade-offs: SRT is contribution-focused; requires server ingest and transcode for massive scale.
  • Callaba product fit: ingest with SRT into a cloud transcode and distribution chain — pair with /products/multi-streaming for restreaming to multiple destinations.
• Large-audience webinars and broadcasts
  • Primary tech: SRT for contribution + cloud transcode → LL-HLS/CMAF for CDN distribution; fallback to standard HLS for broad compatibility.
  • When to pick: 1k–1M viewers where CDN cost and scalability matter.
  • Trade-offs: Slightly higher latency than WebRTC but massively more scalable and cacheable.
  • Callaba product fit: produce recordings and VOD with /products/video-on-demand, and distribute via multi-CDN workflows.
• Hybrid (presenters interactive, audience large)
  • Primary tech: WebRTC for presenters, SRT for studios, a live transcode to LL-HLS for global viewers.
  • Use when: you need low-latency onstage interactivity and huge passive audiences off-stage.

Latency budget / architecture budget

Pick a target latency and allocate it across components. Here are sample budgets for three common targets; treat numbers as engineering starting points and measure end-to-end.

Target: Sub-second (≤500 ms)

• Capture: 20–50 ms (camera capture + exposure)
• Encode: 50–150 ms (use low-latency presets like x264 "ultrafast/veryfast" + tune zerolatency)
• Packetization / framing: 10–40 ms
• Transport (network RTT + jitter buffer): 100–200 ms (requires peer-region or high-quality backbone)
• Decode & render: 50–60 ms
• Reserve buffer: 20–50 ms

Total practical: 350–550 ms. To hit ≤500 ms you must optimize encode and network aggressively and prefer WebRTC.

Target: Near-real-time (500 ms–2 s)

• Capture: 30–80 ms
• Encode: 100–300 ms
• Transport (SRT or optimized UDP): 200–800 ms (tune SRT 'latency' parameter)
• Edge packaging / CDN edge: 100–400 ms
• Decode & render: 50–100 ms

Total practical: 700 ms–2 s. This range allows SRT contribution with ARQ and retransmit to stabilize lossy networks.

Target: Broadcast (2–10 s)

• Segmenter / packaging: 1–3 s (LL-HLS part sizes 200–600 ms with target segment 1–3 s)
• CDN propagation & buffer: 1–5 s

Total practical: 2–10 s. Best for scale and caching but not for interactive use.

Practical recipes

Three production-ready recipes you can implement with existing open-source tools and callaba products.

Recipe A — Sub-second interactive roundtable (8 participants)

Goal: < 500 ms E2E for live conversation and screen-share among 8 participants.

1. Transport: WebRTC SFU (select SFU that supports simulcast and bandwidth management).
2. Encoder settings (publishers):
   • Codec: H.264 or VP8 (H.264 for hardware accel and compatibility)
   • Resolution/bitrate per participant: 720p@30fps => 1.5–3 Mbps; 480p => 600–1200 kbps
   • Keyframe (GOP): 1 s (set keyint = fps * 1), to reduce delay when switching or recovering
   • Preset/tuning: x264 preset 'veryfast' or equivalent; 'tune=zerolatency'
   • Audio: Opus, 24–64 kbps, 48 kHz
3. Network: Ensure STUN + TURN are available with TURN servers colocated in the same region as the SFU; use UDP first to avoid head-of-line blocking.
4. Scaling: SFU handles forwarding; for >100 concurrent rooms use multi-region SFU clusters and traffic steering.
5. Callaba mapping: build client sessions with /products/video-api and use the SFU integration guide at /docs/webrtc-architecture.

Recipe B — Remote studio to cloud to global viewers (SRT contribution + LL-HLS)

Goal: Reliable studio-quality feed from remote contributor, global distribution at 1–3 s latency.

1. Contribution:
   • Transport: SRT (caller mode from encoder to cloud ingest).
   • SRT parameters: latency=600 ms for stable 4G/5G; increase to 1200–2000 ms on unreliable links; pkt_size default 1316 works for most encoders.
   • Encoder: x264 with 'tune=film' or 'tune=zerolatency' depending on desired delay; GOP = 1–2 s for better compressibility with moderate latency.
2. Cloud ingest & transcode:
   • Accept SRT, transcode to multiple ABR renditions, and pack into CMAF fragments (LL-HLS) with part durations 200–400 ms and target segment 1–2 s.
   • Enable server-side FEC/ARQ as needed for contribution reliability.
3. Distribution:
   • Publish to CDN via LL-HLS endpoints; provide standard HLS fallback with 6 s segments for legacy viewers.
   • Use push-to-social or multi-destination streaming with /products/multi-streaming if you need simultaneous outputs.
4. Recording and VOD: rip the live master into VOD assets and manage them with /products/video-on-demand.

Recipe C — Large webinar with interactive presenters (hybrid)

Goal: Presenters interact < 1 s; audience of 10k+ sees a stable 2–4 s stream.

1. Presenters connect via WebRTC to keep interactivity sub-second within the presenter group.
2. Mix or transcode presenter feeds into a single program feed in the cloud (server-side mixer or compositor), then re-ingest that feed into a SRT or internal transport for transcode to LL-HLS for CDN.
3. Audience receives the LL-HLS + HLS fallback; Q&A handled through a low-latency WebRTC return channel for selected participants only.

Practical configuration targets

Exact, testable encoder/packager/transport targets you can paste into your staging configs. Values are conservative engineering recommendations.

Encoder profiles (H.264)

• 720p30
  • Target bitrate: 1.5–3 Mbps
  • Max bitrate: 3.5 Mbps
  • Buffer size: 2 × max bitrate (e.g., 7 Mb)
  • GOP/keyframe interval: 30 fps → keyframe every 30 frames (1 s)
  • Preset: veryfast; tune: zerolatency
  • Profile: Main or High depending on decoder compatibility
• 1080p30
  • Target bitrate: 3.5–6 Mbps
  • Max bitrate: 7–9 Mbps
  • Buffer size: 2 × max bitrate
  • GOP: 1 s recommended
• Audio
  • WebRTC: Opus, 48 kHz, 24–64 kbps for speech; 64–128 kbps for music
  • SRT/Contribution: AAC-LC, 48 kHz, 64–128 kbps for stereo if needed

Transport and packaging

• SRT: set 'latency' to the target buffer in ms (200–800 ms for low-latency links, 800–2000 ms for lossy links); pkt_size 1316 is common.
• LL-HLS/CMAF:
  • Part duration: 200–400 ms
  • Target segment duration: 1–2 s
  • Playlist holdback: 2–4 s
• RTMP: avoid for low-latency use cases — it's fine as an encoder fallback to an ingest that re-encapsulates, but RTMP's TCP-based path increases latency unpredictably.

Limitations and trade-offs

Every low-latency choice imposes trade-offs. Be explicit about them with stakeholders.

• WebRTC
  • Pros: sub-second latency, peer-to-peer or SFU-based scaling for moderate audiences.
  • Cons: scaling above a few thousand viewers forces hybrid architectures; TURN required for restrictive NATs (cost and complexity).
• SRT
  • Pros: resilient over public internet with ARQ and packet recovery; simple to ingest studio feeds.
  • Cons: not a distribution format; needs transcode and packaging for large audiences. Slightly higher initial latency compared to WebRTC because of receiver buffer.
• LL-HLS/CMAF
  • Pros: CDN-friendly, scales easily; parts enable 1–3 s latency.
  • Cons: more complex packager and CDN support required; small parts increase overhead on origin and CDN if not tuned.
• CPU and cost
  • Lower latency often increases CPU (more frequent keyframes, smaller GOPs, more transmuxing). Measure cost impact of additional transcode instances.

Common mistakes and fixes

Hard-earned operational fixes for issues you will encounter during rollout.

• Too large GOP / long keyframe intervals
  • Symptom: slow recovery after packet loss / bad seeking behavior.
  • Fix: set GOP = fps × 1 (1 s) for low-latency; never exceed 2 s for interactive / low-latency streams.
• Encoder buffers mis-sized
  • Symptom: bitrate spikes, bufferbloat, increased latency under load.
  • Fix: set maxrate and bufsize consistently (bufsize ≈ 2 × maxrate) and use CBR or constrained VBR for predictability.
• Using TCP-only transports
  • Symptom: head-of-line blocking, jitter spikes.
  • Fix: prefer UDP-based transports (WebRTC/SRTP, SRT) for low-latency. Use TCP fallback only when necessary.
• Neglecting TURN and NAT testing
  • Symptom: users behind corporate firewalls cannot connect reliably.
  • Fix: deploy TURN servers in each region; run connectivity tests during onboarding. See /docs/srt-setup and /docs/latency for server placement guidance.
• Ignoring packet loss and jitter
  • Symptom: audio dropouts or frozen video.
  • Fix: increase SRT latency parameter or enable FEC/ARQ; for WebRTC increase jitter buffer carefully and consider congestion control tuning.

Rollout checklist

Minimal practical checklist to move from PoC to production.

1. Define latency target and acceptance tests (e.g., 95th percentile ≤ X ms).
2. Choose transport(s): WebRTC for interactive; SRT for contribution; LL-HLS for distribution.
3. Set encoder presets and test at the selected bitrates using 3 network profiles (good Wi‑Fi, 4G, congested Wi‑Fi).
4. Deploy TURN / SRT ingests in each target region. See /docs/srt-setup for parameter examples.
5. Implement server-side monitoring and synthetic monitoring to measure end-to-end latency and packet loss; log metrics at each hop.
6. Run load tests for audience scale; test CDN edge propagation for LL-HLS parts at target part sizes.
7. Enable fallbacks (HLS, lower bitrate) and verify quality switching and sync across clients.
8. Document runbooks for common incidents (packet loss spike, encoder crash, CDN outage).

Example architectures

Three concise architectures with expected benefits and latency characteristics.

Small (teams, classrooms) — WebRTC SFU

Client (browser) --(WebRTC)--> SFU cluster (region) --(WebRTC)--> Clients

• Expected latency: 150–500 ms (region dependent)
• Components: STUN/TURN, SFU, monitoring, optional recording service
• Product mapping: /products/video-api for building embedded rooms; see /docs/webrtc-architecture for SFU sizing.

Medium (remote production) — SRT contribution + cloud transcode

Remote Encoder --(SRT)--> Cloud Ingest/Transcoder --(LL-HLS)--> CDN --> Viewers

• Expected latency: 0.7–3 s (depends on SRT lat and part sizes)
• Components: SRT ingest, transcodes for ABR, CMAF packager, CDN
• Product mapping: ingest via SRT, transcode and multi-destination output with /products/multi-streaming.

Large (global live events) — Hybrid presenters + CDN

Presenters (WebRTC) --> Mixer (Cloud) --> SRT/Transcode --> LL-HLS --> Multi-CDN --> Global viewers

• Expected latency: presenters sub-second internally; global audience 1.5–5 s
• Components: WebRTC cluster for presenter interaction, server-side mixer, SRT contribution to origin, CMAF packager, multi-CDN
• Callaba mapping: orchestrate with /products/video-api, record with /products/video-on-demand, and push to social or partners with /products/multi-streaming.

Troubleshooting quick wins

Fast tests and fixes you can run in order when issues appear.

1. Measure one-way latency with a timestamp overlay to isolate capture vs network vs decode delays.
2. If packet loss >1%:
   • Increase SRT latency to 800–1200 ms, or enable FEC/ARQ.
   • For WebRTC, test at lower bitrates and enable range-based congestion control.
3. If startup is slow for viewers:
   • Reduce initial buffer at client, ensure first CMAF part is present in the playlist immediately.
   • Check CDN TTL and edge fill behavior; adjust prefetch or origin keepalive.
4. If CPU is saturated on transcoders:
   • Lower preset quality or add more instances; consider hardware H.264/H.265 encoders where available.
5. Use iperf and packet captures to identify path bottlenecks (RTT, jitter, MTU issues).

Next step

If your requirement is interactive calls embedded into an app, start a Proof of Concept with /products/video-api. If you need studio-grade contribution and restreaming to social platforms, evaluate /products/multi-streaming as the distribution layer and pair it with ingestion via SRT (see /docs/srt-setup). For recorded assets and VOD management, use /products/video-on-demand.

If you prefer to self-host or want a hybrid deployment, review our self-hosting guide at /self-hosted-streaming-solution or deploy validated marketplace images via AWS: AWS Marketplace listing.

Finally, run these two immediate tests in your environment right now:

1. WebRTC ping test: open two clients in different networks and measure 95th percentile one-way latency.
2. SRT contribution test: stream a 1080p30 feed with latency=600 ms to your cloud ingest and measure end-to-end time to an LL-HLS viewer with 200 ms parts.

Need help mapping an architecture to your audience size and latency SLA? Contact the engineering team to schedule a hands-on architecture review and get a PoC blueprint based on your network profiles and user geography.