Hls

What it means (definitions and thresholds)

HLS (HTTP Live Streaming) is an HTTP‑based adaptive streaming protocol that delivers media via playlists (M3U8) and segmented media files. HLS has two operational modes relevant to production engineering:

• Classic HLS: whole segments (often 4–10 s). Typical end‑to‑end latency: 10–30 s (segment size × playlist length + player buffer).
• Low‑Latency HLS (LL‑HLS / CMAF partial segments): uses CMAF fragmented MP4 + partial segments ("parts") to deliver incremental frames inside a segment. Typical practical latency ranges:
  • < 3 s — "sub‑3s" LL objective (requires SRT contribution, short parts 200–400 ms, HTTP/2 or HTTP/3 or HTTP/1.1 chunked support at CDN).
  • 3–8 s — low‑latency compromise (short segments 1–2 s or parts, more tolerant settings).
  • 10–30 s — classic, broadly compatible HLS with 4–6 s segments and standard playlist behavior.

Key protocol pieces you will see in LL‑HLS: CMAF (fMP4 media segments), EXT‑X‑PART/EXT‑X‑SERVER‑CONTROL tags in playlists, and partial segments (parts) sized typically 100–600 ms. For contribution from field encoders to cloud encoders we recommend SRT for reliable, low‑latency transport with packet recovery (ARQ).

Decision guide

Start by answering three practical questions before you design: audience device capability, latency requirement, and network reliability.

1. If you need sub‑3s glass‑to‑glass for interactive experiences (sports, auctions, betting), choose LL‑HLS + SRT contribution. Use CMAF parts 200–400 ms, and ensure CDN support for blocking playlists or HTTP/2/3 chunked delivery. See our SRT ingest product for contribution: Callaba Ingest.
2. If you need multi‑region scale but can tolerate 3–8 s, prefer short segments (1–2 s) with part support or micro‑segmentation. Use SRT into regional ingress, transcode at edge, and let the CDN do the heavy lifting: Callaba Delivery.
3. If you prioritize maximum device compatibility and extremely large audience sizes over latency, use classic HLS with 4–6 s segments and a highly optimized CDN origin tier: Callaba Streaming.

Before implementation, consult the product documentation relevant to your chosen path: latency engineering notes (Latency docs), LL‑HLS packaging details (LL‑HLS docs), and SRT ingestion instructions (SRT docs).

Latency budget / architecture budget

Design latency as a budget across pipeline stages. Below are practical budgets (ms) you can test against. Treat them as targets; measure and iterate.

• Sub‑3s target (goal: median ≤ 3 s):
  • Capture + encoder pipeline (camera capture, encoder pipeline): 100–400 ms
  • SRT contribution (sender + network + receiver buffer): 200–500 ms (set SRT latency = 200–400 ms)
  • Transcoding / transmuxing / packaging (single pass, low buffering): 150–400 ms
  • Packager (CMAF parts creation + playlist update): 200–400 ms
  • CDN edge propagation and request overhead: 200–600 ms (depends on HTTP/2 vs HTTP/1.1 and CDN support)
  • Player buffer + decode + presentation: 300–800 ms

  Sum ≈ 1.15–3.0 s (real world 1.5–3.5 s depending on network).

• 3–8s target:
  • Encoder: 200–600 ms
  • Contribution (SRT or RTMP): 250–800 ms
  • Packager (2 s segments): 2–4 s total across playlist and buffer)
  • CDN: 200–1000 ms
  • Player buffer: 500–1500 ms
• Classic scale (10–30 s):
  • Segment length dominates (4–10 s). Typical pipeline adds small additional overhead.

How to measure: instrument timestamps at ingress (encoder), after packager (origin), and in player telemetry. Use 1‑way timestamps (NTP/PTS) or an event ID propagated through manifest or API for correlation.

Practical recipes

Below are three repeatable recipes. Each recipe is a minimal, actionable pipeline you can run in staging.

Recipe A — Sub‑3s LL‑HLS (recommended for interactive/live sports)

1. Contribution: send from hardware or software encoder to cloud using SRT. Recommended SRT parameters:
   • pkt_size=1316 (safe for MPEG‑TS), latency=250–300 ms, mtu=1200–1400 bytes
   • Example ffmpeg send (replace placeholders):

     ffmpeg -re -i /dev/video0 -c:v libx264 -preset veryfast -tune zerolatency -g 30 -keyint_min 30 -b:v 5000k -c:a aac -b:a 128k -f mpegts "srt://<INGEST_HOST>:<PORT>?pkt_size=1316&latency=250"

2. Transcode/packaging: ingest SRT at an origin or edge transformer, transmux to CMAF fragmented MP4 and produce partial segments (parts) set to 200–400 ms. Ensure keyframe alignment (IDR every 1 s) and disable B‑frames for the strictest latency.
   • Packaging targets: segment_duration=2 s, part_duration=250 ms (8 parts per segment).
3. Delivery: publish LL‑HLS playlists with EXT‑X‑PART and EXT‑X‑SERVER‑CONTROL. Set manifest headers: Cache‑Control: no‑cache, max‑age=0. Use a CDN that supports HTTP/2 or HTTP/3 and LL features or use edge software that supports blocking playlist reloads.
4. Player: configure LL‑HLS capable player (native Safari on iOS 14+, or an LL‑HLS aware hls.js version). Startup buffer = 2 parts, max buffer = 3 s. Track and report latency in telemetry.

Callaba mapping: use Callaba Ingest for SRT endpoints, Callaba Streaming for transcoding/packaging and Callaba Delivery for global LL‑HLS distribution. See implementation notes in our docs: LL‑HLS docs and SRT docs.

Recipe B — 3–8 s low‑latency HLS (broad compatibility)

1. SRT contribution with latency=300–500 ms (more tolerant networks).
2. Encode with keyframes every 1 s, segment_duration=2 s (no parts required but allowed), playlist target=3 segments. Expected median latency ≈ 4–7 s.
3. Use CDN with short TTLs on playlists. If CDN lacks LL features, rely on short segments and short playlist TTL.

Recipe C — Classic HLS for very large audiences and maximum compatibility

1. SRT for contribution or RTMP if legacy encoders are required.
2. Segment_duration=4–6 s, playlist length 3–5 segments → expected 12–30 s latency.
3. Optimize CDN caching and enable wide geographic edge distribution. Use origin scaling and failover.

Practical configuration targets

Below are concrete values you should set and tune. Use these as experimental defaults and adjust to your network and device population.

• Encoder
  • Codec: H.264 (baseline/main/high) for compatibility. Consider H.265 only where supported.
  • Keyframe interval (GOP): 1 s (use -g 30 for 30 fps, -g 60 for 60 fps). Exact rule: set GOP <= segment length and align IDR frames with segment start.
  • B‑frames: 0 for strict low‑latency; 1 allowed for 1–3s targets but adds a reorder delay.
  • x264 settings (ffmpeg): preset veryfast/fast, tune zerolatency, use constrained bitrate controls (CBR or constrained VBR).
    • Example: -preset veryfast -tune zerolatency -g 30 -keyint_min 30 -sc_threshold 0
  • Bitrate targets (example ladder):
    • 1080p30: 5,000–8,000 kbps
    • 720p30: 2,500–4,000 kbps
    • 480p30: 1,200–2,000 kbps
    • 360p: 600–900 kbps
    • Audio: stereo AAC 96–192 kbps (128 kbps typical)
• SRT contribution
  • latency parameter: 200–500 ms (250 ms is a good default on stable networks; increase to 800–2000 ms for high jitter).
  • pkt_size: 1316 bytes for TS transport; or tune around 1200–1400 to avoid fragmentation on the path.
  • MTU: prefer 1200–1400 for Internet delivery to avoid IP fragmentation and VPN encapsulation issues.
  • Buffer sizes (if configurable): set sndbuf/rcvbuf to 512 KB–2 MB depending on stream bitrates; higher for high bitrate 1080p/4K streams.
• Packager / segmenter (CMAF / LL‑HLS)
  • segment_duration: 2 s (LL), 4–6 s (classic)
  • part_duration: 200–400 ms (recommended 250 ms for balance)
  • parts_per_segment = segment_duration / part_duration (e.g., 2 s / 0.25 s = 8 parts)
  • EXT‑X‑SERVER‑CONTROL and PART‑HOLD‑BACK settings: ensure server supports blocking reloads. If not, increase parts/segment or player holdback.
• CDN / origin
  • Playlists: Cache‑Control: no‑cache, max‑age=0
  • Media parts/segments: allow short caching at edge if CDN supports low‑latency semantics; otherwise set very short TTLs (1–3 s) for parts.
  • Prefer CDNs with HTTP/2 or HTTP/3 support for LL‑HLS. If using HTTP/1.1, ensure chunked transfer and ability to serve partial segments.
• Player
  • Startup buffer: 1–3 parts (e.g., 250–750 ms) for LL‑HLS; 2–3 s for moderate targets.
  • Maximum buffer cap: 3–5 s for LL; 10–30 s for classic HLS.
  • Detect LL support at player startup and choose correct manifest (LL vs fallback classic) from master playlist.

Limitations and trade-offs

• CPU and cost: shorter parts and more frequent keyframes increase encoder/transcoder CPU. Expect encoding cost to rise 10–50% for sub‑3s targets compared to classic encoding.
• CDN compatibility: not all CDNs support LL‑HLS; some require vendor features (blocking playlist support, HTTP/2/3). Test your CDN early.
• Cacheability: low latency reduces cache efficiency (short TTLs); design origin scaling accordingly.
• Player switching / ABR: ABR decisions are harder with very short segments/parts — ensure aligned keyframes and consistent codec settings across renditions.
• Network jitter: LL targets are sensitive. Use SRT for contribution and a higher latency buffer for unstable last‑mile networks.

Common mistakes and fixes

• Misaligned keyframes and segments
  • Symptom: stalls or poor rendition switching.
  • Fix: force keyframe every 1 s and set -sc_threshold 0 (no scene change keyframes breaking alignment).
• SRT latency set too low
  • Symptom: packet loss, stalls, repeated rebuffering.
  • Fix: increase SRT latency to 250–500 ms or higher in unreliable networks. Monitor retransmit rate and adjust.
• CDN caching of manifests
  • Symptom: stale playlists and increased latency.
  • Fix: set Cache‑Control: no‑cache on playlists and use surrogate keys/purge APIs during rollout.
• Incorrect pkt_size / MTU
  • Symptom: UDP fragmentation, packet loss, poor SRT performance.
  • Fix: set pkt_size 1200–1316 and reduce MTU to 1200 when traversing VPNs or mobile networks.

Rollout checklist

1. Unit tests: local loopback ingest → packaging → player. Verify manifest contains EXT‑X‑PART for LL attempts.
2. Lab tests: closed network, measure each stage timestamped. Validate codec alignment and GOP settings.
3. Staging with real SRT: choose single region, use real internet paths, measure median and 95th percentile latency, stall rate, retransmit rate.
4. Small public beta: < 5% of traffic. Monitor telemetry: latency, rebuffer ratio, bitrate switch events, CPU/memory on transcoders.
5. Scale ramp: region by region, test CDN edge warmups, origin autoscaling triggers, and failover scenarios.
6. Fallback: ensure a classic HLS variant is available for non‑LL capable clients and for CDN edges without LL support.

See our production checklist and monitoring guide: Latency docs and the packaging guide: LL‑HLS docs.

Example architectures

Below are simple textual diagrams (components in order of flow) with notes on where to place instrumentation.

Architecture 1 — Single region low‑latency (sub‑3s)

Encoder (camera) → SRT → Ingest cluster (edge) → Transcoder/Packager (CMAF parts) → Origin HTTP server (LL‑HLS playlists) → CDN edge (HTTP/2/3, blocking) → Player

• Instrument timestamps at: encoder, post‑ingest, post‑packager, CDN edge, and player. Use these to verify the budget.
• Map to Callaba: Ingest → Streaming (packager) → Delivery.

Architecture 2 — Global scale with regional aggregation

Multiple encoders → SRT to regional ingress points → regional transcoders for local ABR → origin aggregator + origin packager → multi‑CDN push / pull → player

• Regional transcoders reduce round‑trip and let you keep a lower SRT latency per region; aggregator handles origin consolidation and fallback to classic HLS variants for other CDNs.

Architecture 3 — Hybrid LL + classic fallback

Transcoder outputs both LL‑HLS and classic HLS playlists. Master playlist advertises both; players choose based on capability. This provides graceful fallback for older devices or CDNs without LL support.

Troubleshooting quick wins

• Check keyframe alignment: run ffprobe on ingest and verify IDR spacing. If not aligned, set -g and -keyint_min as above.
• If players stall immediately after startup: increase player startup buffer by 1 part or increase SRT latency slightly.
• If manifest updates are delayed: curl the playlist, verify Cache‑Control headers and CDN behavior; bypass CDN to test origin timing.
• If you see frequent retransmits on SRT: raise latency parameter and check packet size / MTU. Monitor srt statistics (rtt, retransmit count).
• If ABR switches are poor: ensure consistent codecs across renditions, aligned keyframes, and similar segment/part boundaries.

Next step

Pick a recipe above and run a short lab test:

• If you want a turnkey ingest endpoint and SRT onboarding, see Callaba Ingest and the SRT quickstart: SRT docs.
• For packaging and LL‑HLS release, review the packager configuration in LL‑HLS docs and connect it to our transcoding service at Callaba Streaming.
• To serve to a global audience, validate CDN behavior with Callaba Delivery and consult our CDN tuning page in docs: Latency docs.

Want hands‑on help? Start a proof of concept or request a workshop via pricing & trial or create an account. If you prefer a technical walkthrough, contact support from your dashboard or open a ticket referencing this guide and your target latency (e.g., "sub‑3s LL‑HLS with SRT ingress").