Latency in the context of live streaming is the delay (generally expressed in seconds or milliseconds) between a timestamp in a real-life event and the moment viewers are able to view this real-life event on their viewing device. High-latency in live streaming is generally not a good thing: imagine a soccer game where you can only watch a goal 1 minute after it happened ... Twitter and Facebook updates are likely to spoil the suspense for you!
In the broadcasting industry (read traditional TV industry) years of experience and well-established processes have helped reduced latency to near-zero and there is no-reason why the online streaming media industry can not come up with such low-latency solutions.
When Flash was still a valid option for media playback in the online video world, the RTMP Flash-specific protocol could help us stream live content with low-latency. As Flash is no longer a viable option, we cannot use the RTMP protocol anymore. Most adaptive bitrate streaming is done with HLS those days, since it is the de-facto standard for reaching Apple devices and it also works well on a wide array of devices from desktop computers to Android devices and set-top boxes.
Typical reasons for latency in today's HLS streaming world include:
As of mid-2017 Apple recommends a default of 10-seconds content chunks and a certain number of packets to create a meaningful playback buffer. This results in a de-facto 30 seconds end-to-end delay from origin to viewers. Add a CDN, peak-time network congestion, encoder restarts to the party and you are now navigating the 30-60 seconds latency waters ...
You need to tune your streaming chain to achieve low-latency streaming with HLS. Most optimisations happen on the server. You can refer to your transcoder or streaming server manual for more information on how to best tune it for low-latency streaming with HLS. If you are a Wowza customer this guide will help you improve latency of live HLS streams.
There are also a few player settings we can play with to improve latency. In our testing we used a low-latency tuned Wowza server receiving a signal from a FFmpeg-based transcoder, transcoding a 720p live recording into 3 renditions (720p at 2200 kbps, 540p at 1500 kbps, 360p at 600 kbps). We used 1 key-frame per second for transcoding each of our renditions and used a 1 second HLS chunk duration as explained in the above Wowza guide. We also used a CDN (Amazon Cloud Front) during our testing to make sure it would be relevant to a large scale deployment.
Knowing the above we used the below player code:
We let our test run for over an hour and tested on various browsers and mobile devices, while frequently refreshing our test page, to insure we had consistent results. We were able to reach and maintain a ~ 5 seconds latency for our live HLS test stream. On iOS and macOS Safari where we use native HLS playback in HTML5 video (as opposed to Media Source Extensions) latency was more in the 10 seconds range.
Both Apple and hls.js community have started working on standardisation and improvements to low-latency HLS streaming. As of early 2019 those efforts are still experimental but have opened the way for better low-latency HLS streaming. We hope to be able to bring LHLS to Radiant Media Player as soon as those standardisation efforts have stabilized.