idnits 2.17.1 draft-ietf-avt-rfc2429-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '... of the und...' == Line 104 has weird spacing: '...the new optio...' == Line 711 has weird spacing: '...ameters into ...' == Line 753 has weird spacing: '...ibe the frame...' -- 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 (November 2003) is 7467 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) == Unused Reference: 'H263X' is defined on line 1048, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'H263' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263P' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263X' ** Obsolete normative reference: RFC 2032 (Obsoleted by RFC 4587) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Downref: Normative reference to an Historic RFC: RFC 2190 ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Possible downref: Non-RFC (?) normative reference: ref. 'Vredun' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT J. Ott 2 Internet-Draft Univ. Bremen 3 Expires: May 1, 2004 G. Sullivan 4 Microsoft 5 S. Wenger 6 TU Berlin 7 C. Zhu 8 Intel Corp. 9 R. Even 10 Polycom 11 November 2003 13 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 14 (H.263+) 15 draft-ietf-avt-rfc2429-bis-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 1, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document describes a scheme to packetize an H.263 video stream 46 for transport using the Real-time Transport Protocol, RTP, with any 47 of the underlying protocols that carry RTP. 49 The document also describe the syntax and semantics of the SDP 50 parameters needed to support the H.263 video codec. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . 4 56 3. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2 Video Packet Structure . . . . . . . . . . . . . . . . . . . 7 59 4. Design Considerations . . . . . . . . . . . . . . . . . . . 9 60 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . 11 61 5.1 General H.263+ payload header . . . . . . . . . . . . . . . 11 62 5.2 Video Redundancy Coding Header Extension . . . . . . . . . . 12 63 6. Packetization schemes . . . . . . . . . . . . . . . . . . . 15 64 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) . 15 65 6.1.1 Packets that begin with a Picture Start Code . . . . . . . . 15 66 6.1.2 Packets that begin with GBSC or SSC . . . . . . . . . . . . 16 67 6.1.3 Packets that Begin with an EOS or EOSBS Code . . . . . . . . 17 68 6.2 Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . . 17 69 7. Use of this payload specification . . . . . . . . . . . . . 19 70 8. Payload Format Parameters . . . . . . . . . . . . . . . . . 21 71 8.1 IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 72 8.1.1 Registration of MIME media type video/H263-1998 . . . . . . 21 73 8.1.2 Registration of MIME media type video/H263-2000 . . . . . . 24 74 8.2 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 25 75 8.2.1 Usage of SDP H.263 options with SIP . . . . . . . . . . . . 25 76 9. Security Considerations . . . . . . . . . . . . . . . . . . 27 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 78 11. Requirements notation . . . . . . . . . . . . . . . . . . . 29 79 12. changes from RFC 2429> . . . . . . . . . . . . . . . . . . . 30 80 Normative References . . . . . . . . . . . . . . . . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 82 Intellectual Property and Copyright Statements . . . . . . . 33 84 1. Introduction 86 This document specifies an RTP payload header format applicable to 87 the transmission of video streams generated based on the 1998 and 88 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 89 1998 version of H.263 is a superset of the 1996 syntax, this format 90 can also be used with the 1996 version of H.263 [H263], and must be 91 use by new implementations. This format replaces the payload format 92 in RFC 2190[RFC2190], which continues to be used by existing 93 implementations, and may be required for backward compatibility. New 94 implementations supporting H.263 shall use the payload format 95 described in this document. 97 2. New H.263 features 99 The 1998 version of ITU-T Recommendation H.263 added numerous coding 100 options to improve codec performance over the 1996 version. The 1998 101 version is referred to as H.263+ in this document. The 2000 version 102 is referred to as H.263++ in this document. 104 Among the new options, the ones with the biggest impact on the RTP 105 payload specification and the error resilience of the video content 106 are the slice structured mode, the independent segment decoding mode, 107 the reference picture selection mode, and the scalability mode. This 108 section summarizes the impact of these new coding options on 109 packetization. Refer to [H263P] for more information on coding 110 options. 112 The slice structured mode was added to H.263+ for three purposes: to 113 provide enhanced error resilience capability, to make the bitstream 114 more amenable to use with an underlying packet transport such as RTP, 115 and to minimize video delay. The slice structured mode supports 116 fragmentation at macroblock boundaries. 118 With the independent segment decoding (ISD) option, a video picture 119 frame is broken into segments and encoded in such a way that each 120 segment is independently decodable. Utilizing ISD in a lossy network 121 environment helps to prevent the propagation of errors from one 122 segment of the picture to others. 124 The reference picture selection mode allows the use of an older 125 reference picture rather than the one immediately preceding the 126 current picture. Usually, the last transmitted frame is implicitly 127 used as the reference picture for inter-frame prediction. If the 128 reference picture selection mode is used, the data stream carries 129 information on what reference frame should be used, indicated by the 130 temporal reference as an ID for that reference frame. The reference 131 picture selection mode can be used with or without a back channel, 132 which provides information to the encoder about the internal status 133 of the decoder. However, no special provision is made herein for 134 carrying back channel information. 136 H.263+ also includes bitstream scalability as an optional coding 137 mode. Three kinds of scalability are defined: temporal, signal-to- 138 noise ratio (SNR), and spatial scalability. Temporal scalability is 139 achieved via the disposable nature of bi-directionally predicted 140 frames, or B-frames. (A low-delay form of temporal scalability known 141 as P-picture temporal scalability can also be achieved by using the 142 reference picture selection mode described in the previous 143 paragraph.) SNR scalability permits refinement of encoded video 144 frames, thereby improving the quality (or SNR). Spatial scalability 145 is similar to SNR scalability except the refinement layer is twice 146 the size of the base layer in the horizontal dimension, vertical 147 dimension, or both. 149 3. Usage of RTP 151 When transmitting H.263+ video streams over the Internet, the output 152 of the encoder can be packetized directly. All the bits resulting 153 from the bitstream including the fixed length codes and variable 154 length codes will be included in the packet, with the only exception 155 being that when the payload of a packet begins with a Picture, GOB, 156 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 157 the start code are removed and replaced by setting an indicator bit 158 in the payload header. 160 For H.263+ bitstreams coded with temporal, spatial, or SNR 161 scalability, each layer may be transported to a different network 162 address. More specifically, each layer may use a unique IP address 163 and port number combination. The temporal relations between layers 164 shall be expressed using the RTP timestamp so that they can be 165 synchronized at the receiving ends in multicast or unicast 166 applications. 168 The H.263+ video stream will be carried as payload data within RTP 169 packets. A new H.263+ payload header is defined in section 4. This 170 section defines the usage of the RTP fixed header and H.263+ video 171 packet structure. 173 3.1 RTP Header Usage 175 Each RTP packet starts with a fixed RTP header. The following fields 176 of the RTP fixed header are used for H.263+ video streams: 178 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 179 the current packet carries the end of current frame, and is 0 180 otherwise. 182 Payload Type (PT): The Payload Type shall specify the H.263+ video 183 payload format. 185 Timestamp: The RTP Timestamp encodes the sampling instance of the 186 first video frame data contained in the RTP data packet. The RTP 187 timestamp shall be the same on successive packets if a video frame 188 occupies more than one packet. In a multilayer scenario, all 189 pictures corresponding to the same temporal reference should use the 190 same timestamp. If temporal scalability is used (if B-frames are 191 present), the timestamp may not be monotonically increasing in the 192 RTP stream. If B-frames are transmitted on a separate layer and 193 address, they must be synchronized properly with the reference 194 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 195 information on required transmission order to a decoder. For an 196 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 197 the same as that of the RTP payload for H.261 stream [RFC2032]. 198 Since both the H.263+ data and the RTP header contain time 199 information, it is required that those timing information run 200 synchronously. That is, both the RTP timestamp and the temporal 201 reference (TR in the picture header of H.263) should carry the same 202 relative timing information. Any H.263+ picture clock frequency can 203 be expressed as 1800000/(cd*cf) source pictures per second, in which 204 cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using 205 the 90 kHz clock of the RTP timestamp, the time increment between 206 each coded H.263+ picture should therefore be a integer multiple of 207 (cd*cf)/20. This will always be an integer for any "reasonable" 208 picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 209 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for 210 the computer display update rates of 60, 72 and 75 Hz, respectively). 211 For RTP packetization of hypothetical H.263+ bitstreams using 212 "unreasonable" custom picture clock frequencies, mathematical 213 rounding could become necessary for generating the RTP timestamps. 215 3.2 Video Packet Structure 217 A section of an H.263+ compressed bitstream is carried as a payload 218 within each RTP packet. For each RTP packet, the RTP header is 219 followed by an H.263+ payload header, which is followed by a number 220 of bytes of a standard H.263+ compressed bitstream. The size of the 221 H.263+ payload header is variable depending on the payload involved 222 as detailed in the section 4. The layout of the RTP H.263+ video 223 packet is shown as: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | RTP Header 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | H.263+ Payload Header 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | H.263+ Compressed Data Stream 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Any H.263+ start codes can be byte aligned by an encoder by using the 236 stuffing mechanisms of H.263+. As specified in H.263+, picture, 237 slice, and EOSBS starts codes shall always be byte aligned, and GOB 238 and EOS start codes may be byte aligned. For packetization purposes, 239 GOB start codes should be byte aligned; however, since this is not 240 required in H.263+, there may be some cases where GOB start codes are 241 not aligned, such as when transmitting existing content, or when 242 using H.263 encoders that do not support GOB start code alignment. In 243 this case, follow-on packets (see section 5.2) should be used for 244 packetization. 246 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 247 with 16 zero-valued bits. If a start code is byte aligned and it 248 occurs at the beginning of a packet, these two bytes shall be removed 249 from the H.263+ compressed data stream in the packetization process 250 and shall instead be represented by setting a bit (the P bit) in the 251 payload header. 253 4. Design Considerations 255 The goals of this payload format are to specify an efficient way of 256 encapsulating an H.263+ standard compliant bitstream and to enhance 257 the resiliency towards packet losses. Due to the large number of 258 different possible coding schemes in H.263+, a copy of the picture 259 header with configuration information is inserted into the payload 260 header when appropriate. The use of that copy of the picture header 261 along with the payload data can allow decoding of a received packet 262 even in such cases in which another packet containing the original 263 picture header becomes lost. 265 There are a few assumptions and constraints associated with this 266 H.263+ payload header design. The purpose of this section is to 267 point out various design issues and also to discuss several coding 268 options provided by H.263+ that may impact the performance of 269 network-based H.263+ video. 271 o The optional slice structured mode described in Annex K of H.263+ 272 [H263P] enables more flexibility for packetization. Similar to a 273 picture segment that begins with a GOB header, the motion vector 274 predictors in a slice are restricted to reside within its boundaries. 275 However, slices provide much greater freedom in the selection of the 276 size and shape of the area which is represented as a distinct 277 decodable region. In particular, slices can have a size which is 278 dynamically selected to allow the data for each slice to fit into a 279 chosen packet size. Slices can also be chosen to have a rectangular 280 shape which is conducive for minimizing the impact of errors and 281 packet losses on motion compensated prediction. For these reasons, 282 the use of the slice structured mode is strongly recommended for any 283 applications used in environments where significant packet loss 284 occurs. 286 o In non-rectangular slice structured mode, only complete slices 287 should be included in a packet. In other words, slices should not be 288 fragmented across packet boundaries. The only reasonable need for a 289 slice to be fragmented across packet boundaries is when the encoder 290 which generated the H.263+ data stream could not be influenced by an 291 awareness of the packetization process (such as when sending H.263+ 292 data through a network other than the one to which the encoder is 293 attached, as in network gateway implementations). Optimally, each 294 packet will contain only one slice. 296 o The independent segment decoding (ISD) described in Annex R of 297 [H263P] prevents any data dependency across slice or GOB boundaries 298 in the reference picture. It can be utilized to further improve 299 resiliency in high loss conditions. 301 o If ISD is used in conjunction with the slice structure, the 302 rectangular slice submode shall be enabled and the dimensions and 303 quantity of the slices present in a frame shall remain the same 304 between each two intra-coded frames (I-frames), as required in 305 H.263+. The individual ISD segments may also be entirely intra coded 306 from time to time to realize quick error recovery without adding the 307 latency time associated with sending complete INTRA- pictures. 309 o When the slice structure is not applied, the insertion of a 310 (preferably byte-aligned) GOB header can be used to provide resync 311 boundaries in the bitstream, as the presence of a GOB header 312 eliminates the dependency of motion vector prediction across GOB 313 boundaries. These resync boundaries provide natural locations for 314 packet payload boundaries. 316 o H.263+ allows picture headers to be sent in an abbreviated form in 317 order to prevent repetition of overhead information that does not 318 change from picture to picture. For resiliency, sending a complete 319 picture header for every frame is often advisable. This means that 320 (especially in cases with high packet loss probability in which 321 picture header contents are not expected to be highly predictable), 322 the sender may find it advisable to always set the subfield UFEP in 323 PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263P] for 324 the definition of the UFEP and PLUSPTYPE fields). 326 o In a multi-layer scenario, each layer may be transmitted to a 327 different network address. The configuration of each layer such as 328 the enhancement layer number (ELNUM), reference layer number (RLNUM), 329 and scalability type should be determined at the start of the session 330 and should not change during the course of the session. 332 o All start codes can be byte aligned, and picture, slice, and EOSBS 333 start codes are always byte aligned. The boundaries of these 334 syntactical elements provide ideal locations for placing packet 335 boundaries. 337 o We assume that a maximum Picture Header size of 504 bits is 338 sufficient. The syntax of H.263+ does not explicitly prohibit larger 339 picture header sizes, but the use of such extremely large picture 340 headers is not expected. 342 5. H.263+ Payload Header 344 For H.263+ video streams, each RTP packet carries only one H.263+ 345 video packet. The H.263+ payload header is always present for each 346 H.263+ video packet. The payload header is of variable length. A 16 347 bit field of the basic payload header may be followed by an 8 bit 348 field for Video Redundancy Coding (VRC) information, and/or by a 349 variable length extra picture header as indicated by PLEN. These 350 optional fields appear in the order given above when present. 352 If an extra picture header is included in the payload header, the 353 length of the picture header in number of bytes is specified by PLEN. 354 The minimum length of the payload header is 16 bits, corresponding to 355 PLEN equal to 0 and no VRC information present. 357 The remainder of this section defines the various components of the 358 RTP payload header. Section five defines the various packet types 359 that are used to carry different types of H.263+ coded data, and 360 section six summarizes how to distinguish between the various packet 361 types. 363 5.1 General H.263+ payload header 365 The H.263+ payload header is structured as follows: 367 0 1 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | RR |P|V| PLEN |PEBIT| 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 RR: 5 bits 375 Reserved bits. Shall be zero. 377 P: 1 bit 379 Indicates the picture start or a picture segment (GOB/Slice) start or 380 a video sequence end (EOS or EOSBS). Two bytes of zero bits then 381 have to be prefixed to the payload of such a packet to compose a 382 complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the 383 omission of the two first bytes of the start codes, thus improving 384 the compression ratio. 386 V: 1 bit 388 Indicates the presence of an 8 bit field containing information for 389 Video Redundancy Coding (VRC), which follows immediately after the 390 initial 16 bits of the payload header if present. For syntax and 391 semantics of that 8 bit VRC field see section 4.2. 393 PLEN: 6 bits 395 Length in bytes of the extra picture header. If no extra picture 396 header is attached, PLEN is 0. If PLEN>0, the extra picture header 397 is attached immediately following the rest of the payload header. 398 Note the length reflects the omission of the first two bytes of the 399 picture start code (PSC). See section 5.1. 401 PEBIT: 3 bits 403 Indicates the number of bits that shall be ignored in the last byte 404 of the picture header. If PLEN is not zero, the ignored bits shall 405 be the least significant bits of the byte. If PLEN is zero, then 406 PEBIT shall also be zero. 408 5.2 Video Redundancy Coding Header Extension 410 Video Redundancy Coding (VRC) is an optional mechanism intended to 411 improve error resilience over packet networks. Implementing VRC in 412 H.263+ will require the Reference Picture Selection option described 413 in Annex N of [H263P]. By having multiple "threads" of independently 414 inter-frame predicted pictures, damage of individual frame will cause 415 distortions only within its own thread but leave the other threads 416 unaffected. From time to time, all threads converge to a so-called 417 sync frame (an INTRA picture or a non-INTRA picture which is 418 redundantly represented within multiple threads); from this sync 419 frame, the independent threads are started again. For more 420 information on codec support for VRC see [Vredun]. 422 P-picture temporal scalability is another use of the reference 423 picture selection mode and can be considered a special case of VRC in 424 which only one copy of each sync frame may be sent. It offers a 425 thread-based method of temporal scalability without the increased 426 delay caused by the use of B pictures. In this use, sync frames sent 427 in the first thread of pictures are also used for the prediction of a 428 second thread of pictures which fall temporally between the sync 429 frames to increase the resulting frame rate. In this use, the 430 pictures in the second thread can be discarded in order to obtain a 431 reduction of bit rate or decoding complexity without harming the 432 ability to decode later pictures. A third or more threads can also 433 be added as well, but each thread is predicted only from the sync 434 frames (which are sent at least in thread 0) or from frames within 435 the same thread. 437 While a VRC data stream is - like all H.263+ data - totally self- 438 contained, it may be useful for the transport hierarchy 439 implementation to have knowledge about the current damage status of 440 each thread. On the Internet, this status can easily be determined 441 by observing the marker bit, the sequence number of the RTP header, 442 and the thread-id and a circling "packet per thread" number. The 443 latter two numbers are coded in the VRC header extension. 445 The format of the VRC header extension is as follows: 447 0 1 2 3 4 5 6 7 448 +-+-+-+-+-+-+-+-+ 449 | TID | Trun |S| 450 +-+-+-+-+-+-+-+-+ 452 TID: 3 bits 454 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 455 data will use as reference information only sync frames or frames 456 within the same thread. By convention, thread 0 is expected to be 457 the "canonical" thread, which is the thread from which the sync frame 458 should ideally be used. In the case of corruption or loss of the 459 thread 0 representation, a representation of the sync frame with a 460 higher thread number can be used by the decoder. Lower thread 461 numbers are expected to contain equal or better representations of 462 the sync frames than higher thread numbers in the absence of data 463 corruption or loss. See [Vredun] for a detailed discussion of VRC. 465 Trun: 4 bits 467 Monotonically increasing (modulo 16) 4 bit number counting the packet 468 number within each thread. 470 S: 1 bit 472 A bit that indicates that the packet content is for a sync frame. An 473 encoder using VRC may send several representations of the same "sync" 474 picture, in order to ensure that regardless of which thread of 475 pictures is corrupted by errors or packet losses, the reception of at 476 least one representation of a particular picture is ensured (within 477 at least one thread). The sync picture can then be used for the 478 prediction of any thread. If packet losses have not occurred, then 479 the sync frame contents of thread 0 can be used and those of other 480 threads can be discarded (and similarly for other threads). Thread 0 481 is considered the "canonical" thread, the use of which is preferable 482 to all others. The contents of packets having lower thread numbers 483 shall be considered as having a higher processing and delivery 484 priority than those with higher thread numbers. Thus packets having 485 lower thread numbers for a given sync frame shall be delivered first 486 to the decoder under loss-free and low-time-jitter conditions, which 487 will result in the discarding of the sync contents of the 488 higher-numbered threads as specified in Annex N of [H263P]. 490 6. Packetization schemes 492 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) 494 A picture segment packet is defined as a packet that starts at the 495 location of a Picture, GOB, or slice start code in the H.263+ data 496 stream. This corresponds to the definition of the start of a video 497 picture segment as defined in H.263+. For such packets, P=1 always. 499 An extra picture header can sometimes be attached in the payload 500 header of such packets. Whenever an extra picture header is attached 501 as signified by PLEN>0, only the last six bits of its picture start 502 code, '100000', are included in the payload header. A complete 503 H.263+ picture header with byte aligned picture start code can be 504 conveniently assembled on the receiving end by prepending the sixteen 505 leading '0' bits. 507 When PLEN>0, the end bit position corresponding to the last byte of 508 the picture header data is indicated by PEBIT. The actual bitstream 509 data shall begin on an 8-bit byte boundary following the payload 510 header. 512 A sequence ending packet is defined as a packet that starts at the 513 location of an EOS or EOSBS code in the H.263+ data stream. This 514 delineates the end of a sequence of H.263+ video data (more H.263+ 515 video data may still follow later, however, as specified in ITU-T 516 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 518 The optional header extension for VRC may or may not be present as 519 indicated by the V bit flag. 521 6.1.1 Packets that begin with a Picture Start Code 523 Any packet that contains the whole or the start of a coded picture 524 shall start at the location of the picture start code (PSC), and 525 should normally be encapsulated with no extra copy of the picture 526 header. In other words, normally PLEN=0 in such a case. However, if 527 the coded picture contains an incomplete picture header (UFEP = 528 "000"), then a representation of the complete (UFEP = "001") picture 529 header may be attached during packetization in order to provide 530 greater error resilience. Thus, for packets that start at the 531 location of a picture start code, PLEN shall be zero unless both of 532 the following conditions apply: 534 1) The picture header in the H.263+ bitstream payload is incomplete 535 (PLUSPTYPE present and UFEP="000"), and 537 2) The additional picture header which is attached is not incomplete 538 (UFEP="001"). 540 A packet which begins at the location of a Picture, GOB, slice, EOS, 541 or EOSBS start code shall omit the first two (all zero) bytes from 542 the H.263+ bitstream, and signify their presence by setting P=1 in 543 the payload header. 545 Here is an example of encapsulating the first packet in a frame 546 (without an attached redundant complete picture header): 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | first two 0 bytes of the PSC 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 6.1.2 Packets that begin with GBSC or SSC 558 For a packet that begins at the location of a GOB or slice start 559 code, PLEN may be zero or may be nonzero, depending on whether a 560 redundant picture header is attached to the packet. In environments 561 with very low packet loss rates, or when picture header contents are 562 very seldom likely to change (except as can be detected from the GFID 563 syntax of H.263+), a redundant copy of the picture header is not 564 required. However, in less ideal circumstances a redundant picture 565 header should be attached for enhanced error resilience, and its 566 presence is indicated by PLEN>0. 568 Assuming a PLEN of 9 and P=1, below is an example of a packet that 569 begins with a byte aligned GBSC or a SSC: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | starting with TR, PTYPE ... | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | ... | bitstream | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | data starting with GBSC/SSC without its first two 0 bytes 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Notice that only the last six bits of the picture start code, 584 '100000', are included in the payload header. A complete H.263+ 585 picture header with byte aligned picture start code can be 586 conveniently assembled if needed on the receiving end by prepending 587 the sixteen leading '0' bits. 589 6.1.3 Packets that Begin with an EOS or EOSBS Code 591 For a packet that begins with an EOS or EOSBS code, PLEN shall be 592 zero, and no Picture, GOB, or Slice start codes shall be included 593 within the same packet. As with other packets beginning with start 594 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 595 beginning of the packet shall be omitted, and their presence shall be 596 indicated by setting the P bit to 1 in the payload header. 598 System designers should be aware that some decoders may interpret the 599 loss of a packet containing only EOS or EOSBS information as the loss 600 of essential video data and may thus respond by not displaying some 601 subsequent video information. Since EOS and EOSBS codes do not 602 actually affect the decoding of video pictures, they are somewhat 603 unnecessary to send at all. Because of the danger of 604 misinterpretation of the loss of such a packet (which can be detected 605 by the sequence number), encoders are generally to be discouraged 606 from sending EOS and EOSBS. 608 Below is an example of a packet containing an EOS code: 610 0 1 2 611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 6.2 Encapsulating Follow-On Packet (P=0) 618 A Follow-on packet contains a number of bytes of coded H.263+ data 619 which does not start at a synchronization point. That is, a Follow- 620 On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS 621 header, and it may or may not start at a macroblock boundary. Since 622 Follow-on packets do not start at synchronization points, the data at 623 the beginning of a follow-on packet is not independently decodable. 624 For such packets, P=0 always. If the preceding packet of a Follow-on 625 packet got lost, the receiver may discard that Follow-on packet as 626 well as all other following Follow-on packets. Better behavior, of 627 course, would be for the receiver to scan the interior of the packet 628 payload content to determine whether any start codes are found in the 629 interior of the packet which can be used as resync points. The use 630 of an attached copy of a picture header for a follow-on packet is 631 useful only if the interior of the packet or some subsequent follow- 632 on packet contains a resync code such as a GOB or slice start code. 633 PLEN>0 is allowed, since it may allow resync in the interior of the 634 packet. The decoder may also be resynchronized at the next segment 635 or picture packet. 637 Here is an example of a follow-on packet (with PLEN=0): 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 642 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 645 7. Use of this payload specification 647 There is no syntactical difference between a picture segment packet 648 and a Follow-on packet, other than the indication P=1 for picture 649 segment or sequence ending packets and P=0 for Follow-on packets. 650 See the following for a summary of the entire packet types and ways 651 to distinguish between them. 653 It is possible to distinguish between the different packet types by 654 checking the P bit and the first 6 bits of the payload along with the 655 header information. The following table shows the packet type for 656 permutations of this information (see also the picture/GOB/Slice 657 header descriptions in H.263+ for details): 659 -------------+--------------+----------------------+---------------- 660 First 6 bits | P-Bit | PLEN | Packet | Remarks 661 of Payload |(payload hdr.)| | 662 -------------+--------------+----------------------+---------------- 663 100000 | 1 | 0 | Picture | Typical Picture 664 100000 | 1 | > 0 | Picture | Note UFEP 665 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 666 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 667 Xxxxxx | 0 | 0 | Follow-on | 668 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 669 -------------+--------------+----------------------+---------------- 671 The details regarding the possible values of the five bit Group 672 Number (GN) field which follows the initial "1" bit when the P-bit is 673 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 674 of [H263P]. 676 As defined in this specification, every start of a coded frame (as 677 indicated by the presence of a PSC) has to be encapsulated as a 678 picture segment packet. If the whole coded picture fits into one 679 packet of reasonable size (which is dependent on the connection 680 characteristics), this is the only type of packet that may need to be 681 used. Due to the high compression ratio achieved by H.263+ it is 682 often possible to use this mechanism, especially for small spatial 683 picture formats such as QCIF and typical Internet packet sizes around 684 1500 bytes. 686 If the complete coded frame does not fit into a single packet, two 687 different ways for the packetization may be chosen. In case of very 688 low or zero packet loss probability, one or more Follow-on packets 689 may be used for coding the rest of the picture. Doing so leads to 690 minimal coding and packetization overhead as well as to an optimal 691 use of the maximal packet size, but does not provide any added error 692 resilience. 694 The alternative is to break the picture into reasonably small 695 partitions - called Segments - (by using the Slice or GOB mechanism), 696 that do offer synchronization points. By doing so and using the 697 Picture Segment payload with PLEN>0, decoding of the transmitted 698 packets is possible even in such cases in which the Picture packet 699 containing the picture header was lost (provided any necessary 700 reference picture is available). Picture Segment packets can also be 701 used in conjunction with Follow-on packets for large segment sizes. 703 8. Payload Format Parameters 705 This section updates the H.263(1998) and H.263 (2000) media types 706 described in RFC3555 [RFC3555]. 708 This section specifies optional parameters that MAY be used to select 709 optional features of the H.263 codec. The parameters are specified 710 here as part of the MIME subtype registration for the ITU-T H.263 711 codec. A mapping of the parameters into the Session Description 712 Protocol (SDP) [RFC2327] is also provided for those applications 713 that use SDP. Multiple parameters SHOULD be expressed as a MIME 714 media type string, in the form of a space-separated list of 715 parameter=value pairs 717 8.1 IANA Considerations 719 This section describes the MIME types and names associated with this 720 payload format.The section registers the MIME types, as per 721 RFC2048[RFC2048] 723 8.1.1 Registration of MIME media type video/H263-1998 725 MIME media type name: video 727 MIME subtype name: H263-1998 729 Required parameters: None 731 Optional parameters: 733 SQCIF: Describes the frame rate for SQCIF resolution. permissible 734 value are integer values 1 to 32 and it means that the maximum rate 735 is 29.97/ specified value 737 QCIF: Describes the frame rate for QCIF resolution. permissible 738 value are integer values 1 to 32 and it means that the maximum rate 739 is 29.97/ specified value 741 CIF: Describes the frame rate for CIF resolution. permissible value 742 are integer values 1 to 32 and it means that the maximum rate is 743 29.97/ specified value 745 CIF4: Describes the frame rate for 4xCIF resolution. permissible 746 value are integer values 1 to 32 and it means that the maximum rate 747 is 29.97/ specified value 749 CIF16: Describes the frame rate for 16xCIF resolution. permissible 750 value are integer values 1 to 32 and it means that the maximum rate 751 is 29.97/ specified value 753 CUSTOM: Describe the frame rate for a custom defined resolution. 754 The custom parameter receives three comma separated values Xmax , 755 Ymax and frame rate. The Xmax and Ymax parameters describes the 756 number of pixels in the X and Y axis and must be dividable by 4. The 757 frame rate permissible value are integer values 1 to 32 and it means 758 that the maximum rate is 29.97/ specified value 760 A list of optional annexes specifies which annex of H.263 are 761 supported. The annexes optional parameters are defined as part of the 762 H263-1998 also known as H.263 plus. The H263-2000 version also known 763 as H.263 plus plus has a definition of profile which groups annexes 764 for specific application. The usage of the H263-1998 with annexes is 765 mainly for video conferencing applications. 767 The allowed optional parameters for the annexes are "F", "I", "J", 768 "T" which do not get any values and "K", "N" and "P". 770 "K" can receive one of four values: 772 1: - slicesInOrder-NonRect. 774 2: - slicesInOrder-Rect. 776 3: - slicesNoOrder-NonRect. 778 4: - slicesNoOrder-Rect. 780 "N" - Reference Picture Selection mode - Four numeric choices (modes) 781 are available representing the following modes: 783 1: NEITHER: In which no back-channel data is returned from the 784 decoder to the encoder. 786 2: ACK: In which the decoder returns only acknowledgment messages. 788 3: NACK: In which the decoder returns only non-acknowledgment 789 messages 791 4: ACK+NACK: In which the decoder returns both acknowledgment and 792 non-acknowledgment messages. 794 "P" - Reference Picture Resampling with the following submodes: 796 1: dynamicPictureResizingByFour 797 2: dynamicPictureResizingBySixteenthPel 799 3: dynamicWarpingHalfPel 801 4: dynamicWarpingSixteenthPel 803 Example: P=1,3 805 Editor note: Other H.263 annexes are not part of the list and the 806 author is looking for input on the need to specify them explicitly. 807 This includes annexes "D", "E", "G", "L", "M", "O", "Q," "R", 808 "S". 810 PAR - Arbitrary Pixel Aspect Ratio : defines the ratio by two 811 integers between 0 and 255. Default ratio is 12:11 if not otherwise 812 specified. 814 CPCF - Arbitrary (Custom) Picture Clock Frequency: Cpcf is floating 815 point value. Default value is 29.97. 817 MAXBR - MaxBitRate: Maximum video stream bitrate, presented with 818 units of 100 bits/s. MaxBR value is an integer between 1..19200. 820 BPP - BitsPerPictureMaxKb: Maximum amount of kilobits allowed to 821 represent a single picture frame, value is specified by largest 822 supported picture resolution. If this parameter is not present, then 823 default value, that is based on the maximum supported resolution, is 824 used. BPP is integer value between 0 and 65536. 826 HRD - Hypothetical Reference Decoder: See annex B of H.263 827 specification[H263P]. 829 Encoding considerations: 831 This type is only defined for transfer via RTP [RFC3550] 833 Security considerations: See Section 9 835 Interoperability considerations: none 837 Published specification: RFC yyy ( This RFC) 839 Applications which use this media type: 841 Audio and video streaming and conferencing tools. 843 Additional information: none 844 Person and email address to contact for further information : 846 Roni Even: roni.even@polycom.co.il 848 Intended usage: COMMON 850 >Author/Change controller: 852 Roni Even 854 8.1.2 Registration of MIME media type video/H263-2000 856 MIME media type name: video 858 MIME subtype name: H263-2000 860 Required parameters: None 862 Optional parameters: 864 The optional parameters of the H263-1998 type may be used with this 865 MIME subtype. Specific optional parameters that may be used with the 866 H263-2000 type are: 868 PROFILE: H.263 profile number, in the range 0 through 10, specifying 869 the supported H.263 annexes/subparts. 871 LEVEL: Level of bitstream operation, in the range 0 through 100, 872 specifying the level of computational complexity of the decoding 873 process. 875 INTERLACE: Interlaced or 60 fields indicates the support for 876 interlace display according to H.263 annex W.6.3.11 878 Encoding considerations: 880 This type is only defined for transfer via RTP [RFC3550] 882 Security considerations: See Section 9 884 Interoperability considerations: none 886 Published specification: RFC yyy 888 Applications which use this media type: 890 Audio and video streaming and conferencing tools. 892 Additional information: none 894 Person and email address to contact for further information : 896 Roni Even: roni.even@polycom.co.il 898 Intended usage: COMMON 900 >Author/Change controller: 902 Roni Even 904 8.2 SDP Parameters 906 The MIME media types video/H263-1998 and video/H263-2000 string are 907 mapped to fields in the Session Description Protocol (SDP) as 908 follows: 910 o The media name in the "m=" line of SDP MUST be video. 912 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 913 or h263-2000 (the MIME subtype). 915 o The clock rate in the "a=rtpmap" line MUST be 90000. 917 o The optional parameters if any, SHALL be included in the "a=fmtp" 918 line of SDP. These parameters are expressed as a MIME media type 919 string, in the form of as a space separated list of parameter=value 920 pairs." 922 8.2.1 Usage of SDP H.263 options with SIP 924 This document does not specify actual SIP signaling. The decoder 925 send its preferred parameters and let the other end select according 926 to SIP procedures. This syntax may be sent, for example, with SIP 927 INVITE and corresponding status response (200 ok). Other SIP methods 928 may be used. 930 Codec options: (F,I,J,K,N,P,T) These characters exist only if the 931 sender of this SDP message is able or willing to decode those 932 options. 934 Picture sizes and MPI: 936 Supported picture sizes and their corresponding minimum picture 937 interval (MPI) information for H.263 can be combined. All picture 938 sizes can be advertised to the other party, or only some subset of 939 it. Terminal announces only those picture sizes (with their MPIs) 940 which it is willing to receive. For example, MPI=2 means that 941 maximum (decodeable) picture rate per second is about 15. 943 Parameters occurring first are the most preferred picture mode to be 944 received. 946 Example of the usage of these parameters: 948 CIF=4 QCIF=3 SQCIF=2 CUSTOM=360, 240, 2 950 This means that sender hopes to receive CIF picture size, which it 951 can decode at MPI=4. If that is not possible, then QCIF with MPI 952 value 3, if that is neither possible, then SQCIF with MPI value =2. 953 It is also allowed (but least preferred) to send custom picture sizes 954 (max 360x240) with MPI=2. Note that most encoders support at least 955 QCIF and CIF fixed resolutions and they are expected to be available 956 almost in every H.263 based video application. 958 MaxBR and BPP parameters: 960 > Both these parameters are useful in SIP. MaxBitRate is video 961 decoder property, hence it differs from SDP b : bandwidth-value 962 attribute which refers more to application's total bandwidth (an 963 application consists often of both audio and video). 965 > BitsPerPictureMaxKb is needed especially for decoder buffer size 966 estimation to reduce the probability of video buffer overflow. 968 Below is an example of H.263 SDP syntax in SIP message. 970 a=fmtp: xx CIF=4 QCIF=2 MaxBR=1000 F K=1 972 This means that the sender of this message can decode H.263 bit 973 stream with following options and parameters: Preferred resolution is 974 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 975 Maximum receivable bitrate is 100 kbit/s (1000*100 bit/s) and AP 976 and slicesInOrder-NonRect options can be used. 978 9. Security Considerations 980 RTP packets using the payload format defined in this specification 981 are subject to the security considerations discussed in the RTP 982 specification [RFC3550], and any appropriate RTP profile (for example 983 [RFC3551]). This implies that confidentiality of the media streams is 984 achieved by encryption. Because the data compression used with this 985 payload format is applied end-to-end, encryption may be performed 986 after compression so there is no conflict between the two operations. 988 A potential denial-of-service threat exists for data encodings using 989 compression techniques that have non-uniform receiver-end 990 computational load. The attacker can inject pathological datagrams 991 into the stream which are complex to decode and cause the receiver to 992 be overloaded. However, this encoding does not exhibit any 993 significant non-uniformity. 995 As with any IP-based protocol, in some circumstances a receiver may 996 be overloaded simply by the receipt of too many packets, either 997 desired or undesired. Network-layer authentication may be used to 998 discard packets from undesired sources, but the processing cost of 999 the authentication itself may be too high. In a multicast 1000 environment, pruning of specific sources may be implemented in future 1001 versions of IGMP [RFC2032] and in multicast routing protocols to 1002 allow a receiver to select which sources are allowed to reach it. 1004 A security review of this payload format found no additional 1005 considerations beyond those in the RTP specification. 1007 10. Acknowledgements 1009 This is to acknowledge the work done by Carsten Bormann from 1010 Universitaet Bremen and Linda Cline, Gim Deisher, Tom Gardos, 1011 Christian Maciocco, Donald Newell from Intel Corp. who co-authored 1012 RFC2429. 1014 I would also like to acknowledge the work of Petri Koskelainen from 1015 Nolia and Nermeen Ismail from Cisco who helped with drafting the text 1016 for the new MIME types. 1018 11. Requirements notation 1020 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1021 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1022 document are to be interpreted as described in RFC2119[RFC2119]. 1024 12. changes from RFC 2429> 1026 The changes from the RFC 2429 are: 1028 1. The H.263 1998 and 2000 MIME type are now in the payload 1029 specification. 1031 Added optional parameters to the H.263 MIME types 1033 Mandate the usage of RFC2429 for all H.263. RFC2190 payload format 1034 should be used only to interact with legacy systems. 1036 3. Editorial changes to be in line with RFC editing procedures 1038 Normative References 1040 [H263] International Telecommunications Union, "Video coding for 1041 low bit rate communication", ITU Recommendation H.263, 1042 March 1996. 1044 [H263P] International Telecommunications Union, "Video coding for 1045 low bit rate communication", ITU Recommendation H.263P, 1046 February 1998. 1048 [H263X] International Telecommunications Union, "Annex X: Profiles 1049 and levels definition", ITU Recommendation H.263AnxX, 1050 April 2001. 1052 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1053 Streams", RFC 2032, October 1996. 1055 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1056 Internet Mail Extensions (MIME) Part Four: Registration 1057 Procedures", BCP 13, RFC 2048, November 1996. 1059 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1060 Requirement Levels", BCP 14, RFC 2119, March 1997. 1062 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 1063 2190, September 1997. 1065 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1066 Protocol", RFC 2327, April 1998. 1068 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1069 Jacobson, "RTP: A Transport Protocol for Real-Time 1070 Applications", RFC 3550, July 2003. 1072 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1073 Video Conferences with Minimal Control", RFC 3551, July 1074 2003. 1076 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1077 Payload Formats", RFC 3555, July 2003. 1079 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1080 Audio-Visual Services over Packet Networks, Aberdeen, U.K. 1081 9/1997, September 1997. 1083 Authors' Addresses 1085 Joerg Ott 1086 Univ. Bremen 1088 Gary Sullivan 1089 Microsoft 1091 Stephan Wenger 1092 TU Berlin 1094 Chad Zhu 1095 Intel Corp. 1097 Roni Even 1098 Polycom 1099 94 Derech Em Hamoshavot 1100 Petach Tikva 49130 1101 Israel 1103 EMail: roni.even@polycom.co.il 1105 Intellectual Property Statement 1107 The IETF takes no position regarding the validity or scope of any 1108 intellectual property or other rights that might be claimed to 1109 pertain to the implementation or use of the technology described in 1110 this document or the extent to which any license under such rights 1111 might or might not be available; neither does it represent that it 1112 has made any effort to identify any such rights. Information on the 1113 IETF's procedures with respect to rights in standards-track and 1114 standards-related documentation can be found in BCP-11. Copies of 1115 claims of rights made available for publication and any assurances of 1116 licenses to be made available, or the result of an attempt made to 1117 obtain a general license or permission for the use of such 1118 proprietary rights by implementors or users of this specification can 1119 be obtained from the IETF Secretariat. 1121 The IETF invites any interested party to bring to its attention any 1122 copyrights, patents or patent applications, or other proprietary 1123 rights which may cover technology that may be required to practice 1124 this standard. Please address the information to the IETF Executive 1125 Director. 1127 Full Copyright Statement 1129 Copyright (C) The Internet Society (2003). All Rights Reserved. 1131 This document and translations of it may be copied and furnished to 1132 others, and derivative works that comment on or otherwise explain it 1133 or assist in its implementation may be prepared, copied, published 1134 and distributed, in whole or in part, without restriction of any 1135 kind, provided that the above copyright notice and this paragraph are 1136 included on all such copies and derivative works. However, this 1137 document itself may not be modified in any way, such as by removing 1138 the copyright notice or references to the Internet Society or other 1139 Internet organizations, except as needed for the purpose of 1140 developing Internet standards in which case the procedures for 1141 copyrights defined in the Internet Standards process must be 1142 followed, or as required to translate it into languages other than 1143 English. 1145 The limited permissions granted above are perpetual and will not be 1146 revoked by the Internet Society or its successors or assignees. 1148 This document and the information contained herein is provided on an 1149 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1150 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1151 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1152 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1153 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1155 Acknowledgment 1157 Funding for the RFC Editor function is currently provided by the 1158 Internet Society.