Previous: What the codec controller actually does
Up: What the codec controller actually does
Next: Packetisation
Previous Page: What the codec controller actually does
Next Page: Packetisation

Background

H.261 video data coming from the codec is wrapped up inside CRC frames of 64 bytes. The frames are identifiable by a single bit in each 64 byte frame that cycles through a fixed pattern. This pattern has to be seen in same position in a frame three times in a row before a receiving codec can be sure it has achieved H.261 synchronisation. The actual 18 bit cyclic redundancy check is calculated over 492 bit segments of video data, and it is this CRC insertion before feed received data to the receiving codec that constitutes the large proportion of the processing power that the codec controller requires.

The H.261 CRC frames are themselves wrapped up inside the 80 byte frames of the H.221 protocol. These frames are identifiable by a pattern, the Frame Alignment Signal (FAS), occurring across bit 8 of the first 8 bytes of alternate frames. Bit 8 in bytes 9-16 is used to declare what the H.221 frames contain, and is called the Bit-rate Allocation Signal (BAS).

H.261 data itself is coded using variable length Huffman codes. Images are divided into Groups Of Blocks (GOBs), of which three comprise a QCIF image and 12 comprise a CIF image. GOBs are recognisable in the bit stream, by their Group of Block Start Codes (GBSC), which consists of 15 zero bits followed by a 1 bit followed by four bits giving the GOB number. GOBs can vary from less than 10 bytes to several kilobytes, and are typically not even an integer number of bytes in length. GOBs are the smallest synchronisation unit in H261 - the start of a GOB can be seen by scanning the H.261 bit-stream, but inside a GOB, meaning is purely determined by the entire bit-stream from the GBSC.