Recent updates to the HTTP Live Streaming (HLS) standard have made new ways of standard-compliant low-latency streaming possible. But how low can the latency be, by how much do different low-latency flavours of HLS differ and what will the future of HLS bring in terms of delay? NativeWaves Andreas Unterweger and Bartosz Ziemski investigateBy Contributor
Published: April 22, 2021
Recent updates to the HTTP Live Streaming (HLS) standard have made new ways of standard-compliant low-latency streaming possible. But how low can the latency be, by how much do different low-latency flavours of HLS differ and what will the future of HLS bring in terms of delay? NativeWaves' Andreas Unterweger and Bartosz Ziemski investigate
target=_blank title=Share on LinkedIn class=share-linkedin>
Live streaming over the internet is an increasingly popular supplement to traditional broadcasting. With ever increasing demands regarding fast and scalable streaming, the widely adopted HTTP Live Streaming (HLS) standard has undergone recent (draft) revisions to enable lower end-to-end latencies. This version of the standard is commonly referred to as Apple Low-Latency HLS (LLHLS). It is different from previous efforts to supplement the old HLS standard with low-latency capabilities, commonly referred to as Community Low-Latency HLS (LHLS).
Simply put, Community LHLS advertises the most recent (edge) media segment to the receiver while it is still being produced, whereas Apple LLHLS advertises only those portions of it which are already available. Both approaches have their own upsides and downsides. Most prominently, Community LHLS breaks Adaptive Bit Rate (ABR) streaming due to chunked transfer and is already phased out in most implementations in favor of Apple LLHLS. The latter, however, makes caching through Content Delivery Network (CDNs) very hard due to very frequent and potentially client-dependent playlist updates.
While the choice of HLS flavour seems to boil down to the technical, logistical and practical pros and cons, it does not appear to be a question of delay - low latency is low latency after all, or is it not? Perhaps surprisingly, the practical delay bounds for each HLS flavour are not the same and their relative impact on end-to-end delay is larger than one might think. Let us investigate.
End-to-end delay comprises of many different factors, only some of which the sender (operating the live streaming source) can influence directly. Even the most creative engineers have very limited means against, for example, the transmission delay itself - the speed of light is quite a tough barrier to break in our Universe. However, accepting the physical limits of our Universe and thus our global network connections as they come, the remaining delay that can be influenced directly is worth analysing.
To explore the limits of HLS in terms of (influenceable) delay, engineers at NativeWaves set up a streaming server, a distribution (caching) server and a client (player) in a local network. The setup depicted in the image below is based on typical real-world setups for live events: The server captures a known Serial Digital Interface (SDI) input signal with a capture card, encodes it in hardware (on a Graphics Processing Unit (GPU)) and sends the encoded data via HLS directly to a distribution server which streams it to the client. Standard software (including FFmpeg with nvenc support) and typical settings (e.g., six seconds segment size) are used to make the results representative and as close as possible to practice.
data-src=https://www.tvbeurope.com/wp-content/uploads/2021/04/1-726x143.png alt= width=726 height=143 data-srcset=https://www.tvbeurope.com/wp-content/uploads/2021/04/1-726x143.png 726w, https://www.tvbeurope.com/wp-content/uploads/2021/04/1-353x69.png 353w, https://www.tvbeurope.com/wp-content/uploads/2021/04/1-768x151.png 768w, https://www.tvbeurope.com/wp-content/uploads/2021/04/1-1536x302.png 1536w, https://www.tvbeurope.com/wp-content/uploads/2021/04/1-2048x403.png 2048w data-sizes=(max-width: 726px) 100vw, 726px />Setup used for testing consisting of a streaming server, a distribution server and a clientThe end-to-end delay is measured - from the time of capture at the streaming server to the earliest possible playback time at the client in the same local network. The measurements are analysed statistically, but instead of reporting the mean or median delay values, the 95th percentiles are presented. Reasoning about the worst-case delay that 95 per cent of users encounter portrays practical latency experiences much more accurately than focusing only on the better half of experiences.
data-src=https://www.tvbeurope.com/wp-content/uploads/2021/04/2.png alt= width=198 height=148 data-srcset=https://www.tvbeurope.com/wp-content/uploads/2021/04/2.png 554w, https://www.tvbeurope.com/wp-content/uploads/2021/04/2-353x263.png 353w, https://www.tvbeurope.com/wp-content/uploads/2021/04/2-160x120.png 160w data-sizes=(max-width: 198px) 100vw, 198px />Comparison of delay between classical HLS, Apple LLHLS and Community LHLS with a segment size of 6 sSo, what do the results look like? The image on the right shows a comparison of the measured delay values for classical (non-low-latency) HLS (left), Apple LLHLS (middle) and Community LHLS (right). As expected, classical HLS produces orders of magnitude higher delay than the two low-latency flavours. The latter are nearly indistinguishable at this scale, but their differences will be broken down in more detail later. First, let us find out what causes the big difference between classical HLS and the two low-latency flavours.
data-src=https://www.tvbeurope.com/wp-content/uploads/2021/04/3.png alt= width=253 height=189 data-srcset=https://www.tvbeurope.com/wp-content/uploads/2021/04/3.png 554w, https://www.tvbeurope.com/wp-content/upl
