idnits 2.17.1 draft-ietf-avt-h261-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2, 1996) is 10060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio-Video Transport WG 2 INTERNET-DRAFT T. Turletti / C. Huitema 3 draft-ietf-avt-h261-03.txt MIT / Bellcore 4 October 2, 1996 5 Expires: 1/1/97 7 RTP payload format 8 for 9 H.261 video streams 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To learn the current status of any Internet-Draft, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 28 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 29 ds.internic.net (US East Coast), or ftp.isi.edu (US West 30 Coast). 32 Distribution of this document is unlimited. 34 2. Abstract 36 This draft describes a scheme to packetize an H.261 video 37 stream for transport using the Real-time Transport Protocol, 38 RTP, with any of the underlying protocols that carry RTP. 40 This specification is a product of the Audio/Video Transport 41 working group within the Internet Engineering Task Force. 42 Comments are solicited and should be addressed to the working 43 group's mailing list at rem-conf@es.net and/or the authors. 45 3. Purpose of this document 47 The ITU-T recommendation H.261 [6] specifies the encodings 48 used by ITU-T compliant video-conference codecs. Although 49 these encodings were originally specified for fixed data rate 50 ISDN circuits, experiments [3],[8] have shown that they can 51 also be used over packet-switched networks such as the 52 Internet. 54 The purpose of this memo is to specify the RTP payload format 55 for encapsulating H.261 video streams in RTP [1]. 57 4. Structure of the packet stream 59 4.1. Overview of the ITU-T recommendation H.261 61 The H.261 coding is organized as a hierarchy of groupings. 62 The video stream is composed of a sequence of images, or 63 frames, which are themselves organized as a set of Groups of 64 Blocks (GOB). Note that H.261 "pictures" are referred as 65 "frames" in this document. Each GOB holds a set of 3 lines of 66 11 macro blocks (MB). Each MB carries information on a group 67 of 16x16 pixels: luminance information is specified for 4 68 blocks of 8x8 pixels, while chrominance information is given 69 by two "red" and "blue" color difference components at a 70 resolution of only 8x8 pixels. These components and the codes 71 representing their sampled values are as defined in the ITU-R 72 Recommendation 601 [7]. 74 This grouping is used to specify information at each level of 75 the hierarchy: 77 - At the frame level, one specifies information such as the 78 delay from the previous frame, the image format, and 79 various indicators. 81 - At the GOB level, one specifies the GOB number and the 82 default quantifier that will be used for the MBs. 84 - At the MB level, one specifies which blocks are present 85 and which did not change, and optionally a quantifier and 86 motion vectors. 88 Blocks which have changed are encoded by computing the 89 discrete cosine transform (DCT) of their coefficients, which 90 are then quantized and Huffman encoded (Variable Length 91 Codes). 93 The H.261 Huffman encoding includes a special "GOB start" 94 pattern, composed of 15 zeroes followed by a single 1, that 95 cannot be imitated by any other code words. This pattern is 96 included at the beginning of each GOB header (and also at the 97 beginning of each frame header) to mark the separation between 98 two GOBs, and is in fact used as an indicator that the current 99 GOB is terminated. The encoding also includes a stuffing 100 pattern, composed of seven zeroes followed by four ones; that 101 stuffing pattern can only be entered between the encoding of 102 MBs, or just before the GOB separator. 104 4.2. Considerations for packetization 106 H.261 codecs designed for operation over ISDN circuits produce 107 a bit stream composed of several levels of encoding specified 108 by H.261 and companion recommendations. The bits resulting 109 from the Huffman encoding are arranged in 512-bit frames, 110 containing 2 bits of synchronization, 492 bits of data and 18 111 bits of error correcting code. The 512-bit frames are then 112 interlaced with an audio stream and transmitted over px64 kbps 113 circuits according to specification H.221 [5]. 115 When transmitting over the Internet, we will directly consider 116 the output of the Huffman encoding. All the bits produced by 117 the Huffman encoding stage will be included in the packet. We 118 will not carry the 512-bit frames, as protection against bit 119 errors can be obtained by other means. Similarly, we will not 120 attempt to multiplex audio and video signals in the same 121 packets, as UDP and RTP provide a much more efficient way to 122 achieve multiplexing. 124 Directly transmitting the result of the Huffman encoding over 125 an unreliable stream of UDP datagrams would, however, have 126 poor error resistance characteristics. The result of the 127 hierachical structure of H.261 bit stream is that one needs to 128 receive the information present in the frame header to decode 129 the GOBs, as well as the information present in the GOB header 130 to decode the MBs. Without precautions, this would mean that 131 one has to receive all the packets that carry an image in 132 order to properly decode its components. 134 If each image could be carried in a single packet, this 135 requirement would not create a problem. However, a video image 136 or even one GOB by itself can sometimes be too large to fit in 137 a single packet. Therefore, the MB is taken as the unit of 138 fragmentation. Packets must start and end on a MB boundary, 139 i.e. a MB cannot be split across multiple packets. Multiple 140 MBs may be carried in a single packet when they will fit 141 within the maximal packet size allowed. This practice is 142 recommended to reduce the packet send rate and packet 143 overhead. 145 To allow each packet to be processed independently for 146 efficient resynchronization in the presence of packet losses, 147 some state information from the frame header and GOB header is 148 carried with each packet to allow the MBs in that packet to be 149 decoded. This state information includes the GOB number in 150 effect at the start of the packet, the macroblock address 151 predictor (i.e. the last MBA encoded in the previous packet), 152 the quantizer value in effect prior to the start of this 153 packet (GQUANT, MQUANT or zero in case of a beginning of GOB) 154 and the reference motion vector data (MVD) for computing the 155 true MVDs contained within this packet. The bit stream cannot 156 be fragmented between a GOB header and MB 1 of that GOB. 158 Moreover, since the compressed MB may not fill an integer 159 number of octets, the data header contains two three-bit 160 integers, SBIT and EBIT, to indicate the number of unused bits 161 in the first and last octets of the H.261 data, respectively. 163 5. Specification of the packetization scheme 165 5.1. Usage of RTP 167 The H.261 information is carried as payload data within the 168 RTP protocol. The following fields of the RTP header are 169 specified: 171 - The payload type should specify H.261 payload format (see 172 the companion RTP profile document RFC 1890). 174 - The RTP timestamp encodes the sampling instant of the 175 first video image contained in the RTP data packet. If a 176 video image occupies more than one packet, the timestamp 177 will be the same on all of those packets. Packets from 178 different video images must have different timestamps so 179 that frames may be distinguished by the timestamp. For 180 H.261 video streams, the RTP timestamp is based on a 181 90kHz clock. This clock rate is a multiple of the natural 182 H.261 frame rate (i.e. 30000/1001 or approx. 29.97 Hz). 183 That way, for each frame time, the clock is just 184 incremented by the multiple and this removes inaccuracy 185 in calculating the timestamp. Furthermore, the initial 186 value of the timestamp is random (unpredictable) to make 187 known-plaintext attacks on encryption more difficult, see 188 RTP [1]. Note that if multiple frames are encoded in a 189 packet (e.g. when there are very little changes between 190 two images), it is necessary to calculate display times 191 for the frames after the first using the timing 192 information in the H.261 frame header. This is required 193 because the RTP timestamp only gives the display time of 194 the first frame in the packet. 196 - The marker bit of the RTP header is set to one in the 197 last packet of a video frame, and otherwise, must be 198 zero. Thus, it is not necessary to wait for a following 199 packet (which contains the start code that terminates the 200 current frame) to detect that a new frame should be 201 displayed. 203 The H.261 data will follow the RTP header, as in: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 . . 209 . RTP header . 210 . . 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | H.261 header | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | H.261 stream ... . 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The H.261 header is defined as following: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 The fields in the H.261 header have the following meanings: 227 Start bit position (SBIT): 3 bits 228 Number of most significant bits that should be ignored 229 in the first data octet. 231 End bit position (EBIT): 3 bits 232 Number of least significant bits that should be ignored 233 in the last data octet. 235 INTRA-frame encoded data (I): 1 bit 236 Set to 1 if this stream contains only INTRA-frame coded 237 blocks. Set to 0 if this stream may or may not contain 238 INTRA-frame coded blocks. The sense of this bit may not 239 change during the course of the RTP session. 241 Motion Vector flag (V): 1 bit 242 Set to 0 if motion vectors are not used in this stream. 243 Set to 1 if motion vectors may or may not be used in 244 this stream. The sense of this bit may not change during 245 the course of the session. 247 GOB number (GOBN): 4 bits 248 Encodes the GOB number in effect at the start of the 249 packet. Set to 0 if the packet begins with a GOB header. 251 Macroblock address predictor (MBAP): 5 bits 252 Encodes the macroblock address predictor (i.e. the last 253 MBA encoded in the previous packet). This predictor ranges 254 from 0-32 (to predict the valid MBAs 1-33), but because 255 the bit stream cannot be fragmented between a GOB header 256 and MB 1, the predictor at the start of the packet can 257 never be 0. Therefore, the range is 1-32, which is biased 258 by -1 to fit in 5 bits. For example, if MBAP is 0, the 259 value of the MBA predictor is 1. Set to 0 if the packet 260 begins with a GOB header. 262 Quantizer (QUANT): 5 bits 263 Quantizer value (MQUANT or GQUANT) in effect prior to the 264 start of this packet. Set to 0 if the packet begins with 265 a GOB header. 267 Horizontal motion vector data (HMVD): 5 bits 268 Reference horizontal motion vector data (MVD). Set to 0 269 if V flag is 0 or if the packet begins with a GOB header, 270 or when the MTYPE of the last MB encoded in the previous 271 packet was not MC. HMVD is encoded as a 2's complement 272 number, and `10000' corresponding to the value -16 is 273 forbidden (motion vector fields range from +/-15). 275 Vertical motion vector data (VMVD): 5 bits 276 Reference vertical motion vector data (MVD). Set to 0 if 277 V flag is 0 or if the packet begins with a GOB header, or 278 when the MTYPE of the last MB encoded in the previous 279 packet was not MC. VMVD is encoded as a 2's complement 280 number, and `10000' corresponding to the value -16 is 281 forbidden (motion vector fields range from +/-15). 283 Note that the I and V flags are hint flags, i.e. they can be 284 inferred from the bit stream. They are included to allow 285 decoders to make optimizations that would not be possible if 286 these hints were not provided before bit stream was decoded. 287 Therefore, these bits cannot change for the duration of the 288 stream. A conformant implementation can always set V=1 and 289 I=0. 291 5.2. Recommendations for operation with hardware codecs 293 Packetizers for hardware codecs can trivially figure out GOB 294 boundaries using the GOB-start pattern included in the H.261 295 data. (Note that software encoders already know the 296 boundaries.) The cheapest packetization implementation is to 297 packetize at the GOB level all the GOBs that fit in a packet. 298 But when a GOB is too large, the packetizer has to parse it to 299 do MB fragmentation. (Note that only the Huffman encoding must 300 be parsed and that it is not necessary to fully decompress the 301 stream, so this requires relatively little processing; example 302 implementations can be found in some public H.261 codecs such 303 as IVS [4] and VIC [9].) It is recommended that MB level 304 fragmentation be used when feasible in order to obtain more 305 efficient packetization. Using this fragmentation scheme 306 reduces the output packet rate and therefore reduces the 307 overhead. 309 At the receiver, the data stream can be depacketized and 310 directed to a hardware codec's input. If the hardware decoder 311 operates at a fixed bit rate, synchronization may be 312 maintained by inserting the stuffing pattern between MBs 313 (i.e., between packets) when the packet arrival rate is slower 314 than the bit rate. 316 6. Packet loss issues 318 On the Internet, most packet losses are due to network 319 congestion rather than transmission errors. Using UDP, no 320 mechanism is available at the sender to know if a packet has 321 been successfully received. It is up to the application, i.e. 322 coder and decoder, to handle the packet loss. Each RTP packet 323 includes a a sequence number field which can be used to detect 324 packet loss. 326 H.261 uses the temporal redundancy of video to perform 327 compression. This differential coding (or INTER-frame coding) 328 is sensitive to packet loss. After a packet loss, parts of the 329 image may remain corrupt until all corresponding MBs have been 330 encoded in INTRA-frame mode (i.e. encoded independently of 331 past frames). There are several ways to mitigate packet loss: 333 (1) One way is to use only INTRA-frame encoding and MB level 334 conditional replenishment. That is, only MBs that change 335 (beyond some threshold) are transmitted. 337 (2) Another way is to adjust the INTRA-frame encoding 338 refreshment rate according to the packet loss observed by 339 the receivers. The H.261 recommendation specifies that a 340 MB is INTRA-frame encoded at least every 132 times it is 341 transmitted. However, the INTRA-frame refreshment rate 342 can be raised in order to speed the recovery when the 343 measured loss rate is significant. 345 (3) The fastest way to repair a corrupted image is to request 346 an INTRA-frame coded image refreshment after a packet 347 loss is detected. One means to accomplish this is for the 348 decoder to send to the coder a list of packets lost. The 349 coder can decide to encode every MB of every GOB of the 350 following video frame in INTRA-frame mode (i.e. Full 351 INTRA-frame encoded), or if the coder can deduce from the 352 packet sequence numbers which MBs were affected by the 353 loss, it can save bandwidth by sending only those MBs in 354 INTRA-frame mode. This mode is particularly efficient in 355 point-to-point connection or when the number of decoders 356 is low. The next section specifies how the refresh 357 function may be implemented. 359 Note that the method (1) is currently implemented in the VIC 360 videoconferencing software [9]. Methods (2) and (3) are 361 currently implemented in the IVS videoconferencing software 362 [4]. 364 6.1. Use of optional H.261-specific control packets 366 This specification defines two H.261-specific RTCP control 367 packets, "Full INTRA-frame Request" and "Negative 368 Acknowledgement", described in the next section. Their 369 purpose is to speed up refreshment of the video in those 370 situations where their use is feasible. Support of these 371 H.261-specific control packets by the H.261 sender is 372 optional; in particular, early experiments have shown that the 373 usage of this feature could have very negative effects when 374 the number of sites is very large. Thus, these control packets 375 should be used with caution. 377 The H.261-specific control packets differ from normal RTCP 378 packets in that they are not transmitted to the normal RTCP 379 destination transport address for the RTP session (which is 380 often a multicast address). Instead, these control packets 381 are sent directly via unicast from the decoder to the coder. 382 The destination port for these control packets is the same 383 port that the coder uses as a source port for transmitting RTP 384 (data) packets. Therefore, these packets may be considered 385 "reverse" control packets. 387 As a consequence, these control packets may only be used when 388 no RTP mixers or translators intervene in the path from the 389 coder to the decoder. If such intermediate systems do 390 intervene, the address of the coder would no longer be present 391 as the network-level source address in packets received by the 392 decoder, and in fact, it might not be possible for the decoder 393 to send packets directly to the coder. 395 Some reliable multicast protocols use similar NACK control 396 packets transmitted over the normal multicast distribution 397 channel, but they typically use random delays to prevent a 398 NACK implosion problem [2]. The goal of such protocols is to 399 provide reliable multicast packet delivery at the expense of 400 delay, which is appropriate for applications such as a shared 401 whiteboard. 403 On the other hand, interactive video transmission is more 404 sensitive to delay and does not require full reliability. For 405 video applications it is more effective to send the NACK 406 control packets as soon as possible, i.e. as soon as a loss is 407 detected, without adding any random delays. In this case, 408 multicasting the NACK control packets would generate useless 409 traffic between receivers since only the coder will use them. 410 But this method is only effective when the number of receivers 411 is small. e.g. in IVS [4] the H.261 specific control packets 412 are used only in point-to-point connections or in point-to- 413 multipoint connections when there are less than 10 414 participants in the conference. 416 6.2. H.261 control packets definition 418 6.2.1. Full INTRA-frame Request (FIR) packet 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |V=2|P| MBZ | PT=RTCP_FIR | length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | SSRC | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 This packet indicates that a receiver requires a full encoded 429 image in order to either start decoding with an entire image 430 or to refresh its image and speed the recovery after a burst 431 of lost packets. The receiver requests the source to force the 432 next image in full "INTRA-frame" coding mode, i.e. without 433 using differential coding. The various fields are defined in 434 the RTP specification [1]. SSRC is the synchronization source 435 identifier for the sender of this packet. The value of the 436 packet type (PT) identifier is the constant RTCP_FIR (192). 438 6.2.2. Negative ACKnowledgements (NACK) packet 440 The format of the NACK packet is as follow: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |V=2|P| MBZ | PT=RTCP_NACK | length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | SSRC | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | FSN | BLP | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 The various fields T, P, PT, length and SSRC are defined in 453 the RTP specification [1]. The value of the packet type (PT) 454 identifier is the constant RTCP_NACK (193). SSRC is the 455 synchronization source identifier for the sender of this 456 packet. 458 The two remaining fields have the following meanings: 460 First Sequence Number (FSN): 16 bits 461 Identifies the first sequence number lost. 463 Bitmask of following lost packets (BLP): 16 bits 464 A bit is set to 1 if the corresponding packet has been lost, 465 and set to 0 otherwise. BLP is set to 0 only if no packet 466 other than that being NACKed (using the FSN field) has been 467 lost. BLP is set to 0x00001 if the packet corresponding to 468 the FSN and the following packet have been lost, etc. 470 7. Security Considerations 472 Security concerns are not discussed in this memo. 474 Addresses of Authors 476 Thierry Turletti 477 INRIA - RODEO Project 478 2004 route des Lucioles 479 BP 93, 06902 Sophia Antipolis 480 FRANCE 481 electronic mail: turletti@sophia.inria.fr 483 Christian Huitema 484 MCC 1J236B Bellcore 485 445 South Street 486 Morristown, NJ 07960-6438 487 electronic mail: huitema@bellcore.com 489 Acknowledgements 491 This draft is based on discussion within the AVT working group 492 chaired by Stephen Casner. Steve McCanne, Stephen Casner, 493 Ronan Flood, Mark Handley, Van Jacobson, Henning G. 494 Schulzrinne and John Wroclawski provided valuable comments. 495 Stephen Casner and Steve McCanne also helped greatly with 496 getting this document into readable form. 498 References 500 [1] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van 501 Jacobson, RTP: A Transport Protocol for Real-Time 502 Applications, RFC 1889, January 1996. 504 [2] Sridhar Pingali, Don Towsley and James F. Kurose, A 505 comparison of sender-initiated and receiver-initiated 506 reliable multicast protocols, IEEE GLOBECOM '94. 508 [3] Thierry Turletti, H.261 software codec for 509 videoconferencing over the Internet INRIA Research Report 510 no 1834, January 1993. 512 [4] Thierry Turletti, INRIA Videoconferencing tool (IVS), 513 available by anonymous ftp from zenon.inria.fr in the 514 "rodeo/ivs/last_version" directory. See also URL 515 . 517 [5] Frame structure for Audiovisual Services for a 64 to 1920 518 kbps Channel in Audiovisual Services ITU-T (International 519 Telecommunication Union - Telecommunication 520 Standardisation Sector) Recommendation H.221, 1990. 522 [6] Video codec for audiovisual services at p x 64 kbit/s 523 ITU-T (International Telecommunication Union - 524 Telecommunication Standardisation Sector) Recommendation 525 H.261, 1993. 527 [7] Digital Methods of Transmitting Television Information 528 ITU-R (International Telecommunication Union - 529 Radiocommunication Standardisation Sector) Recommendation 530 601, 1986. 532 [8] M.A Sasse, U. Bilting, C-D Schulz, T. Turletti, Remote 533 Seminars through MultiMedia Conferencing: Experiences 534 from the MICE project, Proc. INET'94/JENC5, Prague, June 535 1994, pp. 251/1-251/8. 537 [9] Steve MacCanne, Van Jacobson, VIC Videoconferencing tool, 538 available by anonymous ftp from ee.lbl.gov in the 539 "conferencing/vic" directory. 541 Table of Contents 543 1 Status of this Memo ................................... 1 544 2 Abstract .............................................. 2 545 3 Purpose of this document .............................. 2 546 4 Structure of the packet stream ........................ 2 547 4.1 Overview of the ITU-T recommendation H.261 .......... 2 548 4.2 Considerations for packetization .................... 3 549 5 Specification of the packetization scheme ............. 5 550 5.1 Usage of RTP ........................................ 5 551 5.2 Recommendations for operation with hardware codecs 552 .................................................... 7 553 6 Packet loss issues .................................... 8 554 6.1 Use of optional H.261-specific control packets ...... 9 555 6.2 H.261 control packets definition .................... 10 556 6.2.1 Full INTRA-frame Request (FIR) packet ............. 10 557 6.2.2 Negative ACKnowledgements (NACK) packet ........... 11 558 7 Security Considerations ............................... 11 559 Addresses of Authors ................................... 12 560 Acknowledgements ....................................... 12 561 References ............................................. 12