Brightcove
Asistencia Técnica+1 888 882 1880
Productos
Soluciones
Recursos
Empresa
Search IconA magnifying glass icon.
Hable Con Nosotros

Atrás

Bo Zhang

By Bo Zhang

Principal Software Engineer at Brightcove

The Evolution of Low-Latency Video Streaming

Tech Talk

Low-Latency Live

In the past few years, the video streaming industry has seen immense interest in low-latency video streaming protocols. The majority of interest is on delivering videos with a sub-five-second delay, making them comparable with delays in live broadcast TV systems. Attaining such low delay is critical for streaming live sports, gaming, online learning, interactive video applications, and others.

Developing the Technology for Low-Latency Streaming

The delays in conventional live OTT streaming technologies such as HLS and DASH are much longer. They’re caused by relatively long segments (4-10 seconds) and a segment-based delivery model, requiring complete delivery of each media segment before playback. Combined with the buffering strategies used by the HLS or DASH streaming clients, this typically produces delays of 10-30 seconds, or even longer.

To combat delays, recent evolutions of HLS and DASH standards, known as Low-Latency HLS (LL-HLS) and Low-Latency DASH (LL-DASH), have introduced two key tools:

  • Chunked video encoding. This is an encoding strategy that produces video segments structured as sequences of much shorter sub-segments or chunks.
  • Chunked segment transfer. This is an HTTP transfer mode that enables transmission of shorter video chunks to streaming clients as soon as they are generated.

A streaming client can join a low-latency live stream from any Stream Access Point (SAP) which is made available by the live transcoder on segment boundaries or chunk boundaries. Once joined, a player would only need to buffer the latest video chunk generated by the encoder before decoding and rendering it. Considering that each segment can be split into several chunks (typically 4-10), this reduces the delay significantly.

Several open-source and proprietary implementations of low-latency servers and players are currently available on the market, including one by Brightcove. Many of them have demonstrated lower streaming delay when only a single-bitrate stream is used and when they stream over high-speed network connections. However, their performance under more complex and realistic deployment environments has not been well studied.

Testing the Performance of Low-Latency Streaming

In our paper published in ACM Mile-High-Video 2023 (link forthcoming) as well as a presentation at Facebook@Scale, we reported some results after testing the performance of low-latency video systems.

First, we developed an evaluation testbed for both LL-HLS and LL-DASH systems. We then evaluated various low-latency players using this testbed, including Dash.js, HLS.js, Shaka player, and Theo player. We also evaluated several of the latest bitrate adaptation algorithms with optimizations for low-latency live players. The evaluation was based on a series of live streaming experiments. These experiments were repeated using identical video content, encoding profiles, and network conditions (emulated by using traces of real-world networks).

Table 1 shows our live video encoding profiles for generating the multi-bitrates, low-latency DASH/HLS stream.

RenditionVideo resolution (pixels)Video codec and profileBitrate (kbps)
low768 x 432H.264 main949
mid1024 x 576H.264 main1854
high1600 x 900H.264 main3624
top1920 x 1080H.264 main5166
Table 1. Live video encoding profiles

Figure 1 shows the workflows of our low-latency DASH and HLS streaming testbeds.

LL-DASH toolchain LL-HLS toolchain

Figure 1. System setup used for evaluation of low-latency players.

Figure 2 shows the available network bandwidth of our emulated LTE mobile network. The download bandwidth of the low-latency players is controlled by our network emulation tool and the network traces.

Low-Latency Streaming Test - Network Bandwidth

Figure 2. Available bandwidth of emulated LTE mobile networks (Verizon and T-Mobile)

A variety of system performance metrics (average stream bitrate, amount of downloaded media data, streaming latency) as well as buffering and stream switching statistics were captured and reported in our experiments.

These results have been subsequently used to describe the observed differences in the performance of LL-HLS and LL-DASH players and systems.

A few plots from our study can be seen in the figures below.

Bitrate - DASH TMobile Bitrate - HLS TMobile

Figure 3. Dynamics of bitrate switches reported by LL-HLS and LL-DASH players.

Latency - DASH TMobile Latency - HLS TMobile

Figure 4. Comparison of variations of latency reported by LL-HLS and LL-DASH players.

Performance statistics – T-Mobile LTE network

Player/AlgorithmAvg. bitrate [kbps]Avg. height [pixels]Avg. latency [secs]Latency
var. [secs]
Speed var. [%]Number of switchesBuffer eventsBuffer ratio [%]MBs loadedObjects loaded
DASH.js default27707263.060.2110.493387.99352.2256
DASH.js LolP34968535.654.5922.7705321.96369.4210
DASH.js L2all36999084.143.1819.95197.99368147
Shaka player (dash)38189164.922.0601654.66360.3155
THEO player (dash)45949936.160.0102700418.7152
HLS.js default 2020176356210.0810.918.12629.8130.7589
HLS.js LolP 202017565605.970.26.12400148.1688
HLS.js L2all 2020175256060.235.93400133.1686
HLS.js default 202339718958.931.130800360.8613
Shaka player (HLS)39559087.182.2301473.8230475

Table 2. Performance statistics – T-Mobile LTE network

Evaluating the Performance of Low-Latency Streaming

While LL-HLS and LL-DASH worked well in unconstrained network environments, they struggled in low bandwidth or highly variable networks (which are typical in mobile deployments). Observed effects included highly variable delays, inability to prevent buffering, and frequent bandwidth switches or inability to use the available network bandwidth. Some players simply switched into non-low-latency streaming under such challenging network conditions.

As promising as LL-HLS or LL-DASH are in theory, there is still some room for these technologies to mature.

At Brightcove, we are continuing to work on best-in-class implementations of algorithms for low-latency streaming clients as well as encoder and server-side optimizations. We intend to make our support for low-latency streaming highly scalable, reliable, and fully ready for prime time.

This blog was originally written by Yuriy Reznik in 2021 and has been updated for accuracy and comprehensiveness.


Regresar al principio