Adaptive Media Streaming - Scalable Continuous Media Streaming Systems - page 143

into the server buffer at its playback rate and injected into the network at the rate that its
congestion control algorithm allows. Therefore, when the server buffer builds up, it infers
that the available network bandwidth drops and thus reduces the video bit-rate to decrease the
server buffer occupancy. Its use of transcoding to control the video bit-rate and server-side
information to decide the appropriate video bit-rate makes it readily deployable on existing
streaming platforms.
Cuetos et al. [1, 2] proposed an adaptive rate control for streaming Fine-Grained Scalable
(FGS) video. It adapts the video by controlling the video bit-rate of the enhancement layer of
the FGS-coded video based on the client buffer occupancy and network bandwidth information.
The heuristic rate control algorithm aims to maintain the client buffer occupancy at around
the target level, while at the same time minimizing the video bit-rate variation introduced
by adaptation. Although the control algorithm was originally designed to work with FGS-
coded video, it can also be applied to non-FGS videos using transcoding techniques. The only
limitation is the need to configure a system control parameter which can substantially affect
the algorithm's performance. Our results show that the optimal value of the parameter can vary
considerably over a wide range under different network traffic patterns (cf. Section 8.6) and
so it may be difficult to optimize the algorithm for use in the Internet, where network traffic
patterns are generally very difficult to predict.
8.3 System Model
In this chapter we consider a video streaming system that streams pre-encoded video data using
TCP as the network transport to the receiver for playback. Despite the shortcomings of TCP in
the context of media streaming (cf. Section 6.1), due to its aggressive congestion control and
enforced error-recovery, it does possess a number of appealing features.
First, TCP is intrinsically TCP-friendly and thus fairness with other TCP traffics is automati-
cally guaranteed. Second, using TCP the sender can stream video using, say, the standard HTTP
protocol to the client. As most, if not all, video players in the market support HTTP-based
video streaming and playback, compatibility is greatly enhanced. Third, for security reasons,
many companies and ISP block or throttle UDP traffic at their firewalls and gateways, thus
making UDP-based video streaming impossible. By contrast, TCP/HTTP streaming can pass
through firewalls in the same way as web traffic. Finally, to perform bandwidth estimation, the
sender will need some form of feedbacks from the client. If we use the UDP transport, then the
client will need to be modified to send explicit feedbacks to the sender to enable bandwidth
estimation so that rate adaptation can be performed. By contrast, TCP with its built-in flow
control already can provide implicit feedbacks to the sender and thus no modification to the
client is necessary. Again, this will greatly enhance the compatibility of the rate-adaptation
algorithm to the existing video player software. Nevertheless, the rate-adaptation algorithm
presented in this study can also be applied to UDP-based video streaming with appropriate
support from the client's player software, such as streaming over RTP and using RTCP to
report reception statistics back to the server.
Figure 8.1 shows the key components in the video streaming system. Assume the video
data are encoded at a constant bit-rate of r max bps. The rate controller can convert the encoded
video to any bit-rate between r max and r min (e.g., using scalable video coding [7] or transcoding
[8-10]). Note that there is a lower limit r min on the achievable video bit-rate in the model, for
example, the bit-rate of the base layer in FGS encoded video [7] or the lowest achievable
bit-rate in transcoding [8-10] (cf. Section 2.5).