Video Compression Techniques Over Low-Bandwidth Lines

Video compression techniques over low-bandwidth lines Roalt Aalmoes August 27, 1996 c Copyright 1996, Twente Universi...

Author: Roalt Aalmoes

27 downloads 615 Views 622KB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Video compression techniques over low-bandwidth lines Roalt Aalmoes August 27, 1996

c

Copyright 1996, Twente University

Abstract In this Master Thesis, current video compression techniques are examined and an implementation of a video compression algorithm based on the H.263 standard is presented. All video compression standards that are available now have lossy characteristics: the algorithm reduces the size of video stream signi cantly at the cost of (some) quality loss. Motion-JPEG is currently mostly used, but to make the video stream even smaller, Motion Estimation algorithms are applied, which are found in the H.261, MPEG and H.263 standards. Application of these motion estimation algorithms must be done correctly to make them ecient with regard to compression ratio and computing speed. For Desktop Video Conferencing over lowbandwidth lines, the new H.263 standard is most appropriate due to its high compression ratio. To make an implementation of this standard applicable for Real-Time purposes, the Motion Estimation, DCT, and Quantization algorithm are examined carefully and fast implementations that do not sacri ce quality much are integrated in the encoder. Other advanced techniques that reduce the size of the stream that must compressed are also examined and implementations based on skin detection, background substraction, and change detection are tested and evaluated. The result is a video compression library that compresses QCIF-sized (176 144) video streams at near Real-Time speed on fast desktop platforms. An application that sets the correct video compression parameters based on system load is also implemented.

ii

Preface Welcome to video compression! In the next couple of chapters, I will describe what video compression is, why it is required, and how it can be done eectively. This thesis is the last part of my study Computer Science at Twente University, and I hope my work will be the rst part of further development in the area of Real-Time video compression research. I have looked at video compression for Desktop Video Conferencing (DVC) in particular. Large-size video streams of high quality cannot be compressed that much to transmit it through, for instance, a telephone line. As desktop PCs or small workstations also lack enough computing power for compression of these large video streams, DVC is the best choice for these systems. Emphasis of my work has been put onto software video compression as opposed to hardware compression for a number of reasons. In the rst place, it is much more exible than hardware implementation. To change an algorithm, the code only has to be changed and be compiled. For hardware implementation, a whole new design must be made and implementation of a chip is also quite expensive. Another reason for using software compression is that it can be used to test algorithms eectively, before the actual (intended) implementation in hardware is done. The nal reason is the compatibility of a software compression compared to hardware compression. Software can be run on a variety of systems, while a hardware compression device often requires dierent drivers or is only available for one or not more than a few dierent systems. The result is a software library that can be compiled on many system, independent of their internal architectures. This is also the reason I prevented to use a mixture of a software and hardware solution as it would make the software implementation dependent of (at some point in the future) outdated hardware. I am personally not against a mixture of hard- and software, but only if the hardware provides a clear functional limited part of the encoding that replaces some time-consuming software routines. Some object-oriented approach, where a software object is replaced by a hardware object would in this case be a solution. An example of some software/hardware combination that I did use was the ability of the AVA to transmit YUV color spaced frames, instead of more common RGB color spaced frames1. 1 As will be explained later, video compression is applied on YUV color spaced frames only. If the encoder receives RGB color spaced frames, these must rst be converted to YUV.

iii

Preface

Due to the nature of video streams, large amounts of data must be processed by the processor for any video algorithm, including compression. In the rst time of my graduation, I was a bit sceptical about Real-Time software compression, and thought that the implementation would not be faster than 5{10 fps. However, developments in performance of PCs (Pentiums that are as fast as DEC Alpha workstations), right motion analysis, and usage of fast implementations made it clear Real-Time video conferencing becomes feasible very soon now . Another surprise is the size to which a video stream can be compressed. It might turn out that audio and not video will be the bottleneck of video conferencing2 .

Roalt Aalmoes, August, 1996

2

Although I have not done much research in the area of audio compression

iv

Contents Preface 1 Introduction 1.1 1.2 1.3 1.4 1.5

A brief history of computing power The Pegasus project . . . . . . . . Goals . . . . . . . . . . . . . . . . Problems and Constraints . . . . . Areas of research . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2 Overview of Still-picture Compression Standards 2.1 Introduction . . . . . . . . . . . . . . 2.2 Still-picture compression techniques 2.2.1 Lossy and Lossless . . . . . . 2.2.2 Color spaces . . . . . . . . . 2.2.3 DCT transformation . . . . . 2.2.4 Scalar Quantization . . . . . 2.2.5 Vector Quantization . . . . . 2.2.6 Entropy Encoding . . . . . . 2.2.7 Fractal compression . . . . . 2.2.8 Wavelet compression . . . . . 2.3 Still-picture compression standards . 2.3.1 JPEG . . . . . . . . . . . . . 2.3.2 GIF . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

3 Overview of Video Compression Standards 3.1 Video compression techniques 3.1.1 Prediction . . . . . . . 3.2 Video compression standards 3.2.1 Motion-JPEG . . . . . 3.2.2 MPEG-1 . . . . . . . 3.2.3 MPEG-2 . . . . . . . 3.2.4 MPEG-4 . . . . . . . 3.2.5 H.261 . . . . . . . . . 3.2.6 H.263 . . . . . . . . . 3.3 Summary . . . . . . . . . . .

. . . . . . . . . .

v

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

iii 1 1 2 2 2 3

5

5 6 6 6 8 8 9 9 11 12 13 13 18

19

19 19 20 20 20 22 23 23 25 26

Contents

4 Choosing an encoding standard { the case for H.263 4.1 4.2 4.3 4.4 4.5

Introduction . . . . . . . . . . . . . . . . . . The choice for H.263 . . . . . . . . . . . . . Advanced options in H.263 . . . . . . . . . DVC scenario and H.263 advanced options . Summary . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5.1 Introduction . . . . . . . . . . . . . . . . . . . 5.2 Basics of Motion Estimation . . . . . . . . . . 5.3 Block-comparison alternatives . . . . . . . . . 5.3.1 SAD . . . . . . . . . . . . . . . . . . . 5.3.2 Summation of columns/rows (SOCR) 5.4 Estimation Alternatives . . . . . . . . . . . . 5.4.1 Exhaustive search with search window 5.4.2 Logarithmic search . . . . . . . . . . . 5.4.3 Half-pixel prediction . . . . . . . . . . 5.4.4 Other techniques . . . . . . . . . . . . 5.5 Motion in video sequences . . . . . . . . . . . 5.5.1 Motion vectors . . . . . . . . . . . . . 5.5.2 Frame-rate and motion vectors . . . . 5.5.3 Size of the search window . . . . . . . 5.5.4 Real-Time and frame rate . . . . . . . 5.5.5 Results on SOCR block comparison . 5.6 Quality of a Real-Time video stream . . . . . 5.7 Summary . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

5 Choosing Motion Estimation algorithms

6 Choosing DCT components and Quantization levels 6.1 6.2 6.3 6.4

Introduction . . . . . . . . . . . Implementations of DCTs . . . Comparison of DCT algorithms Quantization . . . . . . . . . . 6.4.1 Scaled DCT . . . . . . . 6.5 Summary . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

7 Choosing advanced video techniques

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Skin selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Implementation of skin selection under H.263 . . . . . . . 7.2.2 Very fast skin selection implementation . . . . . . . . . . 7.3 Background substraction . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Background replacement (Chroma-key with virtual blue room) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Change detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

29

29 29 30 31 31

33

33 33 34 34 35 36 36 36 37 38 38 38 40 40 42 43 44 45

47

47 47 48 49 50 50

51

51 52 52 52 53 54 54 55

Contents

8 Compression techniques vs. network technology 8.1 Introduction . . . . . . . . . . 8.2 Classi cation of networks . . 8.3 Computer networks . . . . . . 8.3.1 POTS . . . . . . . . . 8.3.2 ISDN . . . . . . . . . 8.3.3 Internet . . . . . . . . 8.3.4 ATM . . . . . . . . . . 8.4 Compression and Network . . 8.5 Choice of compression . . . . 8.5.1 Inter vs. Intra frames 8.6 Latency . . . . . . . . . . . . 8.7 Summary . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

9 Implementation and performance of the R263 encoder 9.1 Introduction . . . . . . . . . . . . . . . . . 9.2 Code optimization . . . . . . . . . . . . . 9.2.1 Compiler ags . . . . . . . . . . . 9.2.2 Fine-tuning . . . . . . . . . . . . . 9.3 Implementation of change detection . . . 9.4 Results of the R263 encoder . . . . . . . . 9.5 Adaptive encoding based on system load . 9.5.1 Implementation . . . . . . . . . . . 9.5.2 Results . . . . . . . . . . . . . . . 9.6 Summary . . . . . . . . . . . . . . . . . .

10 Conclusion 11 Acknowledgements

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

57

57 57 58 58 58 58 59 59 60 61 61 62

63

63 63 63 64 65 66 68 69 69 70

71 73

vii

Contents

viii

List of Figures 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

The 4:2:0-format . . . . . . . . . . . . . . The 4:2:2-format . . . . . . . . . . . . . . Quantization and de-quantization . . . . . Example of a Discrete Wavelet Transform Overview of the JPEG codec . . . . . . . Zig-zag coecients sequence . . . . . . . . Component interleaving using MCUs . . . JPEG Lossless prediction for pixel X . . . Hierarchical encoding in JPEG . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

7 8 9 12 14 15 15 17 18

3.1 3.2 3.3 3.4

Forward prediction . . . . . . Average prediction . . . . . . Composition of an H.261 CIF B-frame of H.263 . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

21 22 24 26

SOCR block comparison using 8 8 blocks . . . . . . . . . . . . Logarithmic search algorithm for 9 9 blocks . . . . . . . . . . . Example of interpolation of 2 2 pixels . . . . . . . . . . . . . . Average length of X and Y motion vectors for a video sequence. Maximum length found per frame of X and Y motion vectors for a video sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Size of MV against fraction of MVs with this size . . . . . . . . . 5.7 Size of MV against cumulative percentage of MVs within this size

35 36 37 39

. . . .

5.1 5.2 5.3 5.4 5.5

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

40 41 42

6.1 Plot of compression ratio versus SNR (dB) . . . . . . . . . . . . 50 7.1 Overview of background substraction . . . . . . . . . . . . . . . . 53 7.2 Steps for encoding of one Macro-Block . . . . . . . . . . . . . . . 54 7.3 Macro-block encoding with block change detection . . . . . . . . 55 9.1 Model for a real-time video compression application . . . . . . . 68

ix

List of Figures

x

List of Tables 2.1 LZW encoding of word \bananas" . . . . . . . . . . . . . . . . . 11 2.2 LZW dictionary after encoding/decoding of word \bananas" . . . 11 2.3 Lossless prediction formula table . . . . . . . . . . . . . . . . . . 17 3.1 MPEG-1 Constraint Parameter Bit stream . . . . . . . . . . . . . 23 4.1 Eect of H.263 advanced options on compression ratio (Miss America sequence, 150 frames) . . . . . . . . . . . . . . . . . . . 30 5.1 5.2 5.3 5.4

Search window size for Miss America video stream at 15 fps . . . Search window size for Miss America video stream at 7.5 fps . . SOCR block comparison on Miss America sequence at 15 fps . . Quality of video stream compared with real frame rate of 30.0 fps

41 42 43 45

6.1 6.2 6.3 6.4

SNR comparison of DCT algorithms. . . . . . . . . . . . Performance comparison of DCT algorithms. . . . . . . Compression comparison of DCT algorithms. . . . . . . Quantization versus Quality for Miss America sequence

48 48 48 49

. . . .

. . . .

. . . .

. . . .

. . . .

8.1 Comparison between dierent compression methods for a QCIF frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.1 Comparison of Miss America encoding (75 frames) with and without motion detection (MD) . . . . . . . . . . . . . . . . . . . 9.2 The streams that are used for compression . . . . . . . . . . . . . 9.3 The streams that are used for compression . . . . . . . . . . . . . 9.4 Pro le of encoding . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

66 67 67 68

List of Tables

xii

Chapter 1

Introduction 1.1 A brief history of computing power Computer technology is improved in a revolutionary way since the rst systems were developed in the 50s and 60s: Size of computers decreased signi cantly while at the same time computing power increased by factors of two each year. The developments lead to new applications for each new generation of computers. After the introduction of computer systems in businesses in the 70s, small computer systems entered households in the 80s. First, text-based applications were replaced by graphics-based What You See Is What You Get (WYSIWYG) applications. At the end of the 80s, more and more applications made use of the available graphical user interface (GUI) for cartoon animations and to display pictures. This development encouraged manufacturers of video cards and monitor to display up to true-color1 images on standard computer monitors. The next logical step was the development of technology to display motion-fragments on a computer monitor. In summary, video technology and computing power drove each other to new and higher standards in the computer industry. Video processing requires a large amount of resources. Data storage and network capacity are currently the main bottlenecks for more widespread use of video applications. Waiting for new technology in these elds is not an option and other approaches must be taken to make more eective use of the available resources. Compression might be the solution in this situation. Compression algorithms make it possible to store the same data in less storage space. Compression is not only useful for storage on media such as hard disks, CDs and tape streamers, it is also useful for transmission of data over a network: less bandwidth is used for the same data. However, compression does not come free: the initial data must be transformed to its compressed equivalent. To use the initial data again, the compressed data must be decompressed. This transformation forwards and backwards takes time, may reduce quality of the data, uses system memory and above all, it costs CPU power. 1 True color is 24-bit color, which means that for every red, green and blue component 8 bits per pixel are reserved

1

1.2 The Pegasus project

Introduction

1.2 The Pegasus project The Pegasus Project [Mullender92] is a three-year European ESPRIT project with the University of Twente and the University of Cambridge as main participants. In 1995, this rst project was successfully nished with a workshop in Cambridge. The outcomes of the project is a multimedia system, including a real-time kernel, a lesystem for multimedia-data, and a video conferencing application (the digital TV director). In succession of this project, the Pegasus-II project continues the work in this area. The Pegasus Lab consists of a number of DEC Alpha workstations with DEC JV300 video cards. Cameras and microphones are connected through an Audio/Video Adapter (AVA) to an Asynchronous Transfer Mode (ATM) network. The DEC Alphas are also connected to this ATM network through an OTTO interface card. A Video stream is set up by sending control information to the AVA about the required video stream. This control information includes the video format (RGB, YUV, Motion-JPEG), the size of the image, the frame rate, and scaling information to automatically down-sample the resolution of the camera. Video is displayed on a DEC Alpha through the JV300 video card. The video can also be redirected to an ATM Television (ATV) that displays multimedia streams directly from the ATM network.

1.3 Goals The current algorithms used for video transport and storage are not as ecient as newer, advanced algorithms. In the Pegasus multimedia system, video streams are transmitted as Motion-JPEG streams. These streams consist of video frames that are compressed individually by a factor of 10 with negligible quality loss (invisible to the human eye). This compression mechanism is done Real-Time (30 frames per second). However, more advanced compression algorithms make use of the temporal redundancy found in subsequent video frames. These algorithms compress video up to a factor of 400. Unfortunately, this cannot (at this time) be done real-time without advanced, multiprocessor, dedicated computer systems. To make video conferencing possible between two persons at two dierent locations, these advanced compression algorithms, discussed in the previous paragraph, must be used to reduce the required network bandwidth. Unfortunately, computing power of a desktop personal computer is signi cant lower than for an high-end workstation. Purpose of my work is to examine the dierent video compression algorithms that are available, nd the conditions and parameters that apply to DVC and create a working implementation of a video compression algorithm.

1.4 Problems and Constraints Three mayor constraints determine the eectiveness of a video compression algorithm: 2

Introduction

1.5 Areas of research

Computing power: The computing power that is available in a system

determines the number of instructions that can be executed in a speci ed time. The more instructions are executed, the more redundancies in the data can be found. Processor (CPU) speed, the type of instruction set (e.g. multimedia instructions), main, virtual and cache memory in the the system and the system bus all determine the computing power of a system. Network bandwidth: The bandwidth of the network determines the amount of data that can be transported in a certain time. Not only the average bandwidth of the network is important, the minimum bandwidth and the network latency is also important. The minimum bandwidth is the bandwidth that is guaranteed by the network. In some network, e.g. Internet, this number is equal to zero. In other network, this number is equal to the average bandwidth (ISDN). In ATM-networks, services classes determine this behaviour (See also Section 8.3.4). Latency: The nal constraint for a real-time compression algorithm is the time between capturing a video frame from a camera and displaying this frame after sending it over a network. The latency depends on both the computing power and the network latency. For some applications other than DVC, latency is less important. For instance, when a video stream is stored on hard disk solely for later use. The total latency is the sum of all partial latency that occurs: The time between the frame that is grabbed and the time the data becomes available, the time it takes to compress this frame, the time it takes to transmit and receive a frame, and the time it takes to decompress and display the frame. If all resources are used on a system for compression, the compress latency is equal to the time it takes to compress a frame2. Latency is especially important for situation where interaction is required: the response time may not be too long, because it would disrupt the interaction.

See also Chapter 8 for a closer look at the characteristics of dierent network and the requirements for video communications.

1.5 Areas of research Video compression requires a lot of resources. Computing power is the main obstacle for real-time compression. Although real-time decoding of a compressed video stream is possible for the Motion Picture Experts Group (MPEG) video compression standard [Patel93] [Bhaskaran95b], real-time encoding is impossible without support of enhanced video hardware chips. Especially the motionestimation search algorithms require a lot of CPU time: an optimized encoder requires 5 times more time than its related decoder [Bhaskaran95a]. 2 We only consider full frame compression. Compression latency might be reduced further when frames are compressed in separate parts

3

1.5 Areas of research

Introduction

Current developments in the area of computing indicate that CPUs become faster and real-time encoding is feasible in a couple of years. Other developments in the area of data networks and communication indicate that network capacity will grow and the number of connected people with a faster-thanPOTS3 -connection also increases signi cantly over the next years. These developments give hope for teleconferencing in the future, but to make real-time compression possible now, new approaches must be taken. To make real-time encoding possible, a number of sacri ces must be made. Frame-rate could be decreased to a still-acceptable rate, screen size may be reduced, and the size of the compressed video stream might be increased to win valuable computing power. Another research topic is concentration of computing power to areas of the video screen that are important. These areas can be detected by nding parts of the screen that contain skin color [Zwaal95] or foreground. All these issues in uence each other and make it dicult to nd a standard solution in the form of one piece of hardware and one o-the-shelf software package. Finding an appropriate video compression standard and creating a software codec that satis es this standard is the rst part of my work. The second part is the analysis of a DVC-speci c video stream in order to optimize the codec for this kind of data. The nal, and most ambitious part of this research is the development and implementation of a codec that proves that near Real-Time encoding is possible for modest-sized video sequences. In the next two chapters, respectively image and video compression are discussed. These two chapters were published earlier as a Pegasus Paper [Aalmoes95]. In Chapter 4, the arguments are given to use the H.263 standard for video compression of low-bandwidth streams. In Chapter 5, a video stream is analyzed on its movements and alternative motion estimation algorithms are discussed here. In Chapter 6, a variety of Discrete Cosine Transform (DCT) and Inverse Discrete Cosine Transform (IDCT) algorithms are examined. Quantization, that is sometimes combined with the DCT operation is also discussed here. In Chapter 7, a number of methods are discussed to reduce the video stream or encoding time in an non-confessional way by only compressing the parts of the screen that are most important. In order to connect the technology with the reality, a variety of network connections are discussed and their implications on the video compression engine. In Chapter 8, a number of dierent computer and telecommunications networks are discussed and their implication on video encoding. The implementation of a fast H.263 encoder is discussed in Chapter 9, and its corresponding results are also given here. Finally, in Chapter 10, the conclusions are given on Real-Time video compression for low-bandwidth networks.

3 POTS stands for Plain Old Telephone System, and represents the interconnected telephone network of the national PTTs

4

Chapter 2

Overview of Still-picture Compression Standards This chapter was published earlier together with chapter 3 as the article \Overview of Still-picture and Video Compression Standards", Pegasus paper 95-3

2.1 Introduction In the past years a number of compression standards have emerged and a number is now being developed. Although it would be useful to use only one general video compression standard, a growing number of standards is developed because of enhanced processing power, dedicated hardware, new compression techniques, and networks with dierent bandwidths. Each compression standard supports a speci c video application. It is dicult to choose the correct compression standard for a speci c application. As is true of compression in general that there does not exist one best compression algorithm, the same is true of video compression: there is no best standard. Some applications require fast real-time encoding, at the cost of the compression factor (video-conferencing), while other applications want maximum compression at encoding that need not be done real-time, as long as decoding is real-time (e.g. compressing a video stream on CD-ROM). This paper describes the dierent compression techniques used in the available standards on video compression. This simpli es the choice of which standard is most suitable for a certain application. Furthermore, an estimation can be made on the computational costs and size of video stream of a video compression standard. A division is made between still-picture and video compression techniques. In Section 2.2, some commonly used terms and compression techniques for still-picture compression are explained. These techniques include ways to remove redundant information and information that is not visible to the human eye. In Section 2.3, the most important still-picture compression standards are discussed. Video compression techniques rely strongly on the techniques used in still-picture compression, but also incorporate prediction and motioncompensation algorithms. These algorithms that remove redundant information 5

2.2 Still-picture compression techniques

Overview of Still-picture Compression Standards

between the dierent frames of a video stream are discussed in Section 3.1. In Section 3.2, some video compression standards or standards to be are discussed.

2.2 Still-picture compression techniques 2.2.1 Lossy and Lossless Compression algorithms can be categorized in two groups: lossless and lossy compression. Lossless algorithms generate exactly the same bit pattern of an object after decompression as before the object was compressed. These compression algorithms are used for text and computer binary les. Lossy compression algorithms, however, may loose some information during compression and decompression. In a good lossy compression algorithm, the lost information is not visible in case of a picture. Most lossy compression algorithms have the ability to specify a quality-setting that determines how much quality (information) may be lost for a higher compression factor. Lossy compression algorithms are useful for compression of sampled data. This data is analog data from a microphone or a camera that is converted to a digital approximation. Therefore, lossy compression algorithms that change the data slightly are not catastrophic. Lossy compression followed by decompression, however, causes quality loss that can better be avoided by reducing the number of compression-decompression operations for a picture. If a picture must be manipulated (in the image space), it can best be stored as raw data between the image operations. Video compression methods are generally lossy. Video streams need to be compressed aggressively to reduce the required bandwidth and storage capacity for the video stream. Since lossy algorithms reduce the stream the most, such algorithms are used for video stream compression. It does not really matter much if parts of a video stream are lost: since the video stream is continuous, the next frame may repair the lost frame part.

2.2.2 Color spaces To de ne a video image, not only the resolution of the image must be speci ed but also the way the color information is stored. A gray-scale picture only has one color-component: luminance [Poynton95]. For an 8-bit gray-scale image, the higher the value, the lighter the color gray. The value 0 represents the color black and the value 255 represents the color white. To represent color pictures, three components are required. The most popular color space used is RGB . In this color space, the R (red) component represents the amount of red in the pixel, the G (green) component represents the amount of green in the pixel and the B (blue) component represents the amount of blue. True-color pictures use 8-bit for each component and thus 24-bit per pixel. Another known color space is Y C C . The Y component represents the luminance, while the two chrominance components C and C determine the actual color. B

R

B

6

R



To convert a RGB color space to an Y C C color space, the three color component intensities of RGB determine the luminance Y . The Y value is a weighted sum of the three color intensities: the green component is brighter than the red component and the red component is brighter than the blue component for the same value. The C component is the blue component without the total luminance (C ? Y ). The C component is the red component without the total luminance (C ? Y ). The Hue-Saturation-Brightness (HSB ), the Hue-Lightness-Saturation (HLS ), or also called the Hue-Saturation-Value (HSV ) color space is based on specifying the colors numerically. The Hue component describes the pure color, the Saturation component describes the degree to which the pure color is diluted by while light, and the Brightness describes the brightness or luminance. The problem with this color space is that no reference is made to the linearity or non-linearity of the colors. To determine the lightness from RGB , the three color component values are averaged ((R + G + B )=3), while the visual luminance of green is much higher than the visual luminance of blue. For (lossy) image compression, it is advised to convert RGB color space to Y C C [Wallace91]. The human eye is more sensitive to luminance components than to chrominance components and by separating them, the luminance component can be encoded in a higher resolution than the chrominance components. In other words, less bits for the chrominance components need to be encoded. The relation between the resolution of the luminance components and the chrominance components determines the picture format. A luminance component accompanied by two chrominance components that are down-sampled in both horizontal and vertical dimensions by two is called the 4:2:0-format (see Figure 2.1) [Kleine95] [Filippini95]. If the chrominance components are only down-sampled in horizontal direction by 2, the format is called the 4:2:2-format (see Figure 2.2). Finally, the 4:1:1-format has its chrominance components horizontally down-sampled by 4 and has no down-sampling in the vertical dimension. B

R

B

B

R

R

B

R

+

Y (8 x 8)

+

C

B

(4 x 4)

Figure 2.1: The 4:2:0-format 7

C

R

(4 x 4)



+

Y

+

C

(8 x 8)

B

(4 x 8)

C

R

(4 x 8)

Figure 2.2: The 4:2:2-format

2.2.3 DCT transformation A transformation that is useful in image compression is the DCT [Wallace91]. This transformation converts an n n block of elements into another block of n n coecients. These n n coecients represent two-dimensional unique spatial frequencies. The DCT function is reversible by using an IDCT function. The rst coecient, which has a zero horizontal and vertical frequency, is called the DC-coecient and is equal to the average value of the original elements. The other coecients are called AC-coecients and represent the dimensional spatial frequencies. The DCT and IDCT are lossless if the DCT encoded data are stored with perfect accuracy. In practice, however, the coecients are stored as integers which can introduce small dierences with the original data after the IDCT decoding. If the DCT transformation is applied to blocks of pixels, higher spatial frequency coecients become (near) zero because most pixels next to each other dier little in value. If relative more bits are used to encode the lower frequency coecients than the higher frequency coecients, a (lossy) compression method is created.

2.2.4 Scalar Quantization When people refer to "quantization", they usually mean Scalar Quantization and not other forms of Vector Quantization (VQ) (see Section 2.2.5). Scalar quantization is used to reduce the number of bits that are needed to store an integer. This can be done by dividing the integer by a quantization factor and rounding it to the nearest integer before it is stored. To retrieve the integer again, the stored (quantized) integer is multiplied by the quantization factor again. This step is not lossless, as the density of the domain of the integer is reduced by the quantization factor. An example of quantization is given in Figure 2.3. A 3-bit domain is quantized by factor 2, which reduces it by one bit to a 2-bit domain. After de8



Quantized value

Reproduced value

0

0

0

1

0

0

Original value

2

Quantization by factor 2

1

Dequantization by factor 2

2

3

1

2

4

2

4

5

2

4

6

3

6

7

3

6

Figure 2.3: Quantization and de-quantization quantization, only the values 0, 2, 4 and 6 have the same value as before the quantization, but the other values are approximated by the nearest value to the original integer.

2.2.5 Vector Quantization VQ techniques make use of codebooks in combination with a matrix of vectors to represent an image [Gray92]. Instead of referring to elements directly, elements are referenced via the codebook. To transmit an image, only the references to the codebook (the vectors) have to be sent. A lot of dierent VQ methods exist. For example, each vector points to an RGB-triplet that represents one pixel, or each vector points to an n n image block that represents the vector. The way the contents of the codebook is determined also varies. A common way to generate a codebook is by using a training set to nd the "best" codes, the codes that occurs most frequently. A codebook can also be calculated based on the data that are quantized. In this case, the codebook itself is transmitted together with the vectors. Known video compression implementations based on VQ are Cinepak from Radius and Indeo 3.23 from Intel, both free for developers [Bryan95].

2.2.6 Entropy Encoding An entropy encoding algorithm is a lossless compression method, which encodes the data based on their statistical characteristics. The term "entropy encoding" is used in the JPEG compression method (see Section 2.3.1), but it can apply to all compression algorithms that increases the "energy" or the information 9



density in a message.

Human and Arithmetic compression One of the rst used general-purpose lossless compression algorithms is Human-coding [Nelson91]. This method assigns shorter bit-patterns to characters in the message that occur more frequently and longer bit-patterns to characters that occur less often. The table which is used to nd the frequency of occurrence of a character is called the Human-table. This table is determined before encoding is done by analyzing the statistics of the data to be encoded. If decoding is done on data with the same statistical characteristics, the Human-table is incorporated in the decoder. If the decoder is used to decode data with dierent statistical characteristics, the Human-table itself is sent prior to the encoded data. Another well-known method for entropy encoding is adaptive Humancoding. This method outputs a bit-pattern for each character of the message, based on the occurrence of this character of the previously encoded characters; a character that occured more frequent in the past has a smaller bit-pattern. The Human-table of adaptive Human-coding is built up on the y at the encoder, and in the same way it is rebuilt at the decoder. An advantage of this method is that the Human-table does not have to be transmitted. A variant of Human coding that compresses data more than (adaptive) Human coding, is arithmetic coding. This method assigns a fractional number of bits per code, instead of a xed number of bits in Human-coding. The result of an arithmetic coded message is a number between 0 and 1. This number is multiplied by the number of characters in the message. The integer part is used for decoding the next character and the fraction for decoding the rest of the message. Because the coding table has for each character a range between two fractional numbers to choose from, it can `choose' the best number. A drawback of the arithmetic coding algorithm is that it is patented, and therefore it is mostly replaced by the less ecient Human-coding.

LZW compression Lempel-Ziv-Welch (LZW) is an entropy encoding technique, developed by Terry Welch [Nelson91]. The best known implementations of LZW are the UNIX "compress" utility and CompuServe's Graphics Interchange Format (GIF). LZW is based on the LZ77 and LZ78, which are developed by Lempel and Ziv. LZ77 and LZ78 are dictionary-based algorithms: they build up a dictionary of previously used strings of characters. The output stream of these encoders consists of characters or references to the dictionary. A combination of a reference with a character generates a new reference in the dictionary. For example, a reference to "Hi" in the dictionary followed by the character "s" results in a new reference "His". LZW is an improvement over LZ78. LZW uses a table of entries with an index eld and a substitution-string eld. This dictionary is pre-loaded with every possible symbol in the alphabet. Thus, every symbol can be found in 10



the dictionary by using a reference. The encoder searches in the dictionary for the largest possible reference to the string at the input. This reference plus the rst symbol of the input stream after the reference is stored in the output stream. An example of the encoding of the word "bananas" is given in Figure 2.2 and Table 2.1. The decoder reads the encoded stream and replaces the reference by the substitution string that is stored in the associated entry of the dictionary. The symbol that follows the reference is directly stored in the decoded stream. The reference and the symbol are also used to create a new entry in the dictionary. Input stream 'b' 'a' 'n' 'a' 'n' 'a' 's'

Generated entry Output stream 256 = \ba" 257 = \an" 258 = \na" 257 259 = \ana" 260 = \as"

'b' 'a' 'n' 257 'a' 's'

Table 2.1: LZW encoding of word \bananas" Index 0 1 ... 255 256 257 258 259 260

substitution string (char) 0 (char) 1 .. (char) 255 \ba" \an" \na" \ana" \as"

Table 2.2: LZW dictionary after encoding/decoding of word \bananas"

2.2.7 Fractal compression Fractal compression is one of the latest techniques in lossy image compression. Fractals are images that recursively contain themselves. They are de ned by a number of translations that include rescales, rotations and dimensional ips. If you zoom into a fractal image, it appears that the image has an in nite resolution, but it is actually a part of the same image that reappears in itself. The idea behind fractal compression is to automatically nd a fractal that resembles the image that must be compressed. A mayor advantage of fractal compression is the ability to decompress the image to any given resolution. The rst implementation of such an algorithm was implemented by Arnaud Jacquin [Gailly95] 11



and was capable of compression from 8:1 to 50:1 while remaining reasonable quality. This implementation searches a combination of transformations that represent the image the best. Unfortunately, the search to nd these transformation is very computationally intensive, which makes it unattractive for real-time image compression. Iterated Systems developed and sells a fractal-based compressor/decompressor, mainly used for CD-ROM encyclopedia applications.

2.2.8 Wavelet compression A relative new and promising development in the area of lossy compression is the use of wavelet transformation [cody92] [press91]. An important characteristic of this transformation is that if it is applied on a time-domain signal, it results in a representation that is localized in time domain as well as in frequency domain. Compared to the Fast Fourier Transform (FFT) that is of an order of N 2 log(N ) for N elements, a fast wavelet transform has an order of N for the same number of elements. The wavelet transformation converts a sample of 2 values into 2 ?1 approximation wavelet transform coecients and 2 ?1 detail wavelet transform coecients. This transformation can be repeated over the generated approximation wavelet transform coecients a number of times, until the minimum number of 2 approximation transform coecients and 2 ? 2 detail transform coecients remain. The number of transformations is called the number of levels of the wavelet transformation. The wavelet transformation is inversive, so applying this inverse wavelet transform a number of times (equal to the number of levels) on the generated wavelet coecients, the original sample is recomposed. J

J

J

J

X0

S

X1

S

X2

S

0

1

2

Approximation transform coordinates

DWT X3

S

X4

D0

X5

D1

X6

D2

X7

D3

3

Detail transform coordinates

Figure 2.4: Example of a Discrete Wavelet Transform An example of wavelet transform is given in Figure 2.4. In this example a Discrete Wavelet Transform (DWT) is applied to an array of 8 coordinates. The result are 4 approximation transform coordinates S0::S3 (also called the smooth vector) and 4 detail transform coecients D0::D3 (also called the detail vector). Now, the DWT is applied again on the approximation transform coecients. 12


2.3 Still-picture compression standards

All of these resulting coecients together with the detail transform coecients from Figure 2.4 form the nal wavelet coecients. Wavelet compression is obtained by only storing those coecients of the wavelet transformation that have an amplitude above a certain threshold together with the place of those coecients in the transformed domain. Because the coecients are also time-domain, high contrast edges are maintained at the cost of low contrast areas. By using quantization and entropy encoding in combination with wavelet transform the number of bits needed to store the wavelet coecients is further reduced.

2.3 Still-picture compression standards Still-picture compression techniques take advantage of spatial redundancy found in images: in most cases, pixels close to each other have the same color, or almost the same color.

2.3.1 JPEG The JPEG standard [Wallace91] is developed by the Joint Photographic Experts Group. It is a collaboration between the former International Telegraph and Telephone Consultative Committee (CCITT)1, and the International Standardization Organization (ISO). The JPEG standard is now widely adopted in the world. There are four modes of operation:

Sequential encoding: This is the general mode, in which a picture is encoded from top to bottom.

Progressive encoding: In this mode, the picture builds up in multiple scans. After each scan, the picture gets sharper.

Lossless encoding: In this mode, the picture is compressed in a way that no data is lost after decompression. The algorithm used for lossless encoding is rather dierent from one used in the sequential and progressive modes of operation.

Hierarchical encoding: In this mode, the image is encoded in dierent

resolutions. Accessing a low-resolution version does not require decompression of the full resolution version.

The JPEG encoder works on one color component at a time. For gray-scale pictures, which only consist of one component, the encoding is straight-forward. For color pictures, every component is encoded separately just like a gray-scale picture. The color components can be interleaved with each other or can be sent after one another, see Section 2.3.1. 1

The CCITT is now called the International Telecommunication Union (ITU)

13



Sequential encoding The most common way to encode a JPEG picture is by using sequential encoding. An overview of the codec (Compressor/de-compressor) is given in Figure 2.5. JPEG-encoder

Data analysis Quantization table

Original picture

Color space conversion

DCT

Quantization

Huffman table

Entropy encoding

Compressed picture

Decompressed picture

Color space conversion

IDCT

De-quantization

Quantization table

Entropy decoding

Huffman table

JPEG-decoder

Figure 2.5: Overview of the JPEG codec For every component, the picture is divided in blocks of 8 8 pixels. Each block is transformed in another 8 8 block using a DCT function. The resulting transformed block consists of 64 unique two-dimensional spatial frequencies coecients, of which the higher frequency coecients are very small or zero. After the DCT transformation, the transformed block is quantized by using an 8 8 quantization table. This means that every coecient is divided by its corresponding quantization value and rounding the result to the nearest integer. Note that this step is lossy and removes data that may not be visible to the human eye. The resulting block of coecients contains even more small or zero values. This block of coecients is stored in a sequence according to a zig-zag route de ned in the block, see Figure 2.6. This zig-zag sequence is chosen in a way that low-frequency coecients are stored rst and the highfrequency coecients last. Putting the high-frequency coecient next to each other results in a series of low or zero value data at the end of the sequence. This sequence is encoded eciently by using the entropy encoder. The nal step is entropy encoding of the created sequence. The quantized DC coecients are treated a little dierent from the other AC coecients: because the value of DC coecient of adjacent blocks correlate strongly, not the value itself but the dierence with the previous DC coecient is used for entropy encoding. The entropy encoder is a mixture of a variable-length encoder and the Human or arithmetic encoder. 14



Figure 2.6: Zig-zag coecients sequence

Color Component Interleaving It is possible to interleave the dierent color components per frame. In interleaving mode, every color component is divided in a number of Minimum Coding Units (MCUs). Every MCU consists of i by j (where 1 i; j 2) data units for each color component. A data unit is a block of 8 8 pixels that is converted to its DCT equivalent block of 8 8 coecients. Data units in an MCU, and MCUs in a frame are ordered in a left-to-right and top-to-bottom order. The number of data units in a MCU may not exceed 10. Because of this restriction, not all non-interleaved JPEG compressed images can use interleaving. For a 4:2:0-format, an MCU contains 4 data units of the Y component, 1 data unit of the C component, and 1 data unit of the C component, see Figure 2.7. The interleaved video stream of this example looks like this: MCU1 ; MCU2; ::: = B

R

Y0 0 ; Y1 0 ; Y0 1 ; Y1 1 ; C ;

0

;

;

2

;

4

B0;0

;C

R0;0

6

; Y2 0; Y2 1; Y3 0; Y3 1; C ;

;

;

0

0

;

B1;0

;C

R1;0

2

; :::

0

0

2

0

2

+

4

+ 2

2 6

Y

C

(8 x 8)

MCU 1

B

(4 x 4)

MCU 2

Figure 2.7: Component interleaving using MCUs 15

C

R

(4 x 4)



Progressive encoding Progressive encoding allows a user to transmit a picture in a number of scans. The rst scan is a rough approximation of the picture, but every next scan improves the picture. Progressive encoding uses the same compression techniques found in sequential encoding. The progressive encoding mode, however, introduces a buer between the quantization and entropy encoding step large enough to store the whole DCT-encoded and quantized picture. The buer is then entropy encoded in a number of scans. Two methods can be chosen to select the information per scan:

Spectral selection: a selection of the quantized coecients is made that

are transmitted. For example, in the rst scan, only the DC coecient and the three rst AC coecients (according to the zig-zag ordering) are transmitted, in the second scan the next 16 AC coecient are transmitted, and in the nal scan the last 44 AC coecients are transmitted. Successive approximation: a bit selection of every quantized coecient is sent per scan instead of the whole quantized coecient. For instance, in the rst scan, the three most signi cant bits of all the quantized coef cients are transmitted and in the second and nal scan the rest of the quantized coecients are transmitted.

The two methods can be mixed, which enables the user to choose the "progression" in a very exible way. The drawback of progressive encoding compared to sequential encoding is the extra buer that is introduced in the encoder and the decoder, and a more computational-intensive decoder as for each scan the quantization and IDCTprocesses must be executed again.

Lossless encoding The JPEG lossless mode does not make use of the DCT transformation. Instead of DCT and quantization, it uses a prediction process that determines the value based on the values of the pixels on the left and above the current pixel, see Figure 2.8. The selection value for prediction (see Table 2.3) and the dierence with the actual pixel value is then sent to the entropy encoder. The entropy encoder can be either an Human encoder or an arithmetic encoder. For the Human encoder, the entropy encoding stage is almost identical the the DCcoecient encoder in the sequential mode.

Hierarchical encoding Hierarchical encoding allows a user to decode a low-resolution version of a picture, without decoding and down-sampling the whole encoded picture. The hierarchical mode is used in combination with lossless, sequential, or progressive encoding mode. A number of steps are done by the hierarchical encoder, see Figure 2.9: rst, the picture is down-sampled a desired number of times by a factor of two in 16



C

B

A

X

Figure 2.8: JPEG Lossless prediction for pixel X Selection value Prediction for X 0 no prediction 1 A 2 B 3 C 4 A+B ?C 5 A + (B ? C )=2 6 B + (A ? C )=2 7 (A + B )=2 Table 2.3: Lossless prediction formula table horizontal dimension, in vertical dimension, or in both dimensions. The result is the minimal resolution of the picture that can be retrieved by the decoder. Then, the encoder compresses this down-sampled picture using one of the sequential, progressive or lossless compression modes. This compressed image is sent to the outgoing video stream. After that, the encoder decompresses the compressed image, so it has the same image as the decoder2 . This image is up-sampled by a factor of 2 in either horizontal, vertical or both dimensions, by using an interpolation lter that is also used in the decoder. The result is then compared with the original image which is down-sampled to the same resolution, or with the original image itself (without down-sampling) if it is already the same resolution. The dierence of this comparison is encoded using the same compression method as mentioned before. In this encoding, a dierent quanti cation table can be used, because the dierence of two images has other (statistical) characteristics than an image itself. If the up-sampled image still has a lower resolution than the original image, the encoder can up-sample, interpolate, compare with the (down-sampled) original image, and calculate a compressed dierence-image again, until the whole resolution of the original image is sent over. The drawback of hierarchical encoding is the need for picture buers for each resolution that is sent over at the encoder and one extra buer at the decoder. Furthermore, if the decoder wants the picture with the highest resolution, a lot more calculations must be made at the encoder and at the decoder than with sequential coding. 2 This decoding step can be optimized when lossless mode is used or an intermediate result is stored before the lossless entropy encoding during encoding.

17


Overview of Still-picture Compression Standards Down-sampled image

Original image

First scan Down-sampling

Upsampled reconstructed image

Compression

Decompressed image

Up-sampling &

Decompression

Interpolation

Difference image

Comparison

∆

Second scan Compression

Figure 2.9: Hierarchical encoding in JPEG The Independent JPEG Group (IJG) developed a public domain source code that supports lossless, sequential and progressive operations modes. Hierarchical mode is not (yet) supported.

2.3.2 GIF

GIF is a lossless, 256 color, still-picture compression standard [Gailly95]. It a variation of the LZW compression technique called Variable-Length LZW. GIF is most suitable for images that have a small number of colors, such as computer generated graphics and cartoons. It is also useful for small images. The dierence between the LZW compression method and Variable-Length LZW used in GIF is that in the latter the size of the code to represent an entry in the table is increased by a bit when the table is full. If this code is 12-bit and the table is full, a special character symbol (a clear code) is encoded to indicate that the table must be emptied and the table must be rebuilt from scratch. There are two widely used versions of GIF: 87a and 89a [Compuserv90]. The 89a version has some extensions to insert text into the picture, and comments and application speci c codes in a GIF le, but the LZW algorithm used is not dierent.

18

Chapter 3

Overview of Video Compression Standards This chapter was published earlier together with chapter 2 as the article \Overview of Still-picture and Video Compression Standards", Pegasus paper 95-3

3.1 Video compression techniques The advantage of video compression standards over still-picture compression standards is that they not only make use of spatial redundancy, but also make use of temporal redundancy, which can reduce the size of the video-stream signi cantly. Temporal redundancy is the property of a video stream to show the same information (objects) over a certain period of time (a number of frames). In video compression algorithms, motion-compensation prediction techniques are used to scan previously sent frames for parts that are (about) the same as the current frame that is encoded.

3.1.1 Prediction The most basic form of prediction checks if a block of n m data in the current frame is the same as the block on the same place in the previous frame. If there is no change, the data of this block is not encoded. Although this is an easy example, the implementation still requires quite some thought: What size is chosen for the block that is compared and must the blocks be exactly the same, or is there a threshold value before the block is marked as changed? In most implementations, prediction is combined with motion-compensated interpolation. If a block of data is not identical to a block of data in a previous frame, the best matching block is found and the dierence is used for further compression. The resulting block is compressed better than the original block of data. The area that is used for comparison of the block determines the quality of the nal prediction. The larger the area that is searched to nd a matching block, the larger the change it is actually found. But most matching blocks are 19

3.2 Video compression standards

Overview of Video Compression Standards

found around the place of the original block and increasing the search area also increases the computation time to nd a matching block. Bi-directional prediction not only searches a previous frame for a closematching block, it also searches a next frame in the video stream. Another advantage of bi-directional prediction is that it can combine the prediction of a previous frame with the prediction of a next frame into an average prediction image block.

3.2 Video compression standards 3.2.1 Motion-JPEG The (lossy) JPEG compression standard is so successful that it is also used for motion-picture compression [Lane95]. Although Motion-JPEG is not declared as a standard by any standardization committee, it is used by many vendors and may therefore be called a de facto standard. Motion-JPEG has no standard set of picture formats, nor is there agreement over the le format. Motion-JPEG encodes every frame as a sequential mode JPEG-picture, without making use of temporal redundancies in the video stream. MotionJPEG has a number of advantages. First, Motion-JPEG requires less computation time than other compression standards, because of the lack of motioncompensation algorithms. Second, random access of frames is possible as every frame can be encoded and decoded independent of the other frames. Third, Motion-JPEG introduces less latency than methods with Motion Estimation like MPEG (See the next Chapter). The main disadvantage of Motion-JPEG is the poor compression factor, due to the lack of temporal redundancy reduction techniques.

3.2.2 MPEG-1 MPEG stands for Motion Picture Experts Group, and is concerned with the development of video compression standard [Gall91]. Although the MPEG is also developing audio and synchronization standards as part of the MPEG standard, we only look at the video compression techniques used. MPEG-1 is the rst standard of the MPEG-group. It describes the way a video stream must be stored, but it does not give speci cations on how the coding (and decoding) must be done. The MPEG-1 standard is designed for (encoded) video streams of 1.5 Mbps, which is sucient for CD-ROM applications. MPEG-1 supports encoding of the Standard Interchange Format (SIF), which has a resolution of 352 240 pixels at a rate of 30 frames per second for NTSC and a resolution of 352 288 at a rate of 25 frames per second for PAL and SECAM. A MPEG video stream uses three dierent types of frames:

I-frames: The I or intra-picture frames are compressed independent of the other frames in the video stream.

20



P-frames: P or predicted frames are frames that store the dierence be-

tween the current frame and the previous P or I frame that is encoded. B-frames: B or Bidirectional prediction frames use both the previous I or P frame and the next I or P frame to predict the current frame.

I, B and P frames are compressed dierently. In I frames, compression is achieved by reducing spatial redundancy in the frame. P and B frames also use temporal redundancy reduction to improve the compression factor. Because B-frames make also use of the next I or P frame as reference, B frames have the highest compression factor. An MPEG video stream consisting of only I frames has, except for some quantization and Human-encoding details, the same compression factor as a motion-JPEG video stream (using the same video format). However, I frames are important for random access, the ability to decode independent frames without decoding the whole video stream. A frame is divided in a number of 16 16 blocks of pixels called Macroblocks. A macro-block can be encoded in four dierent ways:

Intra-block encoding: no prediction is used. Forward predicted encoding: A 16 16 block of pixels is searched in the

next I or P-frame that most closely resembles the current macro-block, see Figure 3.1. The dierence between these blocks are used for further compression. Backward predicted encoding: This encoding is the same as forward predicted encoding, but with the dierence that blocks are searched in the previous I or P frame instead of the next frame. Average encoding: Backward and forward predicted encoding is used to nd two blocks of pixels that resemble the current macro-block best, see Figure 3.2. These two blocks are averaged and the dierence with the current macro-block is used for further compression.

T0

T1

Figure 3.1: Forward prediction 21


T-1


T0

T1

Figure 3.2: Average prediction I frames only use intra-block coding; P frames use either intra-block coding or backward predicted coding. B frames use any of the encoding modes. After motion prediction, a macro-block must be compressed to reduce spatial redundancy. An 8 8 DCT is used similar to one found in JPEG. After DCT, coecients are stored in zig-zag order. These coecient are quantized depending of the original encoding mode. For intra-block encoding, low spatial frequency coecients are quantized with a lower quantization factor than high spatial frequency coecients. For the other encoding modes, the coecients are DCT-transformed dierences of pixel blocks. Low frequencies of these blocks will be close to zero, because of the applied prediction. Therefore, another quantization matrix must be used than for intra-block-encoded, DCT blocks. MPEG also allows dierent quantization step sizes for dierent blocks. This is independent of the encoding mode (intra or predictive encoding). Dierent quantization step sizes allow the encoder to code certain blocks more accurate than others. In general, an MPEG video stream consists of many B-frames, some Pframes and a few I-frames. The I-frames guarantee random-access in the video stream. P frames are also important because B-frames can only refer to I or P-frames, not to B-frames. After motion prediction, DCT and quantization, the output stream is entropy encoded by a variant of the variable-length compression technique found in JPEG. The MPEG-1 is tuned for compression of video streams that comply to a Constraint Parameter Bit stream (CPB), see Table 3.1. Video streams that use more bandwidth compared to this CPB may be encoded through MPEG-1, but the encoding is not necessarily ecient and support is not guaranteed by MPEG-1 hardware.

3.2.3 MPEG-2 The MPEG-2 standard is developed for high-end video applications that need a compressed video stream from 4 Mbps up to 100 Mbps [Kleine95] [Okubo95]. MPEG-1 may not be ecient for these video streams, but is to video streams 22



Horizontal size in pixels Vertical size in pixels Total macro-blocks per picture Total macro-block per second Frame rate Bit rate Decoder buer

720 576 396 396*25 (=330*30) 30 1.86 Mbps 376832 bits

Table 3.1: MPEG-1 Constraint Parameter Bit stream that conform to the CPB of MPEG-1. Furthermore, interlaced video streams, which are common in the television industry, are not easily converted to MPEG1; MPEG-2 is more suited for these interlaced video streams. Video streams of MPEG-2 are nevertheless compatible with MPEG-1. The MPEG-2 standard deals with dierent resolution video streams that are divided in pro les and levels. The lowest level format is 352 288 pixels (PAL format) and the highest is 1920 1152 (PAL format) pixels. The simplest pro le does not use B-frames, is not scalable and uses a 4:2:0 luminance/chrominance format, while the high pro le uses B-frames, is scalable and uses either a 4:2:0 or a 4:2:2 luminance/chrominance format.

3.2.4 MPEG-4 At this moment, MPEG-4 is still in development and no concrete algorithms or methods are yet determined [Filippini95]. However, an outline of the goals of MPEG-4 is available. MPEG-4 is not just a compression standard, it will incorporate a description language that determines the contents of a video stream. It also distinguishes dierent objects that enables the user to set priorities to dierent objects so that the foreground of a picture has a higher priority than the background. MPEG4 intends to support a wide variety of video streams from low-bandwidth to 3-dimensional video streams. An MPEG-4 stream combines tools, algorithm and pro les. These will determine how data is stored. For example, subtitles will be coded dierently than other video objects. MPEG-4 is scheduled to become a standard in the end of 1998.

3.2.5 H.261 The CCITT developed the H.261 video compression standard that is designed for video communications over ISDN networks [Liou91][Turletti93]. H.261 can handle p 64 Kbps (where p = 1; 2; :::; 30) video streams and this is equal to the possible bandwidths in ISDN. The H.261 standard supports the following two video formats:

Common Intermediate Format (CIF). This format has a resolution of 360 288 pixels for the luminance (Y ) part of the video stream and a 23



resolution of 180 144 pixels for the two chrominance parts (C and C ) of the video stream; R

B

Quarter-CIF (QCIF). This format contains a quarter of the information of a CIF video stream. This means that the luminance resolution is 180 144 pixels and the two chrominance resolutions are 90 72 pixels; The maximum frame rate for a H.261 video stream is 30 frames per second. The CIF and QCIF consist of pictures for each frame, and within each picture of Group Of Blocks or GOBs, see Figure 3.3. A QCIF has 3 GOBs, while a CIF has 12 GOBs. Each GOB consist of 3 11 Macro Blocks (MB). A Macro Block is composed of 4 8 8 luminance blocks and two 8 8 chrominance blocks (C and C ). A macro block can be compared to an MCU in JPEG. B

R

GOB

QCIF C Y

CIF

B

C

R

MB

Figure 3.3: Composition of an H.261 CIF The H.261 encoder can operate in two modes. In the intra-frame mode, every 8 8 block is DCT-transformed, linearly quantized, and sent to the video multiplexer. In the inter-frame mode, every 8 8 block is also DCT-transformed and linearly quantized, but the result is rst sent to a motion-compensator before it is sent to the video multiplexer. The motion-compensator is used for comparing the macro-block of the current frame with blocks of data from the previously sent frame. If the dierence is below a pre-determined threshold, no data is sent for this block. Otherwise, the dierence is DCT transformed, and linearly quantized. The nal encoding step is the video multiplexer that uses a variable wordlength coder to reduce the bit stream even more. After the video multiplexer, the result is inserted in a transmission buer, which controls the linear quantizer in order to regulate the outgoing bit stream. H.261 is similar to MPEG with respect to the DCT encoding and quantization. During the standardization of MPEG-1, this is done on purpose to simplify implementations that encode or decode both H.261 and MPEG. The main dierence between H.261 and MPEG-1 is that motion vectors in H.261 are restricted to 15 pixels away from the original place in the picture. Furthermore, no future-prediction is used in H.261 which means that H.261 has no equivalent of B-frames in MPEG. 24



INRIA Video conferencing System (IVS) is an implementation of a video conferencing tool that uses H.261 for video compression. Vic is also a video conferencing tool that supports H.261.

3.2.6 H.263 The ITU H.263 draft 1 [ITULBC95] is an improvement over H.261. H.263 is developed for low-bandwidth communications over Plain-Old Telephone Systems (POTS), in particular 28.8 Kbps modems. Compared to H.261, the number of available picture formats is increased, the motion-compensation algorithm has improved, better entropy encoding is used and a new frame is introduced that allows a simple form of forward-prediction. Three new video formats are added in H.263: a sub-QCIF format is added (128 96), a 4CIF format is added (704 786), and a 16CIF format is added (1408 1152). As in H.261, the number of chrominance pixels is always half of the number of total (luminance) pixels. This means that for 2 2 luminance pixels, one C and one C pixel is used. H.263 also supports unrestricted motion vector mode. In the default (restricted) motion vector mode, the block that is referenced should be fully inside the picture. In unregistered motion vector mode, an arbitrary number of pixels may be outside the pixel. For every reference to these pixels, the closest edge pixel is used instead. The Advanced Prediction mode is also new in H.263. Instead of one motion vector to a 16 16 macro-block, four motion vectors to 8 8 blocks are used for prediction. Although this encoding uses more bits than with one motion vector, the quality of prediction improves signi cantly. Another improvement in H.263 is the use of motion vectors that refer to half-pixel displacements instead of displacements with a integer number of pixels. To calculate the referenced sub-pixels, the value of surrounding pixels are interpolated. Besides Intra and Inter encoded frames, H.263 introduces PB-frames. The name is derived from the MPEG P and B frames. A PB-frame (see Figure 3.4) consists of two mixed frames: one "normal" P-frame frame and one bi-directional prediction frame. When a PB-frame is decoded, rst the B-frame and after that the P-frame is shown. The P-frame can use Inter- or Intra encoding modes, but the B-frame can only use the new forward or older backward prediction mode and not the intra encoding mode. The B-frame can refer to the associated P-frame in the PB-frame, and to an average of the associated P-frame and the previously encoded P-frame. Test Model Near (TMN) is an implementation of the upcoming H.263 standard and is used as test model for this standard. It claims that it has a factor of two better compression than H.261 [Telenor95]. Source code of TMN is also available. B

1

R

At the moment of writing, H.263 is not yet a standard.

25

3.3 Summary


T-1

T0

T1

B frame

P frame

PB-frame

Figure 3.4: B-frame of H.263

3.3 Summary A number of picture and video compression techniques are discussed. For picture compression, distinction is made between lossless and lossy methods. Lossless compression generate an exact copy of compressed data after decompression. Lossy compression methods give up this requirement to obtain a much higher compression factor. Thus, the quality of lossy compression depends not only on the compression factor as with lossless compression , but also on the way the decompressed image resembles the original picture. Lossless methods for compression are LZW, (adaptive) Human and DCT, although the latter loses this property during storage of the rounded coecients. DCT transforms a block of n n pixels into a matrix of n n coecient which represent spatial frequencies. Because most high-frequency coecients are (near) zero, compression is attained. Quantization reduces the number of bits for data by reducing the density of the domain. Scalar quantization does this by dividing data by a quantization factor; decompression is done by multiplying with the same quantization factor. Vector quantization methods use a codebook to translate data to an index in the codebook; the collection of indexes and the codebook together are used to retrieve the original picture. Wavelet transform is another technique that transforms a time domain into a time-frequency domain. Compression is done by storing only some of the generated coecients. JPEG has four dierent operating modes. The lossy modes use a combination of the lossy DCT and quantization methods together with lossless entropy encoding methods to compress pictures. The progressive mode allows a user to send the picture in a number of scans so that the picture improves after each scan. The JPEG lossless mode uses a prediction-based method to compress a picture. Hierarchical mode enables a user to send dierent resolutions of a picture at the same time; low-end decoders will only decode the rst scan or the rst couple of scans, while high-end decoders decode all scans. 26


3.3 Summary

GIF uses the LZW algorithm to compress lossless 256-color pictures. Video compression techniques not only make use of spatial redundancy to reduce the bitstream, but also use temporal redundancy found in consecutive video frames. In this way, the current frame is predicted from the previous and sometimes future frames and only the dierence of these frame with the current frame is encoded. All video compression standards discussed here use DCT-transformation followed by quantization and entropy encoding. A number of video compression standards are available. Motion-JPEG is a series of JPEG compressed images stored after each other. Only spatial redundancy and not temporal redundancy is reduced. The advantage of this method is the easy implementation and random access of individual frames. The disadvantage is the poor compression factor of video streams. MPEG-1 is a standard for (compressed) bitstreams of 1.5 Mbps. It uses three dierent types of frames: I-frames that store a frame independent of the others in a stream, P-frames that store the dierence between the current and the previous I- or P-frame, and B-frame that use both the previous I- or P-frame and the next I- or P-frame in the video stream for prediction of the current frame. Pand B-frames use motion compensation techniques for their prediction. MPEG2 is an enhancement of MPEG-1 that is optimized for higher bitstreams and better video resolutions than MPEG-1. MPEG-4 is still in development but will make it possible to determine individual objects in video streams. Standards designed for ISDN and POTS telecommunication are H.261 and H.263, respectively. H.261 has two picture formats: CIF has a resolution of 352 288 and QCIF is a quarter of the CIF resolution. H.261 frames operate in either of the following modes: In intra-frame mode, the frame is individually compressed. In inter-frame mode, the dierence with the previous frame is calculated (using motion-compensation) and is stored in the outgoing video stream. H.263 is an improvement over H.261 which supports two more resolutions: 4CIF (704 786) and 16CIF (1408 1152). Furthermore, it introduces a PB-frame that enables a simple form of forward-prediction. The motion prediction algorithm is also improved in H.263.

27

3.3 Summary


28

Chapter 4

Choosing an encoding standard { the case for H.263 4.1 Introduction In Chapters 2 and 3, a number of image and video compression methods are discussed. The conclusion is that there are a number of compression algorithms that are useful video encoders in their speci c environment. Computing speed and network bandwidth are the most important constraints that determine the encoder to use. In this short chapter, the ideas for using H.263 in Desktop Video Conferencing are discussed.

4.2 The choice for H.263 If we take a look at the dierent standards that are used for video compression, it might be clear that MPEG is a leap ahead of the other standards. First, MPEG is the rst real video compression standard. Other formats existed before, but where merely variations of Motion-JPEG. Second, MPEG makes it possible to encode a video in a number of ways, including a Motion-JPEG variant (by using only I or Intra frames). Third, most applications that use MPEG do not use it with MPEG as real-time encoding source. Although this is changing currently with digital satellite TV, MPEG still requires a lot of processing power for real-time encoding. Standards that are aimed at one-to-one or few-to-few telecommunication are H.261 and now also H.263. These standards make it possible to encode video stream and transmit them over low-bandwidth networks, such as Integrated Services Digital Network (ISDN) and Plain-Old-Telephone-System (POTS). H.261 is the standard for ISDNp 64 Kbps connections (where 1 1 Mbps), are not a requirement for video communication: New, advanced standards such as H.263 are able to compress video streams drastically if enough computing power is available. Although dedicated hardware implementation are the fastest solution, this work shows that the more exible way of software encoding is a serious option. With the introduction of new processors capable of handling more data in parallel (multimedia instructions), and faster chip technology, prospects of real-time software video compression are more than hopeful. I therefore recommend further research on the usefulness of this new generation of processors for video encoding.

1 Numbers taken for sequences with moderate movement: When there is no movement at all, the encoder compresses already at the maximum of 25 fps

72

Chapter 11

Acknowledgements A large number of people have helped me during my study in one way or another. I will try to give everyone who helped me some credits, but the order of the credits given here is irrelevant, as classi cation of the dierent kinds of \help" might be a master thesis on its own. I would like to thank my graduation committee: Prof. Sape Mullender, for giving me such an interesting assignment, Peter Bosch for being my rst rst \begeleider" (I bought Elements of Style !) and of course Lars Vognild for being my second rst \begeleider". I also like to thank the other group members: Arne, Martijn, Paul, Pierre and Tatjana and everyone I forget. I also like to thank everyone who had given me work as student-assistant: Martin Beusekamp, Mr. Bonnema, Hans Scholten, Albert Schoute, and everyone else. Also would I like to thank all students who made working at SPA inspiring and pleasant. Thanks to Erwin: the word \Hacker" is named after you. Thanks BJ for your excellent taste for music. Thanks Mars for your AVA code. Thanks Robert (at least somebody else also working on H.263). And not to forget: Eelco, Berend, Rob, Tjipke (how about all your schedules?), Jing-Xu (success on your promotion), Nick, Michiel, and all others. There are a lot of people who helped me enormously, who I have never met or seen. With the result of my work, we might have a video conference in the future. Of course would I like to thank Karl Lillevold for making the H.263 code freely available. Without him, it would have taken several more months before my work was nished. I also like to thank him for his clear implementation of the code. I also want to thank Leonid Kasperovich for an interesting discussion on motion estimation in H.261, your encoder looks promising! Also thanks to Burkhard Neidecker-Lutz, I will try to give you a copy. In particular I would like to thank Edwin, whom I worked with for quite some courses. However, Coca Cola (TM) is it! 73

Acknowledgements

The other part of my life at Twente could be pronounced in a six-letter word: KRONOS. Thank you all! Training has been the best distraction there is, and I will miss you. In the nal place, and last but de nitely not least I would would like to thank my family for supporting me during my study, in every way possible. Even in a small country like the Netherlands, Twente is a long way from Schagen, and the Dutch public transportation does not always help to bridge the gap (and neither does the Secretary of Education).

Roalt Aalmoes

74

Bibliography [Aalmoes95] Roalt Aalmoes and Peter Bosch. Overview of Still-picture and Video Compression Standards. Pegasus 95-03. University of Twente, December 1995. in preparation. [Bhaskaran95a] V. Bhaskaran and K. Konstantinides. Image and video compression standards. Kluwer academic publishers, 1995. [Bhaskaran95b] Vasudev Bhaskaran, Konstantinos Konstantinides, Ruby B. Lee, and John P. Beck. Algorithmic and Architectural Enhancements for real-time MPEG-1 decoding on a General Purpose RISC workstation. IEEE Transactions on circuits and systems for video technology, 5(5):380{ 6, October 1995. [Bryan95] John Bryan. Compression scorecard. Byte, 20(5):107{12, May 1995. [Chan96] Yui-Lam Chan and Wan-Chi Siu. New adaptive pixel decimation for block motion vector estimation. IEEE Transactions on circuits and systems for video technology, 6(1):113{18, February 1996. [cody92] Mac A. Cody. The fast wavelet transform. Dr. Dobbs journal, 17(4):16{28, April 1992. [Compuserv90] CompuServe Inc. Graphics interchange format (sm) version 89a. Technical report. CompuServe, Incorporated Columbus, Ohio, 1990. [Feig92] Ephraim Feig and Shmuel Winograd. Fast algorithms for the discrete cosine transform. IEEE Transactions on signal processing, 40(9):2174{93, September 1992. [Filippini95] Luigi Filippini. MPEG informations, questions and answers, 31 July 1995. http://www.crs4.it/~luigi/MPEG/mpegfaq.html. [Gailly95] Jean loup Gailly. comp.compression frequently asked questions, 28 September 1995. ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/part[1-3]. [Gall91] Didier Le Gall. Mpeg: A video compression standard for multimedia applications. Communications of ACM, 34(4):46{58, april 1991. [Girod96] Bernd Girod. Recent advances in video compression. ISCAS-96 (Atlanta , May 1996), May 1996. 75

Bibliography

[Gray92] Robert M. Gray, Pamela C. Cosman, and Eve A. Riskin. Image compression and tree-structured vector quantization. In James A. Storer, editor, Image and text compression, Communications and information theory, pages 3{34. Kluwer academic publishers, 1992. [ITULBC95] R. Schaphorst. Draft recommendation H.263. Technical report LBC-95-251. ITU-T, 3 October 1995. [Kleine95] G. Kleine. Digitale televisie met behulp van mpeg-2-kompressie. Elektuur, 35(9):68{75, September 1995. [Koga81] T. Koga, K. Iinuma, A. Hirano, Y. Iijima, and T. Ishiguro, Motioncompensated interframe coding for video conferencing, Proceedings of NTC 81 (New Orleans), November/December 1981. [Lane95] Tom Lane. JPEG-faq, part 1, 28 May 1995. ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/part1. [Liou91] Ming L. Liou. Overview of the p*64 kbit/s video coding standard. CACM, 34(4):60{3, apr. 1991. [Liu93] Bede Liu and Andre Zaccarin. New fast algorithms for the estimation of block motion vectors. IEEE transactions on circuits and systems for video technology, 3(2):148{57, April 1993. [McCanne95] Steven McCanne and Van Jacobson. vic: a exible framework for packet video. ACM Multimedia (San Franscisco, November 1995), November 1995. [Moura96] Jose M. F. Moura, Radu S. Jasinschi, Hirohisa Shiojiri, and JyhCherng Lin. Video over wireless. IEEE personal communications, 2:44{54, February 1996. [Mullender92] Sape J. Mullender, Ian M. Leslie, and Derek McAuley. Pegasus Project Description. Memoranda Informatica 92{75. University of Twente, Faculty of Computer Science, September 1992. [Nelson91] Mark Nelson. The data compression book. M & T Publishing, Incorporated, 501 Galveston Drive, Redwood City, CA 94063-4728, U.S.A., 1991. [Okubo95] Sakae Okubo, Ken McCann, and Andrew Lippmann. MPEG-2 requirements, pro les and performance veri cation | framework for developing a generic video coding standard. Signal processing image communication, pages 201{9, July 1995. [Patel93] Ketan Patel, Brian C. Smith, and Lawrench A. Rowe. Performance of a Software MPEG Video Decoder. ACM Multimedia Conference (Anaheim 1993), 1993. [Poynton95] Charles A. Poynton. Frequently asked questions about colour, 1995. ftp://ftp.inforamp.net/pub/users/poynton/doc/colour/. 76

Bibliography

[press91] William H. Press. Wavelet Transforms. Harvard-Smithsosian Center for Astrophysics, 1991. Preprint No. 3184. [Renxiang94] Renxiang Li, Bing Zeng, and Ming L. Liou. New three-step search algorithm for block motion estimation. IEEE Transactions on circuits and systems for video technology, 4(4):438{42, August 1994. [Telenor95] Karl O. Lillevold. Digital video coding at Telenor R&D, 11 November 1995. Homepage on internet. [Turletti93] Thierry Turletti. H.261 software codec for videoconferencing over the internet. Technical report 1834. INRIA, January 1993. [Wallace91] Gregory K. Wallace. The jpeg still picture compression standard. Communications of ACM, 34(4):30{44, april 1991. [Yokoyama95] Yutaka Yokoyama, Yoshihiro Miyamoto, and Mutsumi Ohta. Very low bit rate video coding using arbitrarily shaped region-based motion compensation. IEEE Transactions on circuits and systems for video technology, 5(6):500{7, December 1995. [Zwaal95] Hugo Zwaal. The Design and Implementation of a Camera Independent Face Tracker. Technical report 95-09. University of Twente, January 1995.

77

Video Compression Techniques Over Low-Bandwidth Lines

Real-Time Video Compression: Techniques and Algorithms

Real World Video Compression

Wavelet Image and Video Compression

Wavelet image and video compression

The H 264 Advanced Video Compression Standard

Efficient algorithms for MPEG video compression

Still Image and Video Compression with MATLAB

Digital Audio and Video Techniques

Real-Time Video Compression: Techniques and Algorithms (The Springer International Series in Engineering and Computer Science)

Video Compression Systems: From First Principles to Concatenated Codecs

The H.264 Advanced Video Compression Standard, Second Edition

Standard Codecs: Image Compression to Advanced Video Coding

A Practical Guide to Video and Audio Compression

Standard Codecs: Image Compression to Advanced Video Coding

H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia - Iain E

H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia

lines

Data compression

H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Text compression

Text compression

Video Processing and Computational Video

Video Conferencing over IP. Configure, Secure and Troubleshoot

Building Jazz Bass Lines: A compendium of techniques for great jazz bass lines

Fundamental Data Compression

Video Compression Techniques Over Low-Bandwidth Lines

Real-Time Video Compression: Techniques and Algorithms

Real World Video Compression

Wavelet Image and Video Compression

Wavelet image and video compression

The H 264 Advanced Video Compression Standard

Efficient algorithms for MPEG video compression

Still Image and Video Compression with MATLAB

Digital Audio and Video Techniques

Real-Time Video Compression: Techniques and Algorithms (The Springer International Series in Engineering and Computer Science)

Video Compression Systems: From First Principles to Concatenated Codecs

The H.264 Advanced Video Compression Standard, Second Edition

Standard Codecs: Image Compression to Advanced Video Coding

A Practical Guide to Video and Audio Compression

Standard Codecs: Image Compression to Advanced Video Coding

H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia - Iain E

H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia

lines

Data compression

H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Multimedia over IP and Wireless Networks: Compression, Networking, and Systems

Text compression

Text compression

Video Processing and Computational Video

Video Conferencing over IP. Configure, Secure and Troubleshoot

Building Jazz Bass Lines: A compendium of techniques for great jazz bass lines

Fundamental Data Compression

Recommend Documents