M3U8 in Live Streaming

Live Streaming Architecture

In live streaming scenarios, the M3U8/HLS workflow works as follows: the encoder encodes the real-time video stream and pushes it to a streaming server, which segments the stream into small TS fragments and generates a continuously updated M3U8 playlist. The player polls the M3U8 file to get the latest fragment addresses for playback.

A typical live streaming system includes the following components: capture devices (cameras, screen recording, etc.), encoders (hardware encoders or software like OBS), streaming servers (like Nginx-RTMP, SRS), CDN distribution networks, and players. Encoders typically use RTMP to push streams to servers, which then convert them to HLS format for player consumption.

Live Latency Analysis

HLS live streaming latency typically ranges from 10-30 seconds, determined by:

• Segment duration: TS segments are typically 2-10 seconds, longer segments mean higher latency but more stable playback.
• Player buffering: Players usually buffer 2-3 segments before starting playback.
• Polling interval: How frequently the player requests new segments affects latency.
• Encoding delay: Video encoding and packaging introduces additional delay.

Low-Latency HLS

Apple added Low-Latency HLS (LL-HLS) support, reducing latency to 2-5 seconds through:

• Partial Segments: Further dividing TS segments into smaller parts for earlier playback.
• Preload Hints: Server informs player of next segment URL for提前 requests.
• Blocking Playlist Reload: Server can block responses until new content is available.