Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT T.Turletti, C. Huitema INRIA March 1995 Expires: September 95 RTP Packetization of H.261 Video Streams March 8, 1995 Thierry Turletti, Christian Huitema INRIA Christian.Huitema@sophia.inria.fr Thierry.Turletti@sophia.inria.fr 1. Status of this Memo This document is an Internet draft. Internet drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this document is unlimited. INTERNET-DRAFT Packetization of H.261 2. Abstract This draft describes a packetization scheme of H.261 video stream. The scheme proposed can be used to transport such a video flow over the protocols used by RTP. This specification is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. 3. Purpose of this document The ITU-T recommendation H.261 [7] specifies the encodings used by ITU-T compliant video-conference codecs. Although these encodings were originally specified for fixed data rate ISDN circuits, experimentations [4] have shown that they can also be used over the internet. The purpose of this memo is to specify how H.261 video streams can be carried over the protocols used by RTP [1], such as UDP, ST-II, etc. 4. Structure of the packet stream H.261 codecs produce a bit stream. In fact, H.261 and companion recommendations specify several levels of encoding: (1) Images are first separated in blocks of 8x8 pixels. Blocks which have moved are encoded by computing the discrete cosine transform (DCT) of their coefficients, which are then quantized and Huffman encoded. (2) The bits resulting of the Huffman (or Variable Length Codes VLC) encoding are then arranged in 512 bits frames, containing 2 bits of synchronization, 492 bits of data and 18 bits of error correcting code. (3) The 512 bits frames are then interlaced with an audio stream and transmitted over px64 kbps circuits according to specification H.221 [6]. Turletti, Huitema [Page 2] INTERNET-DRAFT Packetization of H.261 When transmitting over the Internet, we will directly consider the output of the Huffman encoding. We will not carry the 512 bits frames, as protection against errors can be obtained by other means. Similarly, we will not attempt to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing. Directly transmitting the result of the Huffman encoding over an unreliable stream of UDP datagrams would however have very poor error resistance characteristics. The H.261 coding is in fact organized as a sequence of images, or frames, which are themselves organized as a set of Groups of Blocks (GOB). Each GOB holds a set of 3 lines of 11 macro blocks (MB). Each MB carries information on a group of 16x16 pixels: luminance information is specified for 4 blocks of 8x8 pixels, while chrominance information is only given by two color difference components 8x8 "red" and "blue" blocks. These components and the codes representing their sampled values are as defined in the ITU-R Recommendation 601 [8]. This grouping is used to specify information at each level of the hierarchy: - At the frame level, one specifies information such as the delay from the previous frame, the image format, and various indicators. - At the GOB level, one specifies the GOB number and the default quantifier that will be used for the MBs. - At the MB level, one specifies which blocks are present and which did not change, and optionally a quantifier, as well as precisions on the codings such as distance vectors. The result of this structure is that one needs to receive the information present in the frame header to decode the GOBs, as well as the information present in the GOB header to decode the MBs. Without precautions, this would mean that one has to receive all the packets that carry an image in order to properly decode its components. In fact, the experience has shown that: (1) It would be unrealistic to carry an image in a single packet: video images can sometimes be very large. Turletti, Huitema [Page 3] INTERNET-DRAFT Packetization of H.261 (2) GOB information typically fits in a packet. In fact, several GOBs can often be grouped in a packet. Once we have take the decision to correlate GOB synchronization and packetization, a number of decisions remain to be taken, due to the following conditions: (1) The algorithm should be easy to implement when packetizing the output stream of a hardware codec. (2) The algorithm should not induce rendition delays -- we should not have to wait for a following packet to display an image. (3) The algorithm should allow for efficient resynchronization in case of packet losses. (4) It should be easy to depacketize the data stream and direct it to an hardware codec's input. (5) When the hardware decoder operates at a fixed bit rate, one should be able to maintain synchronization, e.g. by adding padding bits when the packet arrival rate is slower than the bit rate. (6) The fragmentation process should break the frame up so that packets start on GOB boundaries when possible. The H.261 Huffman encoding includes a special "GOB start" pattern, composed of 15 zeroes followed by a single 1, that cannot be imitated by any other code words. That pattern marks the separation between two GOBs, and is in fact used as an indicator that the current GOB is terminated. The encoding also includes a stuffing pattern, composed of seven zeroes followed by four ones; that stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator. The first conclusion of the analysis is that the packets should contain all the GOB data, including the "GOB start" pattern that separate the current block from its follower. Actually, as this pattern is well known, we could as well use a single bit in the data header to indicate that a GOB-start pattern must be added at the decoder side. Turletti, Huitema [Page 4] INTERNET-DRAFT Packetization of H.261 Not encoding the GOB-start pattern has two advantages: (1) It reduces the number of bits in the packets, and avoids the possibility of splitting packets in the middle of a GOB separator. (2) It authorizes gateways to hardware decoders to insert the stuffing pattern in front of the GOB, in order to meet the fixed bit rate requirement. Another problem posed by the specificities of the H.261 compression is that the GOB data have no particular reason to fit in an integer number of octets. 5. Specification of the packetization scheme The data header will thus contain two three-bit integers, EBIT and SBIT: SBIT indicates the number of bits that should be ignored in the first (start) data octet. EBIT indicates the number of bits that should be ignored in the last (end) data octet. Although only the EBIT counter would really be needed for software coders, the SBIT counter was inserted to ease the packetization of hardware coders output. A sample packetization procedure is found in annex A. At the receiving sites, the GOB synchronization can be used in conjunction with the synchronization service of the RTP protocol. In case of losses, the decoders could become desynchronized. The "S" bit of the H.261 option field will be set to indicate that the packet includes the beginning of the encoding of a GOB. A GOB start code must be prepended to that packet before decoding. If several GOBs are encoded inside a same packet, all the GOBs except the first one contain the GOB start code. The receiver will detect losses by looking at the RTP sequence numbers. The receiver is recommended to resequence out of order packets in order to limit the packet loss effect. Some misordering of packets in the network seems likely, even when there is no loss, and one would not want to drop a frame because of that. In case of losses, it will ignore all packets whose "S" bit is null. Once an S bit packet Turletti, Huitema [Page 5] INTERNET-DRAFT Packetization of H.261 has been received, it will prepend the GOB start code to that packet, and resume decoding. The "E" bit of the H.261 header will be set to indicate that the packet contains the end of a GOB, so after resequencing, it can safely be decoded without having decoder state hanging between packets. In a previous version of the draft, we specified a "fragment offset" field set to the byte offset of the current packet into the frame. This field was used to estimate how much memory should be left for the late packets. After attempting implementation, it appeared that this offset did not serve its intended purpose (which was a single copy reassembler). So, in this new draft, we replaced it by a 2 byte-field used to encode some MB state information. This new field allows to process each packet independently and hence to reduce the effect of packet loss. To decode all segments of a huge GOB, even if the first segment of the GOB is lost, the following is requested: (1) Each packet sent must end with an end of MB, i.e. MB cannot be sent in several packets. (2) MB state information must be added in the H.261 header of each packet sent. This MB state information contains the current GOB number, the last MB number encoded and the last quantizer used in the current GOB (GQUANT or MQUANT). (3) SBIT and EBIT three-bit integers must be used to state the beginning and the end of MB data inside the packet. However, the MB state information is easier to obtain with a software coder than a hardware coder. So, a flag "F" is added to indicate if the 2 byte-field is valid or not. In case it is not valid and to allow fast implementation of decoders, all packets sent must have the same size so that, for example, incoming packets could simply be placed at the right point in a circular buffer. For example, if the maximal size is 1000 bytes and the huge GOB length is 2600 bytes, the first two segments will have 1000 bytes and the third 600 bytes. Note that maximal size must be the same for all the life of the session. Note that Picture headers are handled in the same way that GOB headers. Turletti, Huitema [Page 6] INTERNET-DRAFT Packetization of H.261 5.1. Usage of RTP The H.261 information are carried as data within the RTP protocol. The payload type should specify the corresponding H.261 type (see companion profile document RFC TBD). The RTP timestamp encodes the date at which the image was grabbed. The timestamp consists of the middle 32 bits of a 64-bit NTP timestamp, as defined in RFC 1305 [2]. That is, it counts time since 0 hours UTC, January 1, 1900, with a resolution of 65536 ticks per second. (UTC is Coordinated Universal Time, approximately equal to the historical Greenwich Mean Time.) The very definition of this settings implies that the beginning of an image shall always be synchronized with a packet. The RTP sequence number can be used to detect missing packets. In this case, one shall ignore all incoming packets until the next synchronization mark is received ("S" bit set in the H.261 header). The marker "M" bit of the RTP header can be used as a flag to trigger display the new image on the screen. This marker has a value of one in the last packet of a video frame. The H.261 data will follow the RTP header, as in: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . RTP header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.261 header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.261 stream ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The H.261 options field is defined as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|SBIT |E|EBIT |I|V| MBZ |SIZE |F|X| MB | GOB | QUANT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Turletti, Huitema [Page 7] INTERNET-DRAFT Packetization of H.261 ________________________________________________________________ |S (1 bit) | Start of GOB. Set if the packet is a | | | start of GOB. | |_______________|______________________________________________| |SBIT (3 bits) | Start bit position number of bits | | | that should be ignored in the first data | | | octet. SBIT must be null if S is unset. | |_______________|______________________________________________| |E (1 bit) | End of GOB. Set if the packet is an | | | end of GOB. | |_______________|______________________________________________| |EBIT (3 bits) | End bit position number of bits | | | that should be ignored in the last data | | | octet. EBIT must be null if E is unset. | |_______________|______________________________________________| |I (1 bit) | Full Intra Image flag. Set if it is the | | | first packet of a full intra image. | |_______________|______________________________________________| |V (1 bit) | Movement Vector flag. Set if movement | | | vectors are encoded. All V | | | bits of the same frame must be identical. | |_______________|______________________________________________| |MBZ (3 bits) | Must Be Zero. | |_______________|______________________________________________| |SIZE (3 bits) | Image format: | | | QCIF, CIF or number of CIF in SCIF. | |_______________|______________________________________________| |F (1 bit) | Flag set if the following fields are valid.| |_______________|______________________________________________| |X (1 bit) | Must Be Zero. | |_______________|______________________________________________| |MB (5 bits) | Last MB encoded in the current GOB. | |_______________|______________________________________________| |GOB (4 bits) | Current GOB number. | |_______________|______________________________________________| |QUANT (5 bits) | Last quantizer used (MQUANT or GQUANT). | |_______________|______________________________________________| The image format (3 bits) is defined as following: Turletti, Huitema [Page 8] INTERNET-DRAFT Packetization of H.261 _____________________________ | QCIF | 000| |____________________|______| | CIF | 001| |____________________|______| | POTS | 010| |____________________|______| | SCIF 0 | | | upper left corner | 100| | CIF in SCIF image | | |____________________|______| | SCIF 1 | | | upper right corner | 101| | CIF in SCIF image | | |____________________|______| | SCIF 2 | | | lower left corner | 110| | CIF in SCIF image | | |____________________|______| | SCIF 3 | | | lower right corner | 111| | CIF in SCIF image | | |____________________|______| With: - CIF: Common interchange format for video images with 352 x 288 pixels. - QCIF: Quarter CIF with 176 x 144 pixels. - POTS: standardised in ITU-T SG15 with 128 x 96 pixels. - SCIF: Super CIF with 704 x 576 pixels. 5.2. Usage of RTCP control packets When sending or receiving H.261 streams through the RTP protocol, the stations should be ready to: (1) process or ignore all generic RTCP control packets. (2) send or receive H.261 specific RTCP control packets, to request a video refreshment. Turletti, Huitema [Page 9] INTERNET-DRAFT Packetization of H.261 This memo describes two H.261 specific RTCP control packets, "Full Intra Request" and "Negative Acknowledgement". 5.2.1. Controlling the reverse flow Support of the reverse RTCP control packets by the H.261 sender is optional; in particular, early experiments have shown that the usage of this feature could have very negative effects when the number of sites is very large. Thus, reverse RTCP control packets should be used with caution. The aim of these packets is to speed the refreshment of the video when it is possible. Videoconferencing applications do not require reliable multicast packet delivery such as whiteboard applications. Reliable multicast protocols can use similar NACK RTCP control packets but in this case, the main purpose is to provide reliable data transfer to the receivers packets with minimal throughput. A few reliable multicast protocols use random delays to prevent NACK implosion problem [3]. On the other hand, it is more efficient in videoconferencing applications to send NACK control packets as soon as possible, i.e. as soon as a loss is detected, without adding any random delays. In this case, multicasting NACKs control packets generates useless traffic between receivers since only the coder will use them. But this method is only efficient when the number of receivers is small. e.g. in IVS [5] reverse RTCP control packets are used only if there are less than 10 participants in the conference. A site may distinguish reverse RTCP packets from forward RTCP packets by their arrival port. Reverse RTCP packets arrive on the same port that the site uses as a source port for forward (data) RTP packets. 5.2.2. Full Intra Request (FIR) RTCP control packet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T=2|P| MBZ | PT=RTCP_FIR | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This packet indicates that a receiver requires a full encoded image in order to either start decoding with an entire image Turletti, Huitema [Page 10] INTERNET-DRAFT Packetization of H.261 or to refresh its image and speed the recovery after a burst of lost packets. The receiver requests the source to force the next image in full "Intra" coding mode, i.e. without using differential coding. The various fields are defined in the RTP specification [1]. SSRC is the synchronization source identifier for the sender of this packet. The value of the packet type (PT) identifier is the constant RTCP_FIR (192). 5.2.3. Negative ACKnowledgements (NACK) RTCP packet Packets lost are detected using the RTP sequence number. After a packet loss, the receiver will resynchronize on the next GOB. However, as H.261 uses differential encoding, parts of the images may remain blurred as long as all corresponding MBs are not encoded in INTRA mode; i.e. absolute encoding without relation to previous frame. There are several ways to put it right. The fastest way is to request a refreshment. As all GOB belonging to a given video image carry the same time stamp, the receiver can determine a list of GOBs which were really received for that time stamp, and thus identify the "missing blocks". Requesting a specific reinitialization of these missing blocks is more efficient than requesting a complete reinitialization of the image through the "Full Intra Request" item. When it is impossible to use NACK, e.g. if the number of receivers is large or if the coder does not handle NACK, another method consists to periodically force INTRA encoding each MB. The H.261 recommendation specifies that a MB is INTRA encoded at least every 132 times it is transmitted. However, the INTRA refreshment rate can be raised in order to speed the recovering when the loss rate measured is important. Turletti, Huitema [Page 11] INTERNET-DRAFT Packetization of H.261 The format of the NACK RTCP control packet is as follow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T=2|P| MBZ | PT=RTCP_NACK | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGOBL | LGOBL | MBZ |SIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp (seconds) | timestamp (fraction) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The various fields T, P, PT, length and SSRC are defined in the RTP specification [1]. The value of the packet type (PT) identifier is the constant RTCP_NACK (193). SSRC is the synchronization source identifier for the sender of this packet. The remaining fields have the following values: _____________________________________________________ | FGOBL | First GOB Lost: | | | Identifies the first GOB lost number.| |___________|________________________________________| | LGOBL | Last GOB Lost: | | | Identifies the last GOB lost number. | |___________|________________________________________| | MBZ | Must Be Zero. | |___________|________________________________________| | SIZE | Repeat the format indicator of the | | | received image, including the number | | | of the SCIF subimage if present. | |___________|________________________________________| | Timestamp | The RTP timestamp of the | | | original image | |___________|________________________________________| Turletti, Huitema [Page 12] INTERNET-DRAFT Packetization of H.261 Acknowledgements This draft is based on discussion within the AVT working group chaired by Stephen Casner. Steve McCanne, Stephen Casner, Ronan Flood, Mark Handley, Van Jacobson and Henning G.Schulzrinne provided valuable comments. References [1] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van Jacobson, RTP: A Transport Protocol for Real-Time Applications, INTERNET-DRAFT, July 18, 1994. [2] D.L. Mills, ``Network time protocol (version 3) -- specification, implementation and analysis,'' Network Working Group Request for Comments RFC 1305, University of Delaware, Mar. 1992. [3] Sridhar Pingali, Don Towsley and James F. Kurose, A comparison of sender-initiated and receiver-initiated reliable multicast protocols, IEEE GLOBECOM '94. [4] Thierry Turletti, H.261 software codec for videoconferencing over the Internet INRIA Research Report no 1834, January 1993. [5] Thierry Turletti, INRIA Videoconferencing tool (IVS), available by anonymous ftp from zenon.inria.fr in rodeo/ivs/last_version. See also URL . [6] Frame structure for Audiovisual Services for a 64 to 1920 kbps Channel in Audiovisual Services ITU-T (International Telecommunication Union - Telecommunication Standardisation Sector) Recommendation H.221, 1990. [7] Video codec for audiovisual services at p x 64 kbit/s ITU-T (International Telecommunication Union - Telecommunication Standardisation Sector) Recommendation H.261, 1993. [8] Digital Methods of Transmitting Television Information ITU-R (International Telecommunication Union - Radiocommunication Standardisation Sector) Recommendation 601, 1986. Turletti, Huitema [Page 13] INTERNET-DRAFT Packetization of H.261 Appendix A The following code can be used to packetize the output of an H.261 codec: #include #define BUFFER_MAX 512 int right[] = { /* Number of successives zeroes starting at the MSB for each octet */ 8,7,6,6,5,5,5,5,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3, 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; int left[] = { /* Number of successives zeroes starting at the LSB for each octet */ 8,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 6,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 7,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 6,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0, 5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0}; h261_sync(F) FILE *F; { int i, ebit, sbit, start_of_group, end_of_group, c, nz; unsigned char buf[BUFFER_MAX]; i = 0; ebit = 0; sbit = 0; start_of_group = 1; nz = 0; while ((c = getc(F)) != EOF) { Turletti, Huitema [Page 15] INTERNET-DRAFT Packetization of H.261 buf[i++] = c; if (c == 0) { nz += 8; } else { nz += right[c]; if (nz >= 15) { end_of_group = 1; if (right[c] == 7) { ebit = 0; send_message(buf, i - 2, sbit, ebit, end_of_group, start_of_group); sbit = 0; i = 0; } else { ebit = 7 - right[c]; send_message(buf, i - 2, sbit, ebit, end_of_group, start_of_group); i = 0; buf[i++] = c; sbit = right[c] + 1; } start_of_group = 1; } else { nz = left[c]; if (i >= BUFFER_MAX) { ebit = 0; end_of_group = 0; send_message(buf, i - 2, sbit, ebit, end_of_group, start_of_group); buf[0] = buf[i - 2]; buf[1] = buf[i - 1]; i = 2; sbit = 0; start_of_group = 0; } } } } } Turletti, Huitema [Page 16] INTERNET-DRAFT Packetization of H.261 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 2 3 Purpose of this document .............................. 2 4 Structure of the packet stream ........................ 2 5 Specification of the packetization scheme ............. 5 5.1 Usage of RTP ........................................ 7 5.2 Usage of RTCP control packets ....................... 9 5.2.1 Controlling the reverse flow ...................... 10 5.2.2 Full Intra Request (FIR) RTCP control packet ...... 10 5.2.3 Negative ACKnowledgements (NACK) RTCP packet ...... 11 Acknowledgements ....................................... 13 References ............................................. 13 Appendix A ............................................. 15 Turletti, Huitema [Page 17]