QoS of Digital Video in Mobile Environment

1         INTRODUCTION
1.1      General Information
1.2      Aim of the Study
1.3      Structure of the Study

2         VIDEO COMPRESSIONS
2.1      Principle of Compression
2.1.1   Lossless Compression
2.1.2   Lossy Compression
2.2      Main Compression Standards
2.2.1   H.261/H.263
2.2.2   M-JPEG
2.2.3   MPEG Series
2.2.4   Others

3         STREAMING TECHNOLOGY
3.1      Why Use Streaming Technology?
3.2      Seven Areas regarding Streaming Video
3.2.1   Video Compression
3.2.2   Application-layer QoS Control for Streaming Video
3.2.3   Continuous Media Distribution Services
3.2.4   Streaming Servers
3.2.5   Media Synchronization Mechanisms
3.2.6   Protocols for Streaming Media
3.2.7   Streaming Video over Wireless IP Networks
3.3      Various Streaming Technologies
3.3.1   Microsoft Windows Media Technologies
3.3.2   RealNetworks
3.3.3   QuickTime and Sorenson

4         NETWORKS
4.1      Wireless Local Area Network
4.1.1   Infrastructure Mode
4.1.2   Adhoc Mode
4.2      GSM/GPRS

5         TERMINAL DEVICE - PDA
5.1      Classification
5.2      PDA Parts
5.2.1   Microprocessor
5.2.2   Operating System
5.2.3   Memory
5.2.4   Battery
5.2.5   LCD Display
5.2.6   Input Device
5.2.7   Input/Output Port

6         COMPRESSIONS WITH MULTIPLE TOOLS AND COMPARISON
6.1      Video Compression Tools
6.1.1   Adobe® Premiere® 6.0
6.1.2   Microsoft® Windows MediaTM Encoder 9 Series
6.1.3   Helix(tm) Producer
6.1.4   VirtualDub 1.5.10
6.2      Process of Compression
6.2.1   Adobe Premiere
6.2.2   Windows Media Encoder
6.2.3   Helix Producer
6.2.4   VirtualDub
6.3      Comparison
6.3.1   Different Resolution
6.3.2   Different Bit Rate
6.3.3   Different Video Mode
6.3.4   Different Audio Mode
6.3.5   Different Compression Tool
6.3.6   Different Technologies of Playing
6.3.7   Other Aspects Related to QoS

7         INSTALLATION OF MEDIA SERVER
7.1      Helix (Real) Server
7.2      Windows Media Server
7.3      Quick Time Streaming Server

8         TESTING IN MOBILE ENVIRONMENT
8.1      Test in Lab Environment
8.2      Test in Real Internet
8.3      Test in Intranet

9         CONCLUSION AND FUTURE RESEARCH

LIST OF ABBREVIATIONS
REFERENCE


1. INTRODUCTION

1.1 General Information
Nowadays more and more servers offer video information in Internet. Clients can download these video files, and then watch them. As we know that video files are large, so it requires a comparative large bandwidth to transmit them. However, in mobile network we face with the problem that is the lack of bandwidth. By using encoding methods, we are able to compress the video information efficiently. In this way, we can resort to the encoding methods in order to find a solution to this unbalanced situation.

There are two methods for using video files in mobile devices; one is downloading and the other is streaming. The downloading method is that after download the whole file, the clients play it. This goal is hard to achieve for PDA users, because PDA has low capacity of memory. However, comparing with mobile phone, PDA has its own advantages, such as large display screen. In this situation, it is meaningful to handle this problem for PDA users. Then streaming technology is put into use. Streaming technology is developing greatly in recent years. By using this advanced technology, people needn't to download the whole file before enjoy it. The initial parts of the file are played while the rest of the file is downloaded at the same time. Accordingly, the obvious advantage of streaming technology is the requirement of memory is sharply decreased.

1.2 Aim of the Study
The aim of the study is to analyze how to convert the video information into the suitable format for the mobile PDA users. Nettiradio Mikaeli, Finnish Broadcasting Company (YLE) offers video files for mobile PDA users to watch. And we will work out a solution for it.

We are capable of converting a video file into various types of file format by the purpose of compressing it. The main purpose of study is to learn different methods of coding. There are many kinds of codec in the market which is produced by famous companies. We can study on each codec and then by setting parameters of codec into different values, we are able to evaluate which one can give the client good performance of the video files in mobile environment.

1.3 Structure of the Study
In theory part, the principle of video coding and streaming technology will be learned. There are three companies who have made great progress in this field. I would like to pay attention to technologies of these three companies. They are Windows Media, Real Media and QuickTime. Each of them has its own proprietary production, such as compression tool for server side and file player for client side.

Chapter 2 will introduce the main video compressions. In chapter 3 streaming technology will be focused. Chapter 4 will refer to networks, both Wireless LAN and GSM/GPRS. And chapter 5 will learn terminal device for my research area, namely PDA.

In practical part, huge amount of testing will be done. We will create compressed files with different parameter. On the other hand, we will use different compression tools. Finally we can evaluate the effect of different parameters and tools to the QoS experienced by the PDA user.

Chapter 6 is to compare the compressed files with different settings. And then I will do more research of them in mobile environment in chapter 7 and 8.


2 VIDEO COMPRESSIONS

With the development of Internet, the technologies that transmit the video files through Internet have become remarkable. However, there are some difficulties in transmitting video files. In order to achieve the effective and high-quality video transmission in Internet, many advanced technologies are needed. Video compression and streaming are two important technologies in video transmission. This chapter refers to video compression, and then streaming technology will be focused in chapter 3.

2.1 Principle of Compression
The Figure 2.1 shows the process of compression. The data is compressed by the encoder before transmission, and then, after transmitting through channel, it's received and decompressed by the decoder.



Figure 2.1 The Compression Process (Based on Luther, 1997, Figure 9.1)

The algorithm is the detailed technical description of a specific compression technique. (Luther, 1997, p.226) Although the number of compression methods is limited, they can be combined in various ways, resulting in a vast number of possibilities for algorithms. Since the encoder and the decoder must use the equivalent processing, the standardization of algorithms becomes very important.

There are two kinds of compression: lossless compression and lossy compression. In lossless compression, the receiver can decode the signal which it receives exactly back to the original one before compression. On the other hand, lossy compression is to send the "good-enough" digital representation of data. After decoding it, the receiver can only get an approximation of the original digital media. (Topic, 2002, p.60) However, lossy compression is based on the human nervous system, when we see or hear the reproduced media, our perceptions ignore the deficiencies.

2.1.1 Lossless Compression
All lossless methods only depend on certain statistics about the data and they don't need to know what the data represent. Lossless compression methods are often used as part of a lossy algorithm by introducing approximations into their calculations. The key to lossless compression is that the process is reversible. The information that has been transmitted by the transmitter can be recovered by the receiver. (Jayant and Noll, 1984, p.16)

Run-Length Encoding
Data may contain the values which repeat many times. For example, if an image has an area of same color, adjacent pixels in that area have the same value. Such data can be compressed and represented by another code. Whenever a string of repeated values transmits, this code will be transmitted instead of it. This is RLE (run-length encoding). How does the decoder know where the RLE occurs? A reserved value solves this problem. Such a reserved value is called an escape code. (Luther, 1997, p.228) For example, in an 8-bit system, 255 may be the reserved value. When the reserved value is encountered, the decoder knows that the following two values show the pixel value and the times it repeats.

The Figure 2.2 is an example of RLE. Since in the incoming data, the value 028 repeats for 5 times. Then in the outgoing data, such a string of repeated value is represented by three codes. The first one which is 255 tells the decoder that now an RLE value occurs; the second one shows that the value is 028; the third one indicates this value repeats 5 times. It's obvious that if the length of repeated value is long enough, we can compress the data shapely by using this method.



Figure 2.2 Example of RLE (Based on Luther, 1997, Figure 9.2)

Pattern Matching
It is also known as dictionary-based compression. In some way, the principle of pattern matching is similar to RLE. It can recognize repeated patterns rather than just words. At the decompression end, the compressed data is decoded by looking up a lookup table (a code book). (Luther, 1997, p.229) Comparing with RLE, patterns can be matched even when they are located at different places in the data; that is the advantage of pattern matching. However, this method of compression is not useful by compressing audio and video because they often contain random noise.

The Figure 2.3 is an example of pattern matching.



Figure 2.3 Example of pattern matching (Based on Luther, 1997, Figure 9.3)

Statistical Coding
It's also called entropy coding. Sometimes certain values are used more often than others, so a coding system can be designed to transmit the high-occurrence values with a short (few bit) code, meanwhile, less frequently occurring values can use longer bit codes. (Luther, 1997, p.230) In this way, we can achieve a significant improvement in the transmission efficiency. The Morse code of Telegraphy system uses this principle. Huffman coding is the most common method for statistical coding and it's widely used in video compression algorithms. (Luther, 1997, p.230)

The Figure 2.4 is an example of Huffman coding. The encoding process consists of the following steps:
- List the symbols with their probabilities in descending order
- Connect the lowest two unused probabilities one by one until the probabilities merge to a single point (this process is called "binary fusion")
- Assign 1s and 0s to each of the pairs throughout the horizontal tree
- Read from the symbol on the left to the final single point on the right and then we can get the code for each symbol.



Figure 2.4 Example of Huffman coding (skylondaworks.com)

We should get to know that entropy coding works best when the source produces a highly skewed statistical distribution. (Calhoun, 2003, p.250) "It is only when the probabilities of the source symbols of the message are very different that we get a significant economy from the Huffman encoding process" (Sayood, 1996, p.69) In other words, if the source is highly structured data, with skewed statistics, then the entropy coding is more effective. If there are too much noises and random information in the incoming data, we gain less from this method.

Data Compaction
The Huffman coding which mentioned above is based on a prior knowledge of the source statistics. What should we do if we don't know the statistics in advance? There are three solutions to this question.
-  To modify the Huffman process to work adaptively
It becomes "a two-pass procedure: the statistics are collected in the first pass, and the source is encoded in the second pass" (Sayood, 1996, p.43) Indeed, coding ingenuity will find a way to accomplish the code development in a single pass soon, generating and modifying the Huffman codebook.
-  To construct a true dictionary for the source
Instead of transmitting the actual data, we transmit the index. In adaptive dictionary compression schemes, both the transmitter and the receiver build the identical dictionaries to process the data stream. In Figure 2.5, we can see the data compaction at both transmitter side and the receiver side.



Figure 2.5 Data compaction at TX and RX (Blahut, 1990)

-  The Ziv-Lempel algorithms, which were published in 1977 and 1978
The most popular adaptive dictionary techniques are based on these algorithms. (Calhoun, 2003, p.250) The encoder keeps a copy of encoded data and looks up each substring of data in its dictionary, and then it encodes the index but not the substring itself.

2.1.2 Lossy Compression
Unlike lossless compression, lossy compression must learn the data format and the importance to the application of every bit or word in the data. Besides, the viewer and the specified viewing condition are also necessary to get to know. (Luther, 1997, p.230)

Truncation
Truncation is to delete some less important bits from the samples. Sometimes it's also called requantizing. Video component samples should have at least 8bpp (bits per pixel) under ideal viewing condition. And under less-than-ideal viewing condition, this can be reduced to 6bpp without too much noticeable degradation. However, truncation is not very good tradeoff in terms of data reduction versus performance reduction because of degradation in quantizing SNR. (Luther, 1997, p.231)

Subsampling
This method is based on the fact that the human eyes are less sensitive to colors (chrominance) than brightness (luminance), so the color bandwidth (sample rate) can be reduced without viewers notice the loss.

Color Tables
By making the pixel value itself be an index in a table of color values that are selected from a larger number of bits/pixel, it's possible to reduce the number of bits/pixel.

Differential Coding
If the data is compressed by coding differences between samples rather than the samples themselves, fewer bits are needed to be transmitted than the original samples contained. Such coding process is called DPCM (Differential Pulse Code Modulation) and it is a member of a larger class called predictive coding. (Luther, 1997, p.233)

Predictive Coding
This technique is to use the predictor to predict the next sample from the previous sample or samples. Then the result of the predictor is compared with the next sample and only the difference is transmitted. At the decoder end, with the difference it receives and the identical predictor, the next sample can be reproduced. The codec can be seen in Figure 2.6:



Figure 2.6 The codec of predictive coding (Luther, 1997, Figure 9.7)

Speech Coding
The best methods for speech coding are on the basis of modeling the human voice track in electronic. Such techniques can work well with speech, but for general sounds, they are not very effective.

Transform Coding
Each transform should have an inverse transform - the transform is used during the compression and the inverse transform is used during the decompression. It's usually to consider an 8x8 block of pixels as a unit. By using transform coding, we can transform it to the frequency domain. And transform coding technique is based on the fact that high spatial frequencies are less visible than lower ones.

The prime transform is the DCT (discrete cosine transform). DCT is an orthogonal mathematical transform that is used to remove spatial redundancy by concentrating the signal energy into only a few coefficients. Mathematically, it is expressed in Equation 2.1:

F(u,v)=1/4C(u)C(v)∑∑f(x,y)cos[(2x+1)uπ/16]cos[(2x+1)vπ/16] (Equation 2.1)

where x and y are indices into the 8x8 block of pixel
          u and v are indices into the 8x8 of output coefficients

          C(w)=1/√2 for w=0
          C(w)=1 for w>0 (Arch C. Luther, 1997, P.236)

The Figure 2.7 illustrates the process of transform coding. Firstly, we get a 8×8 block of pixels from the image. Then we convert it into color value matrix. Finally, after DCT, we get the DCT coefficients.



Figure 2.7 The process of DCT (Fischer and Schroeder, 1999, Figure 2)

Zigzag ordering is often used when we list the coefficients. That is to put the coefficients into ascending-frequency order. Because the higher frequency components tend to zero or small values and they are not too important, they can be quantized coarsely without too much loss of information. Thus, only the components that have nonzero values will be transmitted. Consequently, there is a remarkable reduction in data transmission. After certain values, the rest coefficients are zero and they are usually encoded with RLE and entropy coding which are mentioned above. The Figure 2.8 shows the zigzag ordering.



Figure 2.8 Zigzag (Fiedler, 2000, Figure 3.1)

Motion Compensation
In motion video, most of a frame is not new information at all. Sometimes, it has the same background as others or only a tiny object moves a little in the image. In this case, the information which has already in the picture needn't to be transmitted again. The task is to find out which information is new or old. And this is motion compensation. However, because of huge amount of computation, the effectiveness of this technique is always limited. (Luther, 1997, p.237)

Intra-frame DCT (Discrete Cosine Transform) coding and motion-compensated inter-frame prediction are the two key techniques employed in an MPEG codec.

2.2 Main Compression Standards
Nowadays the most important compression standards in video transmission are H.261/H.263, M-JPEG and MPEG, and besides, Real Video, Windows Media Technology and QuickTime are widely used in Internet. Figure 2.9 shows a tree diagram of existing standards.



Figure 2.9 Multimedia Standards (Based on Palmers and Callahan and Marsh, 1991)

2.2.1 H.261/H.263
H.261/H.263 are put out by ITU-T (International Telecommunications Union).

H.261 was initially designed for achieving video meeting by ISDN. The algorithm for coding of H.261 is similar to the algorithm used in MPEG, but they are not compatible with each other. In real-time coding, H.261 requires less CPU operation than MPEG. (Deng, 2003, p.1) As a result, the algorithm is optimum for the bandwidth at the cost of quality of dynamic images.

The algorithm for coding of H.263 is the same as H.261, but with some improvement which can enhance performance and correction capability. (Deng, 2003, p.1) Now H.263 has basically replaced H.261.

2.2.2 M-JPEG
M-JPEG (Motion-Joint Photographic Experts Group) technology is motion & still images compression technology. It treats motion video sequence as continuous still images. (Deng, 2003, p.1) This kind of compression method can compress each frame independently. Every frame can be edited randomly. Besides, the encoding and decoding are symmetric. They can be accomplished by same hardware and software.

However, M-JPEG only aims at the intra-frame spatial redundancy, it don't compress the inter-frame temporal redundancy. So it has the disadvantage of low compression ratio. (Deng, 2003, p.1) Moreover, the compression method of M-JPEG is not an absolutely uniform compression standard. Different manufacturers have their own versions of M-JPEG, so it's impossible to transmit such data between servers and clients in Internet.

2.2.3 MPEG Series
MPEG is the abbreviation of Motion Picture Exports Group, whose aim is to support coding of moving pictures and associated audio. So far, it has more than 300 members including some well-known companies, such as IBM, SUN, BBC, NEC, INTEL, AT&T. Each standard set by MPEG has its special target and application. At present, it has already put out MPEG-1, MPEG-2, MPEG-4, MPEG-7 and MPEG-21. (Deng, 2003, p.1)

MPEG-1 was published in August, 1993. It was originally designed to play the stereo audio, and then studied on full motion video recordings on CD players. (Deng, 2003, p.1) Its transmission rate is 1.5Mbps.

MPEG-2 was put out in November, 1994. It is considered as "Generic coding of moving pictures and associated audio information". And it also investigated the greater input-output flexibility, data rates and system considerations such as transport and synchronization which was neglected in MPEG-1. (Deng, 2003, p.2) MPEG-2 standard is targeted for SDTV (Standard Digital TV) and HDTV (High-Definition TV). So the encoding rate is from 3Mbps to 100Mbps. MPEG-2 is especially applicable to the coding and transmission of digital TV broadcast.

Table 2.1 shows the bandwidth requirements for video compression standards which mentioned above.

Table 2.1 Bandwidth requirements for video (Jha and Hassan, 2002, Table 1.3)

EncodingBandwidthResolutionStandard
H.26164 Kbps-2 Mbps177x144QCIF (conference)
352x288CIF (VHS quality)
MPEG3-8 Mbps352x288CIF (VHS quality)
15-25 Mbps720x486CCIR601 (PAL)
60-100 Mbps1920x1080HDTV
MPEG-11.2-3 Mbps352x288CIF (VHS quality)
5-10 Mbps720x486CCIR601 (PAL)
20-40 Mbps1920x1080HDTV
MPEG-2 (H.262)1-2 Mbps352x288CIF (VHS quality)
4-5 Mbps720x486CCIR601 (PAL)
8-10 Mbps960x576EDT
20-30 Mbps1920x1080HDTV

The first version of MPEG-4 was published in February, 1999. In the end of 1999, the second version came out and became an international standard in the beginning of 2000. Comparing to MPEG-1 and MPEG-2, MPEG-4 has its own advantages, for example, interoperability based on content, high-efficient compression. (Deng, 2003, p.2) It's obvious that these characteristics accelerate the development of multimedia application. Many fields gain benefit from this phenomenon, such as broadcast TV, interoperable video game and remote video monitor. Basic block diagram of MPEG-4 video coder is showed in Figure 2.10.



Figure 2.10 Basic block diagram of MPEG-4 video coder (Koene, 2001, p.53)

MPEG-7 standard is called as "Multimedia Content Description Interface" and was put out in October, 1998. It offers standardized descriptions for various multimedia information. Such descriptions are related with the content of information and it allows fast and effectively checking the information which users have interest in. (Deng, 2003, p.3)

With the emergence of e-business, new problems come out. How to protect the quality of service? How to protect the knowledge property right of multimedia information? Such problems required a structure to ensure the simplification of digital media consumption and deal with the relationship between the factors in digital consumption. (Deng, 2003, p.3) MPEG-21 was put forward in this situation.

2.2.4 Others
There are also some popular technologies, such as RealNetworks, Windows Media Technology and QuickTime. These three technologies will be discussed in details later in chapter 3 about their streaming technologies.


3 STREAMING TECHNOLOGY

Streaming technology can be considered as pseudo-real-time consumption of multimedia information. (Nokia, 2002, p.197) By using this technology, once a client makes a connection with the server and begins to stream the media at a payload rate, the client can play the video file immediately.

Figure 3.1 shows the structure of streaming media.



Figure 3.1 Structure of streaming media
(Media Working Group; the Greater Cincinnati and Northern Kentucky Film Commission; The Union Institute, Cincinnati, OH, 2002, p.9)

3.1 Why Use Streaming Technology?
Why streaming technology becomes popular nowadays? Because it has multiple advantages as follow:
-  free storage space of local hard disk drive and other memory
-  enable to offer larger media files for clients as well as live service
-  handle the issues related to illegal copying of content well

3.2 Seven Areas regarding Streaming Video
A video streaming system typically consists of seven areas, (Wang, Ostermann and Zhang, 2002, p.520) as illustrated in Figure 3.2.



Figure 3.2 Architecture for video streaming
(Based on Wang, Ostermann and Zhang, 2002, Figure 15.1)

3.2.1 Video Compression
Video compression schemes can be classified into two groups: scalable and nonscalable video coding. Scalable video coding scheme produces a compressed bit stream, only parts of which are decodable. Compared with decoding the whole bit stream, decoding part of the compressed bit stream regenerates pictures with degraded quality, or smaller image size, or smaller frame rate. (Wang, Ostermann and Zhang, 2002, p.522) And the scalable video coding can cope well with the bandwidth fluctuations in the Internet. (Ammar, 1998) On the contrary, nonscalable video is more sensitive to bandwidth change, since it can not adapt its video representation to bandwidth fluctuations. (McCanne and Jacobson and Vetterli, 1996) Moreover, scalable video representation is an effective method to achieve efficiency and flexibility for multicasting video over heterogeneous networks. (Ammar, 1998) Because of these reasons, all streaming video services use scalable video coding techniques.

Basic Modes of Scalability
Scalability video coding is typically accomplished by providing multiple versions of video, in terms of amplitude resolution (quality scalability or SNR scalability), spatial resolution (spatial scalability), temporal resolution (temporal scalability), frequency resolution (frequency scalability or data partition), or combinations of these options. (Wang, Ostermann and Zhang, 2002, p.350) All of these types of scalable video consist of a base layer (BL) and one or more enhancement layers (ELs), according to their contribution to quality. (Markopoulou and Han, 2001)

Quality Scalability is defined as the representation of a video stream with varying accuracies in the color pattern. (Wang, Ostermann and Zhang, 2002, p.350) And it is accomplished by quantizing the color values with increasingly finer quantization stepsizes. Since different quantization accuracies lead to different PSNRs (Power Signal-to-Noise Ratio) between the original and the quantized video, this type of scalability is also refered to as SNR scalability. Figure 3.3 shows the temporal dependency as well as the dependency between BL and EL.



Figure 3.3 SNR scalability (Markopoulou and Han, 2001, Figure 1)

Spatial scalability is defined as the representation of the same video in varying spatial resolutions or sizes. (Wang, Ostermann and Zhang, 2002, p.353) Its mechanism of working is that by progressively decoding the additional layers, the viewer can increase the spatial resolution of the image, up to the full resolution of the original image. Figure 3.4 illustrates that direct prediction can be made from the corresponding base layer picture, appropriately scaled, or motion compensated prediction can be made from previous pictures within the enhancement layer. In Figure 3.3, EI stands for Enhancement-I (EI) picture. It is an enhancement layer picture that it's only upward predicted from a reference layer picture. Similarly, a picture that can be forward predicted from a previous enhancement layer picture or upward predicted from the reference layer picture is referred to as an Enhancement-P (EP) picture. (Gallant and Kossentini)



Figure 3.4 Possible prediction modes for spatial scalability, two layers
(Gallant and Kossentini, Figure 1)

Temporal scalability is defined as the representation of the same video in varying temporal resolutions or frame rates. (Wang, Ostermann and Zhang, 2002, p.356) It is encoded in this way: making use of temporal up-sampled pictures from a lower layer as a prediction in a higher layer. The only difference between spatial scalable codec and temporal scalable codec is that the spatial scalable codec uses spatial down-sampling and spatial up-sampling, whereas the temporal scalable codec uses temporal down-sampling and temporal up-sampling. The simplest way to perform temporal down-sampling is by frame skipping. And temporal up-sampling can be accomplished by frame copying.

Frequency scalability is a technique that by including different frequency components in each layer to represent a video frame in multiple layers. The base layer contains low-frequency components, and other layers contain increasingly higher-frequency components. In this way, the base layer will provide a blurred version of the image, and the addition of enhancement layers will produce increasingly sharper images.

Quality, spatial, temporal and frequency scalability are basic scalable mechanisms. They can be combined to get finer granularity.

Fine-granularity scalability (FGS) is a coding method. Its rate and quality increment are much smaller. Bit stream can provide continuously improving video quality with every additional bit. The underlying coding method is called embedded coding. (Wang, Ostermann and Zhang, 2002, p.358) It's obvious that FGS and embedded coding can adapt to bandwidth fluctuation more effectively than any other scalable method. Figure 3.5 shows the architecture of FGS.



Figure 3.5 Architecture and principle of base layer and enhancement layer in FGS MPEG-4 (Vanderschaar, 2001, Figure 1)

Object-Based Scalability
With development of multimedia in more and more applications on networks, new multimedia services such as interactivity, manipulation and scalability are necessary. To meet these requirements, digital image/video coding has changed from block based to object based. (MPEG-4 Applications, 1998, p.1) The idea of objects has provided a lot of functionality besides coding efficiency, such as manipulation and scalability. Meanwhile, object-based wavelet coding schemes have become important and gained widespread acceptance. One major pre-processing objective for any object-based coding is image/video segmentation and shape extraction. (Tab, Mertins and Danyali)

3.2.2 Application-layer QoS Control for Streaming Video
Application-layer QoS control maximizes video quality in the case of packet loss and change in current bandwidth. It has two techniques, namely congestion control and error control. (Wang, Ostermann and Zhang, 2002, p.522) These techniques are employed by the end systems, and don't require QoS support from routers or networks.

Congestion Control
By applying congestion control, we can reduce packet loss and delay. There are two mechanisms for congestion control: rate control and rate shaping. Rate control tries to minimize network congestion and the amount of packet loss by matching the rate of the video stream to the available network bandwidth. On the other hand, rate shaping is used to force the source to send the video stream at the rate dictated by the rate control algorithm. (Eleftheriadis and Anastassiou, 1995)

Figure 3.6 shows classify of rate control.



Figure 3.6 Classify of rate control

The model-based approach is based on a throughput model of a TCP connection. And the throughput of a TCP connection can be characterized by Equation 3.1. And this equation is used to determine the sending rate of the video stream.

  (Equation 3.1)

where λ is the throughput of a TCP connection
          MTU (Maximum Transmission Unit) is the packet size used by the connection
          RTT is the round-trip time for the connection
          p is the packet-loss ratio experienced by the connection (Wang, Ostermann and Zhang, 2002, p.523)

There are many kinds of rate shapers or filters: (Yeadon, Garcia, Hutchison and Shepherd, 1996)
-  Codec filters
They compress and decompress a video stream.
-  Frame-dropping filters
They can distinguish frame types and drop frames according to importance.
-  Layer-dropping filters
They can distinguish and drop layers according to importance.
-  Frequency filters
They operate in the frequency domain. (For example, DCT coefficients)
-  Requantization filters
They first extract the DCT coefficients from the compressed video stream through dequantization. Then they requantize the DCT coefficients with a larger quantizer stepsize, resulting in rate reduction.

Error Control
Error control techniques are classified into four categories: transport-level error control which includes FEC and delay-constrained retransmission, encoder error-resilient coding, decoder error concealment, and encoder-decoder interactive error control. (Wang, Ostermann and Zhang, 2002, p.525)

Transport-level error control is the most important part of error control. It provides a basic QoS level that can be further improved by additional error control mechanisms at the encoder and decoder. (Wang, Ostermann and Zhang, 2002, p.485) FEC (Forward Error Correction) is well known for both error detection and correction in data communication. (Lin and Costello, 1983) FEC is a low-level error control mechanisms, and delay-constrained retransmission belongs to upper-level transport technique. Retransmission has been successfully used for non-real-time data transmission, but it has been considered unacceptable for real-time video applications because of delay.

The design goal in error-resilient coding is to achieve the best decoded video quality for a given amount of redundancy, or minimize the incurred redundancy while maintaining a prescribed quality level. (Wang, Ostermann and Zhang, 2002, p.489) Both of them are under an assumed channel environment.

When packet loss is detected, the decoder can employ error concealment to conceal the lost data and make presentation more pleasing to human eyes. Since viewers can tolerate a certain degree of distortion in video signals, error concealment is a feasible technique for handling packet loss. (Wang and Zhu, 1998)

In the techniques which mentioned above, the encoder and decoder operate independently. But if a backward channel from the decoder to the encoder is available, we can achieve better performance if the transmitter and the receiver cooperate in the process of error control. So encoder-decoder interactive error control is put into use.

3.2.3 Continuous Media Distribution Services
Continuous media distribution services include network filtering, application-level multicast and content replication.

Figure 3.7 illustrates an example of network filtering. Router has no knowledge of the format of the media stream and may randomly discard packets. And filter receives the client's requests and adapts the stream sent by the server accordingly. The filters can be placed on the nodes that connect to network bottlenecks, and there can be multiple filters along the path from a server to a client. Figure 3.8 shows a system model for network filtering.



Figure 3.7 Network filtering
(Based on Wang, Ostermann and Zhang, 2002, Figure 15.5)



Figure 3.8 A system model for network filtering
(Wang, Ostermann and Zhang, 2002, Figure 15.6)

The advantage of application-level multicast is that it breaks the "boundaries" between scalability, network management, and support for congestion control.

Content replication has two forms, namely mirroring and caching. Both of them try to place content closer to the clients and they have the following advantages: (Wang, Ostermann and Zhang, 2002, p.532)
-  reduced bandwidth consumption
-  reduced load on servers
-  reduced latency on clients
-  increase availability

3.2.4 Streaming Servers
Typically, a streaming server consists of three subsystems: (Wang, Ostermann and Zhang, 2002, p.533)
-  Communicator
It involves the application layer and transport protocols implemented on the server.
-  Operating system
It must be a real-time operating system
-  Storage system
Since it is designed for multimedia, it must meet the requirements such as high throughput, large capacity and fault-tolerance.

3.2.5 Media Synchronization Mechanisms
There are three levels of synchronization: (Wang, Ostermann and Zhang, 2002, p.540)
-  Intrastream synchronization
The lowest layer of continuous media or time-dependent data is the media layer. The unit of the media layer is the LDU (Logical Data Unit), such as a video frame. Intrastream synchronization is to maintain the continuity of LDUs.
-  Interstream synchronization
The second layer of time-dependent data is the stream layer. The unit is a whole stream. Interstream synchronization is to maintain temporal relationships among different continuous media.
-  Interobject synchronization
The highest layer of a multimedia document is a object layer, which integrates streams and time-independent data such as text and still images. The target of interobject synchronization is to start and stop the presentation of the time-independent data within a tolerable time interval.

3.2.6 Protocols for Streaming Media
Protocols are designed and standardized for communication between clients and streaming servers. According to their functionalities, the protocols directly related to streaming video in the Internet can be classified into three categories: (Wang, Ostermann and Zhang, 2002, p.542)
-  Network-layer protocol
It provides basic network service support.
-  Transport protocol
It provides end-to-end network transport functions for streaming applications.
-  Session control protocol
It defines the messages and procedures to control the delivery of multimedia data during an established session.

Figure 3.9 illustrates protocol stacks for media streaming. As we can see from this figure, IP belongs to network-layer protocol. UDP and TCP are lower-layer transport protocols, whereas RTP and RTCP are upper-layer transport protocols. And RSTP is a session control protocol.



Figure 3.9 Protocol stacks for media streaming
(Wang, Ostermann and Zhang, 2002, Figure 15.13)

3.2.7 Streaming Video over Wireless IP Networks
Due to high bandwidth fluctuations and bit-error rates, streaming video over wireless IP network requires network-aware applications in the sender of a wireless terminal and the base station of the wireless network. They shape the scalable video bit stream according to the currently available bandwidth. (Wang, Ostermann and Zhang, 2002, p.555) Figure 3.10 illustrates the architecture for transporting scalable video from a mobile to a wired terminal. It contains a network-aware mobile sender, an application-aware base station, and a receiver.



Figure 3.10 An architecture for transporting scalable video from a mobile to a wired terminal (Wang, Ostermann and Zhang, 2002, Figure 15.14)

On the contrary, Figure 3.11 illustrates the architecture for transporting scalable video from a wired to a mobile terminal. And from Figure 3.10 and Figure 3.11, we can know the architecture for transport scalable video between mobile terminals.



Figure 3.11 An architecture for transporting scalable video from a wired to a mobile terminal (Wang, Ostermann and Zhang, 2002, Figure 15.15)

3.3 Various Streaming Technologies
As the users are in different network condition, the transmission speeds are various. Furthermore, because there will be congestion in Internet, the transmission speed will change randomly. So, a new research area emerges. That is self-adaptive transmission. There are two solutions to this problem. (Xie and Xu, 2000, p.1)

One method is that encoder stores multiple bit rates into one file. The request from client is received by Real server and meanwhile server can get to know the information about client's bandwidth. According to the bandwidth, server transfers the corresponding part of file to the client. In the way, client can get the highest quality of transmission.

The other solution is that there is only one compressed version in the server. When the network is crowded, only the most important part of encoded data is transmitted. Then the client can maintain stable performance.

SureStream technology is a representative production of RealNetworks Company. It uses the former method.

Microsoft Company puts out a streaming technology whose name is intelligence stream. This technology is integrated by these two methods. (Xie and Xu, 2000, p.1)

3.3.1 Microsoft Windows Media Technologies
As shown in Figure 3.12, Microsoft Windows Media technologies have three main components, namely Windows Media Tools, Windows Media Services and Windows Media Player, taking charge of creation, distribution and playback of streaming media respectively.



Figure 3.12 Windows Media technology (Bases Topic, 2002, Figure 2.14)

Microsoft Windows Media Server has a technology called Intelligent Streaming. It has many functions, such as multidata rate encoding, intelligent retransmission, and a video playback filter to detect the network condition and adjust the video stream automatically in order to get the best quality. (Topic, 2002, p.86)

Since the traffic in internet is fluctuating, the condition of network is changing all the time. Sometime, whenever there is congestion in internet, the play will run out of material which results in rebuffering. Intelligent streaming solves this problem by sending a stream with the suitable bandwidth when the user connects, then it will dynamically adjusts the bit rate according to the change of network.

There are three important techniques used in intelligent streaming.

Multi Data Rate Encoding
Like RealNetworks' SureStream, when the bandwidth reduces, the playback degrades gracefully. It encodes ten discrete, user-definable video streams and one audio stream into a single Windows Media stream. (Topic, 2002, p.87) The video streams have same content but different bit rates. When a client connects to the server, only one of these video streams can be received which is most appropriate for the current network condition.

Intelligent Bandwidth Control
There are several steps in the process. Each step is a strategy to modify the bit rate in order to keep the stream continuous regardless of the bandwidth. As the condition of network getting worse, the server adopts the strategies one by one to optimize the bit rate according to the current bandwidth. (Topic, 2002, p.87) The strategies are as follows: When the bandwidth decreases, the server switches to a lower bit rate automatically; when the bandwidth improves, the server switches to a higher bit rate but never higher than the original one. When the condition gets worse and worse, the server minimizes the bit rate of video stream to ensure that the audio stream is continuous. If necessary, the server can give up transmitting the video stream. If even the audio stream begins to degrade, the reconstruction of portions of stream is needed to maintain the quality.

Intelligent Image Processing
Blockiness often occurs during the decoding of high-bit-rate streams. A streaming media codec, such as the Windows Media Video codec, encodes an image by breaking it up into pixels. The lower the bit rate, the fewer the pixels. When too few pixels are used to reproduce an image, the pixels become visible as blocks. An intelligent video filter can smooth the edges of blocks in the image and erase certain other artifacts, such as ringing, so that the outgoing video is more pleasing to human eyes. (Topic, 2002, p.88)

3.3.2 RealNetworks
SureStream is the technology used in RealNetworks production. It allows switching to a lower-bandwidth encoding in a RealAudio or RealVideo clip to compensate for network congestion.

With RealSystem's SureStream technology, we can encode a RealAudio or RealVideo clip for up to six different bandwidths by using new RealSystem G2 codec. (RealNetworks, 1998, p.3) The webpage links to a single clip, and when a user clicks the link, RealPlayer and RealServer determine which encoding to use according to the available bandwidth. The Figure 3.13 illustrates this process.



Figure 3.13 SureStream Clip Encoded for Multiple Bandwidths
(RealNetworks, 1998, Figure 3.5)

RealServer and RealPlayer can adjust the stream to compensate for network condition. As shown in Figure 3.14, if a fast connection becomes slow because of network traffic, RealServer automatically switches to a lower bandwidth encoding to prevent the playback from stopping. When the congestion clears, RealServer switches back to the higher bandwidth encoding.



Figure 3.14 Switching Bandwidths during Network Congestion
(RealNetworks, 1998, Figure 3.6)

We can create multiple versions of the clips for different bandwidths. A SMIL (Synchronized Multimedia Integration Language) file is used to designate a bandwidth connection for each of the different groups. (RealNetworks, 1998, p.3) When a user clicks the webpage link, RealPlayer receives the SMIL file and chooses which clip group to play based on its own connection speed.

The Figure 3.15 illustrates a SMIL file that lists two choices between clips, a high-bandwidth choice and a low-bandwidth choice. RealPlayer chooses which clip to receive in consideration of its connection speed and the SMIL file's bandwidth parameters.



Figure 3.15 Bandwidth Choices through SureStream Clip and SMIL
(RealNetworks, 1998, Figure 3.7)

Because each connection speed uses a different set of clips, RealServer can't switch between the different encodings as it can with a single SureStream clip. However, RealServer adopts other techniques to compensate for network congestion. Its advanced stream thinning capabilities let it drop low-priority data to decrease the bandwidth temporarily. (RealNetworks, 1998, p.3) When the congestion clears up, it continues to stream all the data.

3.3.3 QuickTime and Sorenson
Apple Company invented QuickTime as a patent and track-based container format for multimedia files. Every track delivers different element of the content, for example, audio, video, interactivity (such as Flash) and HTML behavior. (Topic, 2002, p.96)

The QuickTime streaming server has its own patented technology. That is "Skip Protection". It protects stream from disruptions in internet and gains a better quality of playback. (Apple, 2004) Its way of working is by using any excess bandwidth to buffer data faster than real time on the client device. In that way, whenever there is something wrong with transmission, the play can continue from its local buffer. Finally, a smooth and high-quality media streaming is achieved. Besides, when packets are lost, only the lost packets will be retransmitted. In this way, impact to network traffic is reduced.


4 NETWORKS

There are several wireless networking technologies, sometimes competing, sometimes complementing, that enable the mobile wireless Internet. Table 4.1 shows the comparison of various wireless data networks. Later in this chapter, we will focus on Wireless LAN and GSM/GPRS.

Table 4.1 Comparison of various wireless data networks
(Jha and Hassan, 2002, Table 11.1)

NetworkSpeedRangeSpectrumSwitchingApplication
802.11b11 Mbps10-20mUnlicensed (free)PacketLAN
HIPERLAN23.5 Mbps50mUnlicensed (free)PacketLAN
Bluetooth1 Mbps10-100mUnlicensed (free)PacketPAN,
home network
GSM9.6 Kbps35mLicensed (expensive)CircuitOutdoor
GPRS28.8 Kbps35mLicensed (expensive)PacketOutdoor
3G144/384 Kbps,
2 Mbps
10-35mLicensed (expensive)PacketIndoor,
outdoor

4.1 Wireless Local Area Network
Wireless LANs are aimed at slow mobility indoor communication, and achieve data rates similar to the existing wired LANs. (Nokia, 2002, p.185) Because of the freedom of mobility and the cableless connection, wireless LAN gains a rapid success in the market. Most WLAN terminal devices are laptops and PDAs (Personal Digital Assistants) with separate WLAN network adapters.

Either IP or ATM protocols can be used, which are referred to as mobile IP and wireless ATM protocols respectively. The main challenges in employing conventional IP and ATM protocols to wireless environments are providing continuous network connectivity to mobile nodes and handling hand-offs. (Wang, Ostermann and Zhang, 2002, p.482) When the mobile terminal switches from the coverage area of one access point to another, hand-off occurs. Reachable bit rates depend on the carrier frequencies. For example, LAN conforming to the IEEE 802.11 standard can have bit rates up to 11 Mbps with lower payload rate. When the user is close to the access point, the connection in a wireless LAN can be very good with the BER (Bit-Error Rate) lower than 10-5. Whereas, when the user is far from the access point, it can be very bad with a BER higher than 10-2. Besides, the packet loss rates also depend on the packet size and the error detection and correction methods incorporated within the packet. There are two modes for wireless LAN in IEEE 802.11b standard, namely infrastructure and Adhoc. (smartBridges, 2001) In infrastructure mode, all the wireless stations communicate with each other through a set of another device called AP (Access Point). All communications in the BSS are routed through APs. Thus, infrastructure mode is also referred as infrastructure BSS. However, there is no AP used in Adhoc mode, BSS communicate with each other on peer to peer basis. This type of network is often formed on temporary basis or in technical terms. This mode is also referred as Independent BSS or IBSS.

4.1.1 Infrastructure Mode
Figure 4.1 illustrates the basic architecture of an infrastructure-based 802.11b wireless LAN. In this figure, MHs (Mobile Hosts) indicates computers and wireless devices while APs stand for access points. A building or any specific indoor area is serviced through a set of APs. Each AP provides the wireless LAN connectivity to any MH within a certain range. And a MH which wants to communicate with a nearby AP must install a wireless LAN card. The APs themselves are connected through a wired backbone that has a gateway to the global internet.



Figure 4.1 The Basic Architecture of an Infrastructure-Based 802.11b Wireless LAN (Based on Jha and Hassan, 2002, Figure 11.2)

IEEE 802.11b is the most popular standard for wireless LANs. It operates in the free, unlicensed ISM (Industrial, Scientific and Medical) band. In this way, to operate an IEEE 802.11b wireless LAN, there is no need to obtain a license from any authority. This makes such wireless LANs even more popular. The rate supported by 802.11b is 11 Mbps, which is on the par with the traditional 10 Mbps Ethernet LANs. (Jha and Hassan, 2002, p.272)

4.1.2 Adhoc Mode
An IEEE 802.11b LAN can also be rapidly deployed without any infrastructure (no APs and no wired backbone) to provide temporary network services in any desired location. Such infrastructureless installations are known as Adhoc network. (Jha and Hassan, 2002, p.272) By loading some Adhoc routing software into the devices, it can support routing of data packets from one device to another outside the range of the wireless card.

The Adhoc allows travellers to access the web through the advanced new communication applications (PDA applications, GPRS and UMTS). (Malliou, Miliarakis, Stavros, Sotiriou and Stratakis, 2002) These new applications allow for fast transmission of data (text, audio, picture and video) through the mobile device (phone or palmtop). The Adhoc system will serve users regardless of time and location.

The Adhoc system will fulfill the following basic requirements: (Malliou, Miliarakis, Stavros, Sotiriou and Stratakis, 2002)
-  Interactivity
-  Interdisciplinarity
-  Unobtrusiveness
-  Availability
-  Adaptability
-  Usefulness
-  Suitability
-  Easy to use

4.2 GSM/GPRS
The basic GPRS (General Packet Radio Service) wireless access network used in the GSM (Global System for Mobile Communications). It employs TDMA (Time Division Multiple Access) and offers a payload bit rate ranging from 9-21.4 kbps using a single time slot. Enhanced GPRS wireless access technology, which is know as enhanced data rates for GSM evolution or EDGE, can provide bit rates ranging from 8.8-59.2 kbps. (Chang, 2001) By using multiple time slots, the raw bit rate can reach as high as 170 kbps. The available data rate depends on the location. When the user is closer to the base station, it gets higher data rate.

Figure 4.2 is the architecture of the traditional cellular network. As shown in this figure, MHs are connected to the network through the base stations. And each BS forms a cell around it. BS in cellular networks plays the similar role as the AP in the wireless LANs. Each BS is connected to a BSC (Base Station Controller) via fixed links. One of the BSC's functions is to perform a hand-off between BSs when an MH exits a cell and enters another. The BSCs together with other devices form the fixed switching backbone of the cellular networks.



Figure 4.2 The Basic Cellular Network Architecture
(Based on Jha and Hassan, 2002, Figure 11.3)

The main function of GPRS is to provide medium-speed data service, but the specifications also allow for the possibility of supporting voice group and broadcast service. (Lloyd-Evans, 2002, p.96) GPRS has been defined in two stages: the first was only for GSM; while the second has both GSM and UMTS (Universal Mobile Telecommunication System) interfaces. (ETSI, 2001)

Three operational modes are defined for GPRS mobiles: (Lloyd-Evans, 2002, p.96)
-  Class A
The mobile is able to support simultaneous transmission of both PS (Packet-Switched) and CS (Circuit-Switched) traffic using different timeslots of GSM TDMA.
-  Class B
The mobile is able to attach to both PS and CS services at the same time and receive pages for both types, but it can only transmit traffic of one type at a time.
-  Class C
The mobile can only handle packet traffic.

The ability of GPRS mobiles to make use of multiple timeslots and also varies them. This leads to the definition of a multislot class. This is based on the numbers of slots that can be used for transmission and reception, with a further distinction on the time required to get ready to transmit or receive. (Lloyd-Evans, 2002, p.96) Multislot class numbers range from 1 to 29, where 1 is for a mobile that is able to use only a single slot and 29 is for a mobile that is able to transmit and receive on all its eight slots.


5 TERMINAL DEVICE - PDA

By definition, PDA stands for Personal Digital Assistant. (Tull, 2004) Since a PDA can not replace a computer, it always serves as an extension to a PC. (Schnyder and Pharm) Because of its small size, portability and ease of use, PDA is a convenient way to keep daily schedules and take notes. Recently, with the development of multimedia and other technologies, to watch the video file from Internet is a new function for PDA.

5.1 Classification
PDAs are classified into two major categories: hand-held computers and palm-sized computers. The major differences between the two are size, display and mode of data entry. Compared to palm-sized computers, hand-held computers tend to be larger and heavier. They have larger liquid crystal displays (LCD). And they use a miniature keyboard, usually in combination with touch-screen technology, for data entry. On the contrary, palm-sized computers are smaller and lighter. They have smaller LCDs and employ stylus/touch-screen technology and handwriting recognition programs for data entry. (Freudenrich, p.2)

5.2 PDA Parts
Figure 5.1 illustrates that a PDA consists of many parts, namely microprocessor, OS, memory, battery, LCD display, input device, input/output ports and desktop PC software. Later, we will discuss each part a bit in detail.



Figure 5.1 The parts that can make up a PDA (Freudenrich, p.2)

5.2.1 Microprocessor
Like in PC, microprocessor is the brain of PDA and coordinates other parts of PDA according to programmed instructions. However, microprocessor used in PDA is smaller and cheaper than the one used in PC. It is known that the frequency of microprocessor for PDA is about 16-75 MHz, (Freudenrich, p.3) while the one for PC is up to 1.4 GHz. Although the microprocessor for PDA is quite slower, it is adequate for the tasks that PDA performs. So the benefits of small size and low price outweigh the cost of slow speed. Figure 5.2 shows a kind of microprocessor for PDA.



Figure 5.2 Motorola Dragonball, microprocessor in a Palm M100 (Freudenrich, p.3)

5.2.2 Operating System
PDA can be classified based on their OS (Operating System). There are two most popular operating systems in North America: one is PalmOS from Palm Company, and the other is PocketPC which uses the Windows CE operation system owned by Microsoft. (Tull, 2004) In addition, there are other platforms, such as EPOC which is more popular in Europe, Psion, and some OS which are capable of running Linux. (UCSD, 2003) But, today most PDAs in marketplace use either PalmOS or PocketPC platform. Table 5.1 is the comparison of these two OS.

Table 5.1 The comparison of PalmOS and PocketPC

PalmOS (Palm)PocketPC (Microsoft)
ExamplesPalm, Handspring Visor, Sony's CLIECheaper than PocketPC, More software and accessories available
Market Share70%10%
PartnershipIBM, QualComm, SonyCasio, HP, Compaq
Main AdvantagesCompaq iPAQ, Dell Axim, Toshiba PocketPCBrighter displays, Easier to learn for Windows users, The coming onset of broadband wireless

5.2.3 Memory
A PDA doesn't have hard drive. It stored data in a ROM (Read-Only Memory) chip, whose content can be retained even when the power is shut down. All PDAs use solid-state memory: some use static RAM (Random-Access Memory) and some use Flash memory; some even employ removable forms of memory. (Freudenrich, p.3) Figure 5.3 shows an inside view of a PDA. In the middle of the single-layer circuit board is the microprocessor, and to the left and above are the memory chips.



Figure 5.3 An inside view of a PDA (Freudenrich, p.3)

PDAs usually come with 2 MB minimum of memory. However, many application programs take up memory space, so more advanced models usually have more memory (5 to 32 MB). Also, PocketPC takes more memory space so that PDAs with this operating system usually have 16 or 32 MB. In some PDA models, the amount of memory is upgradeable. (Freudenrich, p.3)

5.2.4 Battery
PDAs are powered by batteries. Some models use alkaline (AAA) batteries, while others use rechargeable batteries (lithium, nickel-cadmium or nickel-metal hydride). (Freudenrich, p.3)

5.2.5 LCD Display
The LCD screens for desktop or laptop computers are only used as output devices, but PDAs use their screens for both output and input. PDA displays have the following features: (Freudenrich, p.3)
-  LCD, enhanced LCD, or color super-twist nematic (CSTN) types
-  pixel resolutions (160 x 160, 240 x 320)
-  black-and-white (16 grayscale) or color (65,536 colors)
-  passive or active matrix:
Active matrix displays have sharper images and are easier to read.
-  reflective or backlit:
Backlit screens are good for reading in low light.

5.2.6 Input Device
Figure 5.4 shows the input technologies used in PDA. Among these technologies, voice recognition technology is a more advanced one. When people speak into a built-in microphone, the software can convert the voice waves into data.



Figure 5.4 Input technologies for PDA

5.2.7 Input/Output Port
As mentioned above, PDA always serves as an extension device, but not a stand-alone device. So the connectivity between PDA and other devices becomes important. After connected to PC, the PDA can perform some basic functions, such as regular backups, loading and updating software, transferring information. By connecting to a printer, it's easy to print the files in the PDA. The way of connection for PDA can be classified into two groups: wired and wireless connection.

Wired Connection
The most common method for transmitting data between PDA and PC is via a cable through a serial port. (galaxyphones, 2004)

Wireless Connection
There are four wireless technologies used in PDAs, namely infrared, Bluetooth, 802.11b, and 2.5G (which can be found in PDA/phone combination devices). Each type has its best uses, and the technologies are not exclusive. (Brown, 2003, p.1)

-  Infrared
Many PDAs can communicate with each other through an infrared port. The infrared ports use the same technology as the remote control for TV or VCR (Video Cassette Recorder). But it offers a higher data transfer rate which is about the same rate as a parallel port. The infrared port on a PDA should conform to the IrDA standard specified by the Infrared Data Association. (galaxyphones, 2004)

However, IR has a short range. Its working condition requires that devices are in close proximity which is about 10 feet, and they must have a line-of-sight connection. Ever since PDAs employ IR, the most common use of the technology is to synchronize data at a rate of 4 Mbps. (Brown, 2003, p.2)

-  Bluetooth
In the aspect of short wireless range, Bluetooth has the same disadvantage as IR, which is up to about 30 feet. However, to connect with Bluetooth devices doesn't require a direct line-of-sight connection as IR. Bluetooth has a one-way data rate of 720 Kbps. (Brown, 2003, p.3)

-  802.11b
Thanks to the current 802.11 technology, wireless networks exist everywhere. Therefore, the usefulness of equipping a PDA with 802.11 capability has increased. We can browse PDA-friendly web sites while we are out and check the information we need from Internet.

Although only a few PDAs have integrated 802.11, most can easily be equipped with add-ons (usually via CompactFlash adapters, with SD adapters coming soon) Today, the adapters integrated into PDAs use 11-Mbps 802.11b technology. It's likely that PDAs or PDA wireless adapters will soon have combinations of 54-Mbps 802.11a, 54-Mbps 802.11g, and 802.11b standards. (Brown, 2003, p.4)

-  2.5G
The current 2.5G connections (GSM/GPRS and CDMA/1xRTT) range from 40 to 72Kbps. (Brown, 2003, p.5) Since the amount of data transmitted between PDAs or PDA/PC is relatively small, when comparing to the data which download and upload from PCs, the speed of this digital cell-phone technology can be impressive. Additionally, digital phone connections cover a much wider range than any other wireless technology nowadays, 2.5G becomes very appealing.

In a conclusion, infrared and Bluetooth are best for short-range data transfer. 802.11b is best if we want to do basic web browsing with PDA. 802.11b has a faster data rate and costs less than 2.5G. But if we want more flexibility in the way using PDA, then we'll choose 2.5G, and eventually 3G. (Brown, 2003, p.6)


6 COMPRESSIONS WITH MULTIPLE TOOLS AND COMPARISON

In the chapter, multiple tools will be used to compress material. The material is offered by Nettiradio Mikaeli, Finnish Broadcasting Company. By setting the parameters to different value and implementing the enhanced functions of the tools, we can get various compression results. Then we will compare them in different aspects.

6.1 Video Compression Tools
Before compressing the material, some general information about the compression tools will be learned. There are many compression tools available, such as Adobe Premiere, Helix Producer, etc. I will now give a short introduction to them.

6.1.1 Adobe® Premiere® 6.0
Adobe Premiere is a powerful production of Adobe Company. It can do some advanced editing with the video and audio materials. In addition, it also implements Windows Media and RealMedia technologies when exporting the file. A screen shot of Adobe Premiere is shown in Figure 6.1.



Figure 6.1 Adobe Premiere screen shot

Adobe Premiere supports following source file formats:
*.avi; *.gif; *.dv; *.flm; *.mpeg; *.mpe; *.mpg; *.mov; *.ai; *.eps; *.bmp; *.dib; *.rle; *.jpg; *.jpe; *.jfif; *.pic; *.pct; *.pcx; *.psd; *.tif; *.wmf; *.aif; *.mp3; *.wmv

6.1.2 Microsoft® Windows MediaTM Encoder 9 Series
This is the latest version of Windows Media technology so far. It provides the functions of capturing audio/video, converting a file, broadcasting a live event and so on. It offers multiple methods of content distribution, such as streaming, progressive download, Pocket PC, etc. A screen shot of Microsoft Windows Media Encoder is shown in Figure 6.2.



Figure 6.2 Screen shot of Windows Media Encoder

Windows Media Encoder supports following source file formats:
Video Files: *.asf; *.avi; *.bmp; *.jpg; *.mpg; *.wmv
Audio Files: *.mp3; *.wmv; *.wma

6.1.3 Helix(tm) Producer
Helix Producer Basic is a famous production from RealNetworks, Inc. It can also be seen in Adobe Premiere which I mentioned above. It has many options before compressing. We can deploy SureStream technology. And we can also choose whether the compressed file is allowed to download or recording. This function is really useful to protect the copyright of material which is offered on Internet. It uses four kinds of filters, namely noise filter, resize filter, inverse-telecine and de-interlace filter. Besides, it provides 2-pass encoding, variable bit rate encoding and loss protection. 2-pass encoding is to analyze the static files prior to encoding. It increases quality of encoded video but also increases the time required to encode. Variable bit rate encoding is to increase quality of encoded video by varying bit rate. Using VBR may increase the startup latency of the encoded clip. Loss protection is to protect against packet loss by adding error correction codes and more keyframes to the video stream when possible. It has minimal impact on quality, suitable for all streamed content. Figure 6.3 shows a screen shot of Helix Producer Basic.



Figure 6.3 Screen shot of Helix Producer Basic

Helix Producer Basic supports the following source file formats:
AIFF Files: *.aif; *.aifc; *.aiff
AVI Files: *.avi
Digital Video Files: *.dv
MPEG: *.mpg; *.mpeg; *.m1v; *.mp2; *.mp3
NeXT Sound Files: *.snd
QuickTime Files: *.mov; *.qt
Sun Audio Files: *.au
WAV Files: *.wav
Windows Meta Files: *.wma; *.wmf; *.wmv

The version of Helix Producer I used is downloaded from the webpage of RealNetworks: http://www.realnetworks.com/products/producer/basic.html
Because this Basic version is for free, it has limited functions comparing with commercial Plus version. Table 6.1 illustrates the functionalities of Basic and Plus versions.

Table 6.1 Functionalities of Basic and Plus versions (RealNetworks)

FEATUREBASICPLUS
Convert media files into RealVideo 9 and RealAudio 8XX
Create content for unlimited target audiences/bitrate streams X
Create content for up to 3 target audiences/bitrate streamsX
Customizable Target Audience and Server Templates X
Job File Saving, re-using, and sharing support X
Multiple Destination Support to unlimited servers and files X
Multiple Destination Support to 1 server and 1 file destinationX
Backwards Compatible with RealPlayer G2 thru RealOne Player X
Printed Documentation X
CD-ROM X

But from Figure 6.3 and 6.4, we can find that these two versions have same user interface.



Figure 6.4 Screen shot of Helix Producer Plus

Helix Mobile Producer is an encoding tool for streaming to mobile devices. You can download a trial version for free from RealNetworks website: http://www.realnetworks.com/industries/mobile/operators/products/producer/index.html
Its user interface is a bit different from the conventional Helix Producer which I mentioned above. And it implements not only RealMedia standard, but also H.263 and MPEG-4. Real and Envivio work together to support MPEG-4 in RealOne Player. And it has various parameters can be set to fit your special need. Figure 6.5 shows a screen shot of Helix Mobile Producer.



Figure 6.5 Screen shot of Helix Mobile Producer

6.1.4 VirtualDub 1.5.10
VirtualDub is a production of VirtualDub Company. It lacks of editing power like Adobe Premiere, but is simplified for fast linear operation on video. It has batch-processing capability for processing large number of files. Moreover, it implements multiple three-party filters to optimize the quality of performance. These powerful filters can resize, rotate, and adjust color, saturation, brightness of video. Besides it also has the functions to apply blur to the image and smoothen or sharpen the video. Figure 6.6 shows a screen shot of VirtualDub.



Figure 6.6 Screen shot of VirtualDub

VirtualDub supports following source file formats:
Audio/video interleave: *.avi
MPEG-1 video/systems stream: *.mpg; *.mpeg
Image sequence: *.bmp; *.tga
AVIFile input driver (compat.): *.avs; *.vdr

6.2 Process of Compression
Later I will use figures to illustrate the process of compression by deploying the four tools which have mentioned above.

6.2.1 Adobe Premiere
First, import a file or multiple files and put them on the timeline. After edit the material if necessary, we can select from the menu 'File' --> 'Export Timeline', then we can use 'Advanced Windows Media Export Plug-in for Adobe Premiere' or 'Advanced RealMedia Export Plug-in for Adobe Premiere' to compress the material which is shown in Figure 6.7.



Figure 6.7 Exports in Adobe Premiere

By selecting 'Advanced Windows Media Export Plug-in for Adobe Premiere', we can find that there are some profiles of default setting already. By click 'Custom', we can create new ones. We can choose the audio/video mode and codec which we want, and the bit rate as well.



Figure 6.8 Add bit rate to create new setting in Windows Media Export

If we select 'Advanced RealMedia Export Plug-in for Adobe Premiere', as shown in Figure 6.9, we can see many options which we can choose, such as bit rate, output file resolution, the implementation of Multi-rate SureStream and so on. By click 'Preference', we can do more advanced settings.



Figure 6.9 Set parameters in RealMedia Export

Here I want to explain a bit more about the video codec 'RealVideo G2 with SVT'. SVT stands for Scalable Video Technology. It is based on an interactive video technology from Intel Company. SVT is especially for narrowband users. When the rate of streaming media is too high, narrowband users don't need to decode all the original image data, but by deploying wavelet algorithm in the server side, redundancy can be removed to adjust user's bandwidth in order to ensure he can watch the file.

After setting all the parameters, we click 'OK', and then it goes to exporting session.



Figure 6.10 Exporting session of Adobe Premiere

6.2.2 Windows Media Encoder
First, create a new session and select 'Convert a file' as shown in Figure 6.11.



Figure 6.11 Create a new session in Windows Media Encoder

After indicating the location of source and destination file, it comes to 'Content Distribution'. If we choose 'Pocket PC', we can see that by selecting audio/video mode, there is only single bit rate to encode the file as shown in Figure 6.12.



Figure 6.12 Encoding options in 'Pocket PC'

But if we choose 'Windows Media server (steaming)', we can choose from multiple bit rates which is especially for streaming technology as shown in Figure 6.13.



Figure 6.13 Encoding options in 'streaming'

Then we can start the encoding. Figure 6.14 shows the encoding session of Windows Media Encoder.



Figure 6.14 Encoding session of Windows Media Encoder

6.2.3 Helix Producer
Besides indicate the location of source and destination file, we should also set the parameters by clicking 'Audiences'. Then we can select the bit rate. There are multiple bit rates we can add to encode the material, which is referred to SureStream. Because the version of this software, it has a limitation that it can only add three different bit rates to encode a file as shown in Figure 6.15.



Figure 6.15 Encoding options in Helix Producer Basic

The encoding process is shown in Figure 6.16.



Figure 6.16 Encoding session in Helix Producer

6.2.4 VirtualDub
Firstly, open the source file. Then we can add multiple filters and set other parameters in order to gain better output. Figure 6.17 shows there are many filters we can select.



Figure 6.17 Filters in VirtualDub

After that, the compression begins as shown in Figure 6.18.



Figure 6.18 Encoding session in VirtualDub

6.3 Comparison
By simply using these tools or combinations of them, we can generate many compressed files. Now we are going to compare them in many aspects.

6.3.1 Different Resolution
I use Adobe Premiere to convert original material to .mov format without high compression ratio. These compressed files have the same settings except resolution.

Table 6.2 Comparison of different resolution with files in .mov format

ResolutionCompressed File SizePerformance
320x240371 MB
240x162 (4:3)220 MB
160x120143 MB

Then I use Helix Producer Plus to convert a file to .rm format and also only change the setting of resolution.

Table 6.3 Comparison of different resolution with files in .rm format

ResolutionCompressed File SizePerformance
320x2407.67 MB
240x1607.66 MB
160x1207.65 MB

Conclusion:
If we create a compressed file with smaller resolution, we can drop some pixels without sensible effect of performance, or even better. Consequently, it results in smaller size. However, this is not remarkable if the file has been greatly compressed by other algorithms.

6.3.2 Different Bit Rate
The tool I use here is Helix Producer. The display of PDA is 320x240, but the material offered by Finnish Broadcasting Company has a resolution of 352x288. As the conclusion which we draw above, it's needed to resize the material. Because the Basic version of Helix produce doesn't provide resize function, so I firstly use Adobe Premiere to resize the material to 240x162 and generate a .mov file which has a good quality of performance.

Then I create some compressed files with fixed setting of following parameters:
Audio mode: Voice
Video mode: Normal Motion Video
Video codec: RealVideo 9

But the bit rate is set to different values as shown in Table 6.4.

Table 6.4 Comparison of different bit rate

Bit RateOutput File SizePerformance
16k Substream for 28 Dial-up (16 kbps)572 KB
28k Dial-up (20 kbps)719 KB
26k Substream for 56k Dial-up (26 kbps)930 KB
56k Dial-up (34 kbps)1.18 MB
64k Single ISDN (50 kbps)1.72 MB
128k Dual ISDN (100 kbps)3.42 MB
150k LAN (150 kbps)5.15 MB
256k DSL or Cable (225 kbps)7.65 MB
384k DSL or Cable (350 kbps)11.8 MB
1.5M VBR Download (1500 kbps)50.6 MB

Conclusion:
It's obvious that how big the compressed file and how good the performance of the compressed video have close relationship with the bit rate. What we can do is to find out a trade-off among these three elements.

6.3.3 Different Video Mode
To an indicated bit rate, I change the video mode to see the result. In Helix Producer, there are five video modes, namely Normal Motion Video, Sharpest Image, Smoothest Motion, Slide Show and No Video. Slide Show is not for playing continuous video. And No Video is also not suitable.

Table 6.5 shows the comparison of different video mode.

Table 6.5 Comparison of different video mode

Bit RateVideo ModeOutput File Size
56k Dial-up (34 kbps) Normal Motion Video1.18 MB
Sharpest Image1.18 MB
Smoothest Motion1.18 MB
64k Single ISDN (50 kbps) Normal Motion Video1.72 MB
Sharpest Image1.72 MB
Smoothest Motion1.72 MB
128k Dual ISDN (100 kbps) Normal Motion Video3.42 MB
Sharpest Image3.42 MB
Smoothest Motion3.42 MB
150k LAN (150 kbps) Normal Motion Video5.15 MB
Sharpest Image5.14 MB
Smoothest Motion5.15 MB
256k DSL or Cable (225 kbps) Normal Motion Video7.65 MB
Sharpest Image7.65 MB
Smoothest Motion7.65 MB
384k DSL or Cable (350 kbps) Normal Motion Video11.8 MB
Sharpest Image11.8 MB
Smoothest Motion11.8 MB
1.5M VBR Download (1500 kbps) Normal Motion Video50.6 MB
Sharpest Image50.6 MB
Smoothest Motion50.6 MB

Conclusion:
With a same bit rate, when we choose 'Sharpest Image', the less continuous we can feel from the performance. On the contrary, when we choose 'Smoothest Motion', the worse the quality of image shows. So we can get the following fact: When compressing video which contains many motion pictures (eg. sports), we can get good quality of motion effect by using 'Smoothest Motion'. In the other hand, if the material contains many still images or the movement of the pictures is not too much (eg. interview), we can focus on the effect of image, but not the motion, by using 'Sharpest Image'. 'Normal Motion Video' is a trade-off between these two settings.

The size of compressed files isn't affected by only change the video mode setting. So we needn't take the size of compressed file into consideration, when we decide which video mode we use.

Suggestion:
We can divide the material into small parts when it contains these two kinds of video information. We can use different ways to compress them in order to achieve better result for both of them.

6.3.4 Different Audio Mode
Although my study is about the digital video, I will mention a little digital audio as well in this part. There are some audio modes we can select, such as music, voice or no audio. Moreover, we can also select the Audio Codec. In this part, I keep the following parameters to fixed value, and set Audio Mode to different values. The result can be seen in Table 6.6.
Bit rate: 256k DSL or Cable (225 kbps)
Normal Motion Video, RealVideo 9 Codec, 240x160

Table 6.6 Comparison of different audio mode

Audio ModeCompressed File Size
Music7.68 MB
Voice7.65 MB

Conclusion:
Music, comparing to voice, generate a bit bigger compressed file.

6.3.5 Different Compression Tool
The following table is the comparison with four tools. I use them to compress material. By setting different parameters and watching the generated files in PDA, I have found out what is the best setting for each of them, as seen in 6.3.7. Now, I will compare the compressed files in a larger scale, between different compression tools.

Table 6.7 Comparison of different compression tool

ToolHelix ProducerAdobe Premiere's RealMedia Plug-inAdobe Premiere's Windows Media Plug-inHelix Mobile Producer
File Format.rm.rm.wmv.rm
Bit Rate50 kbps50 kbps50 kbps50 kbps
Video Codec8889
Frame Rate 10 fps10 fps10 fps
Resolution208x160208x160208x160208x160
Size1.72 MB1.72 MB1.62 MB1.73 MB
Encoding Time6 min 5 sec4 min 40 sec1 min 39 sec5 min 23 sec
Result1s buffer. The image is sharp, but sometimes blocking occurs. The motion is smooth when the movement is not very big, but for big movement, the motion is no longer smooth.1s buffer. Sometimes the image becomes blurred, but no blocking occurs. The motion is also only smooth when there is no big movement.1s buffer. The audio is obviously no as well as the previous two, not clear. The image is blurred. The motion is not smooth enough even the movement is not very big, and sometimes even stops for 1 or 2 seconds.7s buffer. The image is sharp, but if the movement is big, the image becomes blurred. The motion is jerky. But if we can get much better quality if we optimize the parameter settings. There is always a mark in the compressed file. By gaining another version can solve this problem.

6.3.6 Different Technologies of Playing
When we implement streaming technology in encoding material, the compressed file is much bigger. That's because streaming technology can combine multiple bit rates in a single file in order to adjust to bandwidth fluctuation, while downloading technology only allows single bit rate for one file. Later, in Chapter 7, we will compare these two technologies in mobile environment.

6.3.7 Other Aspects Related to QoS
There are also many other aspects which should be taken into consideration when we evaluate the QoS of multimedia service.

-  Version Problem between Players and Encoders
In my study, I meet a problem that when I copy the compressed file into PDA. The PDA doesn't play it or only with audio output. Finally, I find this is because of the version problem. I implement Windows Media Encoder 9 Series to encode the material, but the player can support the video which is compressed by Windows Media 8 Codec. The compression tool is newer, or in another word, more advanced than the player. So the compressed file which is generated by latest tool can not be played by an old player. In addition, even if both the compression tool and player are the latest, it's still possible that the player for PC which is corresponding to the latest compression tool comes out, but not the player for PDA.

So when the company offers video clips on Internet, they should take the user's player into consideration. If the server implements advanced codec and tools in compression, the client may not be able to play the file at all, let alone enjoy the good quality provided by the compression tools. Maybe they can offer the corresponding player which also be downloaded from their website. But they should also do a bit test to find out which player is suitable.

-  Restriction of Players
The latest version of RealPlayer for Pocket PC can be downloaded from the web site of RealNetworks. That is RealPlayer for Pocket PC 1.1 Preview Release. It is said that it can support RealVideo 9. So far, the devices which it supports are Nokia 9210 Communicator, Audiovox's Maestro Pocket PC, Casio Cassiopeia E-200 and above, Compaq iPAQ Pocket PC H3600 Series and above, HP Jornada 565 and above, O2 xda from mmO2 (upon availability), NEC MobilePro P300, Sagem WA3050 (audio only), Toshiba e570. So our PDA is compatible with this player.

However, when I use Adobe Premiere and Helix Producer Plus to compress the material into .rm format, nearly all of the compressed files can not be played in PDA with this RealPlayer. Finally, I find out the reason is that RealPlayer for Pocket PC has very strict requirements with the video file which it can play. It's better to meet the following three requirements:
(1) The file is no more than 15 frames per second.
(2) Bit rate is no more than 50 kbps.
(3) Video Codec is RealVideo 8 or lower.
Lacking of any requirement may results in enable to play well.

I set the parameters to different values to generate multiple compressed files, and then see the result with PDA. The results are shown in Table 6.8 and 6.9.

Table 6.8 Result of the files compressed by Helix Producer Plus,
which are in .rm format

Bit RateVideo CodecResolutionResult
50 kbps8320x240Success, 2s buffer
50 kbps9320x240Only audio output
50 kbpsG2 with SVT320x240Success, 1s buffer
50 kbps8240x160Success, 1s buffer
50 kbps8160x120Success, <1s buffer
34 kbps8320x240No audio output at all
100 kbps8320x240Only audio output
100 kbps9320x240Only audio output
100 kbps9240x160Only audio output
150 kbps8320x240Only audio output

Here the time of buffer is also affected by the PDA. If there are other tasks running at the same time when we play the file, even transmit the data, the buffer time would become longer.

From the result, we can draw such conclusions that the restrictions of compressed file which want to be played in PDA are:
(1) Bit Rate should be set to 50 kbps which is for 64k Single ISDN.
If it's higher than 50 kbps, we can only hear the audio output and without any video output. And if it's lower than this value, for example, 34 kbps, even no audio output at all.
(2) We should use Video Codec 8 or lower.
Although RealNetworks said that this latest version of Player can support Video Codec 9, the fact has proved that files compressed by Helix Producer with Video Codec 9 do not work. If we implement Video Codec 9 in our compression, there is no video output.

Table 6.9 Result of the files compressed by Adobe Premiere, which are in .rm format

Bit RateVideo CodecFrame RateResolutionResult
20 kbps815 fps320x240Success, <1s buffer
34 kbps815 fps320x240Success, <1s buffer
45 kbps815 fps320x240Success, 2s buffer
45 kbpsG215 fps320x240Success, 1s buffer
45 kbpsG2 with SVT15 fps320x240Success, <1s buffer
45 kbps816 fps320x240Only audio output
45 kbps815 fps240x160Success, <1s buffer
80 kbps815 fps320x240Only audio output
80 kbps814 fps320x240Only audio output
150 kbps830 fps320x240Only audio output
225 kbps830 fps320x240Only audio output

In Adobe Premiere, there is a special setting named 'Player Compatibility'. I created two compressed files with different selection of this parameter: one is Player G2; the other is Player 5.0 or later. The result is both of them can be played in this version of RealPlayer.

From the result, we can draw such conclusions that the restrictions of compressed file which want to be played in PDA are:
(1) Bit Rate should be set to 45 kbps and lower.
If it's higher than 45 kbps, we can only hear the audio output and without any video output.
(2) Frame Rate should be no more than 15 fps.
Otherwise, the file can not be played correctly.

Helix Producer Plus can only change Bit rate and Resolution settings, but with Adobe Premiere's Advanced RealMedia Export Plug-in, we can set these three parameters. So if we want PDA users to enjoy the .rm format files which we offer on Internet, we should pay attention to the three aspects which I mentioned above.

Since RealPlayer for Pocket PC has such restrictions if we use Helix Producer and Adobe Premiere as compression tools, especially for the bit rate and frame rate settings, it is obvious that it can not give PDA users good quality of performance. And the fact which we experience from playing video file in PDA proves so. In this case, we should resort to other solutions which can give us good QoS. Later, I find Helix Mobile Producer.

I have introduced Helix Mobile Producer in 6.1.3. Table 6.10 is the testing with compressed files which are encoded by this tool.

Table 6.10 Result of the files compressed by Helix Mobile Producer,
which are in .rm format

Bit RateFrame RateKey frame PeriodResolutionResult
200 kbps30 fps5000 ms320x240Only audio output
100 kbps15 fps2000 ms320x240Only audio output
60 kbps10 fps5000 ms176x144Success, 1s buffer
80 kbps10 fps5000 ms176x144Success, 2s buffer
80 kbps15 fps5000 ms320x240Only audio output
80 kbps10 fps5000 ms320x240Only audio output
80 kbps14 fps5000 ms320x240Only audio output
80 kbps10 fps5000 ms208x106Success, 1s buffer
80 kbps10 fps5000 ms240x160Success, 2s buffer
80 kbps10 fps2000 ms176x144Success, 1s buffer
80 kbps10 fps1000 ms240x160Success, 3s buffer
80 kbps10 fps500 ms176x144Success, 1s buffer

All the testing files deploy Video Codec 9.

From the result, we can draw such conclusions that the restrictions of compressed file which want to be played in PDA are:
(1) Bit Rate should be no more than 80 kbps.
(2) Frame Rate should be no more than 10 fps.
(3) Resolution should be less than 320x240.

Although, there are also some restrictions by using Helix Mobile Producer, we can deploy Video Codec 9 this time and the compressed files can be played successfully. Surprisingly, even there are also some limitations in bit rate and frame rate; however, it gives us much better quality. The performance of this tool can be seen in 6.3.5. And Table 6.11 shows the requirements about settings of compressed files played in PDA.

Table 6.11 Requirements about settings of compressed files played in PDA

ToolCodecBit RateFrame RateResolution
Helix Producer PlusRealVideo 8 or lower50 kbps--
Adobe Premiere-No more than 45 kbpsNo more than 15 fps-
Helix Mobile Producer-No more than 80 kbpsNo more than 10 fpsLess than 320x240

7 INSTALLATION OF MEDIA SERVER

Nowadays, there are two solutions to transmit audio or video information on Internet, namely downloading and streaming. Due to the limitation of network bandwidth, it requires several minutes or even a few hours by using downloading. Since it has great delay, it's not suitable for some service which has high requirement on real-time, such as VOD (Video on Demand) and remote education. So the streaming technology plays a dominant role in network application. Under the condition of very congested network, it can also provide clear audio/video performance without any interruption, and then it makes transmitting multimedia information in narrowband network possible.

Media server provides multiple operational modes, such as unicast, multicast, on-demand and broadcast. The point-to-point connection between client side and server side has one-to-one relationship. This is unicast. Multicast is for a group, so there are single sender and multiple receivers. On-demand is that the client initially connects to the server. Although broadcast is also one-to-multiple, it is different from the multicast. It sends packets in all the clients in the network, no matter whether they request for it or not. So it wastes the bandwidth in some ways.

7.1 Helix (Real) Server
The Helix Server was become one of the most popular streaming servers in network application. This is mainly due to the high compression of rm audio/video file. Helix Server can be downloaded for free from RealNetworks website:
http://licensekey.realnetworks.com/rnforms/products/servers/eval/index.html
By filling your email address, a license key will be sent to your email box later. The protocol used here is RTSP (Real-Time Streaming Protocol).

During the installation of the server, there will be some steps to set the ports. If the computer has installed IIS already, here it is better to change the default setting of http connection port from 80 to 8080 as shown in Figure 7.1; otherwise there will be some troubles later. IIS stands for Internet Information Server. Microsoft IIS is a web server which allows publishing information in public Intranet or Internet. It uses HTTP to transmit information. And it can also provide FTP or gopher services. Once set the HTTP port already, it's better that do not change it again. I have tried to change HTTP port from 8080 back to 80 after installation, but then the Helix server can not work. The reason probably like that this port is kept in use as long as we start the server. Although we change its value, but it would like to remain the previous setting, then it would result in fail to use the server. Reinstallation of Helix server should be needed if we do so.



Figure 7.1 Set port for HTTP connections

If the computer has installed Windows Media server already, here it is better to change the default setting of mms connection port from 1755 to others as shown in Figure 7.2.



Figure 7.2 Set port for MMS connections

And we can keep other ports setting to their default values.



Figure 7.3 Helix Server configurations

After installation, you must restart the computer.

As shown in Figure 7.4, in 'Connection Control' which is under 'Server Setup', we can set the 'Maximum Client Connections' according to our own bandwidth and the capability of machine. If we set 'RealPlayer Plus Only' to 'On', it can effectively avoid user use a third-party software to download the media. However, user can only use RealPlayer Plus version, not Basic version.



Figure 7.4 Connection Control

By using 'Access Control' which is under 'Security', we can allow or deny any traffic we want.

After configuration with the server, we can put it into use by writing the address of file in player at client side. For .rm or .rmvb format:
rstp://streaming server ip:554/name of mount point/name of file directory/file name(including the extended name)
(where ':554' can be omitted)
When using RealPlayer 8 or later to play a RealMedia, content creators can include port hints with the cloakport parameter. The player then attempts to connect to the server using the specified protocol and ports. This is useful if you have multiple Helix Universal Servers that use different ports. Content creators do not then have to know exactly which port is used on each machine. In the following example, RealPlayer attempts to connect through RTSP on port 554. If that doesn't work, it tries RTSP on port 550, and so on. You can specify up to four ports:
rtsp://helixserver.example.com/video1.rm?cloakport="554 550 1012 9120"
For Windows Media format like .wmv or .asf:
mms://streaming server ip:1755/name of mount point/name of file directory/file name
(where ':1755' can be omitted. But if we use Helix server to play Windows Media file, the name of file directory and file name should not be Chinese, otherwise it maybe some mistakes.
.avi and .mpg4 format can also be played by Helix server.

According to the requirement from Nettiradio Mikaeli, Finnish Broadcasting Company, I will mainly do research on Real's production.

7.2 Windows Media Server
The protocol used here is MMS (Microsoft Media Server Protocol).

There are three ways of publishing:
(1) Create a corresponding ASX file. User can connect to the server by downloading this file and then play.
(2) Publish the URL in own website. When the user clicks the link, the local player can automatically start and connect to the Windows Media server. And the audio/video in the server will be played in the streaming way.
(3) Plug Microsoft ActiveX component in the web page in order to set up player in web page. In this way, user can play the media even he doesn't have any player.

7.3 Quick Time Streaming Server
Darwin Streaming Server is the streaming server software from QuickTime. You can download it for free from the following link:
http://developer.apple.com/darwin/projects/streaming/
ActivePerl is essential software when we establish QuickTime on Windows platform. It is also for free and you can download it from its official web site: http://www.activestate.com/Products/
The latest version I get is 'ActivePerl-5.8.3.809-MSWin32-x86.msi'.


8 TESTING IN MOBILE ENVIRONMENT

There are three environments for testing the compressed files. One is the WLAN built in laboratory. Another is to put files in the main server of Finnish Broadcasting Company. They have a Real streaming server. The third one is the Intranet in school.

8.1 Test in Lab Environment
As shown in Figure 8.1, it is the structure of WLAN which built in laboratory. We put the compressed files into the server. WLAN service is provided by the WLAN access point on the server side and the WLAN card on the client side. And two routers take charge of changing network bandwidth.



Figure 8.1 Structure of testing environment

-  PDA and WLAN card
This kind of PDA is Compaq iPAQ H3970. Its operating system is Microsoft(r) Pocket PC which included WinAs some of compressed files are .rm format, we must install a RealPlayer which is for mobile device in order to play video in PDA, as shown in Figure 8.2. Such software can be downloaded from RealNetworks' web:
http://www.realnetworks.com/industries/mobile/operators/products/player/index.html



Figure 8.2 RealOne Player for Pocket PC

And a driver should be installed in PDA to recognize the WLAN card. After that, we should also do some configurations with it, such as set the IP address and so on. Since the WLAN card we use is D-Link DCF-650W, we can download its drivers in from following URL: http://support.dlink.com/products/view.asp?productid=DCF%2D650W

-  Server
We install Sambar Server in the server, which is powerful web server software. You can set up your own website in your PC. Moreover, you can also put your website on Internet. Make sure the program of 'Sambar Server' has launched before we use the WLAN.

I use trace route command to test the connection between local server and WLAN access point, as shown in Figure 8.3, the connection is ok.



Figure 8.3 Tracing route

As shown in Figure 8.4, I create a new mount point named "video" to test files in Helix Server. I put the testing files in the local server under the directory of "C:\sambar53\docs\pda", which I set as "Base Path".



Figure 8.4 Create a new mount point

-  Router As mentioned in Figure 8.1, the routers' function here is to change the bandwidth in order to simulate bandwidth fluctuation. Firstly, we should connect the console ports of server's and router's. Then we can use "Hyper Terminal" to configure the router, as shown in Figure 8.5. Remember to exit from configuration mode after change the setting.



Figure 8.5 Configure the router to change the bandwidth

There are many values can be chosen from when set the clock rate, as shown in Figure 8.6.



Figure 8.6 Choices of clock rate

After configuration, we can use "show running-config" command to show the change. We can see from Figure 8.7, the value of "clockrate" has changed.



Figure 8.7 Show running-config

I use a file compressed by Adobe Premiere to find out the actual speed of each clock rate value, as shown in Table 8.1. The file has following parameters: 15kbps (VBR), 30fps, RealVideo 8 codec, 208x160, 548 KB.

Table 8.1 Speed of each clock rate

Clock Rate (bps)Downloading TimeDownloading SpeedStreaming Result
1200"An unknown error has occured"-
9600503s8.73 kbps49s "loading" in the beginning; "Shuttingdown" at 0:24 "Response or data from server timed out"
19200254s17.29 kbps27s "loading" in the beginning; "Shuttingdown" at 0:35 "Response or data from server timed out"
38400129s34.05 kbps27s "loading" in the beginning
5600086s51.07 kbps27s "loading" in the beginning
6400077s57.04 kbps27s "loading" in the beginning
7200067s65.55 kbps27s "loading" in the beginning
12500039s112.61 kbps27s "loading" in the beginning
14800033s133.09 kbps27s "loading" in the beginning
25000020s219.59 kbps27s "loading" in the beginning
50000014s313.70 kbps27s "loading" in the beginning
80000014s313.70 kbps27s "loading" in the beginning
100000012s365.98 kbps27s "loading" in the beginning
130000012s365.98 kbps27s "loading" in the beginning
200000012s365.98 kbps27s "loading" in the beginning
400000012s365.98 kbps27s "loading" in the beginning

From Table 8.1, we can see that if the network condition is quite good or the file size is really small, downloading can be superior to streaming.

After these, we can start the test. At first, I set the clock rate as a fixed value. Here I select 56000, because its corresponding speed for downloading is around 50 kbps. And the speed of GPRS network is also at this value. So firstly I test the files in the simulated GPRS network.

Then I open the RealOne Player in my PDA, select from the menu "File" --> "Open Location", as shown in Figure 8.8.



Figure 8.8 Use RealOne Player for Pocket PC

There, it requires user to type the address of the file. As mentioned in 7.1.1, according to the server's IP address and settings with mount point, we should type "rtsp://197.197.197.2/video/1.rm" here if we want to stream No.1 file in PDA. Figure 8.9 shows how to stream a .rm file named "a130". Then we can play the file by streaming it. Sometimes, it needs a bit long time to loading it.



Figure 8.9 Write address when streaming a file

The testing files compressed by different tools with different parameters are listed in Table 8.2.

Table 8.2 Parameters of testing files

Compression ToolCodecBit Rate (bps)Frame RateResolutionOutput File Size
1.rmHelix Mobile ProducerRV910k, 12k, 15k, 20k, 25k, 30k, 40k, 50k, 60k, 80k10 fps208x16010.4 MB
2.rmHelix Mobile ProducerRV920k, 60k10 fps208x1602.78 MB
3.rmAdobe PremiereRV820k, 34k, 45k15 fps208x1605.09 MB
4.3gpHelix Mobile ProducerMPEG-414k5 fps176x1441.04 MB
5.wmvAdobe PremiereWMV8, WMA921k, 60k, 100k15 fps208x1605.59 MB
6Helix Mobile ProducerRV815k, 20k, 25k5 fps176x1441.87 MB
7Helix Mobile ProducerRV840k, 50k6 fps176x1443.11 MB
8Adobe Premiere (1 min)RV820k, 34k10 fps208x160763 KB
9Adobe Premiere (1 min)RV820k (VBR)10 fps208x160179 KB
10Adobe Premiere (1 min)RV8, RA820k7.5 fps240x176179 KB

where in "codec"
RV stands for RealVideo, RA stands for RealAudio;
WMV stands for Windows Media Video, WMA stands for Windows Media Audio.

Here, I would like to talk a bit about CBR and VBR. CBR stands for Constant Bit Rate, while VBR stands for Variable Bit Rate. Only a single bit rate can be used with VBR encoding. Unlike CBR, VBR doesn't use constant bit rate for sampling. It can distribute the bandwidth adaptively in order to gain best quality with smallest file size.

Because No.4 has a format which is 3GPP for mobile phone, there is no player for it in PC and PDA, so we don't test it in PC and PDA.

The result of testing the files list in Table 8.2 is like this:
-  No.1 keeps "loading" all the time, the bit rate which player selects is 25kbps. From RealOne Player, we can see that the timeline moves every other 10s, but with the last two or three times, the interval is about 20s. So in this way, the player just shows several still images between the intervals. Most of situation, it's totally black image, in another word, no image at all. The images of the video only appear 7 times, and which is blurred. No audio output.
-  No.2 has similar situation with No.1, but with a few differences. The bit rate which player selects is 20 kbps here. The images of the video appear 5 times, but in the last 8s, the file plays continuously.
-  No.3, 8, 9, 10 work with a bit rate of 20 kbps. The quality is not good, but bearable. Audio is not clear and image is blurred. For big movement, the motion is not continous.
-  No.5 is in .wmv format. When I use Windows Media Player 9 Series for Pocket PC to play it, by typing mms://197.197.197.2/video/5.wmv, it shows "Windows Media Player cannot play this file", as shown in Figure 8.10 and 8.11. Neither works by RealOne Player, shown in Figure 8.12.



Figure 8.10 Windows Media Player for Pocket PC



Figure 8.11 Result of Windows Media Player



Figure 8.12 Result of RealOne Player

-  No.6 also has similar situation with No.1. But the images of the video appear once.
-  No.7 doesn't work. The player displays "Connecting" at first, then "Shuttingdown" at once with error information of "Clip is not playable".

From the result, we can see that in the lab testing environment, where we use WLAN which has a connection speed of 11Mbps; there is no bandwidth limitation here. However, the player still selects 20kbps and 25kbps, even though there are many higher bit rates which they choose also. And also we see from No.7, because it doesn't contain a bit rate of 20kbps and 25kbps, it is even not playable. But as shown above, 25kbps doesn't work fine. So 20kbps is the best choice when we streaming the video in PDA. But we need more testing to prove this idea.

We do test with Helix Mobile Producer which can implement RealVideo 9 Codec and G2 with SVT, and Adobe Premiere which uses RealVideo 8 and G2 with SVT. The testing results are shown in Table 8.3 and 8.4. The total encoding time of Helix Mobile Producer is twice as long as Adobe Premiere, which is also a disadvantage of it.

When using Helix Mobile Producer, I set the resolution to 208×160 and audio mode to voice.

Table 8.3 Result from Helix Mobile Producer

CodecBit Rate (bps)Frame RateFile SizeResult
RV910k, 12k,15k,20k15 fps1.65 MB"slide show"
RV915k15 fps536 KB"slide show"
RV980k10 fps2.74 MBIt can be played in PDA local memory. But by streaming it, it displays "Clip is not playable".
RV925k10 fps892 KB"slide show"
RV912k10 fps430 KB"slide show"
RV920k7 fps717 KB"slide show"
G2 SVT25k15 fps897 KB"slide show"
G2 SVT20k7 fps721 KB"slide show"

where "slide show" means the following situation: The timeline moves every other 10s. The player just shows several still images between the intervals. Most of situation, it's totally black image, in another word, no image at all.

From Table 8.3, we can see that Helix Mobile Producer can not offer the compressed files for streaming in PDA when the bandwidth is not too high. Maybe it's because RealVideo 9 Codec is not appropriated for streaming in mobile device with narrowband network. However, files which compressed by Adobe Premiere with G2 SVT Codec can streaming in PDA, as shown in Table 8.4. In this case, it leads me to suspect that it's the problem of Helix Mobile Producer.

When using Adobe Premiere, I also set the resolution to 208×160 and audio mode to voice.

Table 8.4 Result from Adobe Premiere

CodecBit Rate (bps)Frame RateFile SizeResult
RV820k (VBR)20 fps2.27 MBplays well, no buffer
RV827k (VBR)15 fps993 KB"Clip is not playable"
RV826k (VBR)15 fps956 KBplays, "jump buffer" occurs three times
G2 SVT26k (VBR)15 fps956 KBplays, "jump buffer" occurs twice and buffer twice
RV826k (VBR)30 fps955 KB

958 KB

954 KB
plays
In "Normal" mode, "jump buffer" occurs three times and buffer once.
"Smoothest Motin", "jump buffer" occurs four times.
"Sharpest Image", "jump buffer" occurs six times.
RV819k (VBR) 30 fps700 KBplays well, no buffer
RV820k (VBR)23.5 fps736 KBplays, "jump buffer" once
RV820k (VBR)23 fps734 KBplays well, no buffer
RV821k (VBR) 14 fps772 KBplays, buffer once

where "buffer jump" means the following situation: During the buffer, timeline jumps for a few seconds at first, then only audio output for a few minutes, after that play well again. It often takes place about 1 min after beginning and 1 min before ending.

As shown in Table 8.4, if the bit rate should be no more than 26kbps, otherwise the video clip is not playable. But even if we set the bit rate at 26kbps or below, it can't make sure that the video can play well. We should set the frame rate to an appropriate value according to the bit rate; otherwise there will be some troubles. Sometime buffer occurs, but sometime the situation gets worse: the "jump buffer" occurs. If this happens, the user will miss some parts of the video which can not get good QoS. We can see from Table 8.5 that, we have already found several matched settings under the clock rate of 56000bps, which simulated GPRS network.

Table 8.5 Matched settings with bit rate and frame rate in simulated GPRS network

Bit RateFrame Rate (range from 0 fps to 30 fps)Output File Size
21 kbpsless than 14 fpsaround 772 KB
20 kbpsno more than 23 fpsaround 734 KB
19 kbpsany valuearound 700 KB

Then I change the clock rate to other values and test, as shown in Table 8.6.

Table 8.6 Matched settings with different clock rates

Clock Rate (bps)Downloading SpeedVideo CodecBit RateFile Size
5600051.07 kbpsRV820 kbps734 KB
125000112.61 kbpsRV8 and RV980 kbps2.79 MB
250000219.59 kbpsRV8 and RV9150 kbps5.07 MB
800000313.70 kbpsRV8 and RV9225 kbps7.58 MB
4000000365.98 kbpsRV8 and RV9225 kbps7.58 MB

In the settings above, I set Frame rate as 15 fps under any clock rate. Because I find we can not set Frame rate to a too high value, such as 30 fps. Even in the best connection, when clock rate is 4000000bps, if Frame rate is 30 fps, the file doesn't play smoothly even at a bit rate of 120 kbps. However, compare with the result in Table 8.6, we can find that under a same clock rate, if Frame rate is 15 fps, we can get a good quality with a bit rate of 225 kbps.

After finding the best settings of each bandwidth, I am going to test with multi-bitrate file. I compress a file with multiple bit rates and test it by changing the bandwidth. This file contains multiple bit rates of 20kbps, 80 kbps, 150 kbps and 225 kbps, which are corresponding to different connection speeds, as shown in Table 8.6.

At first, I set the clock rate to 4000000bps, after 20s of loading, the file starts to play with good performance. It selects 225kbps to play. Then I change the bandwidth by setting clock rate to 250000bps, after 10s, the quality becomes worse. And then, after 33s more, the player shuts down with error of "Response or data from server timed out". Similar situation happens if I change the clock rate to 56000bps, but not 250000bps. And the result is a bit worse: after 16s, the player shuts down with error of "Response or data from server timed out".

Then I test again. I set clock rate to a lower value at the beginning. Not matter which value I use, 56000bps or 250000bps, both of them select 225kbps to play, which results in unbearable quality of performance.

After seeing these, I think the problem is that the file itself can not distinguish the bit rate which is suitable for current bandwidth. If during compression, some configurations about indicating bit rate to corresponding bandwidth, I think this problem can be solved then. Later, I also check this problem form Internet, it is said that web server can not support the multi-bitrate file, because they don't monitor the change of bandwidth. However, Windows Media Server can support multi-bitrate. Since Windows Media Server can only be installed from the CD of Microsoft Windows NT operating system, here I can not continue my study on multi-bitrate file with streaming.

8.2 Test in Real Internet
We put the compressed files in the main server of Finnish Broadcasting Company, which allows users to stream them. Meanwhile, we also put them in FTP server of Nettiradio Mikaeli, which allows users to download them. Then we create a webpage which provides the URLs of these files, as shown in Figure 8.13. By clicking the URLs, users can play them easily.



Figure 8.13 Webpage for testing

At first, we test some files listed in Table 8.2 with PC. The result is good. Both streaming and downloading them work well.

Then we use PDA to test them and PDA is connected to the Internet via a PC. Then we click the URLs in PDA. Downloading them does work. But streaming them does not work at all. The result is mostly like this: The RealOne Player in Pocket PC displays following information, firstly "Connecting", then "Loading", finally "Shuttingdown" with error information that "Response or data from server timed out". Only No.7 gives a different result: firstly "Conecting", then directly "Shuttingdown" with error information that "Clip is not playable". And this happens not matter we want to streaming it or downloading it. I think the reason is that No.7 doesn't contain a bit rate about 20kbps. 20kbps is appropriate for streaming in Pocket PC under that bandwidth.

As for the error of other files, "timed out" error information, it seems to be a common problem. I looked some technical forum on Internet. There are many PDA users meet the same situation as me. And it appears to suggest that RealOne Player is not giving enough time for a connection to be established. Unfortunately there is no option to change this setting in the RealOne Player. Another explanation to this is PDA use PC's IP address to send request to server and ask for streaming the video. When server responses, it is confused with the IP address, so it doesn't know whom to response, PDA or PC, which results in "Response or data from server timed out". Later, I do the test in Intranet to prove whether it is the problem or not.

One more test also takes place. That is testing PDA in real WLAN. We click the URLs of the testing webpage in the school's WLAN, which can access to Internet. The result is when downloading, the files work well. But when streaming them, it always displays "Failed to connect to the server".

8.3 Test in Intranet
Here, I put the testing files in the Real streaming server of our school. Then I type the address in the RealPlayer. PDA connects to the server through the WLAN in school. The result is that the player still displays "Response or data from server timed out". So it proves that this is not the IP address problem which I assumed above.


9 CONCLUSION AND FUTURE STUDY

My aim of study was to find out a solution to improve QoS of digital video in mobile environment. However, during my study, I find that unlike PC, mobile devices have many restrictions on enjoying the video files from Internet. In this case, firstly, I try to find out which setting of compressed files can be playable, and then I go on my research to find out the best solution.

As shown in my case part, the performance of video is affected greatly by bit rate and frame rate. According to different compression tools, resolution and codec have their effect on performance as well. However, in mobile environment, there are many factors which should be taken into consideration when we evaluate the quality of multimedia service. Bandwidth is one of the most important factors.

In addition, when we set the parameters before compression, the fact is not like this: the higher value we select, the better quality we get. In order to get good performance, we should make every parameter matches each other well.

According to my current study, I think I can do further study in future in two aspects.

One is the multi-bitrate used in streaming technology. It is an advanced technology which can change the bit rate to play by monitoring current network condition. As I mentioned in 7.2.1, only Windows Media server can support multi-bitrate files so far. So I can study with Windows Media server about multi-bitrate later.

The other is the strange result I find in my study. As shown in Table 6.11, it is the requirements with files when we copy the file to the local memory of PDA and play. The bit rate is limited to a really low value. For example, in Adobe Premiere, the bit rate should be no more than 45 kbps. However, in my study with streaming technology, I find the bit rate of files which plays by streaming are much higher than this. According to different bandwidth, the bit rate of files ranges from 20 kbps to 225 kbps, as shown in Table 8.6. Here the result surprised me a lot. Because I think if play in PDA's local memory, there is no limitation with bandwidth, the bit rate which is playable should be higher than playing on Internet. So I think it should be an interesting topic to do further research and to find out whether there is some bottleneck existed here.