Nowadays, numerous multimedia streaming applications like video-on-demand services, transmissions of recorded sports events or concerts, and distant learning depend on the efficient transfer of prerecorded video. Content servers usually store video on large and fast disks [5]－[7]. Clients such as PCs or set-top boxes, which have a limited-size playback buffer for storing temporary media data, can connect to content servers through IP networks.
If high-quality videos are demanded, they will still require a huge amount of storage space and transmission bandwidth, even when they are already compressed by the most advanced encoding technologies such as MPEG-4 or H.264. These modern encoding schemes generate bitstreams of constant quality but variable-bit-rate (VBR) to avoid the quality degradation caused by constant-bit-rate (CBR) encoding methods [8] [9].
However, this VBR characteristic can cause significant burstiness on multiple time scales due to the natural variations within and between scenes, and the frame structure of the encoding algorithm [10], and as a result, complicates the allocation of disk, memory, and network resources [11]. Therefore, to be able to efficiently transmit constant-quality video, a technique that can smooth the burstiness is required. Intuitively, one may suggest that the server, network, and client could allocate resources based on the peak bitrate of the video, such over-reserving is exceedingly wasteful and depreciates the benefits of a constant-quality encoding.
Fortunately, prerecorded video gives us an opportunity to reduce the variability of the network bandwidth requirements by transmitting frames to the client playback buffer in advance of each burst [12]. Based on a priori knowledge of the size of each frame, the
server can precompute a transmission plan that minimizes the bitrate variation and peak bitrate while avoiding both underflow and overflow of the client’s buffer. This technique is what we call “bandwidth smoothing”. Its benefits are the results of removing both short-term burstiness (e.g. large size difference between I-frames and P-frames) and medium term burstiness within and between scenes [13].
So far, in this field, six major smoothing algorithms have been proposed [13]－[18].
They have a common primary goal that is to reduce the peak rate of the stream, but however, they differ in what performance metrics they attempt to optimize. Hence, they can generate different transmission schedules of different performance properties, such as minimum number of rate changes in transmission, minimum variability of the bandwidth requirements, minimum utilization of the client buffer, minimum number of on–off segments in an on–off transmission model, change of transmission rates only at periodic intervals, and minimum general cost metrics through dynamic programming.
For the implementation of the system concerned in this paper, since MVBA [13]
achieves the goals of minimizing the peak transmission rate and the rate variability, and it is easier to implement than other algorithm, it will be selected among six smoothing algorisms to help the server transmit more efficiently.
2.3.1 MVBA
Goals
The goals of MVBA, as claimed by the authors [13], are that given a fixed-size client buffer, a feasible transmission plan with:
z minimum variance of transmission rate z minimum peak transmission rate
z and maximum lowest transmission rate
will be computed based on the a prior knowledge of frame sizes in the stored video. Note that a feasible transmission plan is a transmission plan that ensures the client buffer will never be drained nor overflowed. If the client buffer starves, then the presentation will be held up until more data are received. Conversely, if the client’s buffer is overloaded with data, then all the lately arriving data will be discarded until some spaces of the buffer become available.
Main Concepts
z Intuitively, because CBR transmission is the smoothest possible, during the computation of the transmission plan, CBR transmission segments should be extended as far as possible.
z When the transmission rate must be increased or decreased to avoid starving or overflowing the client buffer, respectively, this rate change should be taken place as early as possible as to ensure the minimum rate variability.
Therefore, with MVBA, the transmission rate changes always occur at the earliest possible times for both rate increases and decreases. Thus, the generated transmission plan indeed gradually modifies the bandwidth requirement of the stream.
Concept Realization
Up to now, only the goals of MVBA and the ideas behind MVBA have been introduced. How MVBA can be implemented in a real server system is still unmentioned and should be described now. In [13], the authors provide a complete pseudo code and ways that can generate an MVBA transmission schedule. The following notations are worth knowing [13]:
z Cmax: the maximum transmission rate at which the server can stream over a given interval, without overflowing the client buffer.
z Cmin: the minimum transmission rate at which the server can stream over a given interval, without draining the client buffer.
In fact, the resulted transmission schedule will consist of a series of CBR transmission segments that might be Cmax or Cmax. Thus, to implement MVBA in a real server system, the system developer will just have to re-write the pseudo code in the used programming language such as C or C++. The resulted transmission plan will be the number of bytes that should be sent at each time instants. For example, for a video with the framerate of 25 frames per second, then the transmission plan probably will specify that at 0 ms, 1666.67 bytes should be transmitted, at 40 ms, 566.67 bytes should be transmitted, at 80 ms, another 333.33 bytes should be transmitted, and so on.
2.3.2 Packet-based MVBA
It is well known that in the current model of Internet, the data being transmitted from the source to the destination are not injected into the network bit by bit or byte by byte.
Instead, in the real world, the data are sent as packets. Because along the path from the source to the destination, packets might pass by many different types of networks, each of which can support different maximum packet size (MTU), packets should not be made to be larger than the smallest MTU in these networks to avoid unnecessary fragmentations and reassembly. In addition to the maximum packet size, the size of each packet should be integers. A problem arises at this point. Recalling from previous section that at each time instant, the generated transmission plan will specify at each time instant how many bytes should be transmitted. The numbers of bytes specified may be of multiple decimal digits of precision or larger than the smallest MTU. To cope with this problem, a packet-based MVBA is needed and developed [24].
In short, the packet-based MVBA will generate a feasible transmission plan that follows the original MVBA generated plan the closest possible. The first step is to divide each video frame into fixed-size (say 1024 bytes) packets. For example, a frame of 3000 bytes will be segmented into two full 1024-byte packets and one 952-byte packet. Now instead of a series of frames available, a series of packets are on hand. Secondly, instead of just knowing the numbers of bytes that should be sent for different time instants as specified by the original MVBA, the accumulated number of bytes should also be computed. In other words, the total number of bytes that should be sent before and at each time instant is calculated. This new information will be referenced to derive the new packet-based plan.
Now, it is time to derive the new transmission schedule. Essentially, for the time instant belonging to the Cmax segment in the original MVBA plan, the packet-based MVBA will take a number of packets from the series of available packets in order whose sizes sum up to be smaller or equal to the original accumulated number of bytes. This step ensures that the new schedule will approximate the old one the best and the client buffer will not be overflowed. Conversely, for the time instant belonging to the Cmin segment in the original MVBA plan, the packet-based MVBA will take a number of packets from the series of available packets in order whose sizes sum up to be equal to or larger the
original accumulated number of bytes. This step is to guarantee that the new schedule will follow the original one the closest possible and the client buffer will never starve.
This short section only describes the packet-based MVBA in brief. For a more complete and in depth discussions about it, readers are encouraged to refer to [24].
3 Some Programming Techniques
Traditional C/C++ programming techniques are not sufficient to provide enough functionality for system designers to implement an extremely complicated, sophisticated, and multi-functional system, such as the proposed client/server streaming system. Hence, more advanced programming techniques are needed. In this section, the notions of threads and synchronization objects are explained and discussed.