Hardware-Assisted, Low-Cost Video Transcoding Solution in Wireless Networks
Hardware-Assisted, Low-Cost Video Transcoding Solution in Wireless Networks
Hardware-Assisted, Low-Cost Video Transcoding Solution in Wireless Networks
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
Abstract—Wireless video streaming has become an extremely popular application in recent years. Internet video streaming to mobile
devices, however, faces several challenges, e.g., unstable wireless connections, long latency, high jitter and etc. Bitrate adaptive
streaming and video transcoding solutions are widely used to address the above-mentioned issues, however, there are still several
shortcomings of these approaches. Such challenges hinder providing satisfactory quality of video streaming service to the mobile users.
We propose a hardware-assisted, real-time video transcoding solution implemented on a commercial off-the-shelf device, Raspberry
Pi. We employ the software and hardware coupled architecture in order to improve the performance/quality of video streaming and
enhance the user satisfactions in wireless network. Our video transcoding solution can be applied to both the downlink and uplink
streaming: for downlink stream, it can provide agile bitrate adaptation to sudden network dynamics and enhance video quality by
running our transcoding solution at the wireless edge. It can be used to uplink stream for broadcasting live streams in real-time. We
present the design and implementation of our video transcoding system in both cases with practical scenarios. The evaluation results
reveal that our transcoding solution enhances the performance of video streaming compared with other adaptive bitrate streamings
and it provides higher video quality without causing rebuffering or video stall. We bridge the gap between the wireless channel capacity
and the video quality while providing a better streaming experience to end user.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
TABLE 1
Both HLS and DASH-dynamic use less than 60% of the
10
available bandwidth.
5
condition). The performance of video streaming over wireless
could be improved when it is serviced from the vicinity of the
0
0 20 40 60 80 100 AP due to the above reasons.
Time (sec) Bandwidth. The bandwidth utilization can be inferred by
selected video bitrates and the time duration of video seg-
Fig. 3. The adaptive steaming solutions under-utilize the ments. In other words, the area of bitrate plotted in Fig. 3
available bandwidth by selecting lower video bitrates. corresponds to the bandwidth utilization for each adaptive
scheme. We obtained the average bandwidth utilization of
HLS-remote, HLS-edge, and DASH-dynamic by repeating
and HLS conservatively under-utilize available bandwidth, and multiple runs with the same condition and summarized the
hence the user experiences a lower video quality (HLS-remote results in Table 1. It can be seen that both HLS and DASH-
selects lower video bitrate comparing to HLS-edge under the dynamic barely use about 60% of the network capacity. Again,
same network conditions). Such lower video quality could we confirm that the cloudlet (i.e., HLS-edge) improves HLS’s
have been improved, given that network bandwidth is much performance by 37% in terms of bandwidth utilization. We
higher than the selected bitrates. This observation corroborates can see that the selection of lower bitrate in turn leads to the
findings from prior researches that compare the performance under-utilization of given network capacity.
of several adaptive HTTP streaming players [12], [13]. Perhaps Thus, carefully selected video bitrates are indeed critical
one may argue that the client selects lower bitrates due to the for improving bandwidth utilization and to providing higher
unavailability of other bitrates, however, this may not be true. streaming quality to the users. In addition, providing video
For instance, the client could have picked a video segment of streaming at the wireless edge (AP) could help to improve the
6.5, 10 or 15 Mbps bitrate during 80-100 seconds while the quality of video streaming.
available bandwidth is around 17 Mbps, however, 3.5 and 10
Mbps were the highest bitrates selected by HLS-remote and 3.2 Rebuffering and Stall
HLS-edge, respectively.
In this section, we focus on how bitrate selection affects video
We notice that HLS and DASH-dynamic sometimes select
quality with respect to video freeze and rebuffering time. The
bitrates higher than the available network capacity. Such ag-
client player utilizes the buffer for storing video frames ahead
gressive selection causes significant amounts of time to freeze
of time in order to prevent stalls due to unexpected networking
the video during playback, resulting in poor video quality (we
changes and dynamics. Besides the network capacity, the
will elaborate in the next subsection). After a high selection,
player’s buffer occupancy is one of the factors for adaptively
DASH-dynamic lower the bitrate to the lowest (0.25 Mbps at
determining the bitrates of video segments when downloading.
71 second) even though it could adapt to higher bitrates. The
For instance, when the player’s buffer level is above the
main reason that both HLS and DASH-dynamic can not select
threshold, then the client chooses higher bitrates to provide
an appropriate bitrate is due to the behavior of their adaptation
a better video quality, whereas when the buffer is low, the
algorithm (inaccurate estimation, not able to detect network
client selects lower bitrates to fill the buffer up again. In this
changes, decision priority and etc.). One interesting observa-
sense, if bitrate decisions are not carefully managed based on
tion is that selected bitrates are higher when the client receives
buffer occupancy, then it could lead to unpleasant results such
video segments from the media server connected to AP (HLS-
as frequent stalls and long rebuffering times.
edge) than they are from the remote server (HLS-remote).
Buffer. We used the same HLS remote server and controlled
Higher bitrates could be beneficial for users because they
the network capacity at the AP in the same manner as
could provide a better streaming service. Note that HLS-edge,
described in the subsection 3.1. During the experiments, we
however, still under-utilizes the available bandwidth. There are
measured the instantaneous buffer level at the client player and
many network factors that have an impact on the quality of
its bitrate decisions. Fig. 4 presents one particular example of
video streaming service. For example, high bandwidth and low
HLS’s buffer level and selected bitrate while streaming video
network latency are required to provide satisfactory service
to the client.1 We observed buffer depletion between 30 and
(e.g., no stall, no glitch) to users. In this sense, there are multi-
40 seconds as marked in the circle. During this period, the
fold advantages of deploying video streaming service near the
client player stopped and rebuffered for about 10 seconds.
AP; (i) it can reduce the latency by providing service close
to the user and (ii) it is agile to network changes since it can 1. We have observed same behavior from other experiments and presented
instantaneously incorporate client’s feedback (wireless channel one of them for the sake of brevity. The duration of test video is 600 seconds.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
20 20 35 20
Buffer Buffer Bitrate
Wrong selection Bitrate
30
25
Bitrate (Mbps)
Buffer (sec)
wrong
20 selection
10 Wrong selection 10 10
wrong
15 selection
10
5 5 5
5
0 0 0 0
0 20 40 60 80 100 0 20 40 60 80 100
Time (sec) Time (sec)
Fig. 4. Inaccurate bitrate selection in HLS leads to stall Fig. 5. DASH-dynamic keeps higher bitrates than the
and rebuffering. The client player freezes during 30-40 available bandwidth (at 40 and 60 seconds), which results
seconds due to buffer depletion (marked in a red circle). in almost buffer depletion.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
4=<.2>?3&805@=.&
'()&
A.6<1&35-04.& &&&/0123456.0&&
!*B/'%& !71389.00:&;<%&
&&&R2>.02.>& )''&
!"#$%& '()&
*+)& +')& ,-.-. & )'' &
'()&
!*B$"%&
)19=.&/C&2.>D50E&
&&&&&FG&4H122.=3& IJ&7.4.<K<2L&1&4H122.=&0.M-.3>&126&>H.&-3.0&805@=.&
FJ&*.>.0N<2<2L&9<>01>.3&913.6&52&>H.&4=<.2>?3&<2O5&
PJ&/0123456<2L&50<L<21=&K<6.5&D<>H&>H.&6.>.0N<2.6&9<>01>.&
QJ&*.=<K.0<2L&>0123456.6&3>0.1N&>5&>H.&4=<.2>3&
Fig. 6. TransPi interacts with the client to determine the parameters (e.g., bitrate) for video transcoding and provides
seamless streaming service in real-time. TransPi switches the encoding bitrate according to changes in the network.
estimation and subsequent reactions based on the estima- server, we leverage a video transcoding scheme that generates
tion. There are several approaches to improve the adaptation a single stream whose bitrate is instantaneously determined.
algorithm, however, they have focused on application layer Instead of adapting within given bitrates of segments, TransPi
solutions (e.g., accurate channel estimation, better adaptation transcodes the original source to the most appropriate bitrates
algorithm and etc.) which do not involve changes of or to the and provides streaming service. It thereby eliminates ineffi-
media source itself. Second, it is challenging to pre-process cient bitrate adaptations for the client. TransPi takes a channel-
and store numerous bitrates of segments for providing fine- aware approach for determining the bitrates of a transcoded
grained bitrate adaptation because there are too many video stream (details in Section 4). Unlike HLS and DASH-dynamic,
codecs and platforms of diverse users and pre-processing TransPi adaptively switches the video bitrates while receiv-
requires additional storage for outputs. A limited choice of ing instantaneous client’s bandwidth feedback from the AP,
bitrates frequently causes under-utilization of network capac- therefore it is more agile to network changes. Knowing the
ity, and this leads to lower quality of streaming service. It benefits of cloudlet architecture for video streaming service,
is hard to pre-process live media sources (e.g., sports games, we deploy our transcoding system at the wireless edge where it
news, and teleconferences) in real-time, thus pre-processing is can monitor the client’s profile from the nearest vantage point.
limited to certain purposes such as video on demand. Third, the In addition, having video transcoding solution at the wireless
cloudlet or wireless edge system would be beneficial for video edge provides more affordability to the end user and allows
streaming service especially over wireless networks since it speedy deployment in existing systems. Since TransPi changes
could address low latency requirement and quickly incorporate the media source directly, it does not require additional storage
high variations of wireless network. One may argue that for hosting various bitrates of segments.
most recent wireless standard (e.g., 802.11ac) and AP can
provide much higher bandwidth (e.g., up to 1 Gbps), therefore
last hop bottleneck no longer exists. However, the wireless 4 S YSTEM D ESIGN
environment is highly variable due to fading, interference and
4.1 Overview
etc., therefore it is not able to guarantee stable and continuous
service to end user. Specifically, the authors in [23] showed a Our system consists of four components; media source
large variation in terms of throughput while having streaming (DATN), video transcoder on Raspberry Pi (RPi), bandwidth
service. For instance, network capacity varies widely from monitor running on AP and client’s video player as depicted
500Kbps to 17 Mbps when downloading video segment. To in Fig. 6. The basic operations of system are as follows:
provide better streaming services, we need to address the 1. On the client’s video player, the client selects a channel
issues of unstable network, high fluctuations in throughput and to watch. This will trigger the transcoding process by
bandwidth sharing. sending a channel request to the video transcoder on RPi.
Above-mentioned inferences motivate us to design a 2. The bandwidth monitor running on AP periodically (100
channel-aware transcoding solution that directly modifies the msec) sends the client’s information to the encoder on
media data instead of providing various versions and bitrates. RPi. This information is used for determining transcoding
We propose TransPi, a video transcoding system running at parameters instantaneously.
the wireless edge that enhances user experience with the video 3. The video transcoder fetches the requested TV stream
streaming. TransPi provides seamless streaming service to the from the media source (DATN) and then decodes and
user in a variant wireless environment taking into account the encodes the requested stream. While encoding, the video
user’s profile. Considering the difficulty of storing multiple transcoder adapts the video bitrates for transcoding based
versions of the same video with various bitrates in a media on the received client’s information.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
Bitrate (Mbps)
4: for i ∈ [1 : |I|] do
5: if (pi > bi × (1 + α)) || (pi < bi × (1 − α)) then 10
6: bi = pi , si = pi
7: end if
8: end for 5
9: si : selected bitrate for client i
0
0 20 40 60 80 100
Time (sec)
provides agile adaptation. We set α = 0.1 to switch the bitrate
of encoding when the network bandwidth changes more than
Fig. 9. TransPi’s channel-aware approach keeps the
10% compared to the previous configuration (we empirically
transcoding bitrates close to the client’s downlink capacity,
set α to 0.1; a lower threshold triggers frequent adaptations,
thus fully utilizes bandwidth.
whereas a higher threshold can not respond quickly to network
changes). We have tried other parameters and bitrate selection
algorithms, however their gains are not significant considering Time (sec) Bandwidth Avg. bitrate Stdev.
0-20 17 Mbps 16.90 Mbps 0.19 Mbps
complexity. Our goal is to enhance the user experience (e.g., 20-40 12 Mbps 11.83 Mbps 0.21 Mbps
achieve higher bitrate and eliminate stalls and rebuffering) 40-60 7 Mbps 6.88 Mbps 0.19 Mbps
by providing the most appropriate video bitrates according to 60-80 4 Mbps 3.96 Mbps 0.08 Mbps
80-100 17 Mbps 16.96 Mbps 0.08 Mbps
downlink capacity, thus Algorithm 1 is simple but effective
for real-time video streaming.
TABLE 3
The average video bitrate of TransPi is very close to the
4.3 Client Player network capacity.
We used multiple open-source video players (ffmpeg and
gstreamer) on clients for playback. The video player initially
creates a TCP connection (for reliability and performance transcoded output is due to the behavior of the hardware
reasons) to the video transcoder on RPi and requests a TV video encoder in RPi. This video encoder sets the range of
stream. Moreover, streaming over TCP is highly scalable, video bitrates during the encoding process instead of a single
it does not require web server an additional software or bitrate value. For this reason, even if the measured bandwidth
plugins and it does not require synchronization between video is stable (with small variation) and we set the video bitrates,
streaming server and client. Video quality would not be the video encoder is not able to keep the output video bitrates
degraded by network impairments (e.g., high delay and packet at a single value. The variation of bitrate across I/P-frames in
loss) because of TCP’s reliable service. However, client-side a group of picture (GoP) inherently propagates to the bitrate
rebuffering can still occur and can not be handled by TCP, of transcoding. As a result, this introduces small variations
therefore it can affect the user experience. This is why we in output bitrates as shown in Fig. 9. We present the average
need better bitrate adaptation or equivalent solution to enhance bitrate and standard deviation of the transcoded stream in Table
the streaming quality. The transcoded video segments are 3. The average of bitrates during each 20 second period (with
consistently delivered to the client as a single, continuous respect to the network changes) is very close to that of the
stream and the client plays them in real-time. Note that we bandwidth and the standard deviation remains relatively small.
only adapt the HLS and DASH formats for playing video TransPi frequently switches the bitrates, however, this does
without having their bitrate adaptation algorithm since TransPi not break (or interrupt) video playback nor affect the user
only provides a single stream at a time. experience at all because the client player seamlessly plays
continuous video stream. Specifically, there are no sudden
5 E VALUATION scene change or freeze during playback.
Comparison with DASH-BBA. Buffer-based approach
5.1 Controlled Setting (DASH-BBA) [23] is one of the state-of-the-art streaming
Bitrate. To show how accurately TransPi adapts bitrates for solutions and it adapts the bitrate according to buffer occu-
transcoding according to the network changes, we present pancy. In order to compare the performance of TansPi with
video bitrates of transcoded output and network bandwidth DASH-BBA, we have conducted experiments with the same
(grey area) in Fig. 9. We can clearly see that the video bitrate network configuration. The selected bitrate and instantaneous
of transcoded output is very close to the downlink capacity buffer occupancy of DASH-BBA are shown in Fig. 10. Similar
while TransPi incorporates the client’s instantaneous chan- to HLS and DASH-dynamic, we confirm that DASH-BBA
nel feedback to determine the video bitrates of transcoding. underutilizes the available bandwidth. For instance, during the
We point out that the small variation of video bitrates of first 20 seconds, DASH-BBA could switch to higher bitrates
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
20 25
TransPi-bitrate BBA-Buffer 0.5
BBA-bitrate Transcoder
Client
Bitrate / Bandwidth (Mbps)
0 0 0 0
0 20 40 60 80 100 0 20 40 60 80 100 120
Time (sec) Time (sec)
Fig. 10. DASH-BBA frequently switches bitrate and un- Fig. 11. The transcoder keeps the size of output queue to
derutilizes the network capacity. 400 msec to minimize the delay. The client’s input buffer
remains stable (30-50 Kbytes).
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
20 0.8
Bitrate (Mbps)
0.6
15
CDF
0.4
10
0.2 TransPi
5 DASH
BBA
0
0 100 200 300 400 500 600 700 800
0 Time (msec)
0 20 40 60 80 100 120 140
Time (sec) Fig. 13. CDF of end-to-end delay.
Fig. 12. TransPi adapts to higher bitrates whenever
DASH-BBA or DASH-dynamic select lower bitrates.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
DASH- DASH-
Scheme BBA dynamic TransPi HLS DASH TransPi
Bitrate LTE: 5.34 LTE: 7.43 LTE: 6.57 50
(Mbps) FCC: 3.99 FCC: 5.47 FCC: 5.15
Delay LTE: 117.2 LTE: 137.3 LTE: 79.3 40
(msec) FCC: 146.3 FCC:170.6 FCC:87.6
Frequency
Number of LTE: 0.6 LTE: 3.45 LTE: 0
Stall FCC: 0 FCC: 0.9 FCC: 0 30
Rebuffering LTE: 6.38 LTE: 12.15 LTE: 0
Time (sec) FCC: 0 FCC: 2.36 FCC: 0 20
TABLE 5
TransPi outperforms DASH-BBA and DASH-dynamic in 10
terms of average bitrate, delay and rebuffering.
0
1 2 3 4 5
MOS
5.3 User Quality of Experience (QoE) Fig. 14. The distribution of MOS. Participants clearly
Next, we assess the performance of TransPi using subjective indicate that TransPi provides higher QoE.
user studies. The video quality is inherently subjective quan-
tity. The Quality of Service (QoS) is expressed by several Scheme HLS DASH-dynamic TransPi
network parameters (bandwidth, jitter, packet loss, delay and Avg. MOS 3.36 3.52 4.24
Std. MOS 0.83 0.88 0.65
etc.), however a good QoS does not always guarantee a good User preference (%) 11.1 18.9 70.0
user experience. For instance, even if the provided video qual-
ity is high, frequent stalls and long buffering time could lead TABLE 6
to less user engagement and low satisfaction because several TransPi is superior to others in terms of average MOS.
metrics are interrelated. This eventually lowers the quality to Participants prefer TransPi over ABR schemes.
the users. The Quality of Experience (QoE) has emerged to
address such issue and expresses the user satisfaction of a
service. QoE is affected by both users and network system.
rebuffing time, delay at startup and bitrate switches. Our
Mean Opinion Score (MOS) is mostly used metric and its
experiment results (both objective and subjective tests) confirm
scale is the 5-point Absolute Category Rating (ACR) scale:
above-mentioned inferences that TransPi provides higher bi-
5-Excellent, 4-Good, 3-Fair, 2-Poor and 1-Bad [27].
trate, no rebuffering or stall, therefore user QoE is much higher
We have conducted subjective tests with 15 users in a than others. The main purpose of utilizing video transcoding
single stimulus manner (without reference) [27]. We have used in this work is to provide better streaming service to the user
6 video sequences and asked the participants to rate each when the wireless network cannot provide successful transmis-
video sequence individually on an ACR scale. In addition, sion of original video data on time. TransPi can compensate
participants indicate their preferences among HLS, DASH- for some loss of video quality by eliminating stalls, buffering
dynamic and TransPi (without knowing the schemes). Table and start time and improving the user experience (note that
6 shows the average and standard deviation of MOS for each the quality of the original video is clearly higher than that
scheme along with the user’s preference (note that we have of transcoded one, because transcoding downgrades the video
used 90 video sequences in total). We can clearly see that quality in terms of bitrate, resolution and etc.).
TransPi has higher QoE than ABR schemes and people prefer
TransPi over HLS or DASH-dynamic. The main reason for
achieving higher QoE in TransPi is that it provides seamless 5.4 Fairness and Providing Differentiated Service
streaming service, whereas two ABR schemes suffer from Fairness. Significant unfairness between clients has been ob-
rebuffering, and hence stalls bother the participants and their served for bitrate adaptive streaming solutions when multiple
engagements. It is well know that reffering has a significant clients share the network bandwidth [30]. Providing bandwidth
impact on user QoE. For instance, the authors in [28] have fairness is important to guarantee the QoS in multi-client
shown that time spent rebuffering and the frequency of re- deployment. TransPi determines the bitrates for transcoding
buffering events can significantly reduce the QoE. In addition, based on the client’s downlink capacity, thus selected bitrates
video streaming service providers prefer to lower the quality allocate the bandwidth for clients in the network. This eventu-
of the video delivered rather than cause an interruption in its ally ensures fair sharing of bandwidth across multiple clients.
playback. Our QoE measurement results clearly corroborate To evaluate the performance of TransPi under a competing
such inference. Fig. 14 represents the distribution of MOS scenario, we repeat similar experiments with two clients. In
collected from the same set of experiments. It can be seen this setup, each client receives transcoded video streaming
that TransPi has received a large number of “Excellent” and from a dedicated transcoder (RPi) and shares downlink band-
the MOS difference is significant. We can conclude that higher width while associating with the same AP. Each transcoder
bitrate and less rebuffering result in higher QoE. incorporates its client’s network bandwidth to decide the
Several previous researches [14], [29] shown that user output bitrates. To evaluate the fairness under multiple clients
engagement and QoE depend on many factors; video bitrate, deployment, we first set the downlink bandwidth in a sym-
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
Client1
10 10
9
8
Bitrate (Mbps)
Bitrate (Mbps)
7
6.5
6
Client2
5
4
3.5
3
2
Client1 Client3
Client2 Client4 1
0 0
0 20 40 60 80 100 0 20 40 60 80 100 120
Time (sec) Time (sec)
Fig. 15. Regardless of the bandwidth changes in the Fig. 16. Client1 receives twice as much downlink band-
network, the transcoding bitrates for each client remain width as client2.
the same. Four clients equally share the bandwidth.
Intel server (i7) TransPi (RPi)
Avgerage power 92.94 W 2.65 W
Duration 85 sec 519 sec
metric manner. Fig. 15 shows the selected bitrates of four Energy consumption 2.19 J 0.38 J
clients while applying bandwidth changes configured to 40,
26, 15 and 40 Mbps for 25 seconds each (the shared bandwidth TABLE 7
for each client is 10, 6.5, 3.5 and 10 Mbps during each Energy consumption comparison.
time interval). We can clearly see that the selected bitrates
for each client remain same; four clients equally share the
transcoding tasks in real-time without degrading the perfor-
available bandwidth, 1/n where n is the number of clients
mance and video quality. To monitor and evaluate the energy
in the network. This ratio of bitrates for clients is maintained
efficiency of TransPi, we measured the power consumption of
same even with the network’s bandwidth changes. The sum
both the RPi and a dedicated transcoding server (Intel i7-6700
of selected bitrates for both clients equals to the network
CPU with 16GB RAM). We have executed the same video
capacity, thus TransPi efficiently utilizes bandwidth (utilization
transcoding task (1080p HD) on both platforms while logging
is around 99%). In this experiment, we set the time interval
the instantaneous power consumption (we ran the same video
to 25 seconds to characterize the network dynamics, however
transcoding solution on both machine). Fig. 17 shows one
even smaller time interval (e.g., 1 second) is feasible, because
typical power measurement result (we have conducted multiple
TransPi configures the transcoding bitrate every 1 second. We
runs and obtained the same results). We can see that the
omit the result for the sake of brevity.
desktop implementation of transcoding server consumes more
Providing differentiated service. TransPi instantaneously than 35 times power comparing to that of RPi while running
determines the video bitrates for transcoding. Based on such transcoding task. We can see that Intel-based transcoding
characteristics, we can easily configure the downlink band- server finishes the same transcoding task much faster (6.1×)
width for each client when multiple clients share the network. than the RPi because of the powerful and sufficient resources.
We can provide differentiated service (i.e., allocating different Note that video transcoding time on RPi is much longer Intel-
bandwidth) for each client by configuring different bitrate based transcoding server, however, RPi is still sufficient to
for transcoding. In this experiment, we control the downlink transcode live streaming without incurring additional delays.
bandwidth in an asymmetric manner; client 1 receives two The areas in Fig. 17 (excluding idle states) represent the total
times the downlink bandwidth compared to client 2. Similar power consumption of each transcoder implementation. Table
to the fair sharing experiment, we configure the network 7 summarizes the power measurements for both platforms. We
bandwidth to 15, 10, 5 and 10 Mbps for 30 seconds each. can see that TransPi is more energy efficient (i.e., 5.76× less
Shown in Fig. 16, we confirm that the ratio of the selected energy) and much cheaper than transcoders built with general-
bitrates for each client stays at 2:1 as we configure the purpose processors.
downlink bandwidth for two clients, and the ratio remains
same while the network’s bandwidth changes. In this set of
experiments we have confirmed that both fair-sharing and con-
6 B ROADCAST L IVE S TREAMING V IDEO
trolled configuration (unequal sharing) are feasible in TransPi We introduced the design and implementation of TransPi that
by adapting the bitrates for the clients in the network. addresses the problem of channel variation for downlink video
streaming. In this section, we present a broadcast application
that uses video transcoding for real-time streaming uploads.
5.5 Energy Consumption Broadcasting live events (e.g., sports game, breaking news) is
Compared with a dedicated video transcoding server, RPi challenging because the wireless channel is highly variable and
is a cost-effective device that is capable of executing video the uplink bandwidth is relatively small. Toward this, we apply
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
4
100 Running
3.5
90
80 3 Running
Idle Idle
Power (W) 70 2.5
Power (W)
60
2 Idle
50
40 1.5
30 1
20
0.5
10
0 0
0 20 40 60 80 100 120 140 0 100 200 300 400 500
Time (sec) Time (sec)
(a) Desktop transcoding server (Intel i7 CPU) (b) TransPi (RPi)
Fig. 17. TransPi significantly reduces power consumption compared to the dedicated transcoding server.
600
500
300
200
100
0
0 50 100 150 200 250 300 350
Time (sec)
Fig. 18. Drone broadcasts live aerial streams to multiple users while Fig. 19. The client maintains a stable buffer
adapting video bitrates to minimize the delay. level.
video transcoding solution to uplink case for broadcasting live cellular base-station, and a web server that hosts segments of
streams. Next, we describe an implementation of TransPi on video streaming, as depicted in Fig. 18. We used DJI F550 [31]
drone for streaming aerial real-time images to the user. (a basic, user-configurable drone without a camera or wireless
modules) for our aerial vehicle. Our drone is equipped with the
Raspberry Pi for video encoding, an RPi camera module, and
6.1 Real-time Broadcasting using TransPi
a LTE USB adaptor for wireless connection during flight. The
Aerial vehicles such as Aircraft, MedFlight, and delivery drone broadcasts live aerial video streaming taken from RPi
drones need connectivity for communication and data trans- camera to the various users in real-time. In this configuration,
mission. They rely on satellite or cellular networks, however, uplink bandwidth (i.e., drone to the media server via LTE) is
such networks tend to have considerable variability due to relatively smaller than downlink capacity (i.e., media server to
fading and interference, especially in outdoor wireless net- the end users) and is a bottleneck. Such bandwidth limitation
works. Given that ensuring 100% guaranteed connectivity hinders uploading live stream in real-time, and hence incurs
with wireless medium is extremely difficult to achieve, it delay to the end users. In the worst case, user may experience
may be useful to provide reliable services in the application frequent stalls and buffering. It therefore requires optimization
domain. We have explored a new application domain, aerial for uploading data to provide seamless streaming service to the
vehicles, with channel-aware video encoding for broadcasting user in real-time while avoiding stall or freeze. To circumvent
live streaming service. Broadcast live streaming is one of the bandwidth limitation, unstable connection and variability
the popular applications in recent years due to the easy of of wireless channel, we apply video transcoding solution when
access and availability of numerous tools, cheap devices and uploading the recorded aerial video as depicted in Fig. 18.
network infrastructure (e.g., cloud). Given the popularity of the
mobile streaming service, there are continued demand growth First, the transcoder in RPi takes video streaming from
for high bandwidth in wireless mobile network. The goal of the camera module and encodes them using the GStreamer
this application is to provide live-streaming aerial coverage to framework as described in section 4.2. We have implemented
multiple users while adapting to the variant wireless channel. a similar GStreamer pipeline to handle video streams. RPi on
Our system consists of three components: a drone, LTE drone instantaneously determines the video bitrates according
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
the authors in [41] proposed online transcoding policies that accelerate the system deployment.
transcode video segments in a just-in-time fashion when
bitrates are actually requested by the user. They focus on
8 C ONCLUSION
theoretical analysis of predictive model to reduce transcoding
workload, therefore it is limited to simulation. Similarly, We present the design, implementation and evaluation of a
TransPi operates video transcoding on-the-fly. Unlike [41], real-time video transcoding solution in wireless networks.
TransPi is implemented on a COTS device and demonstrates Our proposed system provides quick bitrate adaptation under
its efficacies and user satisfactions in real-world scenarios. unstable wireless conditions and efficiently utilizes avail-
Albanese et al. [42] propose the video transcoding unit ap- able bandwidth. We show the feasibility of real-time video
plication that leveraging MEC architecture. They demonstrated transcoding solution on a cheap single-board computer RPi
the superiority of GPU-accelerated video transcoding com- and demonstrate its superiority over bitrate adaptive streaming
pared to the software-only one, but they simply adopted the approaches. TransPi is capable of transcoding live streaming,
COTS GPU hardware without any further modification. The on-the-fly, with minimal delay. We plan to improve its scala-
main difference is that we design and optimize the architecture bility in a practical setting (i.e., supporting hundreds of clients
of GStreamer pipeline to improve transcoding performance simultaneously and incorporating 100+ IPTV channels).
on a COTS device and enhance the user experience. Our
implementation is publicly available and easily adaptable to ACKNOWLEDGMENT
many applications that require real-time streaming.
In summary, TransPi has several unique features when This work was supported by Basic Science Research Pro-
compared to other works: (i) TransPi employs the software and gram through the National Research Foundation of south
hardware coupled architecture on a cost-effect and powerful Korea (NRF) funded by the Ministry of Education NRF-
COTS device to improve the video streaming quality and user 2018R1C1B6006436.
satisfactions. (ii) Our transcoding solution can be used for both
the downlink and uplink video streams. It provides real-time R EFERENCES
transcoding service, and hence it can handle live streaming
[1] Cisco visual networking index, Global mobile data traffic forecast update
with minimal delay. (iii) Unlike other transcoding systems, 2012-2017, http://www.cisco.com/.
TransPi provides each user with a dedicated streaming that [2] T. Stockhammer, “Dynamic Adaptive Streaming over HTTP: Standards
takes the user’s profile instantaneously to determine the bi- and Design Principles”. In Proceedings of ACM MMSys, 2011.
[3] H. Schwarz, D. Marpe and T. Wiegand, “Overview of the Scalable Video
trates of the transcoding. Thus, it quickly adapts to the user’s Coding Extension of the H.264/AVC Standard”, In IEEE Transactions on
network condition as opposed to other adaptation solutions Circuits and Systems for Video Technology, vol. 17, no. 9, pp. 1103-1120,
that only serve a limited choice of pre-processed bitrates. Sep. 2007.
[4] Z. Li, Y. Huang, G. Liu, F. Wang and Z. Zhang. “Cloud Transcoder:
(iv) It provides seamless bitrate adaptation while transcoding Bridging the Format and Resolution Gap between Internet Videos and
video in fine time granularity, that ensures end users are Mobile Devices”, In Proceedings of ACM NOSSDAV, 2012.
not interrupted during playback. (v) TransPi does not require [5] Z. Huang, C. Mei, L. E. Li and T. Woo. “CloudStream: Delivering
High-quality Streaming Videos through a Cloud-based SVC Proxy”, In
preprocessing or additional storage because TransPi runs on- Proceedings of IEEE Infocom, 2011.
the-fly. [6] Raspberry Pi, http://www.raspberrypi.org/.
Deployment. Video transcoding is a computationally inten- [7] HTTP Live Streaming (HLS), “IETF Internet-Drafts 2014”,
http://tools.ietf.org/html/.
sive task for general purpose processor. The performance of [8] ISO/IEC23009-1, “MPEG Dynamic Adaptive Streaming over HTTP
hardware transcoding clearly outperforms the software-based (DASH)”, http://dashif.org/mpeg-dash/.
solution. For instance, Hameed et al. [43] have shown that [9] M. Satyanarayanan, P. Bahl, R. Caceres and N. Davies. “The Case
for VM-Based Cloudlets in Mobile Computing”, In IEEE Pervasive
ASIC implementation of H.264 encoder could improve power Computing, vol. 8, no. 4, pp. 14-23, Oct. 2009.
efficiency up to 500 times compared to the software-based one [10] DASH client 2.7.0, https://github.com/Dash-Industry-Forum/dash.js/
running on general purpose processor. Similarly, we leverage [11] DASH test stream, https://dash.akamaized.net/akamai/bbb 30fps/bbb
30fps.mpd/
the GPU in RPi for designing video transcoding solution, [12] S. Akhshabi, A. C. Begen and C. Dovrolis. “An Experimental Evaluation
however, a single RPi can only transcode 4 HD streams of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP”, In
simultaneously. Given the large number of video streams Proceedings of ACM MMSys, 2011.
[13] S. Akhshabi, L. Anantakrishnan, C. Dovrolis and A. C. Begen. “What
requested by multiple users, it is necessary to have a system Happens when HTTP Adaptive Streaming Players Compete for Band-
that can handle many transcoding at the same time. Toward width?”, In Proceedings of ACM NOSSDAV, 2012.
this, we build a RPi-center (e.g., a rack of RPis) and transcod- [14] F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. A. Joseph, A. Ganjam, J.
ing manager that schedules multiple RPis for transcoding. Zhan and H. Zhang, H. “Understanding the Impact of Video Quality on
User Engagement”, In Proceedings of ACM Sigcomm, 2011.
We parallelize the transcoding processes to support multiple [15] Digital Academic Television Network, https://it.wisc.edu/ services/datn/
requests from users and simultaneously support hundreds of [16] Openmax. https://www.khronos.org/openmax/
users. RPi is a cost-effective and powerful hardware, and hence [17] GPU CUDA acceleration, http://www.bdlot.com/resource/gpu-
acceleration.htm/
RPi-center is still much cheaper than maintaining dedicated [18] Node.js, https://nodejs.org/
and massive transcoding servers. With these low-cost and [19] MQTT.js, https://github.com/mqttjs/
performance efficiencies, our system can be easily deployed [20] Gstreamer multimedia framework, http://gstreamer.freedesktop.org/
[21] OpenMAX IL wrapper plugin, https://github.com/pliu6/gst-omx/
in wireless networks. In addition, we are working to integrate [22] TransPi implementation on Raspberry Pi, https://github.com/mobile-
the TransPi into the GPU-embedded WiFi access point to systems-lab/buildroot/
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMC.2019.2898834, IEEE
Transactions on Mobile Computing
[23] T. Y. Huang, R. Johari, N. McKeown, M. Trunnell and M. Watson. “A Suman Banerjee is an Professor in Computer
Buffer-Based Approach to Rate Adaptation: Evidence from a Large Video Sciences at UW-Madison where he is the found-
Streaming Service”, In Proceedings of ACM Sigcomm, 2014. ing director of the WiNGS laboratory which
[24] K. Winstein, A. Sivaraman, and H. Balakrishnan. “Stochastic Forecasts broadly focuses on research in wireless and
Achieve High Throughput and Low Delay over Cellular Networks”, In mobile networking systems. He received his un-
Proceedings of USENIX NSDI, 2013. dergraduate degree from IIT Kanpur in Com-
[25] D. Raca, J.J. Quinlan, A.H. Zahran, C.J. Sreenan. “Beyond Throughput: puter Science and Engineering and was a gold
a 4G LTE Dataset with Channel and Context Metrics”, In Proc. of medalist in his graduating class. He received
ACM Multimedia Systems Conference, 2018. Trace is available at his M.S. and Ph.D. degrees from the University
https://www.ucc.ie/en/misl/research/datasets/ivid 4g lte dataset/ of Maryland and his Ph.D. dissertation was the
[26] FCC Raw Data - Measuring Broadband America 2016. university’s nomination for the ACM Doctoral
https://www.fcc.gov/reports-research/reports/measuring-broadband- Dissertation Award. While at Wisconsin, Prof. Banerjee received the
america/raw-data-measuring-broadband-america-2016/ CAREER award from the US National Science Foundation and the
[27] ITU-T Rec. P.910. “Subjective Video Quality Assessment Methods for inaugural Rockstar Award from ACM SIGMOBILE for early career
Multimedia Applications”, https://www.itu.int/rec/T-REC-P.910/en/, 2008. achievements and contributions in his field. Prof. Banerjee has authored
[28] R. Mok, E. Chan and R. Chang. “Measuring the Quality of Experience of more than 100 technical papers in leading journals and conferences in
HTTP Video Streaming”, In Proc. of IFIP/IEEE International Symposium the field, including ACM/IEEE Transactions on Networking, ACM/IEEE
on Integrated Network Management, 2011. Transactions on Mobile Computing, ACM Sigcomm, ACM MobiCom,
[29] S. S. Krishnan and R. K. Sitaraman. “Video Stream Quality Im- IEEE Infocom, ACM MobiSys, ACM CoNEXT, ACM IMC, IEEE Dyspan,
pacts Viewer Behavior: Inferring Causality Using Quasi-Experimental and more. It also includes various award papers from conferences such
Designs”, In Proceedings of ACM IMC, 2012. as ACM MobiCom, ACM CoNEXT, and IEEE Dyspan. Prof. Banerjee
[30] J. Jiang, V. Sekar and H. Zhang, H. “Improving Fairness, Efficiency, served as the chair of ACM SIGMOBILE between 2013 and 2017.
and Stability in HTTP-based Adaptive Video Streaming with FESTIVE”,
In Proceedings of ACM CoNEXT, 2012.
[31] DJI F550 Hexacopter drone https://www.dji.com/flame-wheel-arf/
[32] SDK for Beam’s FTL Protocol https://github.com/mixer/ftl-sdk/
[33] Major league baseball http://mlb.tv/
[34] Interactive live streaming platform http://mixer.com/
[35] C. Muller, S. Lederer and C. Timmerer. “An Evaluation of Dynamic
Adaptive Streaming over HTTP in Vehicular Environments”, In Proceed-
ings of ACM MoVid, 2012.
[36] C. Liu, L. Bouazizi, M. Hannuksela and M. Gabbouj. “Rate Adaptation
for Dynamic Adaptive Streaming over HTTP in Content Distribution
Network”, In Image Communication, vol. 27, no. 4, pp. 288-311, Apr.
2012.
[37] A. Warabino, S. Ota, D. Morikawa, M. Ohashi, H. Nakamura, H.
Iwashita and F. Watanabe. “Video Transcoding Proxy for 3Gwireless
Mobile Internet Access”, In IEEE Communications Magazine, vol. 38,
no. 10, pp. 66-71, Oct. 2000.
[38] Z. Lei and N. D. Georganas. “Video Transcoding Gateway for Wireless
Video Access”, In Proc. of IEEE CCECE, 2003.
[39] S. Dutta, T. Taleb, P. A. Frangoudis and A. Ksentini. “On-the-Fly QoE-
Aware Transcoding in the Mobile Edge”, In Proc. of IEEE Globecom,
2016.
[40] D. Wang, Y. Peng, X. Ma, W. Ding, H. Jiang, F. Chen and J. Liu. “Adap-
tive Wireless Video Streaming based on Edge Computing: Opportunities
and Approaches”, In IEEE Transactions on Services Computing, Apr.
2018.
[41] D. K. Krishnappa, M. Zink and R. K. Sitaraman. “Optimizing the Video
Transcoding Workflow in Content Delivery Networks”, In Proc. of ACM
MMSys, 2015.
[42] A. Albanese, P. S. Crosta, C. Meani and P. Paglierani. “GPU-accelerated
Video Transcoding Unit for Multi-access Edge Computing Scenarios”, In
Proc. of The Sixteenth International Conference on Networks, 2017.
[43] R. Hameed, W. Qadeer, M. Wachs, O. Azizi, A. Solomatnikov, B. Lee,
S. Richardson, C. Kozyrakis and M. Horowitz. “Understanding Sources
of Inefficiency in General-Purpose Chips”, In ACM SIGARCH Computer
Architecture News, vol. 38, no. 3, pp. 37-47, 2010.
1536-1233 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.