An adaptive method for low-delay 360 VR video
streaming over HTTP/2
Dang H Nguyen∗ , Minh Nguyen∗ , Nam Pham Ngoc∗ , Truong Cong Thang
∗ Hanoi university of Science and Technology, Hanoi, Vietnam
† The University of Aizu, Aizu-Wakamatsu, Japan
Abstract—Virtually Reality (VR) technology, especially 360
VR videos, is currently a hot topic thanks to its immersive
experience, compared to traditional multimedia applications,
such as allowing users to experience a close real life by panoramic
view. Nevertheless, 360 VR video transmission consumes a huge
bandwidth. Besides, how to reduce the delay of 360 VR video
streaming is another problem. To address these two challenges,
in this paper, we introduce an efficient adaptive 360 VR video
streaming method over HTTP/2 using stream priority and stream
termination features. To support adaptivity, a 360 VR video is
divided into multiple faces and each face is chunked into temporal
segments. The video is also stored at the server with different
levels of quality. In our method, we focus on the low delay
scenario and thus all faces are downloaded simultaneously by
using priority feature of HTTP/2 and the client decodes them
based on the Group of Pictures (GOP). If the bandwidth suddenly
drops, the client will break the simultaneity and inform the
server to push consecutively the faces based on their priorities.
In addition, stream termination feature can be used to terminate
the media parts, which will miss the deadline. The experimental
results show that, when the initial buffer is set to 0.5s, there is
only 0.08% of the number of GOPs in the front face that miss
the deadline in our proposed method, compared to the values of
0.75% and 3.34% of two reference methods.
Index Terms—VR video streaming, HTTP/2, Virtual reality,
HTTP Adaptive Streaming, stream priority, stream termination.
I. I NTRODUCTION
Recent years has been witnessing a remarkable rise in
the commercial progress of VR technology. It reached USD
1.37 billion in 2015 and is expected to grow to USD 33.90
billion in 2022 [1]. People now can use head-mounted displays
(HMDs) such as Samsung Gear VR, HTC Vive, and Facebook
Oculus and then freely adjust their head orientation to watch
panoramic views on the 360 VR videos. Based on the user’s
orientation and the field of view (FoV), those HMDs display
the visible area on the screen. The FoV now is limited around
to 90o both horizontally and vertically [2].
A major challenge in VR video streaming is its high
bandwidth requirement. 360 VR videos need encoding at least
at 4K resolution to meet the acceptable quality of viewing
experience [3]. The reason is that while the whole video is in
4K, the FoV is only one-fifth or sixth of that resolution and the
users just watch nearly 720P video content. As a consequence,
such streaming requires four to five times bandwidth compared
to the traditional one [4]. According to Netflix [5], in order
to stream videos in 4K resolution, the download speed should
achieve at least 25 Mbps. However, the global mobile network
†
connection speed was only 8.7 Mbps in 2017 and will be 20.4
Mbps in 2021 [6].
Recently, a new version of HTTP protocol was proposed
in May 2015, called HTTP/2, intended as a higher perfor-
mance alternative to HTTP/1.1 [7]. It introduces new features
including server push, stream priority, and stream termination.
Server push enables the client to receive multiple objects by
sending only one request. The stream priority feature allows
the client to request the server to spend more resources to push
data in one stream rather than others. Also the streams can be
terminated if the client sends a RST STREAM frame to enable
stream termination feature.
Although 360 VR video is getting much attention in the
research community, streaming of this state-of-the-art video
is now deployed by simply sequentially streaming tiles in a
scene after choosing bitrate for them [14] [15] [17]. Most of
the current approaches are based on HTTP/1 and have not been
adequately evaluated in the literature. Among existing studies,
our previous study in [9] is the first one that exploits the use
of new features of HTTP/2. In this study, the tiles in the same
region are downloaded sequentially, so the client needs to wait
for all those tiles to render the whole region, which results in
high initial delay.
In this paper, a new adaptive streaming method over HTTP/2
is proposed to tackle the aforementioned issues. We focus
on improving the QoE. The QoE can be estimated based on
the initial delay, mean rebuffering duration, and rebuffering
frequency [24]. To decrease the initial delay, the tiles are
encoded by closed GOPs. Using the stream multiplexing and
stream priority features, we guarantee that the same-index
GOPs of all tiles are received at the client at the same
time. We also use priority and termination features to cope
with bandwidth fluctuation for the purpose of minimizing
rebuffering frequency.
In our method, the general process to request the media part
is as follows. First, the client chooses the bitrate for each tile
based on the relative position and the FoV. Second, the client
sends multiple requests at one time to receive simultaneously
tiles from the server. The stream priority is used to control
the time each tile arrives at the client. This feature enables the
client not only to set the expected resource ratio to download
concurrently each tile but also to receive a tile after completely
downloading another. In the case of the sudden bandwidth
drop, the client possibly uses a RST STREAM frame to request
the server to stop sending the late tiles. Experimental results
in variable bandwidth conditions show that our method is
effective with less number of miss-deadline GOPs than other
reference methods when the bandwidth dramatically decreases.
The rest of the paper is organized as follows. In Section II,
we give an overview of video streaming over HTTP/2 and the
related work. Section III presents our proposed method. The
experimental results and discussions are given in Section IV.
Finally, Section V concludes this paper.
II. R ELATED WORK
A. 360 VR streaming
Recently, 360 VR tile-based streaming is considered as
a prospective solution to the problem of high bandwidth
requirement, in which the videos are divided into several
tiles by HEVC/H.265 standard [12] [13]. In order to support
adaptive streaming, every tile is encoded at many quality levels
which are partially split into multiple segments. It should
be noted that the tiles covering a panoramic view can be
encoded and decoded independently. Fig. 1 illustrates the
architecture of a 360 VR tile-based streaming system. Based
on the predicted viewport and bitrate adaptation method, the
client sends requests to the server, receives tiles, and stores
them in the buffer for decoding.
8/3/2018
Encoding &
Packaging
D pr
iff es
re
er e
en nt
t q ati
ua on
lit s
y
Internet
HTTP Server
Fig. 1: 360 VR streaming system architecture
There have been many tile-based adaptive streaming meth-
ods proposed [14]–[17]. Petrangeli et al. [14] use H.265 to
partially divide the video and HTTP/2 to avoid a large number
of requests due to tiling. In this approach, the lowest quality
level is firstly chosen for all tiles. Afterwards, the client
updates the available bandwidth and allocates it to a group
of tiles with the highest possible quality level. This process is
repeated until the client runs out of bandwidth. Only k-push
approach of HTTP/2 is used in their method without stream
priority and stream termination feature. Like the first step of
Petrangeli, the proposed method of Feuvre et al. [15] assigns
the lowest level for all tiles in the beginning. However, they
increase step-by-step the quality level of the tiles with higher
priorities and receive the tiles sequentially from the server.
M. Graf et al. [16] propose two streaming strategies which
are Partial delivery and Full delivery. The Partial delivery
strategy only downloads the visible tiles with the highest
possible version which results in black view when the viewport
is not predicted accurately. Meanwhile, in the Full delivery
chrome-extension://pebppomjfocnoigkeepgbmcifnnlndla/index.html
strategy, the tiles outside of the viewport are assigned the
lowest quality level and the rest the highest possible quality.
However, each request is used to download only one single
tile which easily results in the network overhead because
there are a large number of tiles in a panoramic view. A live
streaming system for Omnidirectional Video is introduced by
Ochi et al. [17] in which two tiles covering the whole view
are requested. A so-called interesting tile covering the FoV is
requested by the client with higher quality version whereas an
image tile covering the whole panoramic view is automatically
pushed to the client with a lower quality. This approach can
tackle the network overhead by using only one request, but
downloading only one interesting tile for the viewport may still
consume much bandwidth budget. Mariem Ben Yahia et al. in
[25] propose an approach using the priority and termination
features of HTTP/2 to request video data at the frame level.
In their study, the priority feature is used to arrange the video
frames following the GOP structure. They also increase the
priority weights of the most important video frames, so it helps
increase the probability that these frames could be decoded and
rendered on time. Besides, by using the termination feature,
the client is able to terminate frames which is less important
or has no chance to arrive on time. However, they do not give
draw.io the detailed algorithm about termination and priority weight
assignment. The use of each HTTP/2 stream for delivery only
one video frame might lead to network overhead because there
are a lot of streams needed to open per second.
In this paper, we focus on the delivery of the 360 VR video
Decoding & using multiplexing, stream priority, and stream termination
Display
features of HTTP/2, rather than the viewport prediction and
the decoding. Additionally, for low delay, the number of GOPs
in the buffer will be considered instead of the number of
segments like in prior work [18]–[21].
HTTP Client
B. HTTP/2 Prioritization and termination
R. Huysegems et al. demonstrate several features of HTTP/2
including multiplexing and server push [8]. However, recently,
much research on server push in video streaming has been
done, whereas multiplexing has not been considered. By
multiplexing, HTTP/2 enables multiple data streams to be
transmitted on a single TCP connection. These streams are
distinguished by their data type, the importance, and their
data size. The priority feature of HTTP/2 enables the server
to allocate its resources based on the priority level of each
stream. The client assigns the priority level of a new stream
by inserting priority information including stream dependency,
and priority weight in the stream’s header. The stream depen-
dency of a stream indicates the other stream that must be
allocated resources ahead this stream. The streams that are
dependent on the same stream should be allocated resources
in proportion to their priority weight. It should be noted that
the priority weight value is an integer number from 1 to 256.
The client could change the priority information by sending
PRIORITY frame at any time.
Besides, HTTP/2 also provides termination feature via
RST STREAM frame. By sending this type of frame, the
1/1
client or the server is able to terminate the referenced stream. client at the same time, we set the priority weight of each
However, the sending peer must receive additional DATA HTTP/2 stream of tiles to satisfy the condition: the weight
frames of terminated stream sent by remote peer before the parameters of tiles are proportional to their bitrates. However,
arrival of the RST STREAM frame. in decrease case, all the tiles of (K − 1)th region are assigned
the priority weight of 1. The priority parameters allocation
III. P ROPOSED METHOD
algorithm is presented in Algorithm 1.
A. Priority parameters allocation
The set priority() function is used to set the priority param-
eters for each request. There are two parameters needed to be
TABLE I: Notations used in this paper
assigned which are stream dependency, and priority weight
Symbol Description with their meaning mentioned in Section 2. In Algorithm 1,
SD Segment duration we set the stream dependency of all streams as the stream id
GD Total duration of all frames in a GOP
βinit Initial buffer of an idle stream which is not used to transport any user data.
Ri Region ith of video view
NiR The number of tiles in region ith
K The number of regions B. Reprioritization and Stream termination
τkj Tile j th of region kth
wi Priority weight of region ith When the client is downloading a segment, the sudden band-
ri Rate of region ith width drop is unpredictable. This might result in rebuffering
Tiest Estimated throughput of segment ith
Tis Smoothed throughput of segment ith
because there are a lot of tiles to be transported concurrently
Tinst Instant throughput and we could not guarantee that all GOPs will be decoded
tinst Instant download time of the current segment before the deadline in a poor network condition. To cope with
Dinst Instant data size downloaded of the current segment
this problem, the more important tiles will be downloaded
dGOP (τkj ) GOP data length of tile τkj of the current segment
before the remaining tiles and they could get entire network
In our proposed method, a video view will be divided into resources. In the worst case, some GOPs of important tiles
K regions: {Ri | i = 1, 2, ..., K}. The tiles in a region have could be received at the client to display. We divide tiles into
the same bitrate, and the smaller i value is, the higher the two sets denoted as Ω1 and Ω2 . Ω2 is a set of tiles which
importance of the region is. The rate allocation algorithm must be temporarily frozen until all of the tiles in Ω1 are
used in this paper is the same as our previous work in [9]. downloaded completely. In the case where wK−1 = 1, we set
We consider two cases to decide the estimated throughput: the initial value of Ω2 as the whole (K − 1)th region. When
increase case and decrease case. In the first case, when a segment is being transported, a tile in Ω1 is able to move
the bandwidth tends to grow, the estimated throughput is to Ω2 if the condition |Ω1 | ≥ N0R is met after the movement.
calculated by smoothed throughput method [10] [11] as (1) With each switched tile, a PRIORITY frame will be sent by
to avoid the short-term fluctuations of the network. In the the client with the stream dependency being set to the stream
decrease case, to cope with the decrease of the bandwidth, the id of any tile in R0 .
throughput of the last segment is considered as the estimated
throughput. Algorithm 2 Change stream dependency
Dinst
(
s
s
(1 − γ) ∗ Ti−1 + γ ∗ Tiavg if i > 0. 1: Tinst ← ;
Ti = (1) tinst
Tiavg otherwise. 2: while true do
3: if |Ω1 | ≤ N0R then
Algorithm 1 Priority parameters allocation 4: return;
1: for k = 0 → K − 1 do 5: Nmiss ← 0;
2: if k == 0 then 6: for each τkj ∈ Ω1 do
SD
3: wk ← 256; 7: for g 0 = g + 1 → d e do
GD j
4: else 8: e 0
calculate tGOP (i, g , τk );
inst
5: if Ti−1 > Tiinst and k == K − 1 then 9: if teGOP (i, g 0 , τkj ) > tdGOP (i, g 0 , τkj ) then
6: wk ← 1; 10: Nmiss ← Nmiss + 1;
7: else SD
rk 11: if Nmiss > α × |Ω1 | × d e then
8: wk ← d256 ∗ e; GD
r0 j
12: select τk ;
9: for j = 0 → NkR − 1 do 13: Ω1 ← Ω1 \{τkj };
10: set priority(stream dependency, wk ); 14: Ω2 ← Ω2 ∪ {τkj };
11: send a request for tile τkj ;
15: send a PRIORITY frame for tile τkj ;
16: else
Table I provides some notations used in the following
17: return;
discussion. To guarantee that all the tiles will arrive at the
 We denote taGOP (i, g, τkj ) and tdGOP (i, g, τkj ) as the arrived
time and display deadline of g th GOP of tile τkj of ith segment,
respectively. A GOP is only decoded and displayed if:
taGOP (i, g, τkj ) ≤ tdGOP (i, g, τkj ). (2)
with
tdGOP (i, g, τkj ) = βinit + SD ∗ i + GD ∗ g. (3)
After receiving g th GOP of ith segment completely, the Time (s)

client is able to predict the received time of g 0th GOP

with g 0 > g of current segment denoted by teGOP (i, g 0 , τkj ) Fig. 3: The bandwidth used in experiments
calculated as the equation (4).
0
(g 0 − g) ∗ DGOP (τkj0 ) face instead of tile. We have three regions (K = 3) and
P
0
∀τkj0 ∈ΩI because of focusing on the video transmission, we assume that
teGOP (i, g 0 , τkj ) = taGOP (i, g, τkj )+ . user does not move his/her head when watching the video.
the
Tinst
(4) Region 1 contains only the front face (face 0), region 2 con-
with ( tains 4 faces surrounding the viewport and the last region has
Ω1 if τkj ∈ Ω1
ΩI = j (5) only the back face (face 5). Each face is divided into temporal
Ω2 if τk ∈ Ω2 segments with the duration of 5s (SD = 5s) and with bitrate
versions in the set {133, 167, 250, 333, 500, 667, 833, 1000}
The details of the reprioritization algorithm is presented in Kbps. The client will start to play out only if its buffer contains
Algorithm 2 with Nmiss is the total number of GOPs which at least 6 GOPs of each face. It means the initial buffer is 1s.
are predicted to miss the deadline. This algorithm is executed After that, the client decodes and renders every 1/6s.
every time the client receives a GOP in Ω1 . A tile τkj , of which The remaining parameters in algorithms are set below: γ =
the stream dependency will be changed is randomly selected 0.125 as recommended in [22] and α = 1 . The bandwidth
6
among the tiles that meet the following condition. used in our experiments as illustrated in Fig 3 is obtained
τkj ∈ Ω1 and k index in τkj is maximum (6) from a mobile network [23].
Besides, the client only terminates several tiles in Ω2 if it B. Experimental results
has received all tiles in Ω1 . Tile τkj will be terminated if all In this section, the proposed method, called priority &
of its teGOP (i, g 0 , τkj ) values are greater than tdGOP (i, g 0 , τkj ). termination, will be compared with two other methods, which
The client handles that by sending the RST STREAM frames are none priority, called none priority and priority without
for streams delivering terminated tiles. termination, called priority. In this paper, we focus on the
/3/2018 draw.io ability to avoid rebuffering instead of focusing on comparing
IV. E XPERIMENTAL RESULTS AND DISCUSSION the received bitrate among methods. Consequently, the same
A. Experiment settings bitrate assignment algorithm will be used for all methods.
The testbed system has three components: the client, the The comparison in the number of GOPs of each face in
server, and IP network (Fig. 2). Both the client and the server every method is given in Fig. 4. It shows that two methods us-
use open source nghttp2 [26] running on Ubuntu 14.04 LTS. ing priority feature treat faces more equally than none priority
To control the network condition, Dummynet tool is installed method. From Fig 4a, it can be seen that because the client
at the client with the RTT set to 50ms. does not use priority feature, the number of GOPs in face 5 are
much higher than the other faces while face 5 is not visible.
The reason is that in this case, the server treats each data
DummyNet
stream equally, so with the lowest segment bitrate, face 5 can
IP Networks be transmitted with the highest number GOPs compared to the
faces in R1 and R2 in the same period of time. In addition, the
HTTP Client number of GOPs of face 0 decreases dramatically to around
HTTP Server
0 GOP in the buffer in the period of time from 73.251s to
Fig. 2: Testbed architecture 75.819s.
On the other hand, the methods using priority feature as
The video in our experiment uses the cube map projection, shown in Fig. 4b and 4c have almost the same number of
in which the frame rate is 30fps and the GOP size is 5 .The GOPs of each face. An important advantage of these methods
content is encoded by HEVC standard using FFmpeg. The is that the number of GOPs of face 0 in the buffer does not
length of the video is 400s. A video view is divided into 6 tiles reduce suddenly when the bandwidth drops as in Fig 5 at 71s.
corresponding to 6 faces. In this section, we use the concept In this case, when the client perceives the falling trend of the
bandwidth, it will send PRIORITY frames to set the stream of
face 0 as the parent stream of the less important faces, which
means that the download streams of these faces are temporarily
frozen to save the bandwidth for the stream of face 0. The
advantages of termination feature can be seen in Fig. 4c, the
termination of useless GOPs saves the bandwidth to download
face 0 of the next segment. As a result, the number of GOPs
of face 0 stays at a high value and only reaches the lowest
point of 1 GOP at 76.267s.
Time (s)
(a) none priority method.
Time (s)
(b) priority method.
Time (s)
(c) priority & termination method.
Fig. 4: The number of GOPs in each face of three methods
Fig. 5 compares the number of GOPs in face 0 received by
the client in three cases. It can be seen that when the bandwidth
falls, there is a significant decrease in the number of GOPs
(from 7 GOPs at 71s to 0 GOP at 75s) if the client does not
use the priority feature. On the contrary, the other two methods
give better and similar results in which the figures keep nearly
unchanged around 8 GOPs and decrease to 4 GOPs at 75s.
In addition, in the priority method, there is not any GOP of
face 0 for 3 times at 76.069s, 76.264, and 76.431s. And there
are always GOPs of this face in the priority & termination
method, whereas the number of times that the none priority
method lacks GOP of face 0 is 13.
Time (s)
Fig. 5: The number of GOPs in the front face of three methods
Fig. 6: The average ratio of number of GOPs in other faces
to the front face
For the accuracy, each method is run 10 times and the result
is the average value. Fig. 6 illustrates the average ratio between
the number of GOPs of faces (1-5) and the number of GOPs
of face 0 at the client which is counted at each display time.
It should be noted that we only consider the cases where the
number of GOPs in face 0 is more than 0. In general, this
ratio in none priority method is higher than others and almost
exceed 200%, especially the ratio of face 5 is around 315%,
that causes bandwidth waste. In contrast, two methods using
the priority feature obtain a better result with around 100%
for faces from 2 to 4 and 70% for face 5. Therefore, the client
can decode and render the GOPs before the deadline and does
not waste bandwidth for downloading unimportant GOPs.
In this paper, we also consider the effect of the initial buffer
to the results of our method. The experiments of three methods
with three different initial buffer values: 0.5s, 1s, 2s is also
performed. Fig. 7 shows the ratio between the number of
missed GOPs of face 0 and the total number of GOPs of
the whole video. It is clear that the termination and priority
features bring the impressive results. The missed GOPs ratio
of none priority method is much higher than that of the other
methods. These ratios in priority method are 0.06%, 0.42%
and 0.75% for the initial buffer 0.5s, 1s, 2s, respectively. In
priority & termination method, this ratio is approximately 0

Fig. 7: The percentage of miss-deadline GOPs in the front
face of three methods with different initial buffer values
for all initial buffer values. This advantage is crucial for low
delay context.
V. C ONCLUSION
In this paper, we have proposed a new tile-based streaming
for 360 VR video, where tiles are downloaded concurrently,
that enables the client to decode and display video as long as [15] J. Le Feuvre, C. Concolato, “Tiled-based adaptive streaming using
at least a certain number of GOPs of all tiles are received.
In addition, a new streaming system with low buffer helps to [16] M. Graf, C. Timmerer, and C. Mueller, “Towards Bandwidth Efficient
minimize initial delay when the priority and stream termina-
tion features of HTTP/2 are deployed in the client. The priority
weight assignment for each tile based on their bitrates enable [17] D. Ochi, Y. Kunita, A. Kameda, A. Kojima, S. Iwaki, “Live Streaming
the GOPs of all tiles to be received and decoded concurrently.
To cope with bandwidth fluctuation while streaming, stream [18] (VR),
dependency can be changed by sending PRIORITY frames
and the highly potential missed-deadline GOPs are terminated
when the client sends RST STREAM frames. The experimental
results obtained indicate that our proposed method is able to
reduce significantly the number of missed-deadline GOPs of
tiles covering the viewport and to balance the proportion of [20] D. V. Nguyen, H. T. Le, P. N. Nam, A. T. Pham, and T. C. Thang,
GOPs of tiles contained in the buffer.
R EFERENCES
[1] marketsandmarkets.com. (2017),“Virtual Reality Market by Compo-
nent (Hardware and Software), Technology (Non-Immersive, Semi-
& Fully Immersive), Device Type (Head-Mounted Display, Ges-
ture Control Device), Application and Geography - Global Fore-
cast to 2022”, Available at https://www.marketsandmarkets.com/
Market-Reports/reality-applications-market-458.html.
[2] H. T.T. Tran et al., “A Subjective Study on QoE of 360 Video for VR
Communication,” in Proc. IEEE MMSP2017.Luton, U.K, Oct. 2017.
[3] Visbit Inc., & Visbit Inc. (2016). “Virtual Reality (VR) and 360 Videos
101 - A Beginner’s Guide”. Available at https://medium.com/visbit/
virtual-reality-vr-and-360-videos-101-a-beginners-guide-70bbade8e39.
[4] S. Hollister, “Youtubes ready to blow your mind with
360-degree videos,” Available at https://gizmodo.com/
youtubes-ready-to-blow-your-mind-with-360-degree-videos-1690989402.
[8] R. Huysegems, T. Bostoen, P. Rondao-Alface, J. van der Hooft, S.
Petrangeli, T. Wauters, and F. D. Turck, “HTTP/2-based methods to
improve the live experience of adaptive streaming,” In ACM Multimedia
Conf. MM, 2015.
[5] Help Center. (2017), “Internet Connnection Speed Recommendations,”
Available at https://help.netflix.com/en/node/306.
[6] Statista, (2018), “Average global mobile network connection speeds from
2016 to 2021 (in Mbps),” Available at https://www.statista.com/statistics/
371894/average-speed-global-mobile-connection/.
[7] M. Belshe, R. Peon and M. Thomson, Hypertext Transfer Protocol
Version 2 (HTTP/2), RFC 7540, May 2015.
[9] Minh Nguyen, Dang H Nguyen, Cuong T Pham, Nam Pham Ngoc, Duc
V. Nguyen, and Truong Cong Thang, “An Adaptive Streaming Method
of 360 Videos over HTTP/2 Protocol,” In NAFOSTED Conference on
Information and Computer Science, 2017
[10] T. C. Thang, Q.-D. Ho, J. W. Kang, and A. Pham, “Adaptive streaming of
audiovisual content using MPEG DASH,” Consumer Electronics, IEEE
Transactions on, vol. 58, no. 1, pp. 7885, February 2012.
[11] S. Akhshabi, S. Narayanaswamya, A. C. Begen, and C. Dovrolisa,
“An experimental evaluation of rate-adaptive video players over HTTP,”
Signal Processing: Image Communication, vol. 27, no. 4, pp. 271287,
April 2012.
[12] M. Hosseini, V. Swaminathan, “Adaptive 360 VR video streaming:
Divide and conquer!,” in Proc. ISM2016,San Jose, CA, USA, 2016.
[13] P. Rondao Alface, J.-F. Macq, and N. Verzijp, “Interactive omnidi-
rectional video delivery: A bandwidth-effective approach,” Bell Labs
Technical Journal, vol. 16, no. 4, pp. 135-147, 2012.
[14] S. Petrangeli, F. De Turck, V. Swaminathan, and M. Hosseini, “Improv-
ing Virtual Reality Streaming using HTTP/2,” in Proc. of the 8th ACM
on Multimedia Systems Conference. ACM, 2017.
MPEG-DASH,” in Proc. of the 7th International Conference on Mul-
timedia Systems ser. MMSys 16, pp. 41: 1-41:3, 2016.
Adaptive Streaming of Omnidirectional Video over HTTP: Design, Im-
plementation, and Evaluation,” in Proc. of the 8th ACM on Multimedia
Systems Conference. ACM, 2017.
System for Omnidirectional Video,” in Proc. of IEEE Virtual Reality
2015.
H. T. Le, T. Vu, N. P. Ngoc, A. T. Pham, and T. C. Thang, “Seamless
mobile video streaming over HTTP/2 with gradual quality transitions,”
IEICE Transactions on Communications, vol. 100, no. 5, pp. 901909,
2017.
[19] D. V. Nguyen, H. T. Le, P. N. Nam, A. T. Pham, T. C. Thang, “Adapta-
tion method for video streaming over HTTP/2,” IEICE Communications
ExPress., vol. 5, no. 3, pp. 69-73, 2016.
“Request adaptation for adaptive streaming over HTTP/2”, in Proc.
of the IEEE International Conference on Consumer Electronics (ICCE
2016), pp.189-191, Jan. 2016.
[21] D. V. Nguyen, H. T. Le, P. N. Nam, A. T. Pham, T. C. Thang, “Adapta-
tion method for video streaming over HTTP/2,” IEICE Communications
ExPress., vol. 5, no. 3, pp. 69-73, 2016.
[22] V. Paxson, M. Alman, H.J. Chu, and M. Sargent, “Computing TCP’s
retransmission timer,” 2011.
[23] C. Muller, S. Lederer, and C. Timmerer, “An evaluation of dynamic
adaptive streaming over HTTP in vehicular environments,” in Proc.
ACM MMSys12, North Carolina, Feb. 2012.
[24] Ricky K. P. Mok, Edmond W. W. Chan, and Rocky K. C. Chang,
“Measuring the Quality of Experience of HTTP Video Streaming,” in
IFIP/IEEE International Symposium on Integrated Network Manage-
ment and Workshops, Dublin, Ireland, May. 2011.
[25] Mariem Ben Yahia, Yannick Le Louedec, Loutfi Nuaymi and Gwendal
Simon, “When HTTP/2 Rescues DASH: Video Frame Multiplexing,” in
IEEE Conference on Computer Communications Workshops, Atlanta,
GA, USA, May. 2017.
[26] nghttp2, https://github.com/nghttp2/nghttp2.