Worked case: live event with chat and replay
Learn to: budget live latency across capture, packaging, delivery and playback.
Prerequisites: 09-hlsjs, 10-dashjs
Live latency budget
On a narrow screen, swipe the diagram horizontally to keep its labels readable.
Scenario and choices synthesis
Proposed design: a broadcast event has many viewers, chat and a replay. Ingest from an encoder into a managed live service or a verified packaging pipeline; distribute HLS/DASH through a CDN. Use hls.js/Mux Player for the matching HLS path, or dash.js for the matching DASH path. Chat travels over a separate WebSocket service.
[S28] [S39]Latency mechanism verified
Low-latency DASH uses promptly available CMAF chunks and playback/catchup controls. Live performance depends on packaging and delivery as well as player settings. A product latency target is a requirement to test, not a promise implied by a library name.
[S28]Decision and trade-off synthesis
For broadcast reach and replay, segmented HTTP delivery is a useful baseline. If the core interaction is a real-time conversation, evaluate WebRTC’s different media/session infrastructure. Separate chat timestamps from video time; viewers may be at different live offsets.
[S28] [S41]Failure → improvement synthesis
A player close to the live edge has less room for slow requests. Test network drops, encoder restarts, a paused viewer returning to live and DVR seeks. Add a clear Go Live control and record both live offset and stalls. Compare candidate latency settings on the same streams and devices.
[S28] [S39]Check yourself: Does faster chat delivery make the video lower latency?
No. The two channels have separate delivery paths. Fast chat can arrive before the scene a buffered viewer is seeing.