Stream App

What it means (definitions and thresholds)

When I say "stream app" in this guide I mean a software service that performs contribution ingest, real‑time/transcoding/packaging, distribution orchestration, and playback endpoints for live video. The guide centers on using SRT for contribution (ingest) because SRT gives reliable, encrypted, retransmission‑based transport across the public Internet while keeping control over latency. For an implementation variant, compare the approach in How To Download Jw Player Videos.

Key terms and practical thresholds: If you need a deeper operational checklist, use Church Online Platform.

• Glass‑to‑glass latency: end‑to‑end time from camera capture to visible frame on the viewer device. Thresholds:
  • <200 ms — ultra‑low, generally achievable only on LAN and Specialized WebRTC SFUs; useful for camera‑to‑camera and pro A/V monitoring.
  • 200–500 ms — interactive experience (two‑way talk, light interactivity) achievable with WebRTC; SRT can reach lower hundreds of milliseconds only on low‑RTT paths.
  • 500 ms–3 s — near‑real‑time. This is the practical low‑latency target for large audiences using chunked CMAF/LL‑HLS / LL‑DASH produced from SRT ingest.
  • >3 s — conventional low‑latency HLS/DASH; easier to scale but worse for interactivity.
• SRT (Secure Reliable Transport): UDP‑based transport with selective retransmission (ARQ), optional AES encryption and configurable latency buffer. Good for contribution because it tolerates packet loss without forcing FEC and can keep higher video quality than raw UDP/RTMP over lossy links.
• GOP / keyframe interval: number of frames between keyframes. For low latency, align keyframes with segment/part boundaries; typical practical GOP ranges are 0.5–2.0 seconds depending on CPU and latency targets.
• Part / chunk size (CMAF / LL‑HLS): sub‑segment duration used to achieve sub‑second playback. Practical part sizes are 120–500 ms. Smaller parts reduce client read latency but increase CPU/IO and HTTP request rate.
• Bitrate ladder: choose discrete bitrates per resolution; e.g. 1080p = 5–8 Mbps, 720p = 2.5–4 Mbps, 480p = 1–2 Mbps, 360p = 600–1000 kbps.
• Socket / OS buffers: make them big enough for bitrate × latency. For example: for 5 Mbps at 500 ms target, buffer >= (5,000,000 bps × 0.5 s) / 8 = 312,500 bytes; practical tuning uses 1–4 MB socket buffers for high bitrates and higher latencies.

Decision guide

Pick technology according to the use case and audience size. Use the following decision checklist when designing your stream app. A related implementation reference is Low Latency.

1. Is sub‑second interactivity required? If yes, prioritize WebRTC for the interactive paths (a small set of viewers or SFU architecture). Use SRT for high quality contribution from remote cameras or OB vans, then transcode to WebRTC where needed.
2. Do you need high bitrate, error‑resilient contribution from remote encoders over the Internet? Use SRT as primary ingest (caller/listener/rendezvous) with an appropriate latency buffer. SRT handles packet loss better than plain UDP and is simpler than custom FEC/bonding solutions.
3. Is the audience large (thousands to millions)? Use chunked CMAF / LL‑HLS / DASH for scalable delivery via CDN. Convert SRT input to CMAF segments (parts) and publish to origin. This combination gives near‑real‑time (500 ms–3 s) latencies at scale.
4. Do you need multi‑social outputs (YouTube, Facebook, Twitch)? Add a re‑stream/multi‑stream step and orchestrate per‑destination encodes. See /products/multi-streaming for native multi‑destination workflows and rate shaping.
5. Do you need to record event VOD automatically? Wire the same origin output to a recording pipeline and hand off to your VOD system. See /products/video-on-demand for post‑event packaging and VOD preparation.
6. Do you need programmatic control, analytics and per‑viewer features? Expose your ingestion and packaging via a control plane or a Video API. See /products/video-api for orchestration and session control features.

Latency budget / architecture budget

Every stream app must have a latency budget. Design by decomposition: assign a number to each component and test against it. Below are example allocations and a worked example. Pricing path: validate with bitrate calculator, self hosted streaming solution, and AWS Marketplace listing.

Typical component allocations for a production stream app targeting 2.5 s glass‑to‑glass:

• Capture + encoder input buffer: 100–300 ms
• SRT contribution transport (one‑way, includes ARQ latency): 200–800 ms (depends on RTT and configured SRT latency)
• Transcode / transmux / packager: 150–500 ms (depends on CPU and keyframe alignment)
• CDN + HTTP delivery: 300–1000 ms (caching, edge fetch, TCP/TLS setup amortized)
• Player buffer + decode: 150–400 ms

Worked example — target 2.5 s E2E:

1. Encoder buffer: 200 ms
2. SRT latency param: 500 ms (this ensures retransmissions across an RTT of ~100 ms are handled)
3. Packager (CMAF chunking, part size 250 ms, segment 1 s): 300 ms
4. CDN edge delivery: 900 ms
5. Player (part prefetch + decode): 300 ms
6. Total = 200 + 500 + 300 + 900 + 300 = 2,200 ms (2.2 s) — within 2.5 s budget, leaves margin for spikes.

Notes:

• SRT's configured latency must be >= expected RTT + processing jitter. If you set SRT latency too low, you will see frequent retransmissions and increased packet loss impact or even dropped frames/beats.
• CDN behaviour changes with part sizes and cache TTLs — use a CDN that supports HTTP/2 and chunked transfer for low requests overhead, and ensure edge TTLs are near‑zero for live content.

Practical recipes

Three production recipes you can implement quickly; each lists the components, concrete configuration values and verification checks.

Recipe A — Single camera remote contribution, near‑real‑time delivery (audience <100k)

1. Components:
   • Remote encoder (hardware or OBS) → SRT (caller) → central origin (listener)
   • Origin: SRT receiver → transmux to CMAF chunked segments (part size 250 ms) → origin storage + CDN
   • Player: LL‑HLS (chunked CMAF) playback on modern players
2. Encoder targets:
   • Resolution / bitrate: 1080p@25–8,000 kbps (VBR target), 720p@3,500 kbps if constrained
   • Codec: H.264 High profile (level 4.2) or H.265 where supported
   • GOP/keyframe interval: 1.0–2.0 s (align to parts: if part=250 ms, ensure keyframes fall on part boundaries every 1 s or 0.5 s)
   • Rate control: CBR or constrained VBR with max bitrate = target × 1.5
3. SRT config (encoder side):
   • mode=caller, target host: origin IP/port
   • latency=400–800 ms (start at 500 ms for public Internet with RTT ~100–200 ms)
   • mtu=1200–1350 bytes (avoid IP fragmentation across many networks)
   • passphrase: use AES passphrase; enable auth if available
4. Origin packager:
   • Part size: 250 ms
   • Parts per segment: 4 (segment target = 1 s)
   • Playlist target duration (EXT‑X‑TARGETDURATION): 1 s
   • Ensure keyframe alignment with segment boundaries
5. Verification checks:
   • End‑to‑end: capture timestamped test frame, measure glass‑to‑glass
   • SRT stats: packet loss & retransmissions should be <1% to keep steady quality
   • Player: confirm part download time < part length under normal conditions

Recipe B — Multi‑bitrate streaming and social rebroadcast

1. Components:
   • SRT contribution from remote encoders → central transcoder → multi‑quality outputs → CDN + social endpoints
2. Transcoder ladder (example):
   • 1080p30 @ 6,500–8,000 kbps, GOP 2 s
   • 720p30 @ 3,500 kbps, GOP 2 s
   • 480p30 @ 1,200–1,800 kbps
   • 360p30 @ 800–1,000 kbps
3. Packaging:
   • Chunked CMAF for primary CDN (part size 250–500 ms depending on CDN capability)
   • Simultaneously build RTMP/RTMPS streams for social endpoints if required, using destination rate shaping to match their max bitrate constraints
4. Orchestration:
   • Use programmatic APIs to start/stop rebroadcast jobs and map outputs. See /products/multi-streaming and /products/video-api for orchestration and destination management.
5. Verification checks:
   • Confirm per‑destination bitrate caps are respected
   • Run a 30‑minute throughput test per social endpoint to adjust rate smoothing

Recipe C — Interactive events: SRT for contribution, WebRTC for audience interaction

1. Components:
   • Remote high‑quality SRT contribution (camera/producer)
   • Origin: transcode to a low-latency WebRTC path (SFU) for audience interaction (chat, polls, guest stage) and to chunked CMAF for broadcast viewers
2. Latency targets and mapping:
   • Glass‑to‑glass for audience interaction: aim 300–700 ms via WebRTC SFU
   • Broadcast viewers (LL‑HLS): accept 500–1,500 ms as tradeoff for much larger scale
3. Verification checks:
   • Ensure audio round‑trip tests between contributor and audience < 700 ms
   • Confirm lip‑sync between WebRTC preview and CMAF broadcast (drift < 100 ms)

For implementation details and lower‑level API calls, consult /docs/low-latency and /docs/srt-guide.

Practical configuration targets

Concrete numbers to copy into your encoder, SRT and packager configuration. Treat these as starting points and test in your network.

Encoder

• Codec: H.264 High (AVC) or H.265/HEVC for bandwidth constrained links
• Profile/Level: High, level 4.2 for 1080p30; higher for 4K
• Bitrate (example ladder): 1080p = 6–8 Mbps, 720p = 3–4 Mbps, 480p = 1–2 Mbps
• GOP/keyframe interval: 1.0–2.0 s; for chunked parts of 250 ms aim to align keyframes every 1.0 s
• B‑frames: 0–2 for low latency (0 if you need consistent low latency and simpler decoder behavior)
• Rate control: CBR or constrained VBR; set maxrate = target × 1.5

SRT

• latency parameter: choose based on RTT
  • LAN: 20–80 ms
  • Well‑peered Internet: 100–300 ms
  • Long haul / variable routes: 400–1,000 ms
• mtu: 1200–1350 bytes
• socket buffers: set OS sndbuf/rcvbuf >= bitrate(bps) × latency(s) / 8; practical minimum 1 MB for high bitrates
• security: set passphrase / AES encryption and rotate per event if required

Packager / CMAF / LL‑HLS

• part/chunk size: 120–500 ms (250 ms is a common balance)
• parts per segment: 2–8 (e.g., 4 parts × 250 ms = 1 s segment)
• segment target duration: 1–2 s for LL; 4–6 s for conventional HLS
• ensure exact alignment of segment boundaries with encoder keyframes
• HTTP cache headers: short TTL (Cache‑Control: max‑age=0, s‑maxage=0) and appropriate CORS headers

Player

• Initial buffer: 0.5–1.0 s for LL players; increase to 2–4 s for stability in poor networks
• Adaptive algorithm: be aggressive on switch down to avoid stalls (switch to lower bitrate within 1–2 segment reads)

See deeper encoder and tuning guidance at /docs/encoding-best-practices.

Limitations and trade-offs

Choose consciously — every low‑latency design has trade‑offs that affect cost, scale and complexity.

• SRT is excellent for contribution but not a browser player protocol. You will need to transcode/transmux to CMAF/LL‑HLS or WebRTC for client playback. That adds server cost and processing latency.
• Lower part sizes reduce latency but increase CPU, disk IOPS and HTTP request rate at the origin and CDN. Expect ~3–6× more HTTP requests compared to conventional HLS.
• ARQ‑based retransmissions in SRT can mask loss but increase delivery latency whenever a retransmit is needed. On very lossy links, consider redundancy or bonding rather than only lowering retransmission latency.
• WebRTC gives the lowest latency for interactive scenarios but does not scale natively to millions without SFU infrastructure and additional cost/complexity.
• Keyframe frequency and small GOPs make bitrate control less efficient; object motion will increase bitrate spikes.

Common mistakes and fixes

Below are frequent operational errors and how to address them quickly.

• Misaligned keyframes → broken/latest GOPs in players
  • Fix: Configure encoder keyframe interval to be a multiple of part size. If part=250 ms and framerate=25, set keyframe every 25 frames (1s) so parts contain predictable I‑frames.
• SRT latency set too low for RTT → frequent retransmits and stalls
  • Fix: Measure RTT (ping/traceroute) and set SRT latency = RTT × 4 as a pragmatic start; adjust down while monitoring retransmissions.
• MTU fragmentation leading to losses on some mobile ISP paths
  • Fix: Force MTU to 1200–1350 bytes on SRT and network interfaces to avoid IP fragmentation.
• Insufficient socket buffers → stalls or dropped packets
  • Fix: Increase OS net.core.rmem_max and net.core.wmem_max and application sndbuf/rcvbuf to meet buffer formula: bitrate(bps) × latency(s)/8.
• CDN edge caches old playlist/parts → viewers see stale content or jumps
  • Fix: Use proper Cache‑Control headers for live content and configure origin to invalidate ephemeral parts aggressively. Test TTLs across edge POPs.

Rollout checklist

A checklist for staging → pre‑prod → production launch of a stream app with SRT contribution.

1. Network prep:
   • Measure RTT, jitter, and path MTU between contributor and origin
   • Ensure firewall rules permit the SRT UDP port ranges used
2. Encoder deployment:
   • Deploy and lock encoder profiles (bitrate ladder, keyframe settings)
   • Test SRT connection modes (caller/listener) and validate passphrase/auth
3. Origin and packager:
   • Enable chunked CMAF/LL‑HLS and confirm part size config
   • Set up failover routes to conventional HLS if LL pipeline is degraded
4. CDN and delivery:
   • Verify CDN supports low‑latency features and is configured for small TTLs
   • Warm edges with test traffic and confirm cache hit ratios
5. Monitoring and logging:
   • Instrument SRT stats (loss, rtt, retransmits), encoder CPU, packager latency
   • Set alert thresholds (e.g., retransmits > 2% or origin packager latency > 500 ms)
6. Operational runbooks:
   • Document immediate fallbacks (switch to conventional HLS, disable parts, increase player buffer)

Example architectures

Architectural blueprints you can adapt. Each is described as components in series and parallel — implement with containerized services, VMs or managed offerings.

Architecture 1 — Simple production: SRT ingest → origin → CDN → LL player

1. Camera → Encoder (SRT caller) → Origin (SRT listener) → Packager (CMAF parts, 250 ms) → CDN (edge caching low TTL) → Player (LL‑HLS)
2. Use cases: Single‑feed live events, corporate streams, remote lectures.

Architecture 2 — Production studio: redundant SRT, transcoder farm, multi‑output

1. Multiple remote SRT contributions → Ingest cluster (redundant listeners) → Mixer/transcoder → Multi‑quality outputs (CMAF + RTMP) → CDN + Social
2. Notes: Use rendezvous or dual SRT streams for redundancy; orchestrate with Video API to spin up per‑event resources. See /products/video-api.

Architecture 3 — Interactive web event

1. SRT from field → Origin ● Transcoder →
   • Path A: Transcode → WebRTC SFU → Audience interaction
   • Path B: Transcode → Chunked CMAF → CDN → Broadcast viewers
2. Use cases: Live shopping, town halls, Q&A where some participants need sub‑second interaction.

Troubleshooting quick wins

When latency or quality deviates, try these quick diagnostics and fixes in order.

1. Measure RTT and jitter (ping/traceroute). If RTT > expected, increase SRT latency and socket buffers.
2. Check SRT stats for retransmissions; if retransmits > 2%, consider increasing latency or enabling a redundant stream.
3. Confirm keyframe alignment: reconfigure encoder keyframe interval to match part/segment boundaries.
4. Reduce part count per segment (i.e., increase part size) temporarily to lower HTTP request rate and CPU if packager is overloaded.
5. If players stall, increase initial buffer to 1–2 s for stability while you address upstream issues.
6. For high CPU on transcoders, drop additional renditions or offload static VOD preparation to /products/video-on-demand after the event.

Next step

If you want a practical path from prototype to production:

• Prototype: implement Recipe A with a single SRT encoder and a lightweight packager. Follow /docs/srt-guide for ingest configuration.
• Scale: add multi‑bitrate transcoding and social outputs using /products/multi-streaming and orchestrate with /products/video-api.
• Archive & VOD: connect recordings into /products/video-on-demand for automated VOD packaging and delivery.
• Self‑hosted option and marketplace: if you prefer to run the stack in your environment, evaluate /self-hosted-streaming-solution or the AWS Marketplace offering: https://aws.amazon.com/marketplace/pp/prodview-npubds4oydmku

If you want hands‑on help mapping your specific use case (audience size, network constraints, device targets) into a production configuration, start a trial or contact our solutions engineers via the Video API product pages: /products/video-api — we can provide templates, monitoring dashboards and deployment scripts to shorten time to first successful low‑latency event.