idnits 2.17.1 draft-ietf-avt-rfc2429-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1175. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 32 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 121 has weird spacing: '...the new optio...' == Line 731 has weird spacing: '...ameters into ...' -- 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 (September 14, 2004) is 7163 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 1082, 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: 10 errors (**), 0 flaws (~~), 6 warnings (==), 11 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: March 15, 2005 G. Sullivan 4 Microsoft 5 S. Wenger 6 TU Berlin 7 R. Even 8 Polycom 9 September 14, 2004 11 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video 12 (H.263+) 13 draft-ietf-avt-rfc2429-bis-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 15, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document describes a scheme to packetize an H.263 video stream 49 for transport using the Real-time Transport Protocol, RTP, with any 50 of the underlying protocols that carry RTP. 52 The document also describe the syntax and semantics of the SDP 53 parameters needed to support the H.263 video codec. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 62 3.2 Video Packet Structure . . . . . . . . . . . . . . . . . . 7 63 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 9 64 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . . 11 65 5.1 General H.263+ payload header . . . . . . . . . . . . . . 11 66 5.2 Video Redundancy Coding Header Extension . . . . . . . . . 12 67 6. Packetization schemes . . . . . . . . . . . . . . . . . . . . 15 68 6.1 Picture Segment Packets and Sequence Ending Packets 69 (P=1) . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1.1 Packets that begin with a Picture Start Code . . . . . 15 71 6.1.2 Packets that begin with GBSC or SSC . . . . . . . . . 16 72 6.1.3 Packets that Begin with an EOS or EOSBS Code . . . . . 17 73 6.2 Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . 17 74 7. Use of this payload specification . . . . . . . . . . . . . . 19 75 8. Payload Format Parameters . . . . . . . . . . . . . . . . . . 21 76 8.1 IANA Considerations . . . . . . . . . . . . . . . . . . . 21 77 8.1.1 Registration of MIME media type video/H263-1998 . . . 21 78 8.1.2 Registration of MIME media type video/H263-2000 . . . 24 79 8.2 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 25 80 8.2.1 Usage with the SDP Offer Answer Model . . . . . . . . 25 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 83 11. Changes from previous versions of the document . . . . . . . 29 84 11.1 changes from RFC 2429 . . . . . . . . . . . . . . . . . . 29 85 11.2 Changes from rfc2429-bis-00 . . . . . . . . . . . . . . . 29 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 88 12.2 Informative References . . . . . . . . . . . . . . . . . . . 31 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 90 Intellectual Property and Copyright Statements . . . . . . . . 32 92 1. Introduction 94 This document specifies an RTP payload header format applicable to 95 the transmission of video streams generated based on the 1998 and 96 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 97 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, 98 this format can also be used with the 1996 version of H.263 [H263], 99 and MUST be use by new implementations. This format replaces the 100 payload format in RFC 2190[RFC2190], which continues to be used by 101 some existing implementations, and may be useful for backward 102 compatibility. New implementations supporting H.263 MUST use the 103 payload format described in this document. 105 This document updates RFC2429. 107 1.1 Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119[RFC2119] and 112 indicate requirement levels for compliant RTP implementations. 114 2. New H.263 features 116 The 1998 version of ITU-T Recommendation H.263 added numerous coding 117 options to improve codec performance over the 1996 version. The 1998 118 version is referred to as H.263+ in this document. The 2000 version 119 is referred to as H.263++ in this document. 121 Among the new options, the ones with the biggest impact on the RTP 122 payload specification and the error resilience of the video content 123 are the slice structured mode, the independent segment decoding mode, 124 the reference picture selection mode, and the scalability mode. This 125 section summarizes the impact of these new coding options on 126 packetization. Refer to [H263P] for more information on coding 127 options. 129 The slice structured mode was added to H.263+ for three purposes: to 130 provide enhanced error resilience capability, to make the bitstream 131 more amenable to use with an underlying packet transport such as RTP, 132 and to minimize video delay. The slice structured mode supports 133 fragmentation at macroblock boundaries. 135 With the independent segment decoding (ISD) option, a video picture 136 frame is broken into segments and encoded in such a way that each 137 segment is independently decodable. Utilizing ISD in a lossy network 138 environment helps to prevent the propagation of errors from one 139 segment of the picture to others. 141 The reference picture selection mode allows the use of an older 142 reference picture rather than the one immediately preceding the 143 current picture. Usually, the last transmitted frame is implicitly 144 used as the reference picture for inter-frame prediction. If the 145 reference picture selection mode is used, the data stream carries 146 information on what reference frame should be used, indicated by the 147 temporal reference as an ID for that reference frame. The reference 148 picture selection mode may be used with or without a back channel, 149 which provides information to the encoder about the internal status 150 of the decoder. However, no special provision is made herein for 151 carrying back channel information. The Extended RTP Profile for 152 RTCP-based Feedback [AVPF] MAY be used as a back channel mechanism. 154 H.263+ also includes bitstream scalability as an optional coding 155 mode. Three kinds of scalability are defined: temporal, signal-to- 156 noise ratio (SNR), and spatial scalability. Temporal scalability is 157 achieved via the disposable nature of bi-directionally predicted 158 frames, or B-frames. (A low-delay form of temporal scalability known 159 as P-picture temporal scalability can also be achieved by using the 160 reference picture selection mode described in the previous 161 paragraph.) SNR scalability permits refinement of encoded video 162 frames, thereby improving the quality (or SNR). Spatial scalability 163 is similar to SNR scalability except the refinement layer is twice 164 the size of the base layer in the horizontal dimension, vertical 165 dimension, or both. 167 3. Usage of RTP 169 When transmitting H.263+ video streams over the Internet, the output 170 of the encoder can be packetized directly. All the bits resulting 171 from the bitstream including the fixed length codes and variable 172 length codes will be included in the packet, with the only exception 173 being that when the payload of a packet begins with a Picture, GOB, 174 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 175 the start code are removed and replaced by setting an indicator bit 176 in the payload header. 178 For H.263+ bitstreams coded with temporal, spatial, or SNR 179 scalability, each layer may be transported to a different network 180 address. More specifically, each layer may use a unique IP address 181 and port number combination. The temporal relations between layers 182 shall be expressed using the RTP timestamp so that they can be 183 synchronized at the receiving ends in multicast or unicast 184 applications. 186 The H.263+ video stream will be carried as payload data within RTP 187 packets. A new H.263+ payload header is defined in section 4. This 188 section defines the usage of the RTP fixed header and H.263+ video 189 packet structure. 191 3.1 RTP Header Usage 193 Each RTP packet starts with a fixed RTP header. The following fields 194 of the RTP fixed header are used for H.263+ video streams: 196 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 197 the current packet carries the end of current frame, and is 0 198 otherwise. 200 Payload Type (PT): According to RFC 3551[RFC3551] table 5, a Dynamic 201 Payload Type SHALL be used to specify the H.263+ and H.263++ video 202 payload formats. 204 Timestamp: The RTP Timestamp encodes the sampling instance of the 205 first video frame data contained in the RTP data packet. The RTP 206 timestamp shall be the same on successive packets if a video frame 207 occupies more than one packet. In a multilayer scenario, all 208 pictures corresponding to the same temporal reference should use the 209 same timestamp. If temporal scalability is used (if B-frames are 210 present), the timestamp may not be monotonically increasing in the 211 RTP stream. If B-frames are transmitted on a separate layer and 212 address, they must be synchronized properly with the reference 213 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 214 information on required transmission order to a decoder. For an 215 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 216 the same as that of the RTP payload for H.261 stream [RFC2032]. 217 Since both the H.263+ data and the RTP header contain time 218 information, it is required that those timing information run 219 synchronously. That is, both the RTP timestamp and the temporal 220 reference (TR in the picture header of H.263) should carry the same 221 relative timing information. Any H.263+ picture clock frequency can 222 be expressed as 1800000/(cd*cf) source pictures per second, in which 223 cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using 224 the 90 kHz clock of the RTP timestamp, the time increment between 225 each coded H.263+ picture should therefore be a integer multiple of 226 (cd*cf)/20. This will always be an integer for any "reasonable" 227 picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 228 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for 229 the computer display update rates of 60, 72 and 75 Hz, respectively). 230 For RTP packetization of hypothetical H.263+ bitstreams using 231 "unreasonable" custom picture clock frequencies, mathematical 232 rounding could become necessary for generating the RTP timestamps. 234 3.2 Video Packet Structure 236 A section of an H.263+ compressed bitstream is carried as a payload 237 within each RTP packet. For each RTP packet, the RTP header is 238 followed by an H.263+ payload header, which is followed by a number 239 of bytes of a standard H.263+ compressed bitstream. The size of the 240 H.263+ payload header is variable depending on the payload involved 241 as detailed in the section 4. The layout of the RTP H.263+ video 242 packet is shown as: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | RTP Header 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | H.263+ Payload Header 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | H.263+ Compressed Data Stream 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Any H.263+ start codes can be byte aligned by an encoder by using the 255 stuffing mechanisms of H.263+. As specified in H.263+, picture, 256 slice, and EOSBS starts codes shall always be byte aligned, and GOB 257 and EOS start codes may be byte aligned. For packetization purposes, 258 GOB start codes should be byte aligned; however, since this is not 259 required in H.263+, there may be some cases where GOB start codes are 260 not aligned, such as when transmitting existing content, or when 261 using H.263 encoders that do not support GOB start code alignment. 263 In this case, follow-on packets (see section 5.2) should be used for 264 packetization. 266 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 267 with 16 zero-valued bits. If a start code is byte aligned and it 268 occurs at the beginning of a packet, these two bytes shall be removed 269 from the H.263+ compressed data stream in the packetization process 270 and shall instead be represented by setting a bit (the P bit) in the 271 payload header. 273 4. Design Considerations 275 The goals of this payload format are to specify an efficient way of 276 encapsulating an H.263+ standard compliant bitstream and to enhance 277 the resiliency towards packet losses. Due to the large number of 278 different possible coding schemes in H.263+, a copy of the picture 279 header with configuration information is inserted into the payload 280 header when appropriate. The use of that copy of the picture header 281 along with the payload data can allow decoding of a received packet 282 even in such cases in which another packet containing the original 283 picture header becomes lost. 285 There are a few assumptions and constraints associated with this 286 H.263+ payload header design. The purpose of this section is to 287 point out various design issues and also to discuss several coding 288 options provided by H.263+ that may impact the performance of 289 network-based H.263+ video. 291 o The optional slice structured mode described in Annex K of H.263+ 292 [H263P] enables more flexibility for packetization. Similar to a 293 picture segment that begins with a GOB header, the motion vector 294 predictors in a slice are restricted to reside within its boundaries. 295 However, slices provide much greater freedom in the selection of the 296 size and shape of the area which is represented as a distinct 297 decodable region. In particular, slices can have a size which is 298 dynamically selected to allow the data for each slice to fit into a 299 chosen packet size. Slices can also be chosen to have a rectangular 300 shape which is conducive for minimizing the impact of errors and 301 packet losses on motion compensated prediction. For these reasons, 302 the use of the slice structured mode is strongly recommended for any 303 applications used in environments where significant packet loss 304 occurs. 306 o In non-rectangular slice structured mode, only complete slices 307 should be included in a packet. In other words, slices should not be 308 fragmented across packet boundaries. The only reasonable need for a 309 slice to be fragmented across packet boundaries is when the encoder 310 which generated the H.263+ data stream could not be influenced by an 311 awareness of the packetization process (such as when sending H.263+ 312 data through a network other than the one to which the encoder is 313 attached, as in network gateway implementations). Optimally, each 314 packet will contain only one slice. 316 o The independent segment decoding (ISD) described in Annex R of 317 [H263P] prevents any data dependency across slice or GOB boundaries 318 in the reference picture. It can be utilized to further improve 319 resiliency in high loss conditions. 321 o If ISD is used in conjunction with the slice structure, the 322 rectangular slice submode shall be enabled and the dimensions and 323 quantity of the slices present in a frame shall remain the same 324 between each two intra-coded frames (I-frames), as required in 325 H.263+. The individual ISD segments may also be entirely intra coded 326 from time to time to realize quick error recovery without adding the 327 latency time associated with sending complete INTRA- pictures. 329 o When the slice structure is not applied, the insertion of a 330 (preferably byte-aligned) GOB header can be used to provide resync 331 boundaries in the bitstream, as the presence of a GOB header 332 eliminates the dependency of motion vector prediction across GOB 333 boundaries. These resync boundaries provide natural locations for 334 packet payload boundaries. 336 o H.263+ allows picture headers to be sent in an abbreviated form in 337 order to prevent repetition of overhead information that does not 338 change from picture to picture. For resiliency, sending a complete 339 picture header for every frame is often advisable. This means that 340 (especially in cases with high packet loss probability in which 341 picture header contents are not expected to be highly predictable), 342 the sender may find it advisable to always set the subfield UFEP in 343 PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263P] for 344 the definition of the UFEP and PLUSPTYPE fields). 346 o In a multi-layer scenario, each layer may be transmitted to a 347 different network address. The configuration of each layer such as 348 the enhancement layer number (ELNUM), reference layer number (RLNUM), 349 and scalability type should be determined at the start of the session 350 and should not change during the course of the session. 352 o All start codes can be byte aligned, and picture, slice, and EOSBS 353 start codes are always byte aligned. The boundaries of these 354 syntactical elements provide ideal locations for placing packet 355 boundaries. 357 o We assume that a maximum Picture Header size of 504 bits is 358 sufficient. The syntax of H.263+ does not explicitly prohibit larger 359 picture header sizes, but the use of such extremely large picture 360 headers is not expected. 362 5. H.263+ Payload Header 364 For H.263+ video streams, each RTP packet carries only one H.263+ 365 video packet. The H.263+ payload header is always present for each 366 H.263+ video packet. The payload header is of variable length. A 16 367 bit field of the basic payload header may be followed by an 8 bit 368 field for Video Redundancy Coding (VRC) information, and/or by a 369 variable length extra picture header as indicated by PLEN. These 370 optional fields appear in the order given above when present. 372 If an extra picture header is included in the payload header, the 373 length of the picture header in number of bytes is specified by PLEN. 374 The minimum length of the payload header is 16 bits, corresponding to 375 PLEN equal to 0 and no VRC information present. 377 The remainder of this section defines the various components of the 378 RTP payload header. Section five defines the various packet types 379 that are used to carry different types of H.263+ coded data, and 380 section six summarizes how to distinguish between the various packet 381 types. 383 5.1 General H.263+ payload header 385 The H.263+ payload header is structured as follows: 387 0 1 388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | RR |P|V| PLEN |PEBIT| 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 RR: 5 bits 395 Reserved bits. Shall be zero. MUST be ignored by receivers 397 P: 1 bit 399 Indicates the picture start or a picture segment (GOB/Slice) start or 400 a video sequence end (EOS or EOSBS). Two bytes of zero bits then 401 have to be prefixed to the payload of such a packet to compose a 402 complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the 403 omission of the two first bytes of the start codes, thus improving 404 the compression ratio. 406 V: 1 bit 408 Indicates the presence of an 8 bit field containing information for 409 Video Redundancy Coding (VRC), which follows immediately after the 410 initial 16 bits of the payload header if present. For syntax and 411 semantics of that 8 bit VRC field see section 4.2. 413 PLEN: 6 bits 415 Length in bytes of the extra picture header. If no extra picture 416 header is attached, PLEN is 0. If PLEN>0, the extra picture header 417 is attached immediately following the rest of the payload header. 418 Note the length reflects the omission of the first two bytes of the 419 picture start code (PSC). See section 5.1. 421 PEBIT: 3 bits 423 Indicates the number of bits that shall be ignored in the last byte 424 of the picture header. If PLEN is not zero, the ignored bits shall 425 be the least significant bits of the byte. If PLEN is zero, then 426 PEBIT shall also be zero. 428 5.2 Video Redundancy Coding Header Extension 430 Video Redundancy Coding (VRC) is an optional mechanism intended to 431 improve error resilience over packet networks. Implementing VRC in 432 H.263+ will require the Reference Picture Selection option described 433 in Annex N of [H263P]. By having multiple "threads" of independently 434 inter-frame predicted pictures, damage of individual frame will cause 435 distortions only within its own thread but leave the other threads 436 unaffected. From time to time, all threads converge to a so-called 437 sync frame (an INTRA picture or a non-INTRA picture which is 438 redundantly represented within multiple threads); from this sync 439 frame, the independent threads are started again. For more 440 information on codec support for VRC see [Vredun]. 442 P-picture temporal scalability is another use of the reference 443 picture selection mode and can be considered a special case of VRC in 444 which only one copy of each sync frame may be sent. It offers a 445 thread-based method of temporal scalability without the increased 446 delay caused by the use of B pictures. In this use, sync frames sent 447 in the first thread of pictures are also used for the prediction of a 448 second thread of pictures which fall temporally between the sync 449 frames to increase the resulting frame rate. In this use, the 450 pictures in the second thread can be discarded in order to obtain a 451 reduction of bit rate or decoding complexity without harming the 452 ability to decode later pictures. A third or more threads can also 453 be added as well, but each thread is predicted only from the sync 454 frames (which are sent at least in thread 0) or from frames within 455 the same thread. 457 While a VRC data stream is - like all H.263+ data - totally self- 458 contained, it may be useful for the transport hierarchy 459 implementation to have knowledge about the current damage status of 460 each thread. On the Internet, this status can easily be determined 461 by observing the marker bit, the sequence number of the RTP header, 462 and the thread-id and a circling "packet per thread" number. The 463 latter two numbers are coded in the VRC header extension. 465 The format of the VRC header extension is as follows: 467 0 1 2 3 4 5 6 7 468 +-+-+-+-+-+-+-+-+ 469 | TID | Trun |S| 470 +-+-+-+-+-+-+-+-+ 472 TID: 3 bits 474 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 475 data will use as reference information only sync frames or frames 476 within the same thread. By convention, thread 0 is expected to be 477 the "canonical" thread, which is the thread from which the sync frame 478 should ideally be used. In the case of corruption or loss of the 479 thread 0 representation, a representation of the sync frame with a 480 higher thread number can be used by the decoder. Lower thread 481 numbers are expected to contain equal or better representations of 482 the sync frames than higher thread numbers in the absence of data 483 corruption or loss. See [Vredun] for a detailed discussion of VRC. 485 Trun: 4 bits 487 Monotonically increasing (modulo 16) 4 bit number counting the packet 488 number within each thread. 490 S: 1 bit 492 A bit that indicates that the packet content is for a sync frame. An 493 encoder using VRC may send several representations of the same "sync" 494 picture, in order to ensure that regardless of which thread of 495 pictures is corrupted by errors or packet losses, the reception of at 496 least one representation of a particular picture is ensured (within 497 at least one thread). The sync picture can then be used for the 498 prediction of any thread. If packet losses have not occurred, then 499 the sync frame contents of thread 0 can be used and those of other 500 threads can be discarded (and similarly for other threads). Thread 0 501 is considered the "canonical" thread, the use of which is preferable 502 to all others. The contents of packets having lower thread numbers 503 shall be considered as having a higher processing and delivery 504 priority than those with higher thread numbers. Thus packets having 505 lower thread numbers for a given sync frame shall be delivered first 506 to the decoder under loss-free and low-time-jitter conditions, which 507 will result in the discarding of the sync contents of the 508 higher-numbered threads as specified in Annex N of [H263P]. 510 6. Packetization schemes 512 6.1 Picture Segment Packets and Sequence Ending Packets (P=1) 514 A picture segment packet is defined as a packet that starts at the 515 location of a Picture, GOB, or slice start code in the H.263+ data 516 stream. This corresponds to the definition of the start of a video 517 picture segment as defined in H.263+. For such packets, P=1 always. 519 An extra picture header can sometimes be attached in the payload 520 header of such packets. Whenever an extra picture header is attached 521 as signified by PLEN>0, only the last six bits of its picture start 522 code, '100000', are included in the payload header. A complete 523 H.263+ picture header with byte aligned picture start code can be 524 conveniently assembled on the receiving end by prepending the sixteen 525 leading '0' bits. 527 When PLEN>0, the end bit position corresponding to the last byte of 528 the picture header data is indicated by PEBIT. The actual bitstream 529 data shall begin on an 8-bit byte boundary following the payload 530 header. 532 A sequence ending packet is defined as a packet that starts at the 533 location of an EOS or EOSBS code in the H.263+ data stream. This 534 delineates the end of a sequence of H.263+ video data (more H.263+ 535 video data may still follow later, however, as specified in ITU-T 536 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 538 The optional header extension for VRC may or may not be present as 539 indicated by the V bit flag. 541 6.1.1 Packets that begin with a Picture Start Code 543 Any packet that contains the whole or the start of a coded picture 544 shall start at the location of the picture start code (PSC), and 545 should normally be encapsulated with no extra copy of the picture 546 header. In other words, normally PLEN=0 in such a case. However, if 547 the coded picture contains an incomplete picture header (UFEP = 548 "000"), then a representation of the complete (UFEP = "001") picture 549 header may be attached during packetization in order to provide 550 greater error resilience. Thus, for packets that start at the 551 location of a picture start code, PLEN shall be zero unless both of 552 the following conditions apply: 554 1) The picture header in the H.263+ bitstream payload is incomplete 555 (PLUSPTYPE present and UFEP="000"), and 557 2) The additional picture header which is attached is not incomplete 558 (UFEP="001"). 560 A packet which begins at the location of a Picture, GOB, slice, EOS, 561 or EOSBS start code shall omit the first two (all zero) bytes from 562 the H.263+ bitstream, and signify their presence by setting P=1 in 563 the payload header. 565 Here is an example of encapsulating the first packet in a frame 566 (without an attached redundant complete picture header): 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | first two 0 bytes of the PSC 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 6.1.2 Packets that begin with GBSC or SSC 578 For a packet that begins at the location of a GOB or slice start 579 code, PLEN may be zero or may be nonzero, depending on whether a 580 redundant picture header is attached to the packet. In environments 581 with very low packet loss rates, or when picture header contents are 582 very seldom likely to change (except as can be detected from the GFID 583 syntax of H.263+), a redundant copy of the picture header is not 584 required. However, in less ideal circumstances a redundant picture 585 header should be attached for enhanced error resilience, and its 586 presence is indicated by PLEN>0. 588 Assuming a PLEN of 9 and P=1, below is an example of a packet that 589 begins with a byte aligned GBSC or a SSC: 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | starting with TR, PTYPE ... | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | ... | bitstream | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | data starting with GBSC/SSC without its first two 0 bytes 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Notice that only the last six bits of the picture start code, 604 '100000', are included in the payload header. A complete H.263+ 605 picture header with byte aligned picture start code can be 606 conveniently assembled if needed on the receiving end by prepending 607 the sixteen leading '0' bits. 609 6.1.3 Packets that Begin with an EOS or EOSBS Code 611 For a packet that begins with an EOS or EOSBS code, PLEN shall be 612 zero, and no Picture, GOB, or Slice start codes shall be included 613 within the same packet. As with other packets beginning with start 614 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 615 beginning of the packet shall be omitted, and their presence shall be 616 indicated by setting the P bit to 1 in the payload header. 618 System designers should be aware that some decoders may interpret the 619 loss of a packet containing only EOS or EOSBS information as the loss 620 of essential video data and may thus respond by not displaying some 621 subsequent video information. Since EOS and EOSBS codes do not 622 actually affect the decoding of video pictures, they are somewhat 623 unnecessary to send at all. Because of the danger of 624 misinterpretation of the loss of such a packet (which can be detected 625 by the sequence number), encoders are generally to be discouraged 626 from sending EOS and EOSBS. 628 Below is an example of a packet containing an EOS code: 630 0 1 2 631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 6.2 Encapsulating Follow-On Packet (P=0) 638 A Follow-on packet contains a number of bytes of coded H.263+ data 639 which does not start at a synchronization point. That is, a Follow- 640 On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS 641 header, and it may or may not start at a macroblock boundary. Since 642 Follow-on packets do not start at synchronization points, the data at 643 the beginning of a follow-on packet is not independently decodable. 644 For such packets, P=0 always. If the preceding packet of a Follow-on 645 packet got lost, the receiver may discard that Follow-on packet as 646 well as all other following Follow-on packets. Better behavior, of 647 course, would be for the receiver to scan the interior of the packet 648 payload content to determine whether any start codes are found in the 649 interior of the packet which can be used as resync points. The use 650 of an attached copy of a picture header for a follow-on packet is 651 useful only if the interior of the packet or some subsequent follow- 652 on packet contains a resync code such as a GOB or slice start code. 653 PLEN>0 is allowed, since it may allow resync in the interior of the 654 packet. The decoder may also be resynchronized at the next segment 655 or picture packet. 657 Here is an example of a follow-on packet (with PLEN=0): 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 662 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 665 7. Use of this payload specification 667 There is no syntactical difference between a picture segment packet 668 and a Follow-on packet, other than the indication P=1 for picture 669 segment or sequence ending packets and P=0 for Follow-on packets. 670 See the following for a summary of the entire packet types and ways 671 to distinguish between them. 673 It is possible to distinguish between the different packet types by 674 checking the P bit and the first 6 bits of the payload along with the 675 header information. The following table shows the packet type for 676 permutations of this information (see also the picture/GOB/Slice 677 header descriptions in H.263+ for details): 679 -------------+--------------+----------------------+---------------- 680 First 6 bits | P-Bit | PLEN | Packet | Remarks 681 of Payload |(payload hdr.)| | 682 -------------+--------------+----------------------+---------------- 683 100000 | 1 | 0 | Picture | Typical Picture 684 100000 | 1 | > 0 | Picture | Note UFEP 685 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 686 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 687 Xxxxxx | 0 | 0 | Follow-on | 688 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 689 -------------+--------------+----------------------+---------------- 691 The details regarding the possible values of the five bit Group 692 Number (GN) field which follows the initial "1" bit when the P-bit is 693 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 694 of [H263P]. 696 As defined in this specification, every start of a coded frame (as 697 indicated by the presence of a PSC) has to be encapsulated as a 698 picture segment packet. If the whole coded picture fits into one 699 packet of reasonable size (which is dependent on the connection 700 characteristics), this is the only type of packet that may need to be 701 used. Due to the high compression ratio achieved by H.263+ it is 702 often possible to use this mechanism, especially for small spatial 703 picture formats such as QCIF and typical Internet packet sizes around 704 1500 bytes. 706 If the complete coded frame does not fit into a single packet, two 707 different ways for the packetization may be chosen. In case of very 708 low or zero packet loss probability, one or more Follow-on packets 709 may be used for coding the rest of the picture. Doing so leads to 710 minimal coding and packetization overhead as well as to an optimal 711 use of the maximal packet size, but does not provide any added error 712 resilience. 714 The alternative is to break the picture into reasonably small 715 partitions - called Segments - (by using the Slice or GOB mechanism), 716 that do offer synchronization points. By doing so and using the 717 Picture Segment payload with PLEN>0, decoding of the transmitted 718 packets is possible even in such cases in which the Picture packet 719 containing the picture header was lost (provided any necessary 720 reference picture is available). Picture Segment packets can also be 721 used in conjunction with Follow-on packets for large segment sizes. 723 8. Payload Format Parameters 725 This section updates the H.263(1998) and H.263 (2000) media types 726 described in RFC3555 [RFC3555]. 728 This section specifies optional parameters that MAY be used to select 729 optional features of the H.263 codec. The parameters are specified 730 here as part of the MIME subtype registration for the ITU-T H.263 731 codec. A mapping of the parameters into the Session Description 732 Protocol (SDP) [RFC2327] is also provided for those applications 733 that use SDP. Multiple parameters SHOULD be expressed as a MIME 734 media type string, in the form of a semicolon separated list of 735 parameter=value pairs 737 8.1 IANA Considerations 739 This section describes the MIME types and names associated with this 740 payload format. The section updates the previous registered version 741 in RFC 3555 [RFC3555]. The section registers the MIME types, as per 742 RFC2048[RFC2048] 744 8.1.1 Registration of MIME media type video/H263-1998 746 MIME media type name: video 748 MIME subtype name: H263-1998 750 Required parameters: None 752 Optional parameters: 754 SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF 755 resolution. Permissible value are integer values from 1 to 32, which 756 correspond to a maximum frame rate of 29.97/ the specified value 757 frames per second. 759 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 760 resolution. Permissible value are integer values from 1 to 32, which 761 correspond to a maximum frame rate of 29.97/ the specified value 762 frames per second. 764 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 765 resolution. Permissible value are integer values from 1 to 32, which 766 correspond to a maximum frame rate of 29.97/ the specified value 767 frames per second. 769 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 770 resolution. Permissible value are integer values from 1 to 32, which 771 correspond to a maximum frame rate of 29.97/ the specified value 772 frames per second. 774 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 775 resolution. Permissible value are integer values from 1 to 32, which 776 correspond to a maximum frame rate of 29.97/ the specified value 777 frames per second. 779 CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom 780 defined resolution. The custom parameter receives three comma 781 separated values Xmax , Ymax and MPI. The Xmax and Ymax parameters 782 describe the number of pixels in the X and Y axis and must be evenly 783 divisable by 4. The permissible value for MPI, are integer values 784 from 1 to 32, which correspond to a maximum frame rate of 29.97/ the 785 specified value. 787 A system that declares support of a specific MPI for one of the 788 resolutions SHALL also implicitly support a lower resolution with the 789 same MPI. 791 A list of optional annexes specifies which annexes of H.263 are 792 supported. The optional annexes are defined as part of H263-1998, 793 H263-2000. Annex X of H.263-2000 defines profiles which group 794 annexes for specific applications. A system that support a specific 795 annex SHALL specify it support using the optional parameters. 797 The allowed optional parameters for the annexes are "F", "I", "J", 798 "T" which do not get any values and "K", "N" and "P". 800 "K" can receive one of four values 1-4: 802 1: - Slices In Order-Non Rectangular 804 2: - Slices In Order-Rectangular 806 3: - Slices Not Ordered - Non Rectangular 808 4: - Slices Not Ordered - Rectangular 810 "N" - Reference Picture Selection mode - Four numeric choices (1-4) 811 are available representing the following modes: 813 1: NEITHER: In which no back-channel data is returned from the 814 decoder to the encoder. 816 2: ACK: In which the decoder returns only acknowledgment messages. 818 3: NACK: In which the decoder returns only non-acknowledgment 819 messages 821 4: ACK+NACK: In which the decoder returns both acknowledgment and 822 non-acknowledgment messages. 824 No special provision is made herein for carrying back channel 825 information. The Extended RTP Profile for RTCP-based Feedback [AVPF] 826 MAY be used as a back channel mechanism. 828 "P" - Reference Picture Resampling with the following submodes 829 represented as a number fro 1 to 4: 831 1: dynamicPictureResizingByFour 833 2: dynamicPictureResizingBySixteenthPel 835 3: dynamicWarpingHalfPel 837 4: dynamicWarpingSixteenthPel 839 Example: P=1,3 841 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height ratio 842 by two colon separated integers between 0 and 255. Default ratio is 843 12:11 if not otherwise specified. 845 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a floating 846 point value. Default value is 29.97 Hz. 848 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 849 bits allowed to represent a single picture. If this parameter is not 850 present, then the default value, based on the maximum supported 851 resolution, is used. BPP is integer value between 0 and 65536. 853 HRD - Hypothetical Reference Decoder: See annex B of H.263 854 specification[H263P]. 856 Encoding considerations: 858 This type is only defined for transfer via RTP [RFC3550] 860 Security considerations: See Section 9 862 Interoperability considerations: These are receiver options, current 863 implementations will not send any optional parameters in their SDP. 864 They will ignore the optional parameters and will encode the H.263 865 stream without any of the annexes. Most decoders support at least 866 QCIF and CIF fixed resolutions and they are expected to be available 867 almost in every H.263 based video application. 869 Published specification: RFC yyy ( This RFC) 871 Applications which use this media type: 873 Audio and video streaming and conferencing tools. 875 Additional information: none 877 Person and email address to contact for further information : 879 Roni Even: roni.even@polycom.co.il 881 Intended usage: COMMON 883 Author/Change controller: 885 Roni Even 887 8.1.2 Registration of MIME media type video/H263-2000 889 MIME media type name: video 891 MIME subtype name: H263-2000 893 Required parameters: None 895 Optional parameters: 897 The optional parameters of the H263-1998 type MAY be used with this 898 MIME subtype. Specific optional parameters that may be used with the 899 H263-2000 type are: 901 PROFILE: H.263 profile number, in the range 0 through 10, specifying 902 the supported H.263 annexes/subparts based on H.263 annex X. 904 LEVEL: Level of bitstream operation, in the range 0 through 100, 905 specifying the level of computational complexity of the decoding 906 process. 908 A system that specifies support of a PROFILE MUST specify the 909 supported LEVEL. 911 INTERLACE: Interlaced or 60 fields indicates the support for 912 interlace display mode. 914 Encoding considerations: 916 This type is only defined for transfer via RTP [RFC3550] 918 Security considerations: See Section 9 920 Interoperability considerations: The optional parameters PROFILE and 921 LEVEL SHALL NOT be used with any of the other optional parameters. 923 Published specification: RFC yyy 925 Applications which use this media type: 927 Audio and video streaming and conferencing tools. 929 Additional information: none 931 Person and email address to contact for further information : 933 Roni Even: roni.even@polycom.co.il 935 Intended usage: COMMON 937 Author/Change controller: 939 Roni Even 941 8.2 SDP Parameters 943 The MIME media types video/H263-1998 and video/H263-2000 are mapped 944 to fields in the Session Description Protocol (SDP) as follows: 946 o The media name in the "m=" line of SDP MUST be video. 948 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 949 or H263-2000 (the MIME subtype). 951 o The clock rate in the "a=rtpmap" line MUST be 90000. 953 o The optional parameters if any, MUST be included in the "a=fmtp" 954 line of SDP. These parameters are expressed as a MIME media type 955 string, in the form of a semicolon separated list of parameter=value 956 pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used 957 with any of the other optional parameters. 959 8.2.1 Usage with the SDP Offer Answer Model 961 When offering H.263 over RTP using SDP in an Offer/Answer 962 model[RFC3264] the following considerations are necessary. 964 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 965 the sender of this SDP message is able to decode those options. 966 These options are receiver's capability even when send in a 967 "sendonly" offer. 969 Picture sizes and MPI: 971 Supported picture sizes and their corresponding minimum picture 972 interval (MPI) information for H.263 can be combined. All picture 973 sizes can be advertised to the other party, or only a subset of it. 974 Terminal announces only those picture sizes (with their MPIs) which 975 it is willing to receive. For example, MPI=2 means that maximum 976 (decodeable) picture rate per second is about 15. 978 If the receiver does not specify the picture size /MPI optional 979 parameter then it SHOULD be ready to receive QCIF resolution with 980 MPI=1. 982 Parameters offered first are the most preferred picture mode to be 983 received. 985 Example of the usage of these parameters: 987 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 989 This means that encoder SHOULD send CIF picture size, which it can 990 decode at MPI=4. If that is not possible, then QCIF with MPI value 991 3, if neither are possible, then SQCIF with MPI value=2. The 992 receiver is able of (but least preferred) decoding custom picture 993 sizes (max 360x240) with MPI=2. Note that most decoders support at 994 least QCIF and CIF fixed resolutions and they are expected to be 995 available almost in every H.263 based video application. 997 Below is an example of H.263 SDP in an offer. 999 a=fmtp:xx CIF=4;QCIF=2;F;K=1 1001 This means that the sender of this message can decode H.263 bit 1002 stream with following options and parameters: Preferred resolution is 1003 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 1004 AP and slicesInOrder-NonRect options MAY be used. 1006 9. Security Considerations 1008 RTP packets using the payload format defined in this specification 1009 are subject to the security considerations discussed in the RTP 1010 specification [RFC3550], and any appropriate RTP profile (for example 1011 [RFC3551]). This implies that confidentiality of the media streams 1012 is achieved by encryption. Because the data compression used with 1013 this payload format is applied end-to-end, encryption may be 1014 performed after compression so there is no conflict between the two 1015 operations. 1017 A potential denial-of-service threat exists for data encoding using 1018 compression techniques that have non-uniform receiver-end 1019 computational load. The attacker can inject pathological datagrams 1020 into the stream which are complex to decode and cause the receiver to 1021 be overloaded. The usage of authentication of at least the RTP 1022 packet is RECOMMENDED 1024 As with any IP-based protocol, in some circumstances a receiver may 1025 be overloaded simply by the receipt of too many packets, either 1026 desired or undesired. Network-layer authentication may be used to 1027 discard packets from undesired sources, but the processing cost of 1028 the authentication itself may be too high. In a multicast 1029 environment, pruning of specific sources may be implemented in future 1030 versions of IGMP [RFC2032] and in multicast routing protocols to 1031 allow a receiver to select which sources are allowed to reach it. 1033 A security review of this payload format found no additional 1034 considerations beyond those in the RTP specification. 1036 10. Acknowledgements 1038 This is to acknowledge the work done by Carsten Bormann from 1039 Universitaet Bremen and Chad Zhu, Linda Cline, Gim Deisher, Tom 1040 Gardos, Christian Maciocco, Donald Newell from Intel Corp. who 1041 co-authored RFC2429. 1043 I would also like to acknowledge the work of Petri Koskelainen from 1044 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1045 for the new MIME types. 1047 11. Changes from previous versions of the document 1049 11.1 changes from RFC 2429 1051 The changes from the RFC 2429 are: 1053 1. The H.263 1998 and 2000 MIME type are now in the payload 1054 specification. 1056 2. Added optional parameters to the H.263 MIME types 1058 3. Mandate the usage of RFC2429 for all H.263. RFC2190 payload 1059 format should be used only to interact with legacy systems. 1061 4. Editorial changes to be in line with RFC editing procedures 1063 11.2 Changes from rfc2429-bis-00 1065 1. Changed from space separted parameters to semi colon acording to 1066 the AVT guidelines 1068 2. Took out the MaxBR optional parameter. 1070 12. References 1072 12.1 Normative References 1074 [H263] International Telecommunications Union, "Video coding for 1075 low bit rate communication", ITU Recommendation H.263, 1076 March 1996. 1078 [H263P] International Telecommunications Union, "Video coding for 1079 low bit rate communication", ITU Recommendation H.263P, 1080 February 1998. 1082 [H263X] International Telecommunications Union, "Annex X: Profiles 1083 and levels definition", ITU Recommendation H.263AnxX, 1084 April 2001. 1086 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1087 Streams", RFC 2032, October 1996. 1089 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1090 Internet Mail Extensions (MIME) Part Four: Registration 1091 Procedures", BCP 13, RFC 2048, November 1996. 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 1097 2190, September 1997. 1099 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1100 Protocol", RFC 2327, April 1998. 1102 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1103 with Session Description Protocol (SDP)", RFC 3264, June 1104 2002. 1106 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1107 Jacobson, "RTP: A Transport Protocol for Real-Time 1108 Applications", STD 64, RFC 3550, July 2003. 1110 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1111 Video Conferences with Minimal Control", STD 65, RFC 3551, 1112 July 2003. 1114 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1115 Payload Formats", RFC 3555, July 2003. 1117 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1119 Audio-Visual Services over Packet Networks, Aberdeen, U.K. 1120 9/1997, September 1997. 1122 12.2 Informative References 1124 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1125 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1126 January 2004. 1128 Authors' Addresses 1130 Joerg Ott 1131 Univ. Bremen 1133 EMail: jo@acm.org 1135 Gary Sullivan 1136 Microsoft 1138 EMail: garysull@windows.microsoft.com 1140 Stephan Wenger 1141 TU Berlin 1143 EMail: stewe@cs.tu-berlin.de 1145 Roni Even 1146 Polycom 1147 94 Derech Em Hamoshavot 1148 Petach Tikva 49130 1149 Israel 1151 EMail: roni.even@polycom.co.il 1153 Intellectual Property Statement 1155 The IETF takes no position regarding the validity or scope of any 1156 Intellectual Property Rights or other rights that might be claimed to 1157 pertain to the implementation or use of the technology described in 1158 this document or the extent to which any license under such rights 1159 might or might not be available; nor does it represent that it has 1160 made any independent effort to identify any such rights. Information 1161 on the procedures with respect to rights in RFC documents can be 1162 found in BCP 78 and BCP 79. 1164 Copies of IPR disclosures made to the IETF Secretariat and any 1165 assurances of licenses to be made available, or the result of an 1166 attempt made to obtain a general license or permission for the use of 1167 such proprietary rights by implementers or users of this 1168 specification can be obtained from the IETF on-line IPR repository at 1169 http://www.ietf.org/ipr. 1171 The IETF invites any interested party to bring to its attention any 1172 copyrights, patents or patent applications, or other proprietary 1173 rights that may cover technology that may be required to implement 1174 this standard. Please address the information to the IETF at 1175 ietf-ipr@ietf.org. 1177 Disclaimer of Validity 1179 This document and the information contained herein are provided on an 1180 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1181 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1182 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1183 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1184 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1185 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1187 Copyright Statement 1189 Copyright (C) The Internet Society (2004). This document is subject 1190 to the rights, licenses and restrictions contained in BCP 78, and 1191 except as set forth therein, the authors retain all their rights. 1193 Acknowledgment 1195 Funding for the RFC Editor function is currently provided by the 1196 Internet Society.