1. Video streaming using Light-Weight Transcoding and In-Network Intelligence
Alireza Erfanian Hadi Amirpour Farzad Tashtarian Christian Timmerer Hermann Hellwagner
Christian Doppler Laboratory ATHENA, Alpen-Adria-Universität, Klagenfurt, Austria
Paper ID: 75
Introduction
Due to the wide variety of devices and applications that leads to an increasingly heterogeneous environment,
providing streaming services with different quality levels is crucial.
Emerging new In-Network intelligence paradigms like network Function Virtualization (NFV) and edge comput-
ing provide storage and computation capabilities closer to clients.
Only a small fraction of videos are popular and they account for almost 80% of total views, while other videos
receive few requests.
In this paper, we propose a novel architecture by employing edge computing capabilities and NFV technologies
called Light-weight Transcoding at the Edge (LwTE) in the context of HTTP Adaptive Streaming (HAS). We inves-
tigate the cost efficiency of LwTE for Video-on-Demand (VoD) and live streaming applications.
How does LwTE work?
The main idea of LwTE is to store the optimal results of encoding search processes as metadata for each video
bitrate and reuse it at the edge servers to reduce the required time and computational resources for transcoding
at the edge. As depicted in Fig. 1, LwTE serves the clients through the following steps:
1. Encoding and extracting metadata: During the encoding process, selected features are extracted and stored as
metadata for all bitrates (except for the highest bitrate) at no additional costs. The metadata is used to reduce
the computation time of the transcoding process at the edge.
2. Optimized downloading: At this stage, the edge servers employ an optimization model to determine which seg-
ments/bitrates should be downloaded from the origin server and which ones should be prepared by transcoding
from the highest bitrate.
3. Light-weight transcoding: This stage will be applied to those segments/bitrates that should be transcoded.
Thanks to the available metadata, the edge server can promptly produce desired bitrates by means of light-
weight transcoding.
4. Delivering requested bitrates: Finally, requested bitrates are delivered from the edge server to the clients.
Encoding
(encode & extract metadata)
Origin Server Edge Servers
Optimized downloading
Delivering
requested bitrates
HAS players
Input
bitstream
Storage
Storage
Transcoding
1 2
4
(light-weight transcoder)
Representation set
Metadata
Highest bitrate+metadata
+
3
Metadata
Segments
Download segments
Download metadata
Optimizer
Figure 1. LwTE architecture
Apply LwTE on VoD application
Problem statement We investigate LwTE approach for Video-on-Demand (VoD) streaming services by optimizing
storage and computation (transcoding) costs at the edge servers and then compare it to the conventional methods.
For unpopular segments/bitrates, LwTE stores only the highest bitrate plus corresponding metadata and serves
the desired bitrates by transcoding by employing the metadata. The popular segments/bitrates are stored at the
edge server in the usual manner.
Evaluation Setup To evaluate the proposed approach, we transcode videos at 30 fps to the full set of bitrates
recommended by Apple using the HEVC/H.265 open-source encoder x265 version 3.4. The “medium” encoder
preset is used as the default; however, we investigate the performance of LwTE under different presets. We
also consider the impact of the video content on the transcoding time by performing the transcoding for various
sequences with different complexities (i.e., “easy to encode” and “hard to encode”) at different segment lengths (i.e.,
four and six seconds). The storage, computation, and bandwidth costs are 0.024$ per GB per month, 0.029$ per
CPU per hour, and 0.12$ per GB based on the Amazon scheme price, respectively. Transcoding operations are
performed on Amazon EC2 instances. We use c5.2xlarge as the default instance type, but repeat our experiments
on various Amazon EC2 instances to investigate the performance of LwTE with different computation power profiles,
i.e., CPU cores and RAM.
Implementation results We compare the compression efficiency of AVC/H.264 using the x264 open-source en-
coder to HEVC/H.265 using the x265 open-source encoder with employing metadata (LwTE) and without use
of metadata (x265). Fig. 2a and Fig. 2c show compression efficiency of the above-mentioned methods for both
medium and veryslow presets for the ParkRunning3 and FoodMarket4 video sequences, respectively. Note that
use of metadata impacts only transcoding time, not compression efficiency. LwTE (x265) yields bitrate savings of
48% and 52% to maintain the same PSNR as compared to x264, for ParkRunning3 and FoodMarket4, respectively.
It is seen from Fig. 2b and Fig. 2d that employing the metadata significantly reduces the transcoding times of
x265, even to lower times than for x264; result in for veryslow and medium presets, on average, 87% and 48%
less than x264, respectively.
As depicted in Fig. 3a and Fig. 3c, storing metadata instead of corresponding bitrate reduces storage up to 80%.
Fig. 3b and Fig. 3d show that using use of metadata results in up to 97% transcoding time saving for the veryslow
preset and approximately 70% for the medium preset. Fig. 4 shows the relative transcoding times for different
presets and AWS instances with different numbers of CPU cores and RAM profiles, namely, c5.2xlarge, c5.4xlarge,
c5.9xlarge, and c5.12xlarge averaged over five sequences. The results show that transcoding on the c5.2xlarge
instance yields the highest transcoding time saving.
(a) (b) (c) (d)
Figure 2. Compression efficiency of x264 and x265 (without metadata) and x265 with metadata employed (LwTE) for (a) ParkRunning3
and (c) FoodMarket4 sequences and medium and veryslow presets. Note that x265 and LwTE have the same compression efficiency.
Transcoding times of x264, x265, and LwTE for (b) ParkRunning3 and (d) FoodMarket4 sequences and medium and veryslow presets.
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
0
10
20
30
40
50
Relative
bitrate(%)
veryslow
medium
(a)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
0
5
10
15
20
25
30
Relative
transcoding
time(%)
veryslow
medium
(b)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
0
10
20
30
40
50
Relative
bitrate(%)
veryslow
medium
(c)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
0
5
10
15
20
25
30
35
Relative
transcoding
time(%)
veryslow
medium
(d)
Figure 3. Average bitrates of metadata relative to its corresponding representations for (a) 4-sec. and (c) 6-sec. segments. Average
transcoding times of “x265 with metadata ” relative to “x265 without metadata” for (b) 4-sec. and (d) 6-sec. segments.
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
2.00
2.25
2.50
2.75
3.00
3.25
3.50
3.75
Relative
transcoding
time(%)
2xlarge
4xlarge
9xlarge
12xlarge
(a)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
22.5
25.0
27.5
30.0
32.5
35.0
37.5
40.0
42.5
Relative
transcoding
time(%)
2xlarge
4xlarge
9xlarge
12xlarge
(b)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
2.0
2.2
2.4
2.6
2.8
3.0
3.2
3.4
Relative
transcoding
time(%)
2xlarge
4xlarge
9xlarge
12xlarge
(c)
r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12
24
26
28
30
32
34
36
38
Relative
transcoding
time(%)
2xlarge
4xlarge
9xlarge
12xlarge
(d)
Figure 4. Average relative transcoding times over five sequences for (a) 4-sec. segments and the very slow preset, (b) 4-sec. segments
and the medium preset, (c) 6-sec. segments and the very slow preset, (d) 6-sec. segments and the medium preset, on different AWS
EC2 instances.
180
200
220
240
260
280
300
320
340
LwTE-M1 (σ=6.6)
LwTE-M1 (σ=4.6)
LwTE-M1 (σ=1.2)
PT (σ=6.6)
PT (σ=4.6)
PT (σ=1.2)
(a) (b) (c)
180
200
220
240
260
280
300
320
340
LwTE-M1 (α=2)
LwTE-M1 (α=1.25)
LwTE-M1 (α=0.75)
PT (α=2)
PT (α=1.25)
PT (α=0.75)
Total
cost
($)
180
230
280
330
380
430
480
530
580 LwTE-M1 (Γ=1.9)
LwTE-M1 (Γ=1.2)
LwTE-M1 (Γ=0.6)
PT (Γ=1.9)
PT (Γ=1.2)
PT (Γ=0.6)
Figure 5. Impact of Zipf distribution parameters on total cost with (a) various video probability distribution, (b) various segment
probability distribution, and (c) various bitrate probability distribution.
Fig. 5(a)–(c) depict the measured total cost for various probability distributions for videos, segments, and bitrates,
respectively. What stands out in figures is that, LwTE surpasses the state-of-the-art approaches in terms of total
cost and transcoding rate in different portability distribution. Moreover, Fig. 5 also indicates that distributions
with a larger standard deviation Moreover, Fig. 5 also indicates that distributions with a larger standard deviation
(i.e., greater α and σ values and smaller Γ values) result in a better performance in terms of total cost.
Apply LwTE on Live streaming application
We also investigate cost-efficiency of LwTE on live application by applying the light-weight transcoding at the edge
method for live applications, LwTE-Live, to decrease the bandwidth utilization and the overall live streaming cost.
During the encoding processes at the origin server, the optimal encoding decisions are saved as metadata and
the metadata replaces the corresponding representation in the bitrate ladder. The significantly reduced size of the
metadata compared to its corresponding representation decreases the bandwidth utilization. The extracted meta-
data is then utilized at the edge to decrease the transcoding time. We formulate the problem as a Mixed-Binary
Linear Programming (MBLP) model to optimize the live streaming cost, including the bandwidth and computation
costs. We compare the proposed model with state-of-the-art approaches, and the experimental results show that
our proposed method saves the cost and backhaul bandwidth utilization up to 34% and 45%, respectively.
Fig. 6 illustrates the LwTE-Live’s performance compared with the state-of-the-art in various bandwidth profiles in
terms of normalized cost, CPU and bandwidth utilization, and number of transcoded representations. The results
show that LwTE-Live surpasses the state-of-the-art approaches in all bandwidth situations in the studied metrics.
Fig. 7 depicts LwTE-Live’s performance for various segment lengths and compare it with state-of-the-art ap-
proaches in terms of normalized cost, bandwidth and CPU utilization, and number of transcoded representations.
In this direction, we conduct our experiments with 1, 2, and 4 seconds segment length. As depicted in Fig. 7 (a)
and (b), LwTE-Live outperforms other approaches in various segment lengths. Fig. 7 (c) and (d) show CPU utilization
and the number of transcoded representations.
60 100 150 200 60 100 150 200
LwTE-Live OSCAR
0
1
.06
0.63
0.58
0.58
0.53
0.70
0.76
CPU
utilization
60 100 150 200 60 100 150 200 60 100 150 200
LwTE-Live OSCAR FetchAll
0
1
0.94
0.32
0.22
0.16
0.97
0.44
0.27
0.20
0.97
0.58
0.39
0.29
Bandwidth
utilization
60 100 150 200 60 100 150 200 60 100 150 200
LwTE-Live OSCAR FetchAll
.0
.1
.2
.3
.4
.5
.6
.7
.8
.9
1.0
Transcoding cost
Fetch cost
Normalized
cost
(a) (b)
60 100150200 60 100150200
LwTE-Live OSCAR
0
10
1
9
9
9
4
4
5
Number
of
transcoded
rep.
(c) (d)
Figure 6. Performance comparison of LwTE-Live with state-of-the-art approaches in terms of (a) normalized cost, (b) bandwidth
utilization, (c) CPU utilization, and (d) number of transcoded representations for various bandwidth profiles.
1Sec 2Sec 4Sec 1Sec 2Sec 4Sec
LwTE-Live OSCAR
0
10
8
9
9
5
4
4
Number
of
transcoded
rep.
1Sec 2Sec 4Sec 1Sec 2Sec 4Sec
LwTE-Live OSCAR
0
1
0.45
0.63
0.60
0.38
0.53
0.54
CPU
utilization
1Sec 2Sec 4Sec 1Sec 2Sec 4Sec 1Sec 2Sec 4Sec
LwTE-Live OSCAR FetchAll
0
1
0.44
0.32
0.31
0.54
0.44
0.43
0.65
0.58
0.58
Bandwidth
utilization
1Sec 2Sec 4Sec 1Sec 2Sec 4Sec 1Sec 2Sec 4Sec
LwTE-Live OSCAR FetchAll
.0
.1
.2
.3
.4
.5
.6
.7
.8
.9
1.0
Transcoding cost
Fetch cost
Normalized
cost
(a) (b) (c) (d)
Figure 7. Performance comparison of LwTE-Live with state-of-the-art approaches in terms of (a) normalized cost, (b) bandwidth
utilization, (c) CPU utilization, and (d) number of transcoded representations for various segment lengths.
Acknowledgment
The financial support of the Austrian Federal Ministry for Digital and Economic Affairs, the National Foundation for
Research, Technology and Development, and the Christian Doppler Research Association, is gratefully acknowl-
edged. Christian Doppler Laboratory ATHENA: https://athena.itec.aau.at/.
https:/
/www.athena.itec.aau.at Mile-High Video Conference (MHV ’22) alireza.erfanian@aau.at