The live video delay is affected by multiple factors. The following section describes the delay at the stream ingest end, CDN end, and streaming end.
Stream ingest client
The keyframe interval. It is usually set to 1s to reduce the delay.
The encoding cache is too large. Many third-party stream ingest software increases the encoding cache to solve the stuck problem caused by insufficient upstream bandwidth. We recommend you use Alibaba Cloud Stream ingest SDK to reduce this impact.
The codec setting for the bitrate and the encoding gear is too high. Due to hardware conditions, the encoding is delayed.
NoteNote: For the use of the push flow device, the push flow iOS is recommended that you use hard coding, because hard coding is not only efficient, but also power saving. On the other hand, for Android devices, hardware coding may cause compatibility problems due to the complex models and large number of CPU types. Therefore, we recommend that you use software coding in stream ingest.
CDN
RTMP and FLV
Pre-playback delay: to ensure one second of ATF and reduce stalling, the server caches data for 4s by default, which varies depending on the GOP size.
In-process playback delay: data cannot be sent to the client due to network jitter. In this case, the server caches the data and sends it to the client when the network connection is recovered.
HLS
Apple's HLS (. m3u8) is a streaming protocol based on TS segments of small files. Each segment is longer than 5 seconds (10s by default). The total latency is high because there are usually 3 to 4 segments.
Playback client
The broadcast supports the fast forward policy: a small amount of proprietary SDK will drop frames to fast forward the received data, ensuring low latency.
Playing does not support the fast-forward policy: Most players decode and display results only after the upload cache is filled up. The upload cache of these players also increases latency.