QccVIDMotionVectorsReadFile.3

NAME

QccVIDMotionVectorsEncode, QccVIDMotionVectorsDecode - encode/decode motion vectors using the variable-length code specified in the H.261 standard

int QccVIDMotionVectorsEncode(const QccIMGImageComponent *motion_vector_horizontal, const QccIMGImageComponent *motion_vector_vertical, const QccVIDMotionVectorsTable *mvd_table, int subpixel_accuracy, QccBitBuffer *output_buffer);

int QccVIDMotionVectorsDecode(QccIMGImageComponent *motion_vector_horizontal, QccIMGImageComponent *motion_vector_vertical, const QccVIDMotionVectorsTable *table, int subpixel_accuracy, QccBitBuffer *input_buffer);

int QccVIDMotionVectorsReadFile(QccIMGImageComponent *motion_vectors_horizontal, QccIMGImageComponent *motion_vectors_vertical, const QccString filename, int frame_num);

int QccVIDMotionVectorsWriteFile(const QccIMGImageComponent *motion_vectors_horizontal, const QccIMGImageComponent *motion_vectors_vertical, const QccString filename, int frame_num);

DESCRIPTION

QccVIDMotionVectorsEncode() encodes the motion-vector field represented by motion_vector_horizontal (the horizontal vector components) and motion_vector_vertical (the vertical vector components), outputing the resulting bitstream to output_buffer.

QccVIDMotionVectorsDecode() carries out the inverse process. Namely, the bitstream is read from input_buffer and the motion vectors are decoding and stored in motion_vector_horizontal and motion_vector_vertical.

QccVIDMotionVectorsEncode() and QccVIDMotionVectorsDecode() support two methods of motion-vector coding: exponential-Golomb coding as in H.264, and Huffman coding as in H.261. See "EXPONENTIAL-GOLOMB CODING" and "HUFFMAN CODING" below for details on these coding procedures. If mvd_table is NULL, then exponential-Golomb coding is used. Otherwise, mvd_table is assumed to point to a valid QccVIDMotionVectorsTable(3) created via QccVIDMotionVectorsTableCreate(3) which is then used for Huffman coding.

QccVIDMotionVectorsReadFile() and QccVIDMotionVectorsWriteFile() read and write, respectively, a motion vector field to/from a file. The motion vectors are stored in ASCII floating-point values, one vector per line. filename gives the filename of the file to read or write. frame_num is the frame number of the frame corresponding to the motion field to be read or written. filename should have a printf(3) -style numerical descriptor which will then be filled in with frame_num (e.g., football.%03d.pgm will become football.032.pgm if frame_num is 32; see QccPackIMG(3) ).

HUFFMAN CODING

Essentially, the H.261 standard specifies that motion vectors are coded by doing a row-wise raster scan through the motion-vector field, starting at the upper-left and proceeding to the lower-right. To code the current motion vector, a difference vector is created by subtracting the previously encountered motion vector from the current motion vector. This difference vector is then coded using the variable-length Huffman coding table specified in Table 3/H.261 of the H.261 standard. The previous motion vector is considered to be the zero vector for the first vector of each row. Use QccVIDMotionVectorsTableCreate(3) to generate mvd_table.

Note that the range of the motion vectors supported by the H.261 table is restricted. Specifically, each vector component can lie in the range -15 to +15 inclusive, thereby yielding difference values in the range -30 to +30.

Strictly speaking, the H.261 standard does not support subpixel-accurate motion vectors. However, the H.261 motion-vector coding strategy has been extended for QccVIDMotionVectorsEncode() and QccVIDMotionVectorsDecode() to support the situtation when subpixel_accuracy is not full-pixel accuracy. Essentially, for subpixel accuracy, encoding is carried out as described above for the motion vector cast to integer-valued components. Then, the fractional part of each motion-vector component is scaled up to be an integer which is then coding using the same mvd_table. That is, if a motion vector is (u, v), then the coding is mvd_table(integer_u - previous_integer_u), mvd_table(integer_v - previous_integer_v), mvd_table((u - integer_u) * S), and mvd_table((v - integer_v) * S), where integer_u and integer_v denote the integer part of u and v, respectively; previous_integer_u and previous_integer_v denote the integer part of the previous motion-vector components; S is a scaling constant suitably chosen so that all the fractional parts of the motion-vectors components are scaled to integer values (for example, S = 4 for quarter-pixel accuracy); and mvd_table() denotes table lookup into mvd_table.

EXPONENTIAL-GOLOMB CODING

In H.264, motion vectors are coded in the raster-scan differencing procedure as described above for H.261, except that an exponential-Golomb code, rather than Huffman coding is used to code the difference values.

In the implementation here, the difference values are created and, if subpixel_accuracy does not indicate full-pixel accuracy, the differences are scaled by an appropriate constant so that fractional values become integer values. QccENTExponentialGolombEncode(3) is then used to code each difference value with an exponential-Golomb code. The procedure is essentially the same as described in Sec. 9.1 of the H.264 standard, except the codewords may differ slightly (although the code lengths are the same).

Exponential-Golomb coding is advantageous for the coding of motion-vector differences since the range of values is not limited as is the case for the Huffman-based H.261 coding described above.

RETURN VALUE

These routines return 0 on success, and 1 on failure.

AUTHOR

Table of Contents

NAME
SYNOPSIS
DESCRIPTION
HUFFMAN CODING
EXPONENTIAL-GOLOMB CODING
RETURN VALUE
SEE ALSO
AUTHOR