HLS, short for HTTP Live Streaming, is a streaming protocol developed by Apple to deliver video streams over HTTP. It works by splitting the video stream into small chunks that the player can fetch one by one.
HLS is the dominant streaming protocol, replacing RTMP that was used by Flash players. It is the world standard streaming protocal with wider support from more players than any other option.
Test our HLS streaming system free here.
The full RFC 8216 HLS specification is found here.
HLS splits a continuous live stream, and breaks it by keyframe interval, into a numbered series of video transport files or "chunks", that are downloaded sequentially.
There are 3 steps in the playback process. First, the player fetches the stream URL, which returns the playlist (playlist.m3u8). The playlist has entries for each available bitrate (chunklists), and a link to the chunklist for that bitrate. The player selects a bitrate, and downloads its chunklist.
The chunklist is also an m3u8 file, but it changes regularly. The playlist file is normally only downloaded once, but the chunklist file updates every time there is a new video chunk available, guiding the player to keep pulling the stream.
The player downloads each available video chunk as soon as it is offered in the updated chunklist, which is constantly checked for updates after each ts file is downloaded.
The chunk size and number of chunks in the buffer have an impact on the stream performance. There is no universally best setting, since everyone's use case is different.
The chunk size affects the amount of video in each chunk. Larger chunks are more efficient on bandwidth, since the amount of overhead per second of video is less. Shorter chunks are quicker to download, meaning the player can start showing video sooner.
The chunk size may only be a multiple of the keyframe rate (number of seconds between keyframes), so shorter chunks require a matching keyframe rate. Please refer to the live stream tuning documentation for the impact of key frame settings.
The number of chunks in the list affects the buffer time. The size of the buffer is chunk size * number of chunks. A longer buffer makes the stream more resistant to network issues, but increases the latency, which may be undesirable.
By default, we set your chunklist to 4 chunks of 8 seconds each. We find this gives a good bitrate efficiency and resistance to network issues. This does cause ~30s latency on streams. For users desiring lower latency, a list of four 4-second chunks will offer ~15s latency, and for those desiring close to realtime, lists of three 2-second or 1-second chunks will offer < 10 second latency. This reduced latency can result in slightly reduced stream reliability if you have clients on poor networks.
Contact us, and we'll get your streams set up just right for you.
Providing secure HTTPS delivery of your HLS streams is essential if you are to reach your audience. The Chrome browser update requiring HTTPS was a big driver of this shift in the streaming industry, but we have been supporting HLS over HTTPS since 2015. All TV apps require streams to be delivered over HTTPS, on Apple and Google TV and Amazon Fire. All in browser HLS is being delivered over HTTPS as browsers will block "mixed content".
With content increasingly consumed on Smart TVs, HTTPS delivery of streams is a necessary part of your video streaming package. Providing secure HTTPS connections to our full CDN is included with all ScaleEngine video streaming services, and is the default for our players, and provided endpoints.