# Increasing the Quality of 360° Video Streaming by Transitioning between
Viewport Quality Adaptation Mechanisms

Christian Koch1, Arne-Tobias Rak1, Michael Zink2, Ralf Steinmetz1, Amr Rizk3
1Multimedia Communications Lab (KOM), Technische Universität Darmstadt,
Germany
2University of Massachusetts Amherst, USA, 3Ulm University, Germany
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract.

Virtual reality has been gaining popularity in recent years caused by the
proliferation of affordable consumer-grade devices such as Oculus Rift, HTC
Vive, and Samsung VR. Amongst the various VR applications, 360° video
streaming is currently one of the most popular ones. It allows user to change
their field-of-view (FoV) based on head movement, which enables them to freely
select an area anywhere from the sphere the video is (virtually) projected to.
While 360° video streaming offers new exciting ways of consuming content for
viewers, it poses a series of challenges to the systems that are responsible
for the distribution of such content from the origin to the viewer. One
challenge is the significantly increased bandwidth requirement for streaming
such content in real time. Recent research has shown that only streaming the
content that is in the user’s FoV in high quality can lead to strong bandwidth
savings. This can be achieved by analyzing the viewers head orientation and
movement based on sensor information. Alternatively, historic information from
users that watched the content in the past can be taken into account to
prefetch 360° video data in high quality assuming the viewer will direct the
FoV to these areas. In this paper, we present a 360° video streaming system
that transitions between sensor- and content-based predictive mechanisms. We
evaluate the effects of this transition-based approach on the Quality of
Experience (QoE) of such a VR streaming system and show that the perceived
quality can be increased between 50% and 80% compared to systems that only
apply either one of the two approaches.

360° Video Streaming, Virtual Reality, Quality Adaptation

††ccs: Information systems Multimedia streaming††ccs: Computing methodologies
Virtual reality††ccs: Computing methodologies Video segmentation

##  1\. Introduction

Large events such as sports matches or the keynotes of Apple and Google are
nowadays regularly captured in 360°. These videos are created by stitching
multiple camera perspectives together and projecting the result on a sphere
with the viewer at its center (El-Ganainy and Hefeeda, 2016). Such videos can
be watched by panning in a traditional web browser’s video player or by using
VR goggles. Especially the latter ones create an immersive experience since
the user’s head movement directly affects the visible area of the video, i.e.,
the field-of-view (FoV).

The proliferation of VR devices such as Oculus
Rift111https://www.oculus.com/rift/ [Accessed: August 28, 2024], HTC
Vive222https://www.vive.com/ [Accessed: August 28, 2024], and Samsung
VR333https://www.samsung.com/us/mobile/virtual-reality/ [Accessed: August 28,
2024] makes 360° video streaming available to a broad audience since they are
affordable also for individual users. In addition, 360° content is offered on
YouTube and other streaming websites. To ensure a reasonable Quality of
Experience (QoE) for viewers of 360° videos, a high resolution and frame rate
is required which also helps preventing motion sickness (Corbillon et al.,
2017b). Transferring the entire 360° video in high resolution is particularly
bandwidth-consuming. 360° videos reach up to 12k, i.e., 1520x6480 pixel in
resolution with 100 frames per second (FPS) (Corbillon et al., 2017b). In many
countries the average Internet speed into households is not sufficient for
this task, e.g., in Germany it is just 15.3 Mbit/s (Akamai, 2017). This is
just a fraction of Google’s recommended bitrate of 68 Mbit/s for for 4k 60 FPS
360° videos.444https://goo.gl/gz556T [Accessed: August 28, 2024] Therefore,
today the average household is incapable of streaming the entire sphere of a
360° video at high quality due to a lack of bandwidth, and streaming several
360° videos in parallel to different household member is impossible.
Optimizing bandwidth utilization for 360° video streaming is a recent research
topic (Bao et al., 2016a; Graf et al., 2017; Qian et al., 2016; Nasrabadi et
al., 2017). One way to lower the bandwidth demand is to stream just the
portion of the video that is currently visible to the viewer in a high
resolution and the remainder in a low resolution (Corbillon et al., 2017b).
This currently watched portion is called viewport and may constitute about 20%
of the entire 360° sphere (Bao et al., 2016a). However, this approach has two
drawbacks: i) A quick response time of about 10 ms to head movements is
crucial to maintain a high QoE (Chakareski et al., 2018). Usually, the Round
Trip Time (RTT) between client and server is too high to allow for a
sufficiently fast quality adaptation. ii) Extracting the visible area from a
video is a computationally expensive task that is hard to support by streaming
servers (Corbillon et al., 2017b). Multiple viewport-oriented schemes have
been proposed to cope with these issues (Nguyen et al., 2017; Qian et al.,
2016; Bao et al., 2016a; Xie et al., 2017). One approach is to predict the
user’s head movement in order to request the new viewport in a timely fashion.
Although this prevents rebuffering to some extent, it is only reliable for the
duration for which the viewport can be accurately predicted which is claimed
to be up to 2 s (Qian et al., 2016). Consequently, maintaining useful content
in the client’s playout buffer in 360° streaming systems is difficult in case
of fluctuating bandwidth. Furthermore, abrupt changes in head position cannot
be predicted which results in playback stalling.

To reduce computational stress on the server’s side, the majority of the
proposed schemes suggest to encode 360° videos into spatial and temporal
segments such that segments corresponding to the current viewport can be
requested instead of extracting them from the original source in an online
manner. Albeit not saving as much bandwidth as the previous approach, a more
robust way of streaming 360° videos is to have the entire area around the
viewport transferred in a lower quality than the viewport itself. This enables
buffering more content, since an incorrectly predicted viewport causes only a
low-quality video segment to be displayed, instead of stopping the playback
until the new segment is downloaded. Several proposals have been published
that incorporate transferring entire frames with a high quality at the
viewport and its proximity (Petrangeli et al., 2017a; Nasrabadi et al., 2017;
Chakareski et al., 2018; Corbillon et al., 2017b). Although helpful for
maintaining a high QoE, viewport prediction is not mandatory in these
streaming schemes and not used in all cases (Kuzyakov and Pio, 2016). Some
proposals introduce additional _content-based prediction_ mechanisms to
further assist and improve accuracy. This includes learning head movements
from user traces for individual videos as well as identifying dynamic areas of
a video which a viewer is likely to look at, i.e., saliency maps (Fan et al.,
2017).

In this paper, we propose a novel approach for 360° video streaming system
which uses, both, sensory and content-based predictive mechanisms. We propose
transitioning between these two mechanisms based on the client-server
connection quality, similar to the self-adaptive concept from (Frömmgen et
al., 2015). Additionally, an intermediate network cache is integrated to
assist the transmission of video data. We assume this cache to be a telco-
owned edge cache that can be rented, e.g., a dedicated cache storage space per
video. Thus, the contributions of this paper are the design of a transition-
based approach to 360° video streaming, as well as an evaluation of the
effects of this scheme on video quality, bandwidth savings, and resulting QoE.

The remainder of this paper is structured as follows. Section 2 discusses the
related work on adaptive 360° video streaming. In Section 3, we briefly
summarize the head movement dataset and its software which we use in this
paper. We present our system design in Section 4 and show our evaluation
results in Section 5. Section 6 discusses the proposed system. We conclude the
paper and provide an outlook on future work in Section 7.

Table 1. Overview of existing works in the area of 360° video streaming. |  |  | Adaptation based on |  |  |  |  |  |  |  |
---|---|---|---|---|---|---|---|---|---|---|---
Reference |  VP-limit |  Sensor pred. |  Content pop. |  Avail. Bandwidth |  Transitions |  Tiled/Monolithic |  Caching |  Encoded Offline |  Codec |  Projection |  HTTP
Petrangeli et al. (Petrangeli et al., 2017b) | no | velocity | - | yes | no | tiled | - | yes | HEVC | equirect | 2
Nasrabadi et al. (Nasrabadi et al., 2017) | no |  linear regression | - | no | no | tiled | base layer | yes | SHVC | cubemap | 1.1
Fan et al. (Fan et al., 2017) | no |  neural network |  saliency- & motion-map | no | no | tiled | - | yes | HEVC | equirect | -
Corbillon et al. (Corbillon et al., 2017b) | no | - | - | yes | no | monolithic | - | yes | HEVC | arbitrary | 1.1
Kuzyakov et al. (Kuzyakov and Pio, 2016) | no | - | - | yes | no | monolithic | - | yes | - | pyramid | 1.1
Chakareski et al. (Chakareski et al., 2018) | no | - | heatmap | yes | no | tiled | - | yes | HEVC | equirect | -
Xu et al. (Xu et al., 2018) | no |  linear regression | - | no | no | monolithic | - | yes | H.264 | pyramid | 1.1
Xie et al. (Xie et al., 2017) | yes |  linear regression | - | yes | no | tiled | - | yes | H.264 | equirect | 1.1
Nguyen et al. (Nguyen et al., 2017) | yes | velocity | - | yes | no | tiled | - | no | HEVC | equirect | -
Qian et al. (Qian et al., 2016) | yes |  linear regression | heatmap | no | no | tiled | - | yes | H.264 | equirect | 1.1
Bao et al. (Bao et al., 2016a) | yes |  neural network | - | no | no | - | - | no | - | equirect | -
_our approach_ | no |  linear regression | heatmap | 555Bandwidth adaptation, as in adjusting quality demands based on available bandwidth, is only used when transitions are disabled. | yes | tiled |  popular tiles | yes | H.264 | Equirect | 1.1

##  2\. Adaptive 360° Video Streaming

A variety of approaches for 360° video streaming has been proposed. First, we
introduce the key properties of 360° video streaming systems to guide the
classification of the related work. We provide a comparative overview of
selected and relevant related work in Table 1.

###  2.1. Viewport-limited Approaches

Viewport-limited approaches limit the transmitted video area to what is
expected to be visible to the viewer. This usually saves more bandwidth than
transferring frames capturing the entire 360° sphere with emphasized quality
regions, since less data needs to be transferred. As viewports cover only
about 20% of a sphere, the remaining 80% can theoretically be omitted (Bao et
al., 2016a). However, an accurate viewport prediction is mandatory in order to
request the correct video areas from the server. Incorrectly predicted
viewports will either cause rebuffering or result in displaying a blank area
to the viewer which significantly decreases the user’s QoE (TaghaviNasrabadi
et al., 2017). To reduce the risk of stalling, viewport-limited streaming
schemes request additional video data, often in lower quality, in the
proximity of predicted viewports, depending on the uncertainty of the
prediction. Furthermore, videos can only be buffered for the duration for
which a sufficiently accurate prediction is possible. According to (Qian et
al., 2016), a between 0.5 s - 2 s is sufficient.

###  2.2. Adaptation Trigger

Next, we present adaptive approaches that regulate the video quality using
either the bottleneck bandwidth measured by the client, the user’s head
movements, or content popularity.

Figure 1. In tiled VR streaming, only tiles belonging to the viewport are
streamed at the highest quality.

####  2.2.1. Bandwidth-oriented Approaches

The video content which is virtually projected to a 360° sphere can be
segmented in video tiles. Only a limited set of tiles matches the user’s
viewport or FoV at a given time, as depicted on an example by Figure 1.
Adapting the requested quality of these tiles to the available bandwidth
reduces the probability of rebuffering if the bandwidth is fluctuating. To
perform this adaptation, a throughput estimation is needed. This can be
achieved passively by measuring the throughput while receiving video data and
assuming it will remain unchanged for the next transmission (Petrangeli et
al., 2017b; Corbillon et al., 2017b; Kuzyakov and Pio, 2016; Chakareski et
al., 2018; Xie et al., 2017; Nguyen et al., 2017). Upon detection of a
decreasing bottleneck bandwidth, a client reduces the requested video quality
accordingly.

####  2.2.2. Prediction-based Approaches

Head-mounted displays (HMDs) and mobile phones contain sensors, i.e.,
gyroscopes that measure the device orientation. This data is used to determine
the viewers head movement, and thus the viewport when watching 360° content.
The location and, in some cases, the movement velocity can be used to predict
the future head position and the corresponding viewport. The predicted
viewports are requested in advance and buffered. Fan et al. (Fan et al., 2017)
and Bao et al. (Bao et al., 2016b) use a neural network for the prediction
task while Nasrabadi et al. (Nasrabadi et al., 2017), Petrangeli et al.
(Petrangeli et al., 2017b), and Xie et al. (Xie et al., 2017) propose
velocity-based approaches using linear regression.

####  2.2.3. Popularity-oriented Approaches

To further improve the accuracy of viewport predictions, several streaming
approaches acquire additional information related to the video content. Fan et
al. (Fan et al., 2017) proposed identifying dynamic and visually salient
regions that are likely to draw the attention of viewers. However, a more
common approach is to produce heatmaps that encode the view traces of viewers
(Corbillon et al., 2017a). Therefore, the viewing behavior of multiple users
is recorded and combined. Heated regions characterize popular areas within a
video, whereas less heated regions imply less relevancy to the viewers. This
can be used to assist viewport prediction or to save these regions in a
separate location or quality.

###  2.3. Tiled or Monolithic

Video segments can either be encoded in tiles, i.e., spatial segments of the
video or without spatial segmentation, i.e., monolithically (Corbillon et al.,
2017b). In tiled approaches, each tile is encoded with a set of different
bitrates, resulting in distinct quality levels. A client can request the tiles
that match its current viewport and request them in a higher quality than the
tiles which are outside of the viewport, i.e., not visible to the viewer.
Monolithic approaches do not split video segments into tiles but encode them
with different quality-emphasized regions (QER) as proposed by Corbillon et
al. (Corbillon et al., 2017b). The QER which fits the client’s viewport best
is requested. The key advantage of monolithic 360° video streaming is that
clients do not have to stitch the tiles back together. However, due to the
multiple representations of each video segment, redundant data tends to
heavily occupy the server-side storage.

###  2.4. Caching

Caching takes advantage of storing frequently requested content at an
intermediate system. Usually caches are deployed by Content Delivery Networks
(CDNs) like Akamai, Facebook CDN, or Google Global Cache. When requesting a
cached file, it is directly served from the cache, without having to fetch it
from the origin, i.e., the streaming server. It is likely that the cache-to-
client connection quality is always equivalent or superior to the origin-to-
client connection quality, since caches are typically placed at the network
edge, i.e., close to clients and, hence, they are less prone to network
congestions on the origin-client delivery path. Obtaining data from a cache
usually results in shorter RTTs, higher throughput, and thus in a faster
arrival of video data (Nasrabadi et al., 2017; Chakareski, 2017).

###  2.5. Offline/Online Encoding

Encoding video segments in an online manner, i.e., extracting the desired
viewport and encoding it in desired quality upon request, is storage-
efficient. Only the original source video needs to be stored on the server,
neither tiled nor in varying quality levels. However, this task is
computationally expensive which leads to a high workload on the server’s
resources. Therefore, the majority of related approaches discussed here, with
the exception of (Nguyen et al., 2017; Bao et al., 2016a), suggest to store
multiple tiled representations of a 360° video, which will not be further
processed by the server.

##  3\. 360° HMD Video Player

Our system is based on the software from Corbillon et al. (Corbillon et al.,
2017a). It is publicly available on GitHub (Corbillon, 2017). The software was
built for tracking the head movement of several participants while watching
various 360° videos. For this purpose, it is capable of rendering locally
saved 360° videos to a HMD. The authors use the OSVR
HDK2666http://www.osvr.org/hdk2.html [Accessed: August 28, 2024] HMD for their
project (Corbillon et al., 2017a). Figure 2 provides a high-level overview of
the software components. The video player consists of two fundamental
processes. Their purposes are to decode a local video file and render it to
the HDK2, respectively. Figure 2 colors their individual steps in red
(decoding) and green (rendering).

Figure 2. Architectural overview of the used system components proposed by
Corbillon et al. (Corbillon et al., 2017a)

In the following, we introduce the key components of the architectural
overview presented in Figure 2.

The main component is the entry point of the application. When launched, it is
provided with a configuration file, containing the path of the locally saved
video file. Next, _Main_ initializes other components and starts the rendering
process.

Mesh maps equirectangular frames (i.e., each frame has the same dimensions) on
the inner surface of a three-dimensional body. The camera is placed in the
center of that body, i.e., a cube in this case. A more intuitive choice would
be a sphere, as this is the geometric body that the captured 360° video is
projected on in the first place. However, in this scenario, the resulting
visual effect using a cube or a sphere are indistinguishable to the viewer
(Harrison, 2003).

The VideoReader continuously reads encoded video data from a local file. This
data is decoded, resulting in raw frames which are added to an internal frame
buffer.

The OSVR black box is an abstraction of all OSVR components that are included
in the system. For this paper, only the OSVR HDK2 HMD is important. It
provides the video player with orientation information and displays the video.

OpenGL is the graphics API used. It interacts with the GPU to render 2D and 3D
scenes to the screen.

The decoding and rendering processes are isolated from each other for two
reasons: (i) Running them in parallel on multiple CPU cores is faster than
sequentially decoding and rendering on a single core. (ii) The refresh rate of
the HMD’s display is usually not equal to the video’s frame rate. The HDK2’s
display has a refresh rate of 90 Hz. It is required to update the displayed
image accordingly to avoid perceivable stuttering, which is done in the
rendering process. However, most videos do not provide this frame rate, so
when a render update occurs, a new video frame cannot always be supplied.
Fortunately, the current head orientation can still be applied to the last
displayed video frame, resulting in an appropriate rendered image. Thereby,
the updates of the current video frame and current rendered image have to
happen desynchronized. For this reason, _VideoReader_ stores decoded frames in
a buffer, so that the _Mesh_ component can pick the appropriate frame
according to the current playback timestamp or keep the last displayed frame
if needed.

The render update instruction is issued from the _main_ component. For each
update a head orientation is provided by _OSVR_. _Mesh_ then potentially gets
a new frame from the internal frame buffer and performs the viewport
extraction using the orientation information conveyed by _main_. _OpenGL_
receives this as a texture and prompts the screen rendering.

##  4\. System Design

This section discusses the design of our proposed system. We propose
transitioning between an approach of _viewport prediction-based quality
adaptation_ in case of sufficient bandwidth and a _tile-popularity-based
approach_ in case the bandwidth is insufficient to deliver the tiles requested
by the first adaptation approach. Thereby, we actively overcome bandwidth
fluctuations and shortages, since we deliver popular content from a cache
close to the user which does not suffer from the bandwidth impairments between
client and content origin. Specifically, we assume a cache on the delivery
path that is beneficial in case of bandwidth impairments between the cache and
the content origin. Examples for such impairments are a high load in the
broadband access ISP’s core network, network congestion between the ISP of the
user and the ISP of the content origin, or non-optimally configured traffic
shaping. To achieve the aforementioned transition-capabilities, we extend the
design presented in Section 3 as follows (ref. Figure 3):

Figure 3. System architecture, each color refers to a process running in
parallel.

  * •

Network streaming: The video tiles are regularly requested from a remote
server that is reachable by the client. In addition, an intermediate cache is
placed on the delivery path, between the content server and the client.

  * •

Spatially tiled videos: The _VideoReader_ is extended to receive and stitch
tiled video segments based on the video manifest, i.e., the Media Presentation
Description (MPD) file which it requests from the server during the
initialization phase. The MPD contains information about the requested video’s
segments, e.g., their duration, location, and the bandwidth required to
download them sufficiently fast. Additionally, the MPEG-SRD extension is used
to describe the spatial relationship between individual tiles (Niamut et al.,
2016). The _AdaptationUnit_ determines the video quality for all tiles and
downloads them. Therefore, it keeps track of the most recent user head
orientations. The _VideoReader_ receives its video data from a new component,
i.e., the _VideoTileStream_ since we no longer assume a monolithic video. The
tile-based decoding and stitching is performed by the _VideoReader_ which
creates entire coherent video frames.

  * •

Quality adaptation: A component is introduced that performs the quality
adaptations based on sensory or content-based predictions and performs
transitions between these quality adaptation mechanisms based on the measured
available network bandwidth.

When the client application is started, a connection to the cache system is
established. Client requests are potentially forwarded to the server,
depending on whether the requested content is cached.

In a next step, the video manifest file, i.e., the MPD is downloaded. The
_AdaptionUnit_ component uses this information to download individual tiles.
To decide in which quality each tile should be requested, the _AdaptionUnit_
performs quality adaptations based on the viewing trace, i.e., the latest user
head orientations, available bandwidth, and tile popularity. Information about
the tile popularity is also contained in the MPD file (cf. Section 4.3). While
new encoded video segments are arriving, the decoding process simultaneously
takes care of decoding the video data. The decoded tiles are reconstructed and
added to the same internal frame buffer that is used in the original software
(cf. Section 3). Our software is publicly available for others to reproduce
our results and for further research projects
777https://github.com/arizk/360transitions [Accessed: August 28, 2024].

###  4.1. Transitions

Both content-based and sensory prediction mechanisms have their benefits and
drawbacks, depending on, e.g., the available bandwidth. Thus, combining them
is likely to result in an improved QoE. Sensory prediction provides the
viewers with high-quality video areas depending on their head movement.
However, this approach is prone to prediction errors and may result in either
stalling events or low video quality when the server-to-client connection’s
bottleneck bandwidth declines. Content-based prediction might still provide
high-quality video, even in the case of throughput decline. In this context,
an intermediate cache will store popular video areas, as they are frequently
requested. Although allowing for persistent video quality, it is unlikely that
a viewer will only look at popular video regions for the entire duration of
the video. Therefore, solely using content-based prediction is not an ideal
solution. Related approaches have combined both adaptation methods by
complementing viewport prediction with different kinds of content-based
mechanisms, e.g., Fang et al. (Fan et al., 2017) and Qian et al. (Qian et al.,
2016). While this does improve the video quality in an ideal network
environment, viewers will still experience a low video quality or even
stalling as soon as bandwidth demands cannot be met by the network. To cope
with this issue, we introduce transitions between these mechanisms. Hence,
either sensory or content-based prediction is used at a given time.
Transitions do not occur randomly, but get triggered by a measurable metric
within in the streaming system. For instance, if the computational power of
the video playback device is not high enough to perform viewport predictions
sufficiently fast, only a content-based prediction mechanism should be used.
This might be useful for complex viewport prediction methods that involve,
e.g., the training of a Neural Network, or in case of high CPU workload caused
by other processes. In our approach, we make use of the estimated bandwidth
metric to determine a transition. We consider the estimated bandwidth as the
most important contextual information. If the bandwidth estimate drops below
the transition threshold $A$, a transition from sensory to content-based
prediction occurs. Note that we estimate only the bandwidth between client and
content origin, i.e., of non-cached video content. In case $A$ is underrun,
popular tiles are requested in high quality. Thereby, mainly popular content
from an intermediary cache is retrieved, avoiding the slow connection to the
content origin. Eventually, when the connection quality recovers, a transition
back to sensory prediction occurs. Figure 4 illustrates this concept. Since we
do not abort started downloads of video tiles, a transition can only occur
between two video segments, i.e., at most once per second given a video
segment length of 1 s. Note that a hysteresis technique can be employed to
limit the transition frequency.

Figure 4. The continuous line represents a network bandwidth trace. When it
drops below the transition threshold $A$, a transition to popularity based
adaptation occurs. If the bandwidth recovers, we transition back to prediction
based adaptation.

###  4.2. Viewport Prediction

The first step to predict a future viewport is estimating the future head
orientation. The _main_ component provides the _AdaptionUnit_ with a viewing
trace every time a viewport prediction is performed. This viewing trace
contains the latest head orientations of the viewer. Each entry consists of a
timestamp and its corresponding head orientation. Using the latest entries, a
linear regression model is fitted. The number of time points contained in the
trace is a configurable parameter. Alternatively, more complex regression
methods could lead to more accurate prediction results (Bao et al., 2016b).
Note however that the accuracy penalty using linear regression is negligible
here (Bao et al., 2016b). The regression model takes a timestamp $t$ as an
input and outputs an estimate for the viewer’s head orientation at time $t+x$.
We compute the visibility of each tile inside the viewport corresponding to
the predicted head orientation at $t+x$. Finally, tiles are sorted by their
respective visibility scores and are assigned matching quality levels. While
assigning quality levels, the increasing bandwidth requirement is continuously
compared to the bandwidth estimate. As soon as the estimate is surpassed,
adaptation is stopped and the last modified tile quality level is reset. This
way, we prevent requesting too much data beforehand, as this may lead to video
playback stalling.

###  4.3. Popularity

Figure 5. Tile popularity distribution in consecutive video segments $S$ with
time index $i$. A brighter color refers to a higher popularity (yellow, green,
purple).

The tile popularity is only involved in determining the tile quality levels
when a transition due to low bandwidth has occurred. Note that the
_AdaptionUnit_ is not responsible for identifying popular video areas. It
rather utilizes popularity information included in the manifest file when
needed. The manifest file contains data about tile popularity for each video
segment. Figure 5 depicts the tile quality distribution for four video
segments ($S_{i},...,S_{i+3}$) with a regular $4\times 4$ tiling grid. We can
observe that, especially in segment $S_{i}$, the center and upper area appears
to be the most popular video region. The quality levels displayed in this
figure are directly taken from the popularity information in the corresponding
manifest file. Thus, internally, tile popularity is represented by a distinct
quality level per tile and segment. In the following, we refer to this as the
_popularity trace_. This makes it simple for the _AdaptionUnit_ to consider
the manifest’s popularity information. Tile quality levels for a segment are
fetched from the popularity trace and downloaded accordingly. If the
popularity quality adaptation is active, the viewer’s movements will not have
an effect on the downloaded tile qualities. Thus, in order to see high-quality
video, a viewer is _guided_ to the popularity trace. This approach can be seen
a natural guidance to get the users to watch the most popular parts of the
video. An alternative approach is to use bitrate adaptation, which reduces the
overall quality of an entire video segment and hence does not guarantee that
the popular parts of the video are displayed in high quality.

In our evaluation, popularity information is obtained from (Corbillon et al.,
2017a), containing head movement traces of 59 participants recorded while they
were watching various 360° videos. Therefore, we can only compute popularity
information about the videos that were shown in this experiment. We imagine,
however, that user feedback or automated saliency calculation methods can be
used to automatically generate such heatmaps. We also note that the
corresponding segments are likely to be at the edge caches due to their high
popularity.

##  5\. Evaluation

This chapter presents the evaluation of our 360° video streaming system. The
goal of the evaluation is to show the benefits and drawbacks of our system
compared to alternative approaches. Therefore, we show the effects of
transitions between quality adaptation mechanisms on bandwidth usage, video
quality, and the resulting QoE, i.e., by measuring playback stalling events
besides the visible video quality. As a benchmark, the naive streaming
approach of not incorporating viewer head movement into quality selection is
chosen. A comparison of our approach with naive streaming is important, as
this is how major VoD platforms implement streaming of omnidirectional content
(Graf et al., 2017). Thereby, it supports comparing our approach with the
state-of-the-art (Graf et al., 2017; Zare et al., 2016; Bao et al., 2016b).

We use a trace-driven simulation for our experiments. Therefore, the 360°
video player (cf. Section 3) was narrowed down to only execute the steps
necessary for collecting the required data. Hence, decoding and rendering
functionalities were skipped. Our simulator uses the viewing traces from
(Corbillon et al., 2017a) to simulate viewer head movements. Additionally,
network traces collected by Winstein et al. (Winstein et al., 2013) are used
to throttle server throughput. They contain timestamps representing the
arrival time of 1500-byte packets in various cellular networks over several
minutes.

###  5.1. 360° Video Dataset

We choose three videos from the dataset provided by (Corbillon et al., 2017a)
with content that motivates different viewer movement: _dive_ , _nyc_ , and
_rollercoaster_. In the _rollercoaster_ video, viewers mainly look at the
roller coaster’s track, while the other videos contain no particular focus
point, and thus, no specific movement can be expected. This characteristic is
reflected in Figure 6 by a higher popularity of the leftmost and rightmost
tiles for _dive_ and _nyc_ compared with the _rollercoaster_ video. Table 2
provides an overview of the videos’ key characteristics.

Table 2. Overview of the videos used for evaluation. The “Original Size” column displays the videos’ sizes before they were tiled and segmented. The “Tiled Size” columns contain the accumulated sizes of all tiles belonging to a quality level, per video. The _high_ quality level matches the original video’s bitrate. Medium and low quality versions were encoded with 0.25 and 0.0625 times the original bitrate, respectively.  Video |  Content |  Duration |  Original Size |  Tiled Size High |  Tiled Size Medium |  Tiled Size Low
---|---|---|---|---|---|---
dive |  Diving scene with a slowly moving camera and no main focus point. | 30 | 73.69 | 80.24 | 17.87 | 4.52
nyc |  Timelapse with static camera and fast moving objects. No main focus point. | 40 | 67.57 | 109.82 | 28.21 | 6.64
roller- coaster |  Fast moving camera attached to roller coaster. Main focus on rail. | 40 | 104.61 | 116.21 | 34.44 | 9.25
Figure 6. Average tile quality of the used video popularity traces for three
different qualities. Brighter $\equiv$ more popular. The videos are encoded in
three quality levels. Here, 0 represents lowest quality. In all videos, the
center area (front) appears to be the most popular area. This is mainly
because when turning from one side to the other, viewers will most likely not
perform a full turn, but rather first turn their head to the front and then to
the other side, as this mimics their natural head movement. However, with
_rollercoaster_ a more distinct quality distribution is observable, with the
main focus point being the center area. This is expected, since the roller
coaster’s rail is visible in the front, which is what most viewers are
interested in viewing.

For preprocessing the videos, we transcode them with factors of 1, 0.25, and
0.0625 times the original bitrate, so that three quality levels exist per
video. The tiled videos are temporally segmented into 1.5 s parts since
typical segment lengths range between 1 s and 2 s (Xu et al., 2018; Qian et
al., 2016). Decreasing the segment length will lead to faster quality
adaptations to changing head orientations, as the tiles are updated more
frequently. However, shorter segment lengths may be more prone to sudden
throughput changes, as they have to be downloaded in a very short time. With
much longer segment lengths, viewport prediction becomes very inaccurate, up
to a point to where future head orientations are practically unpredictable.
After preprocessing the videos, popularity information is generated, using the
viewing traces available for each video. This information is added to the
videos’ respective MPD manifest files. Finally, the manifest and video files
are stored on a HTTP server’s file directory.

###  5.2. Preprocessing

To prepare a 360° video for our streaming system, it has to be spatially tiled
and temporally segmented. Finally, a DASH manifest file has to be generated.
We use _ffmpeg_ 888https://www.ffmpeg.org/ [Accessed: August 28, 2024] and
_MP4Box_ 999https://gpac.wp.imt.fr/mp4box/ [Accessed: August 28, 2024] to
accomplish that. We first crop a video in a fixed but arbitrary $n\times m$
grid pattern to generate the tiles. The cropped videos are saved in a fixed
but arbitrary number of versions $q$, all of them differing in bitrate. Each
tiled video of length $d$ is then temporally segmented, with an a segment
length $s$. The DASH standard introduces an initialization segment per video
stream. In total, including the manifest file, the preprocessing application
generates $n\cdot m\cdot
q\cdot\left(\left\lceil\frac{d}{s}\right\rceil+1\right)+1$ files. For a 40 s
video and a $4\times 4$ tiling pattern, three quality levels (cf. Section
5.1), and 1.5 s segment length, this amounts to 1345 files. Having to store
this many files for one single video can be avoided by using byte ranges.
Rather than saving temporal segments to individual files, using DASH byte
ranges, they are grouped in one coherent file. In this case, the manifest file
contains byte ranges for each segment (Stockhammer, 2011).

###  5.3. Caching

#### Cache Initialization

For most experiments, we use an intermediary cache between the server and the
client. Specifically, we assume a telco-owned rentable cache from which we use
a dedicated cache storage area per video. To construct a realistic steady-
state environment, we initialize the cache by first generating a random
permutation of a set of 30 randomly chosen viewing traces from (Corbillon et
al., 2017a) belonging to the video that is currently used for evaluation.
Note, this is the initial state at the simulation start but the cached content
can change during the simulation, e.g., by a changing tile popularity. In a
productive environment, the cached content caches dynamically depending on the
requested video tiles. However, we assume the content to converge to a steady
state soon after the first users have watched the video. Each viewing trace is
then sequentially used in a viewing simulation, which downloads the tiles in
qualities corresponding to their visibility depending on the head orientations
contained in a trace. The tiles in the center of the FoV are streamed in the
highest quality, while the non-visible tiles are streamed in the lowest
available quality (cf. Section 5.1).

Figure 7. Byte Hit Rate (BHR) when downloading the popularity trace of
different videos, averaged over 30 different experiments with 95% confidence
intervals.

#### Cache Replacement Policies

When a cache reaches its capacity limit, a policy is needed that decides which
files are evicted to create space for new requested content to be cached. To
this end, we evaluate each policy by measuring Cache Hit Rate (CHR) and Byte
Hit Rate (BHR) when downloading a video’s popularity trace. This represents
how the cache contents match our popularity trace. We consider three
replacement policies101010http://www.squid-
cache.org/Doc/config/cache_replacement_policy/ [Accessed: August 28, 2024]:

  * •

Least Recently Used (LRU): Keeps the recently requested content in the cache.

  * •

Least Frequently Used with Dynamic Aging (LFUDA): Keeps popular contents in
the cache, regardless of its size, and thus optimizes BHR at the expense of
CHR since one large, popular object will prevent many smaller, slightly less
popular objects from being cached.

  * •

Greedy-dual Size Frequency (GDSF): Optimizes the CHR by keeping smaller
popular contents in the cache, so it has a higher CHR probability. It achieves
a lower BHR than LFUDA though, since it evicts larger (possibly popular)
contents.

First, we evaluate which cache eviction policy works best in conjunction with
our system using tile popularity-based quality adaptation. Furthermore, as
cache capacity has an impact on how each policy performs, we repeat this
process for a capacity range $C\in\\{20,40,60,80\\}$ MB. These cache sizes
were chosen with regard to the sizes of our preprocessed videos. Hence, we
mimic real-world caches which store on average a particular share of the video
content. For example, the cache can store from $12.5\%$ up to $50\%$ of the
160 MB _rollercoaster_ video. This helps us to make assertions on how cache
capacity settings should be determined based on individual video sizes.

To specify squid’s replacement policy and cache capacity, the
_cache_replacement_policy_ and _cache_dir_ configuration directives are used
inside the _squid.conf_ configuration file, respectively. For each policy and
cache size, _squid.conf_ is modified and squid is restarted to load the
modified settings. Then, the cache is initialized using the initialization
process described in the previous section. We measure CHR and BHR when
downloading the popularity trace of the current video by checking the _X-
Cache_ HTTP response header entry. As the cache varies in content after
initialization, this process is repeated 30 times. For each of these
iterations, the cache is initialized with a new viewing trace permutation.
Figure 7 depicts the average BHR measured over 30 iterations for varying cache
sizes. Overall, LFUDA achieves the best BHR, as the popularity of the entire
history of viewing traces is considered, instead of just the recently
downloaded ones, e.g., when using LRU.

For the _dive_ video and cache sizes 60 MB and 80 MB, GDSF also achieves a
high BHR. Note that GDSF tries to optimize CHR by preferring to cache smaller
files. Consequently, a high CHR can be reached at arbitrary cache sizes by
emphasizing to store all low quality tiles before considering popular high-
quality tiles. However, we argue that the BHR is a more valuable metric since
it directly reflects the amount of data traffic saved. LRU does not perform
well since it only adapts the cache status to recently requested files. Based
on these results, LFUDA is our choice for the following evaluations.

###  5.4. Prediction Accuracy

Figure 8. Prediction errors depending on prediction time $I$ and timeframe $T$
used to compute the linear regression model.

An accurate viewport prediction is needed to provide the viewer with high-
quality tiles within the FoV. We evaluate the prediction accuracy by measuring
the prediction error. This is done for each prediction interval
$I\in\\{0.5,1.0,1.5,2.0\\}$ seconds. For the predictions, we use a linear
regression model similar to Qian et al. (Qian et al., 2016) and Xu et al. (Xu
et al., 2018). Further, we choose the prediction interval to be equal to the
video segment length. Hence, the results imply how viewport prediction would
perform if an equivalent segment duration is chosen. Furthermore, we evaluate
which time frame length $T$ should be chosen to generate an accurate linear
regression model. When $T=1$, every head rotation sample collected within the
last second is used to compute the regression model, i.e., between 40 and 180
samples per second. Depending on the amount of samples, i.e., the time frames
chosen, the prediction accuracy might vary. As we use pre-recorded viewing
traces, the prediction error can be computed by comparing a predicted head
orientation with the actual head orientation contained in the trace at the
according timestamp. We represent the _difference_ between two orientations
using their orthodromic distance, defined as the shortest distance on the
surface of a sphere. We measure it in degrees, so the maximum distance between
two points is 180°. The data acquisition is done by iterating through a
viewing trace in $s$ second steps, with $s$ being the video segment length. In
each iteration, the head orientations of the last $T$ seconds are collected
and then passed to the prediction model, which computes a head orientation for
a future timestamp after $I$ seconds. Next, the orthodromic distance between
the predicted and actual orientation is computed. To get an average prediction
error per (I, T, video) tuple, all viewing traces available for a video are
combined.

Figure 8 presents our results. We observe that the prediction error correlates
with the prediction interval. The error increases the further into the future
a prediction is performed. This is expected, as viewers are likely to change
their head movement direction, and thus, deviating from the linear regression
model’s prediction. Further, the average errors computed on the
_rollercoaster_ video are noticeably lower than on the other two videos since
it has a distinct point of interest. Thus, it is likely that viewers will not
turn their heads as much as in other videos, making it easier to predict a
future orientation. Finally, the average errors created by varying timeframes
most often do not significantly differ. Only with a prediction interval of 0.5
s, the 0.1 s timeframe consistently yields a significantly superior result to
the 1 s timeframe. As a timeframe of 0.1 s always leads to an equal or lower
prediction error compared with larger prediction time invervals, it should be
used for prediction. Additionally, the computational effort involved in
fitting the regression model with fewer samples is lower. Note that a
prediction error as low as 10°-20° can be easily mitigated by requesting an
area that is slightly larger than the viewport itself (Qian et al., 2016).
However, as we can see from the evaluation results, prediction intervals of
1.5 s and longer lead to much higher prediction errors. Thus, ideally, segment
lengths of 1 s and lower should be chosen to guarantee high prediction
accuracy.

Figure 9. Bandwidth usage of multiple adaptation strategies while downloading
the _dive_ video.

###  5.5. Bandwidth Usage

Transferring only a set of video tiles in high quality lowers the bandwidth
required for video streaming compared to streaming the entire video in high
quality. In this section, we evaluate the effects on bandwidth usage when only
transferring sub-parts of 360° videos in the highest quality. To measure the
bandwidth used, the file size of every downloaded tile stream segment is
considered. Thus, the results depend on the quality levels in which the videos
are encoded. For data acquisition, we streamed each video multiple times and
measured the amounts of received bytes as explained in detail in the
following. First, all segments are downloaded in highest quality to represent
the naive approach. For the naive approach, we also benefit from cached
content, however, on a small hit rate compared to other video quality
selection approaches. Next, only the video tiles captured by the tile
popularity trace belonging to the current video are downloaded. Finally, 30
viewing traces are used to stream the video 30 times using viewport
prediction. As our transitioning scheme works by using either popularity or
prediction adaptation, the bandwidth used in a real environment would vary
between what is used by each of these mechanisms alone, depending on available
bandwidth and viewer head movement.

Figure 9 presents the results for the _dive_ video which is chosen as it is
more challenging to predict user head movements compared to the
_rollercoaster_ video. Observing the results, we see that both adaptation
mechanisms result in significantly less transferred data in comparison to the
naive approach. Further, we see that the popularity trace results in fair tile
qualities, as the bandwidth used to download it always lies within the range
of all _Prediction_ samples.

Figure 10. Distribution of segment-wise bandwidth savings compared to naive
streaming approach.

Figure 10 shows the distribution of segment-wise bandwidth savings of all
videos, represented as violin plots. From the width of the plots, which
represent frequency, we can tell that at the majority of times, transferred
data is reduced by 40% to 70%, depending on the video.

(a) a) (b)  (c) b) (d)  (e) c) (f)

Figure 11. Left: Network trace and corresponding client estimation. Right:
Share of viewers using popularity adaptation, while the rest uses prediction
adaptation. Top: test_trace, mid: TMobile-LTE-driving, bottom: Verizon-LTE-
driving. Figure 12. Distribution of stalling durations using viewers per
video.

###  5.6. Transitions and QoE

Our 360° video streaming system issues a transition if the bandwidth estimate
falls beyond a threshold that is determined by the currently selected tile
qualities from the _Prediction_ adaptation policy. Specifically, we determine
the threshold to be the bandwidth required to continue streaming the currently
requested video quality. For our evaluation, a dynamic network environment is
created by using recorded network traces from (Winstein et al., 2013) to adapt
the throughput between the server and the cache in a realistic manner. The
bandwidth between the cache, that we assume to be an edge cache, is not
throttled. To this end we used the Linux command _tc_
111111https://linux.die.net/man/8/tc [Accessed: August 28, 2024]. The traces
in use are _Verizon-LTE-short.down_ , _Verizon-LTE-driving.down_ and _TMobile-
LTE-driving.down_. The throughputs generated from _Verizon-LTE-short.down_
were scaled by 1.5 to cause more transitions, which is named _test_trace_. In
Figure 11, we show the three network traces and our system’s estimate on the
left, while the bandwidth traces in conjunction with the share of users using
popularity adaptation is shown on the right. The orange area behind the dashed
estimation lines represents the standard deviation of running the simulation
30 times. As this area is generally quite small, we can assume that the server
bandwidth throttling and the client’s estimation algorithms operate
consistently. As the client computes a bandwidth estimate only when a new
segment is about to be downloaded from the source, the estimation graphs are
far coarser than the actual network traces. This also leads to the estimate
seemingly lagging behind the real trace. This can be countered by estimating
the bandwidth more frequently (Wang et al., 2016), e.g., between every
downloaded tile. On the right side, we empirically indicate the probability of
a transition to popularity adaptation over the duration of the trace by a bar
at the x-axis. Here, a darker color indicates a higher transition probability.
These results comprise the measurements of 30 different viewing traces
downloading the _dive_ video, while the server throttled its throughput
according to the network trace used. If the same viewing trace was used in all
iterations, the results visible in the mentioned plots would be binary, i.e.,
either popularity or prediction adaptation would be used in all iterations at
a time. However, with different viewing traces, the bandwidth threshold
responsible for triggering transitions varies depending on the predicted tile
qualities.

####  5.6.1. Stalling Events

To evaluate the QoE of our streaming system, we first examine how effectively
stalling events are prevented. This is measured by the total duration of
stalling events occurring during the playback of a video. For the data
acquisition, the server throttles its throughput according to the _test_trace_
, as out of the three network traces, this one causes the most transitions
(cf. Figure 11 a). We repeated the experiment 30 times per video.

Additionally, in each iteration four different adaptation mechanisms were used
to download the videos. _PredictionBA_ uses the bitrate for Bandwidth
Adaptation instead of transitions to mitigate throughput drops. This acts as a
benchmark for our transition scheme, as this is the traditional strategy of
dealing with dynamic network conditions. As our scheme transitions between
prediction and popularity adaptation, these mechanisms were also executed and
measured separately to compare their individual stalling behavior. The results
are presented in Figure 12. We observe that all adaptation mechanisms benefit
from an increased cache size since this increases the chance of a requested
file being stored on the cache. As determined in Section 5.5, popularity
traces tend to have higher bandwidth requirements than prediction adaptation.
Nevertheless, popularity adaptation consistently achieves better results in
stalling duration than prediction adaptation, as a higher BHR is achieved.
Further, we can observe that the distribution of _Transition_ stalling
durations always lies between the corresponding distributions of _Popularity_
and _Prediction_. This is also an expected observation, since with transitions
we always use one of both mechanisms. In case of stable network conditions, a
_Transition_ distribution will converge towards either _Popularity_ or
_Prediction_. With small cache sizes, bitrate adaptation generally achieves
the best results. This is especially noticeable with the _rollercoaster_
video. To achieve a comparable result with our transition logic, the cache
needs to satisfy a capacity requirement that depends on the video size. If the
cache does not meet this requirement, bitrate adaptation should be preferred
over transitions, as minimum stalling is the most important requirement to
provide high QoE (TaghaviNasrabadi et al., 2017). To lower this threshold,
either a cache replacement policy that results in a cache state, which better
matches the segment popularities, or information about which files are
actually stored on the cache is needed. Thereby, popularity adaptation can
achieve a higher BHR with unaltered cache sizes, and thus, also reduce
stalling events. Summarizing, our _transition_ approach shows a stalling
performance between _prediction_ and _popularity_.

####  5.6.2. Video Quality

Next, we evaluate the effects of our scheme on video quality. Therefore, we
measure the average quality level of all tiles downloaded during an entire
video. As the videos are encoded in three quality levels, this value ranges
from 0 to 2. It is important to note that this does not represent the actual
quality displayed in the HMD. We chose not to measure this, as it would
require a human reaction to popularity adaptation, i.e., a reaction to when
only popular tiles are streamed in high quality, independent of head
orientation. An extensive user study would need to be conducted in order to
evaluate this metric. Nevertheless, the average overall quality does reflect
the benefits our streaming scheme has over traditional bitrate adaptation. The
results are depicted in Figure 13. We can observe that _Transition_ always
achieves a significantly higher average quality than _PredictionBA_. Quality
improvements of up to 80% can be observed, e.g., for nyc and test_trace.
Averaged over all videos and network traces, the quality gain amounts to
50.93%. The difference in quality decreases with network traces that have a
higher overall throughput. This is the case because _PredictionBA_ performs
fewer bitrate adaptations when such network traces are in use. Analogous to
the previous evaluation, _Transition_ always achieves results between what is
achieved by _Prediction_ and _Popularity_. Particularly, with the high
throughput network trace _Verizon-LTE-driving_ , _Transition_ converges
against _Prediction_ , as close to no transitions occur with these network
conditions.

Figure 13. Average tile quality per video segment over 30 experiments per
video. The y-axis denotes this quality in a range between 0 and 2, since 3
quality levels are available.

To conclude this section, we combine the previous measurements of video
quality and, additionally, the staling duration over the video playback for
_Transition_ and _PredictionBA_. Both of these aspects have a major impact on
QoE, and thus, Figure 14 illustrates how user-friendly both strategies
perform. To this end, we increased the cache size starting from 20 MB to 80
MB. Note that 80 MB amounts to about 50% of rollercoaster’s file size. At a
cache sizes larger than 40 MB, we observe a similar stalling distribution
between Transition and PredictionBA. PredictionBA achieves particularly good
results for a small cache size of 20 MB, since many predicted tiles overlap
with the popularity trace, as this video has a distinct focus point. With
larger sizes, Transition outperforms _PredictionBA_ , as only few predicted
tiles match the popularity trace. This applies especially for dynamic content
such as the _nyc_ video.

The three videos lead to the three visible density cores, from left to right:
rollercoaster, nyc, and dive. As minimum stalling durations and high video
quality are desired, an ideal distribution would be located at the bottom
right corner in each plot. The _Transition_ mechanism leads to higher stalling
durations than _PredictionBA_ with small cache sizes. This drawback disappears
with growing cache capacities, while video quality is always improved
significantly independent of cache size.

Figure 14. Distribution of stalling durations vs. segment qualities of
_Transition_ and _PredictionBA_ for _test_trace_ and all videos displayed in
order (rollercoaster,nyc,dive). Darker shades represent higher density.

##  6\. Discussion

In the following, we discuss some limitations of our system as well as ways to
mitigate these limitations:

_i)_ Our system does not consider that arbitrary _sensory-predicted_ tiles can
also be stored on the intermediary cache system. Therefore, transitions might
occur too soon, as predicted tiles can be still fetched sufficiently fast,
despite the slow server link. To mitigate this, predicted tiles can be matched
with the popularity trace. Assuming these matching tiles being stored on the
intermediary cache, these tiles can be considered separately when computing
the required bandwidth.

_ii)_ Stalling events can occur when not enough data is fetched directly from
the cache whilst popularity adaptation is active. This can happen when the
intermediary cache does not dedicate enough capacity to store frequently
requested content. This issue can hardly be avoided, since we do not know
which tiles are stored at the cache. Popularity-based adaptation only gives us
an indication about which tiles are _likely_ to be stored at the cache.

_iii)_ The bandwidth requirements provided by the manifest file do not refer
to individual tile segments, but to entire tiled video streams. This results
in inaccurate estimates for the next segment’s bitrate, as segments of a video
differ in file size. A solution to this problem would be to add the bitrate of
each tile segment to the manifest file.

_iv_ To access the Quality of Experience (QoE) of the users, a user study is
desirable but out of scope for this paper. A key research question for such a
study is how the _guided view_ impacts the users’ QoE.

Despite these weaknesses, our transition system improves the performance
compared with bitrate adaptation, given that the cache’s capacity equals or
exceeds a minimum size.

##  7\. Conclusion and Future Work

This paper presents a 360° video streaming system that is able to transition
between video quality adaptation strategies depending on the available
bandwidth. To this end, we consider a cache being placed between the content
origin and the client, e.g., by a CDN or an edge cache operated by the
Internet provider. We demonstrate that the system improves the average video
quality by 50.93% in comparison to a bitrate adaptive scheme. In scenarios
with low network throughput and appropriate caching, up to 80% higher video
quality was measured. We showed in our experiments that the presented system
achieves the highest byte hit rates with the cache eviction policy LFUDA -
Least Frequently Used with Dynamic Aging. Independent of cache size and
network conditions, our system consistently offers significantly higher video
quality. Additionally, our system reduces the bandwidth consumption between
40% and 70% in comparison to basic streaming approaches. In future work, we
plan to extend our system by making the client aware of the cache’s long-
living hot contents (Bhat et al., 2018) and assess the benefit of proactive
caching (Koch, 2018) for our system. Additionally, we will address how so
provision the cache in oder to minimize stalling events given a specific
average video target quality. Further, we plan to incorporate multiple
popularity traces per video to use them to classify users considering the
regions in the videos which they are most interested in.

###### Acknowledgements.

This work has been funded by the German Research Foundation (DFG) as part of
the projects C3 and B4 in the Collaborative Research Center (SFB) 1053 MAKI.

## References

  * (1)
  * Akamai (2017) Akamai. 2017.  Q1 2017 State of the Internet - Connectivity Report.  https://goo.gl/jQtFLg.
  * Bao et al. (2016a) Yanan Bao, Huasen Wu, Albara Ah Ramli, Bradley Wang, and Xin Liu. 2016a.  Viewing 360 Degree Videos: Motion Prediction and Bandwidth Optimization. In _IEEE International Conference on Network Protocols (ICNP)_. 1–2.
  * Bao et al. (2016b) Yanan Bao, Huasen Wu, Tianxiao Zhang, Albara Ah Ramli, and Xin Liu. 2016b.  Shooting a Moving Target: Motion-prediction-based Transmission for 360-degree Videos. In _IEEE International Conference on Big Data (Big Data)_. 1161–1170.
  * Bhat et al. (2018) Divyashri Bhat, Amr Rizk, Michael Zink, and Ralf Steinmetz. 2018\.  SABR: Network-Assisted Content Distribution for QoE-Driven ABR Video Streaming.  _ACM Transactions on Multimedia Computing, Communications, and Applications (TOMM)_ 14, 2s (2018), 32.
  * Chakareski (2017) Jacob Chakareski. 2017\.  VR/AR Immersive Communication: Caching, Edge Computing, and Transmission Trade-Offs. In _ACM Workshop on Virtual Reality and Augmented Reality Network (VR/AR Network)_. 36–41.
  * Chakareski et al. (2018) Jacob Chakareski, Ridvan Aksu, Xavier Corbillon, Gwendal Simon, and Viswanathan Swaminathan. 2018\.  Viewport-Driven Rate-Distortion Optimized 360° Video Streaming.  _arXiv preprint arXiv:1803.08177_ (2018).
  * Corbillon (2017) Xavier Corbillon. 2017\.  360Degree Head Movement Dataset.  https://github.com/xmar/360Degree_Head_Movement_Dataset.
  * Corbillon et al. (2017a) Xavier Corbillon, Francesca De Simone, and Gwendal Simon. 2017a.  360-Degree Video Head Movement Dataset. In _ACM Conference on Multimedia Systems (MMSys)_. 199–204.
  * Corbillon et al. (2017b) Xavier Corbillon, Gwendal Simon, Alisa Devlic, and Jacob Chakareski. 2017b.  Viewport-Adaptive Navigable 360-Degree Video Delivery. In _IEEE International Conference on Communications (ICC)_. 1–7.
  * El-Ganainy and Hefeeda (2016) Tarek El-Ganainy and Mohamed Hefeeda. 2016.  Streaming Virtual Reality Content.  _arXiv preprint arXiv:1612.08350_ (2016).
  * Fan et al. (2017) Ching-Ling Fan, Jean Lee, Wen-Chih Lo, Chun-Ying Huang, Kuan-Ta Chen, and Cheng-Hsin Hsu. 2017\.  Fixation Prediction for 360 Video Streaming in Head-Mounted Virtual Reality. In _ACM Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV)_. 67–72.
  * Frömmgen et al. (2015) Alexander Frömmgen, Björn Richerzhagen, Julius Rückert, David Hausheer, Ralf Steinmetz, and Alejandro P. Buchmann. 2015\.  Towards the Description and Execution of Transitions in Networked Systems. In _IFIP International Conference on Autonomous Infrastructure, Management, and Security, AIMS_. 17–29.
  * Graf et al. (2017) Mario Graf, Christian Timmerer, and Christopher Mueller. 2017\.  Towards Bandwidth Efficient Adaptive Streaming of Omnidirectional Video over HTTP: Design, Implementation, and Evaluation. In _ACM Conference on Multimedia Systems (MMSys)_. 261–271.
  * Harrison (2003) Lynn Thomas Harrison. 2003\.  Basic 3D Objects.  In _Introduction to 3D Game Engine Design Using DirectX 9 and C#_. Springer, 113–166.
  * Koch (2018) Christian Koch. 2018\.  _Proactive Mechanisms for Video-on-Demand Content Delivery_.  Dissertation. Technische Universität Darmstadt.  https://tuprints.ulb.tu-darmstadt.de/8212/
  * Kuzyakov and Pio (2016) Evgeny Kuzyakov and David Pio. 2016.  Next-generation Video Encoding Techniques for 360 Video and VR.  https://goo.gl/XzYK3M.
  * Nasrabadi et al. (2017) Afshin Taghavi Nasrabadi, Anahita Mahzari, Joseph D Beshay, and Ravi Prakash. 2017.  Adaptive 360-Degree Video Streaming using Scalable Video Coding. In _ACM Conference on Multimedia (MM)_. 1689–1697.
  * Nguyen et al. (2017) Duc V Nguyen, Huyen TT Tran, Anh T Pham, and Truong Cong Thang. 2017.  A New Adaptation Approach for Viewport-adaptive 360-degree Video Streaming. In _IEEE International Symposium on Multimedia (ISM)_. 38–44.
  * Niamut et al. (2016) Omar A Niamut, Emmanuel Thomas, Lucia D’Acunto, Cyril Concolato, Franck Denoual, and Seong Yong Lim. 2016\.  MPEG DASH SRD: spatial relationship description. In _ACM Conference on Multimedia Systems (MMSys)_. 5\.
  * Petrangeli et al. (2017a) Stefano Petrangeli, Filip De Turck, Viswanathan Swaminathan, and Mohammad Hosseini. 2017a.  Improving Virtual Reality Streaming using HTTP/2. In _ACM Conference on Multimedia Systems (MMSys)_. 225–228.
  * Petrangeli et al. (2017b) Stefano Petrangeli, Viswanathan Swaminathan, Mohammad Hosseini, and Filip De Turck. 2017b.  An HTTP/2-Based Adaptive Streaming Framework for 360 Virtual Reality Videos. In _ACM Conference on Multimedia (MM)_. 306–314.
  * Qian et al. (2016) Feng Qian, Lusheng Ji, Bo Han, and Vijay Gopalakrishnan. 2016\.  Optimizing 360 Video Delivery over Cellular Networks. In _ACM Workshop on All Things Cellular: Operations, Applications and Challenges_. 1–6.
  * Stockhammer (2011) Thomas Stockhammer. 2011\.  Dynamic Adaptive Streaming over HTTP – Standards and Design Principles. In _ACM Conference on Multimedia Systems (MMSys)_. 133–144.
  * TaghaviNasrabadi et al. (2017) Afshin TaghaviNasrabadi, Anahita Mahzari, Joseph D Beshay, and Ravi Prakash. 2017.  Adaptive 360-Degree Video Streaming using Layered Video Coding. In _IEEE Virtual Reality (VR)_. 347–348.
  * Wang et al. (2016) Cong Wang, Amr Rizk, and Michael Zink. 2016.  SQUAD: A Spectrum-based Quality Adaptation for Dynamic Adaptive Streaming over HTTP. In _ACM Conference on Multimedia Systems (MMSys)_. 1–12.
  * Winstein et al. (2013) Keith Winstein, Anirudh Sivaraman, Hari Balakrishnan, et al. 2013\.  Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks. In _USENIX Conference on Networked Systems Design and Implementation (NSDI)_ , Vol. 1. 2–3.
  * Xie et al. (2017) Lan Xie, Zhimin Xu, Yixuan Ban, Xinggong Zhang, and Zongming Guo. 2017.  360ProbDASH: Improving QoE of 360 Video Streaming Using Tile-based HTTP Adaptive Streaming. In _ACM Conference on Multimedia_. 315–323.
  * Xu et al. (2018) Zhimin Xu, Xinggong Zhang, Kai Zhang, and Zongming Guo. 2018\.  Probabilistic Viewport Adaptive Streaming for 360-degree Videos. In _IEEE International Symposium on Circuits and Systems (ISCAS)_. 1–5.
  * Zare et al. (2016) Alireza Zare, Alireza Aminlou, Miska M Hannuksela, and Moncef Gabbouj. 2016.  HEVC-compliant tile-based Streaming of Panoramic Video for Virtual Reality Applications. In _ACM Conference on Multimedia Systems (MMSys)_. 601–605.