Low Latency Live Streaming Implementation in DASH and HLS

Abdelhak Bentaleb Zhengdao Zhan Farzad Tashtarian May Lim

NUS, Singapore NUS, Singapore AAU, Austria NUS, Singapore
bentaleb@[Link] zhengdao@[Link] [Link]@[Link] maylim@[Link]

Saad Harous Christian Timmerer Hermann Hellwagner Roger Zimmermann

UoS, UAE AAU, Austria AAU, Austria NUS, Singapore
harous@[Link] [Link]@[Link] [Link]@[Link] rogerz@[Link]

ABSTRACT (ABR) scheme to decide the suitable bitrate level to download from
Low latency live streaming over HTTP using Dynamic Adaptive the server (or CDN) according to the stream information given in
Streaming over HTTP (LL-DASH) and HTTP Live Streaming (LL- the DASH Media Presentation Description (MPD) or HLS playlist.
HLS) has emerged as a new way to deliver live content with an In the past decade, there has been a tremendous shift from
respectable video quality and short end-to-end latency. Satisfying traditional cable TV to Internet TV because of technology advances
these requirements while maintaining viewer experience in practice in online video streaming over the Internet. Video services such as
is challenging, and adopting conventional adaptive bitrate (ABR) YouTube, Facebook, Twitch, Netflix and others occupy a huge part
schemes directly to do so will not work. Therefore, recent solutions of today’s Internet ecosystem. Significant growth in video traffic
including LoL+ , L2A, Stallion, and Llama re-think conventional ABR poses many challenges for live video streaming providers and might
schemes to support low-latency scenarios. These solutions have limit their ability to deliver to the viewer an assured quality of
been integrated with [Link] [9] that supports LL-DASH. However, experience (QoE). Therefore, low latency live (LLL) streaming has
their performance in LL-HLS remains in question. To bridge this gap, received tremendous attention by both the research community
we implement and integrate existing LL-DASH ABR schemes in the and the industry. To achieve the low latency objective, DASH and
[Link] video player [18] which supports LL-HLS. Moreover, a series HLS have been extended to support LLL streaming scenarios.
of real-world trace-driven experiments have been conducted to Low latency DASH (LL-DASH) [10] was first introduced in 2018,
check their efficiency under various network conditions including followed by low latency HLS (LL-HLS) [5] in 2020. Both extensions
a comparison with results achieved for LL-DASH in [Link]. Our share common design principles following the Common Media
version of [Link] is publicly available at [3] and a demo at [4]. Application Format (CMAF; ISO/IEC 23000-19) specification [12].
CCS CONCEPTS CMAF allows each media segment to be encoded and delivered
in small non-overlapping chunks (also called parts). The client
• Information systems → Multimedia streaming . starts downloading each chunk of a segment once it is prepared
KEYWORDS and available at the origin server. The chunks of a segment will be
Low Latency Streaming, ABR, LL-DASH, LL-HLS, [Link], [Link]. sent to the client one by one, and the client can start rendering a
ACM Reference Format: segment right after its first chunk is received. Therefore, the glass-
Abdelhak Bentaleb, Zhengdao Zhan, Farzad Tashtarian, May Lim, Saad to-glass latency, i.e., the time lag between video capture and the
Harous, Christian Timmerer, Hermann Hellwagner and Roger Zimmermann. actual playback time at the client, is decoupled from the segment
2022. Low Latency Live Streaming Implementation in DASH and HLS. In duration and reduced to a few seconds (i.e., less than five seconds).
Proceedings of the 30th ACM International Conference on Multimedia (MM LL-DASH differs from LL-HLS on how to deliver chunks to the
’22), Oct. 10–14, 2022, Lisboa, Portugal. ACM, New York, NY, USA, 4 pages.
client where the former uses HTTP/1.1 chunked transfer encoding
[Link]
(CTE) while the latter uses HTTP/2. Although LL-DASH and LL-
1 INTRODUCTION HLS are a step forward in LLL streaming, adopting one of them
HTTP Adaptive Streaming (HAS) has become the dominant directly is not sufficient to reduce latency. In addition, auxiliary
media delivery system allowing various industries to deliver their tasks such as performing ABR decisions and estimating bandwidth
contents and engage with customers efficiently. There are two become more challenging. Furthermore, existing conventional ABR
mainstream HAS delivery systems in the market: MPEG Dynamic schemes cannot be used directly in low-latency scenarios.
Adaptive Streaming over HTTP (MPEG DASH) [13] and HTTP Recently, interesting solutions including LoL+ [6], L2A [14],
Live Streaming (Apple HLS) [17]. Both HAS technologies share a Stallion [11], and Llama [16] have been developed to address
common design principle. On the one hand, the server (or content these issues leveraging LL-DASH. These solutions have shown
delivery network (CDN)) provides segmented video contents at the best performance in LL-DASH. However, their adaptation to
multiple bitrate levels allowing adaptation to different network and performance in LL-HLS is the main focus of this paper. The
conditions. On the other hand, a client uses an Adaptive Bit Rate contributions of this paper are two-fold: (1) We provide a description
of these ABR schemes including their integration and practical
This work is licensed under a Creative Commons Attribution
International 4.0 License.
implementation in the open source video player [Link]. (2) We
validate the efficiency of different integrated ABR schemes over real-
MM ’22, October 10–14, 2022, Lisboa, Portugal world network conditions using realistic trace-driven emulations.
© 2022 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-9203-7/22/10.
We contribute our code to the [Link] main repository [18]. The code
[Link] is publicly available at [3] and demonstrated at [4].

7343
MM ’22, October 10–14, 2022, Lisboa, Portugal Abdelhak Bentaleb et al.

2 LL-DASH SOLUTIONS 3 LL-DASH SOLUTIONS OVER [Link] (LL-HLS)

We briefly describe existing LL-DASH solutions that are 3.1 [Link] Overview
implemented in the [Link] [9] media player.
[Link] [18] is an open-source library that implements an HLS
Learn2Adapt (L2A). L2A [14] utilizes online convex optimization
player. It relies on the HTML Video Element and the Media Source
to formulate the bitrate decision problem. The main objective of L2A
Extensions to play HLS streams directly within a browser. It works
is to minimize the overall latency in the LLL session, while achieving
by transmuxing MPEG-2 Transport Streams and AAC/MP3 streams
a high video bitrate and therefore acceptable QoE. Moreover, it
into ISO BMFF (MP4) fragments. It is written in ECMAScript6 (*.js)
provides improved robustness against fast changes in the critical
and TypeScript (*.ts). Figure 1 highlights the essential modules:
characteristics, including throughput and buffer level. It solves
the optimization problem using an online learning approach that • Controllers. This module implements a set of controllers that
does not require parameter tuning, channel model assumptions, is required by the video player to perform various tasks.
throughput estimation or application-specific adjustments. It comprises: (𝑖) an ABR Controller ([Link])
LL Adaptive Media Algorithm (Llama). Llama [16] is a recently that implements the ABR logic for bitrate selection; (𝑖𝑖) a
introduced ABR scheme that divides the throughput measurement Buffer Controller ([Link]) responsible for
module of the player into two parts. The first part considers the last monitoring the playback buffer occupancy level to avoid
measured throughput of the last downloaded segment to perform rebuffering events or buffer overflow; (𝑖𝑖𝑖) a Stream Controller
bitrate reduction decisions while the second part takes advantage ([Link]) handling all functionalities (e.g.,
of the harmonic mean of the last twenty downloaded segments to load, start, stop stream) related to HLS streams as well as
contribute to video quality up-switch. This design enables more managing other existing controllers; (𝑖𝑣) a CMCD Controller
active reactions when facing worsening network conditions, while ([Link]) implementing various functionalities of
it prevents a potential rapid response to temporary fluctuations common media client data defined in the specification [2]; and
with the smooth estimation brought by the harmonic mean. (𝑣) a Latency Controller ([Link]) responsible
Standard LL Video Control (Stallion). Stallion [11] is a for maintaining latency within its target range and also changing
throughput-based ABR scheme for LLL streaming. The main idea the playback speed rate if required.
behind Stallion is to use a segment-based sliding window algorithm • Loader. This module consists of: (𝑖) Fragment Loader (fragment-
of the last ten downloaded segments to measure the mean and [Link]) to request and download a segment from a server;
standard deviation (std) of both the throughput and the latency, (𝑖𝑖) Key Loader ([Link]) to load and decrypt the key
which are then utilized to perform ABR decisions. Therefore, using associated with the HLS stream for digital rights management
the std along with the mean provides a safer prediction for available (DRM); and (𝑖𝑖𝑖) Playlist Loader ([Link]) to handle
bandwidth and thus reduces the likelihood of rebuffering. media manifest/playlist loading tasks.
Low On Latency Plus (LoL+ ). LoL+ [6] re-visits and extends • Utils. This module implements a set of classes required by various
several important components at the client-side in ABR streaming other modules such as: Fetch Loader ([Link]) and
to support LLL scenarios. LoL+ includes five essential modules. (1) XHR Loader ([Link]) for requesting and downloading
Throughput Measurement: LoL+ implements a novel algorithm to segments, EWMA Bandwidth Estimator (ewma-bandwidth-
address the issue of idle periods [8] in LLL streaming for accurate [Link]) for bandwidth estimation using an exponentially
measurements. (2) Weight Selection: LoL+ adapts a Self Organizing weighted moving average smoothing function, and MP4 Tools
Map (SOM) [15], an unsupervised machine learning technique, ([Link]) to parse MP4 data.
for bitrate selection. SOM is well-known to be very sensitive to • Demux. This module is responsible for reading the multi-
the initial weight values. For this reason, the module implements part (audio, video, and subtitles) HLS stream and saving
a weight selection algorithm that is invoked at every segment each part as a separate stream. Its main class is Transmuxer
download step to pick suitable weights associated with the set ([Link]) which uses TS Demuxer ([Link]), AAC
of considered SOM features. (3) QoE Evaluation: It implements a Demuxer ([Link]) and MP3 Demuxer ([Link])
QoE function that combines five metrics—selected bitrate, bitrate for audio, and MP4 Demuxer ([Link]) for video.
switches, rebuffering duration, latency, and playback speed— • Remux. This module is responsible to take the video and audio
helping the bitrate selection module in choosing a suitable bitrate streams from one container and put them into a new MP4
for the next segment to be downloaded. (4) Playback Speed Control: container using the MP4 Remuxer ([Link]) with the
It dynamically adjusts the playback speed (normal, speed-up, or help of MP4 Generator ([Link]; to generate MP4
speed-down) in order to maintain the latency within its target Box) and Pass Through Remuxer ([Link]).
range while avoiding the risk of rebuffering. (5) Bitrate Selection: • Crypt. This module mainly uses Decrypter ([Link]), AES
It implements the LoL+ ABR scheme that is triggered at each Crypto ([Link]), AES Decryptor ([Link]),
segment download. It formulates the bitrate selection problem as and FAST AES Key ([Link]) classes to facilitate DRM
an unsupervised classification, leveraging the SOM [15] technique. operations and decrypt HLS streams.
For every segment download, the SOM model takes a quadruplet
of features (throughput, rebuffering duration, latency, and bitrate
3.2 LLL Solutions Integration with [Link]
switches) as input and then finds and selects the best matching unit
(BMU) that is associated with the best bitrate. Our modifications are mainly performed in three modules:
Controllers, Loaders, and Utils. Specifically, we added nine new

7344
Low Latency Live Streaming Implementation in DASH and HLS MM ’22, October 10–14, 2022, Lisboa, Portugal

[Link]

Controllers Loaders Utils Demux Remux Crypt

➔ ABR Controller ➔ Fragment Loader ➔ Fetch Loader ➔ AAC Demuxer ➔ MP4 Remuxer ➔ AES Crypto
➔ Buffer Controller ➔ Key Loader ➔ XHR Loader ➔ MP3 Demuxer ➔ Pass Through ➔ AES Decryptor
➔ Stream Controller ➔ Playlist Loader ➔ Bandwidth Estimator ➔ MP4 Demuxer Remuxer ➔ Decrypter
➔ CMCD Controller EWMA|SW|Harmounic ➔ TS Demuxer ➔ MP4 Generator ➔ Fast AES Key
➔ Latency Controller ➔ MP4 Tools ➔ Transmuxer

Figure 1: Overview of [Link] modules. The modules in gray are where our modifications have been performed.
Table 1: Our integration of LLL streaming solutions in [Link]. The live session duration is set according to the duration of the
Module Class State Code Lines
network profile (600 seconds).
[Link] New 574
[Link] New 107 4.2.2 Network Profiles. To emulate various real-world network
[Link] New 129
[Link] New 571 conditions, we used three LTE-based network profiles to shape
Controllers
[Link] New 207 the bandwidth between the server and the player. These profiles
[Link] New 208
[Link] New 51 (Avg: 𝑥 Mbps, std: 𝑥 Mbps), including BelgiumCAR (4.3, 2.5),
[Link] Modified 377 NorwayMETRO (1.5, 0.5), and NyuBUS (9.6, 5.3), are extracted from
[Link] New 36
Utils [Link] New 36 three datasets and can be found in [7]. We fixed the packet delay to
[Link] Modified 36 50 ms and loss rate to 0.08%.
[Link] Modified 3
Loaders [Link] Modified 4 4.2.3 ABR Algorithms and Performance Metrics. We compare the
[Link] Modified 8
performance of five ABR schemes (LoL+ , L2A, Llama, Stallion, and
classes and modified five classes. Table 1 summarizes the newly
Default HLS) in terms of QoE and its following metrics:
added and modified classes in [Link] (v1.0.0).
Each added ABR scheme is enabled in [Link]. • Avg. BR: Average bitrate across the live session (Mbps).
In addition, we modified (a) [Link] to add the • Avg. RD: Average rebuffering duration across the live session (s).
LoL+ playback speed control module, and (b) [Link], • Avg. RC: Average rebuffering count across the live session.
[Link], [Link], and [Link] to • Avg. SC: Average bitrate switching count across the live session.
add the LoL+ throughput measurement module. We also • Avg. PS: Average playback speed across the live session (s).
added the sliding window bandwidth estimator (sw-bandwidth- • Avg. LL: Average end-to-end latency across the live session (s).
[Link]) and harmonic mean bandwidth estimator (sw- Default HLS (D-HLS) is a hybrid ABR scheme that combines the
[Link]) that are used by Stallion and Llama, buffer level and measured throughput to perform ABR decisions.
respectively. We note that we added a logging class to [Link] in order In a nutshell, D-HLS selects the bitrate for the next segment
to simplify collection of performance metrics. based on the latest throughput if the buffer is safe (more than
two segments are buffered). Otherwise, if the buffer is endangered
and the estimated throughput shows that there might be a risk of
4 EXPERIMENTAL EVALUATION
rebuffering, it will downshift and select the lowest bitrate level.
4.1 Implementation and Demo
4.2.4 Setup. To build an end-to-end LL-HLS system, we used
We integrated different LLL ABR schemes in the JavaScript-based a MacBook Pro running macOS Catalina with 6-Core Intel i7
[Link] player (v1.0.0) [18]. Our source code [3] and a demonstrator [4] processor, 16 GB memory, Intel UHD Graphics 630, and two virtual
are available online. The implementation consists of approx. 2,350 machines (VMs). The first VM was used to run the [Link] player in
lines of new or modified code (Table 1). the Google Chrome browser (v88). The second VM executed Apple’s
HLS Tools to produce the HLS stream with LLL mode (encoding
4.2 Methodology and Evaluation Setup
and packaging) to feed into the origin server. To emulate a realistic
4.2.1 Video and Encoding Parameters. We used Apple’s HLS network, we used tcNetEm at the server VM to throttle the total
Tools [1], namely tsrecompressor, mediastreamsegmenter, bandwidth available to the clients according to the network profiles.
and [Link], to generate LL-HLS streams We performed the experiments with two fixed target latency values
conforming to the LL-HLS specification. The tsrecompressor uses of 1.5 and 3 seconds in [Link].
the Big Bug Bunny animation video as input to produce three HLS
streams encoded using the following ABR ladder: {[email protected], 4.3 Results and Analysis
720p@2Mbps, 1080p@4Mbps}, and then it pushes them as MPEG- For each ABR scheme, the experiments were performed five times
2 transport streams to local UDP ports. On the other hand, three using the same network profile and we took the average values as
instances of mediastreamsegmenter are created and listen to these results. Tables 2 and 3 summarize the QoE metrics average results
ports. Each instance is created for one encoded HLS stream and for each ABR for the considered network profiles.
is responsible to (𝑖) chop the encoded stream into segments and As shown in Table 2, LoL+ achieved the best results in terms
parts with a duration of six seconds and one second, respectively, of Avg. BR, Avg. RC, and Avg. RD with an average improvement
(𝑖𝑖) package each part, and (𝑖𝑖𝑖) list the set of segments with their of 49.8% (209.1%), 59.2% (52.4%), and 79.3% (84.1%), respectively,
information (including parts) in a sub-playlist. The resulting sub- compared to all other ABR schemes for both target latency
playlists of the corresponding bitrate levels are then combined in configurations (1.5 and 3 seconds). This LoL+ result comes at
a master playlist. Finally, [Link] acts as an the price of having higher Avg. SC which exactly matches its
HLS origin which is used to push LL-HLS streams to the player. design initiative to react to the rebuffering more actively. Another

7345
MM ’22, October 10–14, 2022, Lisboa, Portugal Abdelhak Bentaleb et al.

Table 2: Average results of ABR schemes on BelgiumCAR. Table 3: Average results of ABR schemes using LL-DASH.
ABR Avg. BR Avg. RC Avg. RD Avg. SC Avg. PS Avg. LL ABR Avg. BR Avg. RC Avg. RD Avg. SC Avg. PS Avg. LL
Target Latency: 1.5 seconds BelgiumCAR
LoL+ 0.79 09 1.69 13 0.99 1.55 LoL+ 2.20 3 0.23 15 1.02 2.98
D-HLS 0.50 23 6.16 3 1.02 1.58 L2A 1.81 7 3.34 6 1.02 3.02
L2A 0.63 23 11.54 6 1.03 1.62 Llama 0.65 6 0.24 4 1.05 3.04
Llama 0.50 24 9.46 0 1.02 1.60 Stallion 1.62 4 0.64 15 1.05 3.03
Stallion 0.50 19 7.45 4 1.02 1.60 NorwayMETRO
Target Latency: 3 seconds LoL+ 0.71 10 2.35 11 1.05 3.02
LoL+ 2.18 03 0.19 17 0.97 2.91 L2A 0.59 8 1.11 6 1.02 3.03
D-HLS 0.51 08 2.60 3 1.01 2.96 Llama 0.50 4 0.93 1 1.02 3.02
L2A 0.92 05 1.62 5 1.01 3.06 Stallion 0.73 19 3.06 7 1.05 3.09
Llama 0.50 06 0.77 0 1.01 3.08 NyuBUS
Stallion 1.60 07 0.96 15 1.01 2.98
LoL+ 3.56 10 0.97 15 0.95 2.95
observation is that L2A suffered from long rebufferings especially L2A 1.38 2 0.99 7 1.01 3.01
Llama 0.91 3 0.55 4 1.00 3.01
for the 1.5 second target latency (with an Avg. RD of 11.54 seconds) Stallion 2.86 3 0.63 11 1.01 3.00
due to inaccurate ABR decisions when the bandwidth is changing 5 CONCLUSIONS
fast. This is in contrast to Stallion and LoL+ which react more
quickly to any sudden change in the bandwidth. D-HLS achieves a Recently, new ABR solutions (LoL+ , L2A, Stallion, and Llama) were
comparable average result in general. In our tests, Llama did not proposed to support LL-DASH, with integration into the [Link]
switch the bitrate during the whole live session, which raised doubts reference player. However, their performance with LL-HLS had not
about its reported performance. It will require further investigation been studied yet. In this paper, we first re-implement and integrate
and evaluation to test its function under more network conditions. these solutions in the [Link] video player to support LL-HLS. The
We note that in all network profiles (NorwayMetro and NyuBUS are source code is available [3] and a demonstration is given [4]. We
not shown), all the ABR schemes achieve consistent Avg. LL within performed a set of experiments to demonstrate the feasibility and
the target latency with a slight increase in some cases. As seen in performance of these solutions under multiple network conditions.
Table 2, different ABR algorithms may perform differently based Our results show the capabilities of these ABR solutions with LL-
on which metrics they tend to prioritize or sacrifice, which makes HLS. We found that the performance of these ABR schemes over
comparisons between these ABR schemes and drawing conclusions LL-HLS is similar to their deployment over LL-DASH.
difficult tasks. One way to compare them is to find the best and REFERENCES
worst performing scheme in each QoE metric and quantify the [1] Apple’s HTTP Live Streaming (HLS) Tools. [Online] Available: [Link]
com/c53j6una. Accessed on Oct. 24, 2021.
relative performance of the other schemes against these boundaries [2] CTA-5004: Web Application Video Ecosystem–Common Media Client Data.
or targets so that a system implementer may choose a scheme based [Online] Available: [Link]
pdfs/[Link]. Accessed on Feb. 20, 2021.
on his/her own priorities and preferences. Here, we followed this [3] Our LL-HLS [Link] Code. [Online] Available: [Link]
strategy for the result analysis. Therefore, if a higher bitrate is LLHLS-ABRs. Accessed on Jan. 28, 2022.
preferred, then LoL+ , Stallion or L2A for the target latency of 3 [4] Our LL-HLS [Link] Demo. [Online] Available: [Link]
demo/[Link]. Accessed on Jan. 28, 2022.
seconds are the best fit. Otherwise, if better video stability, with [5] Apple. Protocol Extension for Low-Latency HLS. [Online] Available: https:
fewer and shorter rebuffering events, are preferable, then Llama or //[Link]/chzvaf5a, 2019. Online; accessed on Jan. 22, 2022.
D-HLS are good alternatives. [6] A. Bentaleb, M. N. Akcay, M. Lim, A. C. Begen, and R. Zimmermann. Catching
the Moment with LoL+ in Twitch-Like Low-Latency Live Streaming Platforms.
To compare the performance of the considered ABR schemes IEEE TMM, pages 1–1, 2021.
with LL-HLS versus LL-DASH, we replicate the same experiments [7] A. Bentaleb and et al.. LoL+ over [Link]. [Online] Available: [Link]
and setup (refer to Section 4.2) using the [Link] reference player [9]. NUStreaming/LoL-plus/, 2021. Online; accessed on Jan. 04, 2022.
[8] A. Bentaleb, C. Timmerer, A. C. Begen, and R. Zimmermann. Bandwidth
We use the target latency of 3 seconds and the LoL+ throughput Prediction in Low-Latency Chunked Streaming. In ACM NOSSDAV, 2019.
measurement module in all ABR schemes for accurate bandwidth [9] DASH-IF. DASH Reference Player ([Link]). [Online] Available: [Link]
[Link]/[Link]/, 2021. Online; accessed on Jan. 22, 2022.
estimation. The average results for different network profiles are [10] DASH-IF and DVB. Low-latency Modes for DASH. [Online] Available: https:
summarized in Table 3. We can extract four essential observations //[Link]/news/low-latency-dash/, 2019. Online; accessed on Jan. 22, 2022.
from these results: (𝑖) The performance of the ABR schemes is [11] C. Gutterman, B. Fridman, T. Gilliland, Y. Hu, and G. Zussman. Stallion: Video
adaptation algorithm for low-latency video streaming. In ACM MMSys, MMSys
very similar in LL-DASH and LL-HLS, mainly for Avg. BR and ’20, New York, NY, USA, 2020. Association for Computing Machinery.
also Avg. LL, which remains within the target value. (𝑖𝑖) The [Link] [12] ISO/IEC. ISO/IEC 23000-19:2020 Information technology – Multimedia
player produces 6× more requests than [Link]. (𝑖𝑖𝑖) Llama prefers application format (MPEG-A) – Part 19: Common media application format
(CMAF) for segmented media. [Online] Available: [Link]
to select lower bitrate levels and never up-shifts to the highest [Link], 2020. Online; accessed on Feb. 04, 2022.
bitrate level for different network profiles. (𝑖𝑣) The playback speed [13] ISO/IEC. 2019. Information technology — dynamic adaptive streaming
over http (dash) — part 1: Media presentation description and segment
and bitrate decisions should be considered jointly to further reduce formats. International standard 23009-1:2019, International Organization for
Avg. RC, Avg. RD, and Avg. LL. Based on (𝑖–𝑖𝑣), we can conclude Standardization, Dec. 2019.
that both LL-DASH and LL-HLS are very promising technologies [14] T. Karagkioules, R. Mekuria, D. Griffioen, and A. Wagenaar. Online learning for
low-latency adaptive streaming. In ACM MMSys, MMSys ’20, New York, NY,
for LLL streaming. However, we believe that there is certainly USA, 2020. Association for Computing Machinery.
room for more work to be performed to optimize the players and [15] T. Kohonen. The SOM. Proceedings of the IEEE, 78(9):1464–1480, 1990.
their modules, including ABR schemes, playback speed control, and [16] T. Lyko, M. Broadbent, N. Race, M. Nilsson, P. Farrow, and S. Appleby. Llama -
low latency adaptive media algorithm. In 2020 IEEE ISM, 2020.
throughput estimators, for large-scale deployments. Additionally, [17] R. Pantos and W. May. HTTP Live Streaming. RFC 8216, Aug. 2017.
we need a new standard QoE model that can support LLL streaming. [18] R. Walch et al. HTTP Live Streaming (HLS). [Online] Available: [Link]
com/video-dev/[Link]/, 2021. Online; accessed on Jan. 04, 2022.

7346