Coding for Videoconferencing (H.261)

Overview

The H.261 standard defines the video coding and decoding methods for digital transmission over ISDN at rates of p × 64 kbit/s, where p is in the range of 1–30 [1]. The video bit rates will lie between approximately 64 kbit/s and 1920 kbit/s. The recommendation is aimed at meeting projected customer demand for videophone, videoconferencing and other audio-visual services. It was ratified in December 1990.

The coding structure of H.261 is very similar to that of the generic codec of Chapter 3 (Figure 3.18). That is, it is an interframe DCT-based coding technique. Interframe prediction is first carried out in the pixel domain. The prediction error is then transformed into the frequency domain, where the quantisation for bandwidth reduction takes place. Motion compensation can be included in the prediction stage, although it is optional. Thus the coding technique removes temporal redundancy by interframe prediction and spatial redundancy by transform coding. Techniques have been devised to make the codec more efficient, and at the same time suitable for telecommunications.

It should be noted that any recommendation only specifies what is expected for a decoder; it does not give information on how to design it. Even less information is given about the encoder. Therefore the design of the encoder and the decoder is at the discretion of the manufacturer, provided they comply with the syntax bit stream. Since the aim of this book is an introduction to the fundamentals of video coding standards, rather than giving instructions on the details of a specific codec, we concentrate on the reference model (RM) codec. The reference model is a software-based codec, which is devised to be used in laboratories to study the core elements as a basis for the design of flexible hardware specifications.

During the development of H.261, from May 1988 to May 1989, the reference model underwent eight refinement cycles. The last version, known as reference model eight (RM8) [2], is in fact the basis of the current H.261. However, the two may not be exactly identical (although very similar), and the manufacturers may decide on a different approach for better optimisation of their codecs. Herein we interchangeably use RM8 for H.261. Before describing this codec, we will first look at the picture format, and spatio-temporal resolutions of the images to be coded with H.261.

Video format and structure

Figure 6.1 shows a block diagram of an H.261-based audio-visual system, where a preprocessor converts the CCIR-601 video (video at the output of a camera) to a new format. The coding parameters of the compressed video signal are multiplexed and then combined with the audio, data and end-to-end signalling for transmission. The transmission buffer controls the bit rate, either by changing the quantiser step size at the encoder, or in more severe cases by requesting reduction in frame rate, to be carried out at the preprocessor.

click to expand
Figure 6.1: A block diagram of an H.261 audio-visual encoder

The H.261 standard also allows up to three pictures to be interpolated between transmitted pictures, so reducing the frame rates to 15, 10 and 7.5, respectively. The use of quarter-CIF, or QCIF, resolution will reduce the sample rate even further to suit low bit rate channels.

In CIF and QCIF, DCT blocks are grouped into macroblocks of four luminance and two corresponding Cb, and Cr chrominance blocks. The macroblocks (MB) are in turn grouped into layers termed groups of blocks (GOB). A CIF frame has 12 GOBs and QCIF has three, as illustrated in Figure 6.2.

click to expand
Figure 6.2: Block, macroblock and GOB structure of CIF and QCIF formatted pictures

The objectives of structuring an image into macroblocks and layers are as follows:

  • similar inter/intra coding mode for luminance and chrominance blocks at the same area
  • the use of one motion vector for both luminance and chrominance blocks
  • efficient coding of the large number of 8 × 8 DCT blocks that will be expected to be without coded information in interframe coding; this is implemented via the inclusion of VLC codes for coded block pattern (CBP) and macroblock addressing [1]
  • to allow synchronisation to be reestablished when bits are corrupted by the insertion of start codes in the GOB headers; note that since DCT coefficients are VLC coded, then any error during the transmission renders the remaining VLC coded data undecodable, hence, with a GOB structure, only a portion of the picture is degraded
  • to carry side information appropriate for GOB, macroblock or higher layers; this includes picture format, temporal references, macroblock type, quantiser index etc.

Video source coding algorithm

The video coding algorithm is shown in Figure 6.3, and is similar to the generic interframe coder of Figure 3.18 in Chapter 3. The main elements are prediction including motion compensation, transform coding, quantisation, VLC and rate control.

click to expand
Figure 6.3: A block diagram of H.261 video encoder

The prediction error (inter mode) or the input picture (intra mode) is subdivided into 16 × 16 macroblock pixels, which may or may not be transmitted. Macroblocks that are to be transmitted are divided into 8 × 8 pixel blocks, which are transform coded (DCT), quantised and VLC coded for transmission. As we discussed in section 6.1, the atomic coding unit in all standard video codecs is a macroblock. Hence in describing the codec we will explain how each macroblock is coded.

In Figure 6.3, the function of each coding element and the messages carried by each flag are:

COMP

a comprator for deciding the inter/intra coding mode for an MB

Th

threshold, to extend the quantisation range

T

transform coding blocks of 8 × 8 pixels

T-1

inverse transform

Q

quantisation of DCT coefficients

Q-1

inverse quantisation

P

picture memory with motion compensated variable delay

F

loop filter

P

flag for inter/intra

t

flag for transmitted or not

q

quantisation index for transform coefficients

qz

quantiser indication

V

motion vector information

f

switching on/off of the loop filter

Prediction

The prediction is interpicture, which may include motion compensation, since motion compensation in H.261 is optional. The decoder accepts one motion vector per macro-block. Both horizontal and vertical components of these motion vectors have integer values not exceeding ±15 pixels/frame. Motion estimation is only based on the luminance pixels and the vector is used for motion compensation of all four luminance blocks in the macroblock. Halving the component values of the macroblock motion vector and truncating them towards zero derives the motion vector for each of the two chrominance blocks. Motion vectors are restricted such that all pixels referenced by them are within the coded picture area.

For the transmission of motion vectors, their differences are variable length coded. The differential technique is based on one-dimensional prediction, that is the difference between the successive motion vectors in a row of GOBs. For the first macroblock in the GOB, the initial vector is set to zero.

MC NO_MC decision

Not all the macroblocks in a picture are motion compensated. The decision whether a macroblock should be motion compensated or not depends on whether motion compensated prediction can substantially reduce the prediction error. Figure 6.4 shows the region (shaded) where motion compensation is preferred. In this Figure the absolute values of frame difference, fd, and those of motion compensated frame difference, mfd, normalised to 16 × 16 = 256 pixels inside the macroblock are compared.

click to expand
Figure 6.4: Characteristics of MC/NO_MC

From the Figure we see that if motion compensated error is slightly, but not significantly, less than the nonmotion compensated error, we prefer to use nonmotion compensation. This is because motion compensation entails a motion vector overhead (even if it might be zero); hence, if the difference between MC and NO_MC error cannot justify the extra bits, there is no advantage in using motion compensation.

Inter intra decision

Sometimes it might be advantageous to intraframe code a macroblock, rather than interframe coding it. There are at least two reasons for intraframe coding:

  1. Scene cuts or, in the event of violent motion, interframe prediction error, may not be less than that of the intraframe. Hence intraframe pictures might be coded at lower bit rates.
  2. Intraframe coded pictures have a better error resilience to channel errors. Note that, in interframe coding, at the decoder the received data is added to the previous frame to reconstruct the coded picture. In the event of channel error, the error propagates into the subsequent frames. If that part of the picture is not updated, the error can persist for a long time.

Similar to the MC/NO_MC decision, one can make a similar decision for coding a macroblock in inter or intra mode. In this case the variance of intraframe MB is compared with the variance of inter (motion compensated or not). The smallest is chosen. Figure 6.5 shows the characteristics of the function for inter/intra decision. Here for large variances no preference between the two modes is given, but for smaller variances interframe is preferred. The reason is that, in intra mode, the DC coefficients of the blocks have to be quantised with a quantiser without a dead zone and with eight-bit resolutions. This increases the bit rate compared with that of the interframe mode, and hence interframe is preferred.

click to expand
Figure 6.5: Characteristics of inter/intra

Forced updating

As mentioned, intraframe coded MB increases the resilience of the H.261 codec to channel errors. In case in the inter/intra macroblock decision no intra mode is chosen, some of the macroblocks in a frame are forced to be intra coded. The specification recommends that a macroblock should be updated at least once every 132 frames. This means that for common intermediate format (CIF) pictures with 396 macroblocks per frame, on average three MBs of every frame are intraframe coded. This has an important impact on the quality of pictures due to errors. For example, in CIF pictures at 10 Hz, the effect of channel errors may corrupt up to 132 frames, and be visible for almost 13 s.

Other types of macroblock

In H.261 there are as many as eight different types of macroblock:

  1. Inter coded: interframe coded macroblocks with no motion vector or with a zero motion vector.
  2. MC coded: motion compensated MB, where the MC error is significant and needs to be DCT coded.
  3. MC not coded: these are motion compensated error MBs, where the motion compensated error is insignificant. Hence there is no need to be DCT coded.
  4. Intra: intraframe coded macroblocks.
  5. Skipped: if all the six blocks in a macroblock, without motion compensation, have an insignificant energy they are not coded. These MBs are sometimes called skipped, not coded or fixed MBs. These types of MB normally occur at the static parts of the image sequence. Fixed MBs are therefore not transmitted and at the decoder they are copied from the previous frame.

Since the quantiser step sizes are determined at the beginning of each GOB or row of GOBs, they have to be transmitted to the receiver. Hence the first MBs have to be identified with a new quantiser parameter. Therefore we can have some new macroblock types, which are:

  1. Inter coded + Q
  2. MC coded + Q
  3. Intra + Q

To summarise the type of macroblock selection, we can draw a flow chart indicating how each one of the 396 MBs in a picture is coded. Decisions on the types of coding follow Figure 6.6 from left to right.

click to expand
Figure 6.6: Decision tree for macroblock type

Addressing of macroblocks

If all the quantised components in one of the six blocks in an MB are zero, the block is declared as not coded. When all six blocks are not coded, the MB is declared not coded (fixed MB or skipped MB). In other cases the MBs are declared coded, and their type are variable length coded. The shortest code is assigned to inter code MB and the longest to intra + Q, as they are the most frequent and most rare MB types, respectively.

Once the type of a macroblock is identified and it is VLC coded, its position inside the GOB should also be determined. Considering that H.261 is a videoconferencing codec, normally used for coding head-and-shoulders pictures, it is more likely that coded macroblocks are in the foreground of the picture. Hence they are normally clustered in regions. Therefore the overhead information for addressing the positions of the coded MB is minimised if they are relatively addressed to each other. The relative addresses are represented by run lengths, which are the number of fixed MBs to the next coded MB. Figure 6.7 shows an example of addressing the coded MBs within a GOB. Numbers represent the relative addressing value of the number of fixed macroblocks preceding a nonfixed MB. The GOB start code indicates the beginning of the GOB. These relative addressing numbers are finally VLC coded.

click to expand
Figure 6.7: Relative addressing of coded MB

Addressing of blocks

Since an MB has six blocks, four luminance and two chrominance, there will be 26 = 64 different combinations of the coded/noncoded blocks. Except the one with all six blocks not coded (fixed MB), the remaining 63 are identified within 63 different patterns. The pattern information consists of a set of 63 coded block patterns (CBP) indicating coded/noncoded blocks within a macroblock. With a coding order of Y0, Y1, Y2, Y3, Cb, and Cr, the block pattern information or pattern number is defined as:

(6.1)  click to expand

where in the equation the coded and noncoded blocks are assigned 1 and 0, respectively. Each pattern number is then VLC coded. It should be noted that if a macroblock is intracoded (or intra+Q), its pattern information is not transmitted. This is because, in intraframe coded MB, all blocks have significant energy and will be definitely coded. In other words, there will not be any noncoded blocks in an intra coded macroblock. Figure 6.8 illustrates two examples of the coded block pattern, where some of the luminance or chrominance blocks are not coded.

click to expand
Figure 6.8: Examples of bit pattern for indicating the coded/not coded blocks in an MB (black coded, white not coded)

Addressing of motion vectors

The motion vectors of the motion compensated macroblocks are differentially coded with a prediction from their immediate preceding motion vector. The prediction vector is set to zero if either: the macroblock is the first macroblock of each row of GOB, the previous macroblock was not coded, coded with zero motion vector or it was intra coded.

The differential vector is then variable length coded (VLC) and is known as the motion vector data (MVD). The MVD consists of a pair of VLC, the first component for the differential horizontal value and the second component for the differential vertical displacement. Since most head-and-shoulders type scenes normally move in a rigid fashion, differential encoding of motion vectors can significantly reduce the motion vector overhead. However, this makes motion vectors very sensitive to channel errors, but the extent of the error propagation is limited within the GOB.

Quantisation and coding

Every one of the six blocks of a selected MB is transform coded with a two-dimensional DCT. The DCT coefficients of each block are then quantised and coded. In section 3.2 we described two types of quantiser: the one without a dead zone which is used for quantising the DC coefficient of intra MB, for the H.261 standard, this quantiser uses a fixed step size of eight; the second type is with a dead zone for coding AC coefficients and the DC coefficient of interframe coded MB (MC or NO_MC).

For the latter case, a threshold, th, may be added to the quantiser scale, such that the dead zone is increased, causing more zero coefficients for efficient compression. Figure 6.9 shows this quantiser, where a threshold, th, is added to every step size. The value of the threshold is sent to the receiver as side information (see Figure 6.3). Ratios of the quantised coefficients to the quantiser step size, called indices, are to be coded.

click to expand
Figure 6.9: A uniform quantiser with threshold

Two dimensional variable length coding

For transmission of the quantisation parameters, a special order is defined which increases the efficiency of capturing the nonzero components. Starting from the DC coefficient on the top left corner of an 8 × 8 coefficient matrix, the values are scanned in a zigzag sequence as shown in Figure 6.10.

click to expand
Figure 6.10: Zigzag scanning of 8 × 8 transform coefficients

The justification for this is that in natural images the main energy of the transform coefficients is concentrated in the lower frequencies (top left corner). Hence the coefficients which normally have the larger values are scanned first. Scanning of the indices terminates when the last nonzero coefficient has been reached.

To increase the coding efficiency a two-dimensional variable length code (2D-VLC) has been adopted. The 2D-VLC is performed in two stages. In the first stage, an event is produced for every nonzero index. The event is a combination of the index magnitude (index) and the number of zeros preceding that index (run).

To see how a two-dimensional index and run generation makes 2D-VLC coding very efficient, the following example is based on a coder having a quantiser step size of q = 16 with equal threshold levels th = q. Let us assume a pixel block is DCT coded with coefficient values as shown partly in Figure 6.11.

click to expand
Figure 6.11: Zigzag scanning and run-index generation

After zigzag scanning, coefficients are quantised. For a dead zone of th = 16, coefficient values less than this threshold are set to zero. Larger values are quantised according to the quantisation characteristics (see Figure 6.9). Here we see that rather than 1D-VLC coding of 17 individual coefficients we need to code only five two-dimensional events, which requires substantially fewer bits.

In this 2D-VLC, since the range of index (possible values of indices) can vary from -127 to +127, and the range of run (number of zeros preceding an index) may vary from 0 to 63, there will be 2 × 128 × 64 = 16 384 possible events. Design of a Huffman code for this large number of symbols is impractical. Some codewords might be as long as 200 bits! Here we use what might be called a modified Huffman code. In this code, all the symbols with small probabilities are grouped together and are identified with an ESCAPE symbol. The ESCAPE symbol has a probability equal to the sum of all it represents. Now the most commonly occurring events and the ESCAPE symbol are encoded with variable length codes (Huffman code) in the usual way. Events with low probabilities are identified with a fixed length run and index, appended to the ESCAPE code. The end of block code (EOB) is also one of the symbols to be variable length coded.

In H.261, ESCAPE is six bits long (i.e. 000001), thus rare events with six bits run (0–63) and eight bits index (-127 to +127) require 20 bits [1]. The EOB code is represented with a two-bit word. The DC/intra index is linearly quantised with a step size of eight and no dead zone. The resulting value is coded with an eight-bit resolution.

Figure 6.12 shows an example of a 2D-VLC table for positive values of indices, derived from statistics of coding the Claire test image sequence. As we see, most frequent events are registered at low index and low run values. The sum of the rare events, which represents the frequency of the ESCAPE, is even less than some frequent events. The corresponding 2D-VLC table is also shown next to the frequency table. Also in this example the sum has the same frequency as the event (run = 4, index = 1).

click to expand
Figure 6.12: An example of run and index frequency and the resulting 2D-VLC table

They are expected to have the same word length. Other events can be defined as ESCAPE + normal run + normal index, with:

  • ESCAPE code = 6 bits,
  • normal run = 6 bits (1 out of 64 possible values)
  • normal index = 8 bits (1 out of 128 values) plus the sign bit
  • total bits for the modified Huffman coded events = 6 + 6 + 8 = 20

Loop filter

At low bit rates the quantiser step size is normally large. Larger step sizes can force many DCT coefficients to zero. If only the DC and a few AC coefficients remain, then the reconstructed picture appears blocky. When the positions of blocky areas vary from one frame to another, it appears as a high frequency noise, commonly referred to as mosquito noise. The blockiness degradations at the slant edges of the image appear as staircase noise. Figure 6.13 illustrates single shots of a CIF size Claire test image sequence and its coded version at 256 kbit/s. The sequence is in colour, with 352 pixels by 288 lines at 30 Hz, but only the luminance is shown. The colour components have a quarter resolution of luminance (176 pixels by 144 lines). As can be seen at this bit rate the coded image quality is very good with no visible distortions.

click to expand
Figure 6.13: Picture of Claire (a original) (b H.261 coded at 256 kbit/s)

At lower bit rates, artefacts begin to appear. This is shown in Figure 6.14, where there are more severe distortions at 64 kbit/s than at 128 kbit/s. When the sequence is displayed at its normal rate (30 Hz), the positions of the distortions move in different directions over the picture, and the appearance of mosquito noise is quite visible.

click to expand
Figure 6.14: H.261 coded at (a 128 kbit/s) (b 64 kbit/s)

Coarse quantisation of the coefficients which results in the loss of high frequency components implies that compression can be modelled as a lowpass filtering process [3,4]. These artefacts are to some extent reduced by using the loop filter (see position of the loop filter in Figure 6.3). The lowpass filter removes the high frequency and block boundary distortions. The same pictures with the use of a loop filter are shown in Figure 6.15.

click to expand
Figure 6.15: Coded pictures with loop filter (a 128 kbit/s) (b 64 kbit/s)

Loop filtering is introduced after the motion compensator to improve the prediction. It should be noted that the loop filter has a picture blurring effect. It should be activated only for blocks with motion, otherwise nonmoving parts of the pictures are repeatedly filtered in the following frames, blurring the picture. Since it is motion based, loop filtering is thus carried out on a macroblock basis and it has an impulse response given by:

(6.2) 

for pixels well inside the picture. For pixels at the image border, or corners, another function may be used. Figure 6.16 shows an example of the filter response in these areas.


Figure 6.16: Loop filter impulse response in various parts of the image

The loop filter is only defined for H.261 (no other video codecs use it) and is activated for all six DCT blocks of a macroblock. The filtering should be applied for coding rates of less than 6 × 64 kbit/s = 386 kbit/s and switched off otherwise. At higher bit rates the filter does not improve the subjective quality of the picture [3]. MPEG-1 does not specify the requirement of a loop filter, because pictures coded with MPEG-1 are at much higher bit rates than 386 kbit/s.

Rate control

The bit rate resulting from the DCT-based coding algorithm fluctuates according to the nature of the video sequence. Variations in the speed of moving objects, their size and texture are the main cause for bit rate variation. The objective of a rate controller is to achieve a constant bit rate for transmission over a circuit switched network. A transmission buffer is usually needed to smooth out the bit rate fluctuations, which are inherent in the interframe coding scheme.

The usual method for bit rate control is to monitor the buffer occupancy and vary the quantiser step size according to the buffer fullness [3,5]. In reference model 8 (RM8) the quantiser step size is calculated as a linear function of the buffer content and expressed by:

(6.3) 

where p is the multiplier used in specifying the bit rates as in p × 64 kbit/s, and ⌊.⌋ stands for integer division with truncation towards zero.

The buffer control system usually has two additional operating states to prevent buffer underflow or buffer overflow from occurring. If the buffer content reaches the trigger point for the overflow state, current and subsequent coded data are not sent to allow the buffer to be emptied. Only trivial side information pertaining to the coded GOB or frame is transmitted.

On the other extreme, bit stuffing is invoked when buffer underflow is threatened. It is essential that buffer underflow is avoided so that the decoder can maintain synchronisation.

In practice, to allow maximum freedom of the H.261 standard codec structure, a hypothetical reference decoder (HRD) buffer is defined. All encoders are required to be compliant with this buffer. The hypothetical reference decoder is best explained with reference to Figure 6.17.

click to expand
Figure 6.17: Hypothetical reference buffer occupancy

The hypothetical buffer is initially empty. It is examined at CIF intervals (1/29.97 ≅ 33 ms), and if at least one complete coded picture is in the buffer, then all the data from the earliest picture is instantly removed (e.g. at tN in Figure 6.17) [6]. Immediately after removing the above data, the buffer occupancy should be less than B, with B = 4Rmax/29.97 and Rmax being the maximum video bit rate to be used in the connection. To meet this requirement, the number of bits for (N + 1)th coded picture, dN+1 must satisfy

(6.4) 

where bN is the buffer occupancy just after time tN, tN is the time at which the Nth coded picture is removed from the hypothetical reference decoder buffer and R(t) is the video bit rate at time t. Note that the time interval (tN+1 - tN) is an integer number of CIF picture periods (1/29.97, 2/29.97, 3/29.97,...).

This specification constrains all encoders to restrict the picture start lead jitters to four CIF picture period's worth of channel bits. This prevents decoder buffer overflow at the decoder in a correctly designed H.261 codec. Jitters in the opposite direction (phase lag) are not constrained by the H.261 recommendation. Phase lag corresponds to buffer underflow at the decoder, which is simply dealt with by making the decoder wait for sufficient bits to have arrived to continue decoding.

A major deficiency with the RM8/H.261 model rate controls is that bits might be unfairly distributed across the image. For example, in the active parts of the picture sequences, such as in the middle of the head-and-shoulders pictures, the buffer tends to fill up very quickly, and hence the quantiser step size rises rapidly. This causes the rest of the picture to be coded coarsely. One of the key issues in H.261, as well as in any video codec, is the way in which the quantiser step size or the rate control is managed. In the past decade numerous manufacturers have produced H.261 codecs, but they may not perform equally. Because of the need for interoperability, the general structure of H.261 must be based on coding elements as shown in Figure 6.3. Therefore the only part which makes one codec better than the others is the rate control mechanism. This part is kept secret by the manufacturers and is subject to further research.

Problems

1. 

In a CIF picture, find the number of macroblocks and blocks per

  1. GOB
  2. picture

 a. 33, 198 b. 396, 2376

2. 

Calculate the macroblock interval in CIF pictures. How large is this value for a QCIF video at 10 Hz?

 ; qcif:

3. 

The absolute value of the motion compensated frame difference per macroblock, |mfd|, is normally smaller than that without motion compensation, |fd|. In a search for motion compensation, the following values for |mfd| and |fd| have been calculated. Using Figure 6.4, determine in which of the following cases motion compensation should be used:

  1. |fd| = 1200 and |mfd| = 1000
  2. |fd| = 600 and |mfd| = 500
  3. |fd| = 200 and |mfd| = 50

 a. mc b. nomc c. nomc

4. 

Why is nonmotion compensation preferred to motion compensation for very small frame difference images?

due to motion vector overhead

5. 

To decide whether a macroblock should be interframe or intraframe coded, the variances of intra and motion compensated interframe macroblocks are compared, according to Figure 6.5. Find in each of the following whether a macroblock should be intra or interframe coded:

 a. inter b. intra c. inter

6. 

In macroblocks with small energy (inter or intra), inter macroblock is preferred to intra, why?

for small values in intra mode dc still needs eight bits, while in inter mode it is less.

7. 

Calculate the coded block pattern (CBP) indices of the following macroblocks in a H.261 codec if:

  1. all the blocks in the macroblock are coded
  2. only the luminance blocks are coded
  3. only the chrominance blocks are coded

 a. 63 b. 60 c. 3

8. 

Assume the transform coefficients of the block given in problem 3 of Chapter 5 belong to an H.261 codec. These coefficients are linearly quantised with the quantiser of Figure 6.9, with th = 16 and q = 12. Using Figure 6.12, calculate the number of bits required to code this block.

 83 0 2 1 0 0 4 0 0 0 -1 0 3 0 0 0 0 0 0 0 3 -1 0 0 -1 1 0 0 0 0 0 0 0 0 3 0 2 0 0 0 0 0 0 0 0 0 0 1 -1 4 0 0 0 0 0 0 2 0 0 0 0 0 0 31 events: (0, 83)(4, 2)(0,1)(0, -1)(1, -1)(1, 1)(4, 3)(4, -1)(1,3)(1,3)(1,4)(2, -1) (3, 4)(0, 2) (3, 2)(20,1)(2, 31) number of bits (including the sign bit): 20 + 9 + 5 + 5 + 6 + 6 + 11 + 8 + 8 + 8 + 9 + 7 + 11 + 5 + 8 + 20 + 20 = 166 no eob is used, as the last coefficient is coded

9. 

Pixels on the top left corner of a picture have values of:

200

135

180

210

75

110

134

230

62

89

52

14

and are filtered with the loop filter of Figure 6.16. Find the filtered values of these pixels.

 159 149 170 105 113 133

10. 

The maximum quantiser step size in H.261 is 62 (quantiser parameter is 31, defined with five bits). A 384 kbit/s H.261 encoder with an RM8 type rate control has a smoothing buffer of 5 kbytes. Find the spare capacity of the buffer, when the quantiser step size is at its maximum value.

@384 kbit/s p = 6 and with q = 62 and p = 6, the buffer content is 36 kbits, left over capacity = 5000 x 8 - 36000 = 4000 bits

Answers

1. 

  1. 33, 198
  2. 396, 2376

2. 

; QCIF:

3. 

  1. MC
  2. NOMC
  3. NOMC

4. 

due to motion vector overhead

5. 

  1. inter
  2. intra
  3. inter

6. 

For small values in intra mode DC still needs eight bits, while in inter mode it is less.

7. 

  1. 63
  2. 60
  3. 3

8. 

83

0

2

1

0

0

4

0

0

0

-1

0

3

0

0

0

0

0

0

0

3

-1

0

0

-1

1

0

0

0

0

0

0

0

0

3

0

2

0

0

0

0

0

0

0

0

0

0

1

-1

4

0

0

0

0

0

0

2

0

0

0

0

0

0

31

events: (0, 83)(4, 2)(0,1)(0, -1)(1, -1)(1, 1)(4, 3)(4, -1)(1,3)(1,3)(1,4)(2, -1) (3, 4)(0, 2) (3, 2)(20,1)(2, 31)

number of bits (including the sign bit): 20 + 9 + 5 + 5 + 6 + 6 + 11 + 8 + 8 + 8 + 9 + 7 + 11 + 5 + 8 + 20 + 20 = 166

no EOB is used, as the last coefficient is coded

9. 

159

149

170

105

113

133

10. 

@384 kbit/s P = 6 and with q = 62 and P = 6, the buffer content is 36 kbits, left over capacity = 5000 x 8 - 36000 = 4000 bits

References

1 H.261: 'Recommendation H.261, video codec for audiovisual services at p × 64 kbit/s'. Geneva, 1990

2 CCITT SG XV WP/1/Q4: 'Specialist group on coding for visual telephony'. Description of reference model 8 (RM8), 1989

3 PLOMPEN, R.H.J.M.: 'Motion video coding for visual telephony' (Proefschrift, 1989)

4 NGAN, K.N.: 'Two-dimensional transform domain decimation technique', IEEE international conference on Acoust. speech and signal processing, ICASP '86, 1986, pp.1001–1004

5 CHEN, C.T., and WONG, A.: 'A self-governing rate buffer control strategy for pseudoconsant bit rate video coding', IEEE Trans. Image processing, 1993, 2:1, pp.50–59.

6 CARR, M.D.: 'Video codec hardware to realise a new world standard', Br. Telecom. J., 1990, 8:3, pp.28–35

Page not found. Sorry. :(



Standard Codecs(c) Image Compression to Advanced Video Coding
Standard Codecs: Image Compression to Advanced Video Coding (IET Telecommunications Series)
ISBN: 0852967101
EAN: 2147483647
Year: 2005
Pages: 148
Authors: M. Ghanbari

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net