idnits 2.17.1 draft-ietf-avt-rfc2429-bis-09.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 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1265. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3555, but the abstract doesn't seem to directly say this. It does mention RFC3555 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3555, updated by this document, for RFC5378 checks: 1999-07-02) -- 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 (April 20, 2006) is 6579 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'H263' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263P' -- Possible downref: Non-RFC (?) normative reference: ref. 'H263X' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) == Outdated reference: A later version (-06) exists of draft-ietf-avt-rfc2190-to-historic-04 -- Obsolete informational reference (is this intentional?): RFC 2032 (Obsoleted by RFC 4587) -- Obsolete informational reference (is this intentional?): RFC 2429 (Obsoleted by RFC 4629) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT J. Ott 3 Internet-Draft Helsinki University of Technology 4 Updates: 3555 (if approved) C. Bormann 5 Obsoletes: 2429 (if approved) Universitaet Bremen FB3 TZI 6 Expires: October 22, 2006 G. Sullivan 7 Microsoft 8 S. Wenger 9 Nokia 10 R. Even, Ed. 11 Polycom 12 April 20, 2006 14 RTP Payload Format for ITU-T Rec. H.263 Video 15 draft-ietf-avt-rfc2429-bis-09.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 27 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 October 22, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 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 describes the syntax and semantics of the SDP 53 parameters needed to support the H.263 video codec. 55 The document obsoletes RFC 2429 and updates the H263-1998 and H263- 56 2000 MIME media type in RFC 3555 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. New H.263 features . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Usage of RTP . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Video Packet Structure . . . . . . . . . . . . . . . . . . 8 66 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 67 5. H.263+ Payload Header . . . . . . . . . . . . . . . . . . . . 12 68 5.1. General H.263+ payload header . . . . . . . . . . . . . . 12 69 5.2. Video Redundancy Coding Header Extension . . . . . . . . . 13 70 6. Packetization schemes . . . . . . . . . . . . . . . . . . . . 16 71 6.1. Picture Segment Packets and Sequence Ending Packets 72 (P=1) . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 6.1.1. Packets that begin with a Picture Start Code . . . . . 16 74 6.1.2. Packets that begin with GBSC or SSC . . . . . . . . . 17 75 6.1.3. Packets that Begin with an EOS or EOSBS Code . . . . . 18 76 6.2. Encapsulating Follow-On Packet (P=0) . . . . . . . . . . . 18 77 7. Use of this payload specification . . . . . . . . . . . . . . 20 78 8. Media Type Definition . . . . . . . . . . . . . . . . . . . . 22 79 8.1. Media Type Registrations . . . . . . . . . . . . . . . . . 22 80 8.1.1. Registration of MIME media type video/H263-1998 . . . 22 81 8.1.2. Registration of MIME media type video/H263-2000 . . . 26 82 8.2. SDP Usage . . . . . . . . . . . . . . . . . . . . . . . . 27 83 8.2.1. Usage with the SDP Offer Answer Model . . . . . . . . 27 84 9. Backward Compatibility to RFC 2429 . . . . . . . . . . . . . . 29 85 9.1. New SDP optional parameters . . . . . . . . . . . . . . . 29 86 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 88 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 89 13. Changes from previous versions of the documents . . . . . . . 33 90 13.1. Changes from RFC 2429 . . . . . . . . . . . . . . . . . . 33 91 13.2. Changes from RFC 3555 . . . . . . . . . . . . . . . . . . 33 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 94 14.2. Informative References . . . . . . . . . . . . . . . . . . 34 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 96 Intellectual Property and Copyright Statements . . . . . . . . . . 37 98 1. Introduction 100 This document specifies an RTP payload header format applicable to 101 the transmission of video streams generated based on the 1998 and 102 2000 versions of ITU-T Recommendation H.263 [H263P]. Because the 103 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, 104 this format can also be used with the 1996 version of H.263 [H263], 105 and is recommended for this use by new implementations. This format 106 replaces the payload format in RFC 2190 [RFC2190], which continues to 107 be used by some existing implementations, and can be useful for 108 backward compatibility. New implementations supporting H.263 SHALL 109 use the payload format described in this document. RFC 2190 is moved 110 to historic status [I-D.ietf-avt-rfc2190-to-historic]. 112 The document updates the media type registration that was previously 113 in RFC 3555 [RFC3555]. 115 This document obsoletes RFC 2429 [RFC2429]. 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119] and 122 indicate requirement levels for compliant RTP implementations. 124 2. New H.263 features 126 The 1998 version of ITU-T Recommendation H.263 added numerous coding 127 options to improve codec performance over the 1996 version. The 1998 128 version is referred to as H.263+ in this document. The 2000 version 129 is referred to as H.263++ in this document. 131 Among the new options, the ones with the biggest impact on the RTP 132 payload specification and the error resilience of the video content 133 are the slice structured mode, the independent segment decoding mode, 134 the reference picture selection mode, and the scalability mode. This 135 section summarizes the impact of these new coding options on 136 packetization. Refer to [H263P] for more information on coding 137 options. 139 The slice structured mode was added to H.263+ for three purposes: to 140 provide enhanced error resilience capability, to make the bitstream 141 more amenable to use with an underlying packet transport such as RTP, 142 and to minimize video delay. The slice structured mode supports 143 fragmentation at macroblock boundaries. 145 With the independent segment decoding (ISD) option, a video picture 146 frame is broken into segments and encoded in such a way that each 147 segment is independently decodable. Utilizing ISD in a lossy network 148 environment helps to prevent the propagation of errors from one 149 segment of the picture to others. 151 The reference picture selection mode allows the use of an older 152 reference picture rather than the one immediately preceding the 153 current picture. Usually, the last transmitted frame is implicitly 154 used as the reference picture for inter-frame prediction. If the 155 reference picture selection mode is used, the data stream carries 156 information on what reference frame should be used, indicated by the 157 temporal reference as an ID for that reference frame. The reference 158 picture selection mode may be used with or without a back channel, 159 which provides information to the encoder about the internal status 160 of the decoder. However, no special provision is made herein for 161 carrying back channel information. The Extended RTP Profile for 162 RTCP-based Feedback [AVPF] MAY be used as a back channel mechanism. 164 H.263+ also includes bitstream scalability as an optional coding 165 mode. Three kinds of scalability are defined: temporal, signal-to- 166 noise ratio (SNR), and spatial scalability. Temporal scalability is 167 achieved via the disposable nature of bi-directionally predicted 168 frames, or B-frames. (A low-delay form of temporal scalability known 169 as P-picture temporal scalability can also be achieved by using the 170 reference picture selection mode described in the previous 171 paragraph.) SNR scalability permits refinement of encoded video 172 frames, thereby improving the quality (or SNR). Spatial scalability 173 is similar to SNR scalability except the refinement layer is twice 174 the size of the base layer in the horizontal dimension, vertical 175 dimension, or both. 177 H.263++ added some new functionalities. Among the new 178 functionalities are support for interlace mode specified in H.263 179 annex W.6.3.11 and the definition of profiles and levels in H.263 180 annex X. 182 3. Usage of RTP 184 When transmitting H.263+ video streams over the Internet, the output 185 of the encoder can be packetized directly. All the bits resulting 186 from the bitstream including the fixed length codes and variable 187 length codes will be included in the packet, with the only exception 188 being that when the payload of a packet begins with a Picture, GOB, 189 Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of 190 the start code shall be removed and replaced by setting an indicator 191 bit in the payload header. 193 For H.263+ bitstreams coded with temporal, spatial, or SNR 194 scalability, each layer may be transported to a different network 195 address. More specifically, each layer may use a unique IP address 196 and port number combination. The temporal relations between layers 197 shall be expressed using the RTP timestamp so that they can be 198 synchronized at the receiving ends in multicast or unicast 199 applications. 201 The H.263+ video stream will be carried as payload data within RTP 202 packets. A new H.263+ payload header is defined in section 5, it 203 updates the one specified in RFC 2190. This section defines the 204 usage of the RTP fixed header and H.263+ video packet structure. 206 3.1. RTP Header Usage 208 Each RTP packet starts with a fixed RTP header. The following fields 209 of the RTP fixed header used for H.263+ video streams are further 210 emphasized here: 212 Marker bit (M bit): The Marker bit of the RTP header is set to 1 when 213 the current packet carries the end of current frame, and is 0 214 otherwise. 216 Payload Type (PT): The RTP profile for a particular class of 217 applications will assign a payload type for this encoding, or if that 218 is not done, then a payload type in the dynamic range shall be chosen 219 by the sender. 221 Timestamp: The RTP Timestamp encodes the sampling instance of the 222 first video frame data contained in the RTP data packet. The RTP 223 timestamp shall be the same on successive packets if a video frame 224 occupies more than one packet. In a multilayer scenario, all 225 pictures corresponding to the same temporal reference should use the 226 same timestamp. If temporal scalability is used (if B-frames are 227 present), the timestamp may not be monotonically increasing in the 228 RTP stream. If B-frames are transmitted on a separate layer and 229 address, they must be synchronized properly with the reference 230 frames. Refer to the 1998 ITU-T Recommendation H.263 [H263P] for 231 information on required transmission order to a decoder. For an 232 H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, 233 the same as that of the RTP payload for H.261 stream [RFC2032]. 234 Since both the H.263+ data and the RTP header contain time 235 information, that timing information must run synchronously. That 236 is, both the RTP timestamp and the temporal reference (TR in the 237 picture header of H.263) should carry the same relative timing 238 information. Any H.263+ picture clock frequency can be expressed as 239 1800000/(cd*cf) source pictures per second, in which cd is an integer 240 from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock 241 of the RTP timestamp, the time increment between each coded H.263+ 242 picture should therefore be a integer multiple of (cd*cf)/20. This 243 will always be an integer for any "reasonable" picture clock 244 frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz 245 PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer 246 display update rates of 60, 72 and 75 Hz, respectively). For RTP 247 packetization of hypothetical H.263+ bitstreams using "unreasonable" 248 custom picture clock frequencies, mathematical rounding could become 249 necessary for generating the RTP timestamps. 251 3.2. Video Packet Structure 253 A section of an H.263+ compressed bitstream is carried as a payload 254 within each RTP packet. For each RTP packet, the RTP header is 255 followed by an H.263+ payload header, which is followed by a number 256 of bytes of a standard H.263+ compressed bitstream. The size of the 257 H.263+ payload header is variable depending on the payload involved 258 as detailed in the section 4. The layout of the RTP H.263+ video 259 packet is shown as: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | RTP Header 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | H.263+ Payload Header 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | H.263+ Compressed Data Stream 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Any H.263+ start codes can be byte aligned by an encoder by using the 272 stuffing mechanisms of H.263+. As specified in H.263+, picture, 273 slice, and EOSBS starts codes shall always be byte aligned, and GOB 274 and EOS start codes may be byte aligned. For packetization purposes, 275 GOB start codes should be byte aligned; however, since this is not 276 required in H.263+, there may be some cases where GOB start codes are 277 not aligned, such as when transmitting existing content, or when 278 using H.263 encoders that do not support GOB start code alignment. 279 In this case, follow-on packets (see section 5.2) should be used for 280 packetization. 282 All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin 283 with 16 zero-valued bits. If a start code is byte aligned and it 284 occurs at the beginning of a packet, these two bytes shall be removed 285 from the H.263+ compressed data stream in the packetization process 286 and shall instead be represented by setting a bit (the P bit) in the 287 payload header. 289 4. Design Considerations 291 The goals of this payload format are to specify an efficient way of 292 encapsulating an H.263+ standard compliant bitstream and to enhance 293 the resiliency towards packet losses. Due to the large number of 294 different possible coding schemes in H.263+, a copy of the picture 295 header with configuration information is inserted into the payload 296 header when appropriate. The use of that copy of the picture header 297 along with the payload data can allow decoding of a received packet 298 even in cases when another packet containing the original picture 299 header becomes lost. 301 There are a few assumptions and constraints associated with this 302 H.263+ payload header design. The purpose of this section is to 303 point out various design issues and also to discuss several coding 304 options provided by H.263+ that may impact the performance of 305 network-based H.263+ video. 307 o The optional slice structured mode described in Annex K of H.263+ 308 [H263P] enables more flexibility for packetization. Similar to a 309 picture segment that begins with a GOB header, the motion vector 310 predictors in a slice are restricted to reside within its 311 boundaries. However, slices provide much greater freedom in the 312 selection of the size and shape of the area which is represented 313 as a distinct decodable region. In particular, slices can have a 314 size which is dynamically selected to allow the data for each 315 slice to fit into a chosen packet size. Slices can also be chosen 316 to have a rectangular shape which is conducive for minimizing the 317 impact of errors and packet losses on motion compensated 318 prediction. For these reasons, the use of the slice structured 319 mode is strongly recommended for any applications used in 320 environments where significant packet loss occurs. 322 o In non-rectangular slice structured mode, only complete slices 323 SHOULD be included in a packet. In other words, slices should not 324 be fragmented across packet boundaries. The only reasonable need 325 for a slice to be fragmented across packet boundaries is when the 326 encoder which generated the H.263+ data stream could not be 327 influenced by an awareness of the packetization process (such as 328 when sending H.263+ data through a network other than the one to 329 which the encoder is attached, as in network gateway 330 implementations). Optimally, each packet will contain only one 331 slice. 333 o The independent segment decoding (ISD) described in Annex R of 334 [H263P] prevents any data dependency across slice or GOB 335 boundaries in the reference picture. It can be utilized to 336 further improve resiliency in high loss conditions. 338 o If ISD is used in conjunction with the slice structure, the 339 rectangular slice submode shall be enabled and the dimensions and 340 quantity of the slices present in a frame shall remain the same 341 between each two intra-coded frames (I-frames), as required in 342 H.263+. The individual ISD segments may also be entirely intra 343 coded from time to time to realize quick error recovery without 344 adding the latency time associated with sending complete INTRA- 345 pictures. 347 o When the slice structure is not applied, the insertion of a 348 (preferably byte-aligned) GOB header can be used to provide resync 349 boundaries in the bitstream, as the presence of a GOB header 350 eliminates the dependency of motion vector prediction across GOB 351 boundaries. These resync boundaries provide natural locations for 352 packet payload boundaries. 354 o H.263+ allows picture headers to be sent in an abbreviated form in 355 order to prevent repetition of overhead information that does not 356 change from picture to picture. For resiliency, sending a 357 complete picture header for every frame is often advisable. This 358 means that (especially in cases with high packet loss probability 359 in which picture header contents are not expected to be highly 360 predictable), the sender may find it advisable to always set the 361 subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. 362 (See [H263P] for the definition of the UFEP and PLUSPTYPE fields). 364 o In a multi-layer scenario, each layer may be transmitted to a 365 different network address. The configuration of each layer such 366 as the enhancement layer number (ELNUM), reference layer number 367 (RLNUM), and scalability type should be determined at the start of 368 the session and should not change during the course of the 369 session. 371 o All start codes can be byte aligned, and picture, slice, and EOSBS 372 start codes are always byte aligned. The boundaries of these 373 syntactical elements provide ideal locations for placing packet 374 boundaries. 376 o We assume that a maximum Picture Header size of 504 bits is 377 sufficient. The syntax of H.263+ does not explicitly prohibit 378 larger picture header sizes, but the use of such extremely large 379 picture headers is not expected. 381 5. H.263+ Payload Header 383 For H.263+ video streams, each RTP packet shall carry only one H.263+ 384 video packet. The H.263+ payload header shall always be present for 385 each H.263+ video packet. The payload header is of variable length. 386 A 16 bit field of the general payload header, defined in 5.1, may be 387 followed by an 8 bit field for Video Redundancy Coding (VRC) 388 information, and/or by a variable length extra picture header as 389 indicated by PLEN. These optional fields appear in the order given 390 above when present. 392 If an extra picture header is included in the payload header, the 393 length of the picture header in number of bytes is specified by PLEN. 394 The minimum length of the payload header is 16 bits, corresponding to 395 PLEN equal to 0 and no VRC information present. 397 The remainder of this section defines the various components of the 398 RTP payload header. Section six defines the various packet types 399 that are used to carry different types of H.263+ coded data, and 400 section seven summarizes how to distinguish between the various 401 packet types. 403 5.1. General H.263+ payload header 405 The H.263+ payload header is structured as follows: 407 0 1 408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | RR |P|V| PLEN |PEBIT| 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 RR: 5 bits 415 Reserved bits. SHALL be zero. MUST be ignored by receivers 417 P: 1 bit 419 Indicates the picture start or a picture segment (GOB/Slice) start 420 or a video sequence end (EOS or EOSBS). Two bytes of zero bits 421 then have to be prefixed to the payload of such a packet to 422 compose a complete picture/GOB/slice/EOS/EOSBS start code. This 423 bit allows the omission of the two first bytes of the start codes, 424 thus improving the compression ratio. 426 V: 1 bit 427 Indicates the presence of an 8 bit field containing information 428 for Video Redundancy Coding (VRC), which follows immediately after 429 the initial 16 bits of the payload header if present. For syntax 430 and semantics of that 8 bit VRC field see section 5.2. 432 PLEN: 6 bits 434 Length in bytes of the extra picture header. If no extra picture 435 header is attached, PLEN is 0. If PLEN>0, the extra picture 436 header is attached immediately following the rest of the payload 437 header. Note the length reflects the omission of the first two 438 bytes of the picture start code (PSC). See section 6.1. 440 PEBIT: 3 bits 442 Indicates the number of bits that shall be ignored in the last 443 byte of the picture header. If PLEN is not zero, the ignored bits 444 shall be the least significant bits of the byte. If PLEN is zero, 445 then PEBIT shall also be zero. 447 5.2. Video Redundancy Coding Header Extension 449 Video Redundancy Coding (VRC) is an optional mechanism intended to 450 improve error resilience over packet networks. Implementing VRC in 451 H.263+ will require the Reference Picture Selection option described 452 in Annex N of [H263P]. By having multiple "threads" of independently 453 inter-frame predicted pictures, damage to an individual frame will 454 cause distortions only within its own thread but leave the other 455 threads unaffected. From time to time, all threads converge to a so- 456 called sync frame (an INTRA picture or a non-INTRA picture which is 457 redundantly represented within multiple threads); from this sync 458 frame, the independent threads are started again. For more 459 information on codec support for VRC see [Vredun]. 461 P-picture temporal scalability is another use of the reference 462 picture selection mode and can be considered a special case of VRC in 463 which only one copy of each sync frame may be sent. It offers a 464 thread-based method of temporal scalability without the increased 465 delay caused by the use of B pictures. In this use, sync frames sent 466 in the first thread of pictures are also used for the prediction of a 467 second thread of pictures which fall temporally between the sync 468 frames to increase the resulting frame rate. In this use, the 469 pictures in the second thread can be discarded in order to obtain a 470 reduction of bit rate or decoding complexity without harming the 471 ability to decode later pictures. A third or more threads can also 472 be added as well, but each thread is predicted only from the sync 473 frames (which are sent at least in thread 0) or from frames within 474 the same thread. 476 While a VRC data stream is - like all H.263+ data - totally self- 477 contained, it may be useful for the transport hierarchy 478 implementation to have knowledge about the current damage status of 479 each thread. On the Internet, this status can easily be determined 480 by observing the marker bit, the sequence number of the RTP header, 481 and the thread-id and a circling "packet per thread" number. The 482 latter two numbers are coded in the VRC header extension. 484 The format of the VRC header extension is as follows: 486 0 1 2 3 4 5 6 7 487 +-+-+-+-+-+-+-+-+ 488 | TID | Trun |S| 489 +-+-+-+-+-+-+-+-+ 491 TID: 3 bits 493 Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC 494 data will use as reference information only sync frames or frames 495 within the same thread. By convention, thread 0 is expected to be 496 the "canonical" thread, which is the thread from which the sync frame 497 should ideally be used. In the case of corruption or loss of the 498 thread 0 representation, a representation of the sync frame with a 499 higher thread number can be used by the decoder. Lower thread 500 numbers are expected to contain equal or better representations of 501 the sync frames than higher thread numbers in the absence of data 502 corruption or loss. See [Vredun] for a detailed discussion of VRC. 504 Trun: 4 bits 506 Monotonically increasing (modulo 16) 4 bit number counting the packet 507 number within each thread. 509 S: 1 bit 511 A bit that indicates that the packet content is for a sync frame. An 512 encoder using VRC may send several representations of the same "sync" 513 picture, in order to ensure that regardless of which thread of 514 pictures is corrupted by errors or packet losses, the reception of at 515 least one representation of a particular picture is ensured (within 516 at least one thread). The sync picture can then be used for the 517 prediction of any thread. If packet losses have not occurred, then 518 the sync frame contents of thread 0 can be used and those of other 519 threads can be discarded (and similarly for other threads). Thread 0 520 is considered the "canonical" thread, the use of which is preferable 521 to all others. The contents of packets having lower thread numbers 522 shall be considered as having a higher processing and delivery 523 priority than those with higher thread numbers. Thus packets having 524 lower thread numbers for a given sync frame shall be delivered first 525 to the decoder under loss-free and low-time-jitter conditions, which 526 will result in the discarding of the sync contents of the higher- 527 numbered threads as specified in Annex N of [H263P]. 529 6. Packetization schemes 531 6.1. Picture Segment Packets and Sequence Ending Packets (P=1) 533 A picture segment packet is defined as a packet that starts at the 534 location of a Picture, GOB, or slice start code in the H.263+ data 535 stream. This corresponds to the definition of the start of a video 536 picture segment as defined in H.263+. For such packets, P=1 always. 538 An extra picture header can sometimes be attached in the payload 539 header of such packets. Whenever an extra picture header is attached 540 as signified by PLEN>0, only the last six bits of its picture start 541 code, '100000', are included in the payload header. A complete 542 H.263+ picture header with byte aligned picture start code can be 543 conveniently assembled on the receiving end by prepending the sixteen 544 leading '0' bits. 546 When PLEN>0, the end bit position corresponding to the last byte of 547 the picture header data is indicated by PEBIT. The actual bitstream 548 data shall begin on an 8-bit byte boundary following the payload 549 header. 551 A sequence ending packet is defined as a packet that starts at the 552 location of an EOS or EOSBS code in the H.263+ data stream. This 553 delineates the end of a sequence of H.263+ video data (more H.263+ 554 video data may still follow later, however, as specified in ITU-T 555 Recommendation H.263). For such packets, P=1 and PLEN=0 always. 557 The optional header extension for VRC may or may not be present as 558 indicated by the V bit flag. 560 6.1.1. Packets that begin with a Picture Start Code 562 Any packet that contains the whole or the start of a coded picture 563 shall start at the location of the picture start code (PSC), and 564 should normally be encapsulated with no extra copy of the picture 565 header. In other words, normally PLEN=0 in such a case. However, if 566 the coded picture contains an incomplete picture header (UFEP = 567 "000"), then a representation of the complete (UFEP = "001") picture 568 header may be attached during packetization in order to provide 569 greater error resilience. Thus, for packets that start at the 570 location of a picture start code, PLEN shall be zero unless both of 571 the following conditions apply: 573 1) The picture header in the H.263+ bitstream payload is incomplete 574 (PLUSPTYPE present and UFEP="000"), and 576 2) The additional picture header which is attached is not incomplete 577 (UFEP="001"). 579 A packet which begins at the location of a Picture, GOB, slice, EOS, 580 or EOSBS start code shall omit the first two (all zero) bytes from 581 the H.263+ bitstream, and signify their presence by setting P=1 in 582 the payload header. 584 Here is an example of encapsulating the first packet in a frame 585 (without an attached redundant complete picture header): 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | first two 0 bytes of the PSC 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 6.1.2. Packets that begin with GBSC or SSC 597 For a packet that begins at the location of a GOB or slice start 598 code, PLEN may be zero or may be nonzero, depending on whether a 599 redundant picture header is attached to the packet. In environments 600 with very low packet loss rates, or when picture header contents are 601 very seldom likely to change (except as can be detected from the GFID 602 syntax of H.263+), a redundant copy of the picture header is not 603 required. However, in less ideal circumstances a redundant picture 604 header should be attached for enhanced error resilience, and its 605 presence is indicated by PLEN>0. 607 Assuming a PLEN of 9 and P=1, below is an example of a packet that 608 begins with a byte aligned GBSC or a SSC: 610 0 1 2 3 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 4 5 6 7 8 9 0 1 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | starting with TR, PTYPE ... | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ... | bitstream | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | data starting with GBSC/SSC without its first two 0 bytes 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Notice that only the last six bits of the picture start code, 623 '100000', are included in the payload header. A complete H.263+ 624 picture header with byte aligned picture start code can be 625 conveniently assembled if needed on the receiving end by prepending 626 the sixteen leading '0' bits. 628 6.1.3. Packets that Begin with an EOS or EOSBS Code 630 For a packet that begins with an EOS or EOSBS code, PLEN shall be 631 zero, and no Picture, GOB, or Slice start codes shall be included 632 within the same packet. As with other packets beginning with start 633 codes, the two all-zero bytes that begin the EOS or EOSBS code at the 634 beginning of the packet shall be omitted, and their presence shall be 635 indicated by setting the P bit to 1 in the payload header. 637 System designers should be aware that some decoders may interpret the 638 loss of a packet containing only EOS or EOSBS information as the loss 639 of essential video data and may thus respond by not displaying some 640 subsequent video information. Since EOS and EOSBS codes do not 641 actually affect the decoding of video pictures, they are somewhat 642 unnecessary to send at all. Because of the danger of 643 misinterpretation of the loss of such a packet (which can be detected 644 by the sequence number), encoders are generally to be discouraged 645 from sending EOS and EOSBS. 647 Below is an example of a packet containing an EOS code: 649 0 1 2 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 6.2. Encapsulating Follow-On Packet (P=0) 657 A Follow-on packet contains a number of bytes of coded H.263+ data 658 which does not start at a synchronization point. That is, a 659 Follow-On packet does not start with a Picture, GOB, Slice, EOS, or 660 EOSBS header, and it may or may not start at a macroblock boundary. 661 Since Follow-on packets do not start at synchronization points, the 662 data at the beginning of a follow-on packet is not independently 663 decodable. For such packets, P=0 always. If the preceding packet of 664 a Follow-on packet got lost, the receiver may discard that Follow-on 665 packet as well as all other following Follow-on packets. Better 666 behavior, of course, would be for the receiver to scan the interior 667 of the packet payload content to determine whether any start codes 668 are found in the interior of the packet which can be used as resync 669 points. The use of an attached copy of a picture header for a 670 follow-on packet is useful only if the interior of the packet or some 671 subsequent follow-on packet contains a resync code such as a GOB or 672 slice start code. PLEN>0 is allowed, since it may allow resync in 673 the interior of the packet. The decoder may also be resynchronized 674 at the next segment or picture packet. 676 Here is an example of a follow-on packet (with PLEN=0): 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 681 | RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 684 7. Use of this payload specification 686 There is no syntactical difference between a picture segment packet 687 and a Follow-on packet, other than the indication P=1 for picture 688 segment or sequence ending packets and P=0 for Follow-on packets. 689 See the following for a summary of the entire packet types and ways 690 to distinguish between them. 692 It is possible to distinguish between the different packet types by 693 checking the P bit and the first 6 bits of the payload along with the 694 header information. The following table shows the packet type for 695 permutations of this information (see also the picture/GOB/Slice 696 header descriptions in H.263+ for details): 698 -------------+--------------+----------------------+---------------- 699 First 6 bits | P-Bit | PLEN | Packet | Remarks 700 of Payload |(payload hdr.)| | 701 -------------+--------------+----------------------+---------------- 702 100000 | 1 | 0 | Picture | Typical Picture 703 100000 | 1 | > 0 | Picture | Note UFEP 704 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 705 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs 706 Xxxxxx | 0 | 0 | Follow-on | 707 Xxxxxx | 0 | > 0 | Follow-on | Interior Resync 708 -------------+--------------+----------------------+---------------- 710 The details regarding the possible values of the five bit Group 711 Number (GN) field which follows the initial "1" bit when the P-bit is 712 "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 713 of H.263 [H263P]. 715 As defined in this specification, every start of a coded frame (as 716 indicated by the presence of a PSC) has to be encapsulated as a 717 picture segment packet. If the whole coded picture fits into one 718 packet of reasonable size (which is dependent on the connection 719 characteristics), this is the only type of packet that may need to be 720 used. Due to the high compression ratio achieved by H.263+ it is 721 often possible to use this mechanism, especially for small spatial 722 picture formats such as QCIF and typical Internet packet sizes around 723 1500 bytes. 725 If the complete coded frame does not fit into a single packet, two 726 different ways for the packetization may be chosen. In case of very 727 low or zero packet loss probability, one or more Follow-on packets 728 may be used for coding the rest of the picture. Doing so leads to 729 minimal coding and packetization overhead as well as to an optimal 730 use of the maximal packet size, but does not provide any added error 731 resilience. 733 The alternative is to break the picture into reasonably small 734 partitions - called Segments - (by using the Slice or GOB mechanism), 735 that do offer synchronization points. By doing so and using the 736 Picture Segment payload with PLEN>0, decoding of the transmitted 737 packets is possible even in such cases in which the Picture packet 738 containing the picture header was lost (provided any necessary 739 reference picture is available). Picture Segment packets can also be 740 used in conjunction with Follow-on packets for large segment sizes. 742 8. Media Type Definition 744 This section specifies optional parameters that MAY be used to select 745 optional features of the H.263 codec. The parameters are specified 746 here as part of the MIME subtype registration for the ITU-T H.263 747 codec. A mapping of the parameters into the Session Description 748 Protocol (SDP) [I-D.ietf-mmusic-sdp-new] is also provided for those 749 applications that use SDP. Multiple parameters SHOULD be expressed 750 as a MIME media type string, in the form of a semicolon separated 751 list of parameter=value pairs 753 8.1. Media Type Registrations 755 This section describes the Media types and names associated with this 756 payload format. The section updates the previous registered version 757 in RFC 3555 [RFC3555]. 759 8.1.1. Registration of MIME media type video/H263-1998 761 MIME media type name: video 763 MIME subtype name: H263-1998 765 Required parameters: None 767 Optional parameters: 769 SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF 770 resolution. Permissible values are integer values from 1 to 32, 771 which correspond to a maximum frame rate of (29.97/ the specified 772 value) frames per second. 774 QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF 775 resolution. Permissible values are integer values from 1 to 32, 776 which correspond to a maximum frame rate of (29.97/ the specified 777 value) frames per second. 779 CIF: Specifies the MPI (Minimum Picture Interval) for CIF 780 resolution. Permissible values are integer values from 1 to 32, 781 which correspond to a maximum frame rate of (29.97/ the specified 782 value) frames per second. 784 CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF 785 resolution. Permissible values are integer values from 1 to 32, 786 which correspond to a maximum frame rate of (29.97/ the specified 787 value) frames per second. 789 CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF 790 resolution. Permissible values are integer values from 1 to 32, 791 which correspond to a maximum frame rate of (29.97/ the specified 792 value) frames per second. 794 CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom 795 defined resolution. The custom parameter receives three comma 796 separated values Xmax , Ymax and MPI. The Xmax and Ymax 797 parameters describe the number of pixels in the X and Y axis and 798 must be evenly dividable by 4. The permissible values for MPI, 799 are integer values from 1 to 32, which correspond to a maximum 800 frame rate of (29.97/ the specified value). 802 A system that declares support of a specific MPI for one of the 803 resolutions SHALL also implicitly support a lower resolution with 804 the same MPI. 806 A list of optional annexes specifies which annexes of H.263 are 807 supported. The optional annexes are defined as part of H263-1998, 808 H263-2000. Annex X of H.263-2000 defines profiles which group 809 annexes for specific applications. A system that supports a 810 specific annex SHALL specify it support using the optional 811 parameters. If no annex is specified then the stream is Baseline 812 H.263. 814 The allowed optional parameters for the annexes are "F", "I", "J", 815 "T", "K", "N" and "P". 817 "F", "I", "J", "T" if supported SHALL have the value "1". If not 818 supported it should not be listed or SHALL have the value "0". 820 "K" can receive one of four values 1-4: 822 1: - Slices In Order-Non Rectangular 824 2: - Slices In Order-Rectangular 826 3: - Slices Not Ordered - Non Rectangular 828 4: - Slices Not Ordered - Rectangular 830 "N" - Reference Picture Selection mode - Four numeric choices 831 (1-4) are available representing the following modes: 833 1: NEITHER: In which no back-channel data is returned from the 834 decoder to the encoder. 836 2: ACK: In which the decoder returns only acknowledgment messages. 838 3: NACK: In which the decoder returns only non-acknowledgment 839 messages 841 4: ACK+NACK: In which the decoder returns both acknowledgment and 842 non-acknowledgment messages. 844 No special provision is made herein for carrying back channel 845 information. The Extended RTP Profile for RTCP-based Feedback 846 [AVPF] MAY be used as a back channel mechanism. 848 "P" - Reference Picture Resampling with the following submodes 849 represented as a number from 1 to 4: 851 1: dynamicPictureResizingByFour 853 2: dynamicPictureResizingBySixteenthPel 855 3: dynamicWarpingHalfPel 857 4: dynamicWarpingSixteenthPel 859 Example: P=1,3 861 PAR - Arbitrary Pixel Aspect Ratio : defines the width:height 862 ratio by two colon separated integers between 0 and 255. Default 863 ratio is 12:11 if not otherwise specified. 865 CPCF - Arbitrary (Custom) Picture Clock Frequency: CPCF is a 866 floating point value. Default value is 29.97 Hz. 868 BPP - BitsPerPictureMaxKb: Maximum number of bits in units of 1024 869 bits allowed to represent a single picture. If this parameter is 870 not present, then the default value, based on the maximum 871 supported resolution, is used. BPP is integer value between 0 and 872 65536. 874 HRD - Hypothetical Reference Decoder: See annex B of H.263 875 specification [H263P]. This parameter if supported SHALL have the 876 values "1". If not supported it should not be listed or SHALL 877 have the value "0". 879 Encoding considerations: 881 This media type is framed and binary, see section 4.8 in [RFC4288] 883 Security considerations: See Section 11 of RFCxxxx(This RFC) 885 Interoperability considerations: 887 These are receiver options, current implementations will not send 888 any optional parameters in their SDP. They will ignore the 889 optional parameters and will encode the H.263 stream without any 890 of the annexes. Most decoders support at least QCIF and CIF fixed 891 resolutions and they are expected to be available almost in every 892 H.263 based video application. 894 Published specification: RFCxxxx (This RFC) 896 Applications which use this media type: 898 Audio and video streaming and conferencing tools. 900 Additional information: none 902 Person and email address to contact for further information : 904 Roni Even: roni.even@polycom.co.il 906 Intended usage: COMMON 908 Restrictions on usage: 910 This media type depends on RTP framing, and hence is only defined 911 for transfer via RTP [RFC3550]. Transport within other framing 912 protocols is not defined at this time. 914 Author: Roni Even 916 Change controller: 918 IETF Audio/Video Transport working group delegated from the IESG. 920 8.1.2. Registration of MIME media type video/H263-2000 922 MIME media type name: video 924 MIME subtype name: H263-2000 926 Required parameters: None 928 Optional parameters: 930 The optional parameters of the H263-1998 type MAY be used with 931 this MIME subtype. Specific optional parameters that may be used 932 with the H263-2000 type are: 934 PROFILE: H.263 profile number, in the range 0 through 10, 935 specifying the supported H.263 annexes/subparts based on H.263 936 annex X [H263X]. The annexes supported in each profile are listed 937 in table X.1 of H.263 annex X. If no profile or H.263 annex is 938 specified than the stream is Baseline H.263 (profile 0 of H.263 939 annex X). 941 LEVEL: Level of bitstream operation, in the range 0 through 100, 942 specifying the level of computational complexity of the decoding 943 process. The level are described in table X.2 of H.263 annex X. 945 According to H.263 annex X, support of any level other than level 946 45 implies support of all lower levels. Support of level 45 947 implies support of level 10 949 A system that specifies support of a PROFILE MUST specify the 950 supported LEVEL. 952 INTERLACE: Interlaced or 60 fields indicates the support for 953 interlace display mode as specified in H.263 annex W.6.3.11. This 954 parameter, if supported SHALL have the values "1". If not 955 supported, it should not be listed or SHALL have the value "0" 957 Encoding considerations: 959 This media type is framed and binary, see section 4.8 in [RFC4288] 961 Security considerations: See Section 11 of RFCxxxx (This RFC) 963 Interoperability considerations: 965 The optional parameters PROFILE and LEVEL SHALL NOT be used with 966 any of the other optional parameters. 968 Published specification: RFCxxxx (This RFC) 970 Applications which use this media type: 972 Audio and video streaming and conferencing tools. 974 Additional information: none 976 Person and email address to contact for further information : 978 Roni Even: roni.even@polycom.co.il 980 Intended usage: COMMON 982 Restrictions on usage: 984 This media type depends on RTP framing, and hence is only defined 985 for transfer via RTP [RFC3550]. Transport within other framing 986 protocols is not defined at this time. 988 Author: Roni Even 990 Change controller: 992 IETF Audio/Video Transport working group delegated from the IESG. 994 8.2. SDP Usage 996 The media types video/H263-1998 and video/H263-2000 are mapped to 997 fields in the Session Description Protocol (SDP) as follows: 999 o The media name in the "m=" line of SDP MUST be video. 1001 o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 1002 or H263-2000 (the MIME subtype). 1004 o The clock rate in the "a=rtpmap" line MUST be 90000. 1006 o The optional parameters if any, MUST be included in the "a=fmtp" 1007 line of SDP. These parameters are expressed as a media type string, 1008 in the form of a semicolon separated list of parameter=value pairs. 1009 The optional parameters PROFILE and LEVEL SHALL NOT be used with any 1010 of the other optional parameters. 1012 8.2.1. Usage with the SDP Offer Answer Model 1014 When offering H.263 over RTP using SDP in an Offer/Answer model 1015 [RFC3264] the following considerations are necessary. 1017 Codec options: (F,I,J,K,N,P,T) These options MUST NOT appear unless 1018 the sender of these SDP parameters is able to decode those options. 1019 These options are receiver's capability even when send in a 1020 "sendonly" offer. 1022 Profile: The offer of a SDP profile parameter signal that the sender 1023 can decode a stream that uses the specified profile. Each profile 1024 uses different H.263 annexes so there is no implied relationship 1025 between them. In the offer/answer exchange this parameter SHOULD be 1026 the same in the offer and answer. A decoder that support a profile 1027 SHALL also support H.263 baseline profile (profile 0). 1029 Picture sizes and MPI: 1031 Supported picture sizes and their corresponding minimum picture 1032 interval (MPI) information for H.263 can be combined. All picture 1033 sizes can be advertised to the other party, or only a subset of it. 1034 Terminal announces only those picture sizes (with their MPIs) which 1035 it is willing to receive. For example, MPI=2 means that maximum 1036 (decodable) picture rate per second is about 15. 1038 If the receiver does not specify the picture size /MPI optional 1039 parameter then it SHOULD be ready to receive QCIF resolution with 1040 MPI=1. 1042 Parameters offered first are the most preferred picture mode to be 1043 received. 1045 Example of the usage of these parameters: 1047 CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2 1049 This means that encoder SHOULD send CIF picture size, which it can 1050 decode at MPI=4. If that is not possible, then QCIF with MPI value 1051 3, if neither are possible, then SQCIF with MPI value=2. The 1052 receiver is capable of (but least preferred) decoding custom picture 1053 sizes (max 360x240) with MPI=2. Note that most decoders support at 1054 least QCIF and CIF fixed resolutions and they are expected to be 1055 available almost in every H.263 based video application. 1057 Below is an example of H.263 SDP in an offer. 1059 a=fmtp:xx CIF=4;QCIF=2;F=1;K=1 1061 This means that the sender of this message can decode H.263 bit 1062 stream with following options and parameters: Preferred resolution is 1063 CIF (its MPI is 4), but if that is not possible then QCIF size is ok. 1064 AP and slicesInOrder-NonRect options MAY be used. 1066 9. Backward Compatibility to RFC 2429 1068 The current draft updates RFC 2429. This section will address the 1069 backward compatibility issues. 1071 9.1. New SDP optional parameters 1073 The draft adds new optional parameters to the H263-1998 and H263-2000 1074 payload type defined in RFC 3555 [RFC3555]. Since these are optional 1075 parameters we expect old implementation to ignore these parameters 1076 while new implementations that will receive the H263-1998 and H263- 1077 2000 payload type with no parameters will behave as if the other side 1078 can accept H.263 at QCIF resolution and 30 frames per second. 1080 10. IANA considerations 1082 This document updates the H.263(1998) and H.263 (2000) media types 1083 described in RFC 3555 [RFC3555]. The updated media types are in 1084 section 8.1. 1086 11. Security Considerations 1088 RTP packets using the payload format defined in this specification 1089 are subject to the security considerations discussed in the RTP 1090 specification [RFC3550], and any appropriate RTP profile (for example 1091 [RFC3551]). This implies that confidentiality of the media streams 1092 is achieved by encryption. Because the data compression used with 1093 this payload format is applied end-to-end, encryption may be 1094 performed after compression so there is no conflict between the two 1095 operations. 1097 A potential denial-of-service threat exists for data encoding using 1098 compression techniques that have non-uniform receiver-end 1099 computational load. The attacker can inject pathological datagrams 1100 into the stream which are complex to decode and cause the receiver to 1101 be overloaded. The usage of authentication of at least the RTP 1102 packet is RECOMMENDED 1104 As with any IP-based protocol, in some circumstances a receiver may 1105 be overloaded simply by the receipt of too many packets, either 1106 desired or undesired. Network-layer authentication may be used to 1107 discard packets from undesired sources, but the processing cost of 1108 the authentication itself may be too high. In a multicast 1109 environment, pruning of specific sources may be implemented in future 1110 versions of IGMP [RFC2032] and in multicast routing protocols to 1111 allow a receiver to select which sources are allowed to reach it. 1113 A security review of this payload format found no additional 1114 considerations beyond those in the RTP specification. 1116 12. Acknowledgements 1118 This is to acknowledge the work done by Chad Zhu, Linda Cline, Gim 1119 Deisher, Tom Gardos, Christian Maciocco, Donald Newell from Intel 1120 Corp. who co-authored RFC 2429. 1122 I would also like to acknowledge the work of Petri Koskelainen from 1123 Nokia and Nermeen Ismail from Cisco who helped with drafting the text 1124 for the new media types. 1126 13. Changes from previous versions of the documents 1128 13.1. Changes from RFC 2429 1130 The changes from the RFC 2429 are: 1132 1. The H.263 1998 and 2000 MIME type are now in the payload 1133 specification. 1135 2. Added optional parameters to the H.263 1998 and 2000 MIME types 1137 3. Mandate the usage of RFC 2429 for all H.263. RFC 2190 payload 1138 format should be used only to interact with legacy systems. 1140 13.2. Changes from RFC 3555 1142 This document adds new optional parameters to the H263-1998 and H263- 1143 2000 payload types. 1145 14. References 1147 14.1. Normative References 1149 [H263] International Telecommunications Union, "Video coding for 1150 low bit rate communication", ITU Recommendation H.263, 1151 March 1996. 1153 [H263P] International Telecommunications Union, "Video coding for 1154 low bit rate communication", ITU Recommendation H.263P, 1155 February 1998. 1157 [H263X] International Telecommunications Union, "Annex X: Profiles 1158 and levels definition", ITU Recommendation H.263AnxX, 1159 April 2001. 1161 [I-D.ietf-mmusic-sdp-new] 1162 Handley, M., "SDP: Session Description Protocol", 1163 draft-ietf-mmusic-sdp-new-25 (work in progress), 1164 July 2005. 1166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1167 Requirement Levels", BCP 14, RFC 2119, March 1997. 1169 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1170 Jacobson, "RTP: A Transport Protocol for Real-Time 1171 Applications", STD 64, RFC 3550, July 2003. 1173 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1174 Video Conferences with Minimal Control", STD 65, RFC 3551, 1175 July 2003. 1177 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 1178 Payload Formats", RFC 3555, July 2003. 1180 14.2. Informative References 1182 [AVPF] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1183 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 1184 January 2004. 1186 [I-D.ietf-avt-rfc2190-to-historic] 1187 Even, R., "RTP Payload Format for H.263 using RFC2190 to 1188 Historic status", draft-ietf-avt-rfc2190-to-historic-04 1189 (work in progress), December 2005. 1191 [RFC2032] Turletti, T., "RTP Payload Format for H.261 Video 1192 Streams", RFC 2032, October 1996. 1194 [RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", 1195 RFC 2190, September 1997. 1197 [RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, 1198 C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. 1199 Zhu, "RTP Payload Format for the 1998 Version of ITU-T 1200 Rec. H.263 Video (H.263+)", RFC 2429, October 1998. 1202 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1203 with Session Description Protocol (SDP)", RFC 3264, 1204 June 2002. 1206 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1207 Registration Procedures", BCP 13, RFC 4288, December 2005. 1209 [Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. 1210 Audio-Visual Services over Packet Networks, Aberdeen, 1211 U.K. 9/1997, September 1997. 1213 Authors' Addresses 1215 Joerg Ott 1216 Helsinki University of Technology 1218 Email: jo@netlab.hut.fi 1220 Carsten Bormann 1221 Universitaet Bremen FB3 TZI 1223 Email: cabo@tzi.org 1225 Gary Sullivan 1226 Microsoft 1228 Email: garysull@windows.microsoft.com 1230 Stephan Wenger 1231 Nokia 1233 Email: Stephan.Wenger@nokia.com 1235 Roni Even (editor) 1236 Polycom 1237 94 Derech Em Hamoshavot 1238 Petach Tikva 49130 1239 Israel 1241 Email: roni.even@polycom.co.il 1243 Intellectual Property Statement 1245 The IETF takes no position regarding the validity or scope of any 1246 Intellectual Property Rights or other rights that might be claimed to 1247 pertain to the implementation or use of the technology described in 1248 this document or the extent to which any license under such rights 1249 might or might not be available; nor does it represent that it has 1250 made any independent effort to identify any such rights. Information 1251 on the procedures with respect to rights in RFC documents can be 1252 found in BCP 78 and BCP 79. 1254 Copies of IPR disclosures made to the IETF Secretariat and any 1255 assurances of licenses to be made available, or the result of an 1256 attempt made to obtain a general license or permission for the use of 1257 such proprietary rights by implementers or users of this 1258 specification can be obtained from the IETF on-line IPR repository at 1259 http://www.ietf.org/ipr. 1261 The IETF invites any interested party to bring to its attention any 1262 copyrights, patents or patent applications, or other proprietary 1263 rights that may cover technology that may be required to implement 1264 this standard. Please address the information to the IETF at 1265 ietf-ipr@ietf.org. 1267 Disclaimer of Validity 1269 This document and the information contained herein are provided on an 1270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1272 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1273 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1274 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1277 Copyright Statement 1279 Copyright (C) The Internet Society (2006). This document is subject 1280 to the rights, licenses and restrictions contained in BCP 78, and 1281 except as set forth therein, the authors retain all their rights. 1283 Acknowledgment 1285 Funding for the RFC Editor function is currently provided by the 1286 Internet Society.