idnits 2.17.1 draft-ietf-avt-rtp-h264-params-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3984, updated by this document, for RFC5378 checks: 2002-10-24) -- 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 (January 30, 2008) is 5930 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3984 (ref. '3') (Obsoleted by RFC 6184) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport WG T. Kristensen, Ed. 3 Internet-Draft TANDBERG 4 Updates: 3984 (if approved) R. Even 5 Intended status: Standards Track Polycom 6 Expires: August 2, 2008 January 30, 2008 8 Parameters for Static Macroblocks and Aspect Ratio in the RTP Payload 9 Format for H.264 Video 10 draft-ietf-avt-rtp-h264-params-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 2, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document updates RFC 3984. It defines new optional parameters 44 addressing recent extensions currently supported in H.323 systems: 45 The signalling of the maximum rate of static macroblocks a decoder is 46 able to process. The signalling of the sample aspect ratio supported 47 by the sender or the receiver. 49 Table of Contents 51 1. Introduction and Overview . . . . . . . . . . . . . . . . . . . 3 52 1.1. Static macroblocks . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Sample aspect ratio . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 4 55 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . . 4 56 3.1. Media Type Registration . . . . . . . . . . . . . . . . . . 4 57 4. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Mapping of the optional parameters to SDP . . . . . . . . . 5 59 4.2. Usage with SDP offer/answer . . . . . . . . . . . . . . . . 5 60 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction and Overview 70 The ITU-T H.264 [4] codec and the extended video procedures and 71 control signals for H.300 series terminals in ITU-T H.241 [5], 72 continue to evolve. The IETF RTP payload formats and parameters need 73 to be updated to include important new functionalities not covered in 74 RFC 3984 [3]. This document describes new parameters used to signal 75 maximal number of static macroblocks per second and the sample aspect 76 ratio of the H.264 video stream. 78 The new parameters are already defined in the latest version of H.241 79 [5]. This proposal defines media type parameters for them and allows 80 their use in SDP based systems. 82 1.1. Static macroblocks 84 Running H.264 encode and decode operations require large amounts of 85 video processing power. The challenge being to sustain high frame 86 rate (e.g. 30 frames/sec) with the large frame sizes that stems from 87 recent demand for HD resolution. In practice, a certain amount of 88 macroblocks in the video stream, which do not change in a frame, can 89 be defined as static and, this way, free up additional processing 90 cycles for the handling of non-static macroblocks. 92 Based on a given amount of video processing resources and a given 93 resolution, a higher number of static macroblocks enables a 94 correspondingly higher frame rate. A new parameter MaxStaticMBPS 95 (maximum static macroblocks per second) was introduced in H.241 to 96 address this issue. The MaxStaticMBPS parameter is specified in 97 Section 8.3.2.8 of H.241 [5]. 99 1.2. Sample aspect ratio 101 Sample Aspect Ratio (SAR) is the intended ratio of the horizontal 102 distance between the columns to the vertical distance between the 103 rows of the luma sample array in a frame. SAR is expressed as h:v, 104 where h is horizontal width and v is vertical height (in arbitrary 105 units of spatial distance). A sample is an individual luma picture 106 element ("pixel") making up the complete displayed image (including 107 both fields in the case of interlaced-scan video). For example, the 108 sample aspect ratio for a CIF picture with a 4:3 Picture Aspect Ratio 109 (PAR) is 12:11. For a CIF picture with a 16:9 PAR, the sample aspect 110 ratio is 16:11. 112 All systems which send H.264 video should indicate the sample aspect 113 ratio in the VUI parameters specified in Annex E of H.264 [4]. 115 In the absence of a H.264 VUI parameter aspect_ratio_idc value in the 116 received H.264 bitstream, and in the case of an aspect_ratio_idc 117 value equal to 0, the sample aspect ratio may be assumed to have a 118 value according to Table 1b in H.241 [5]. 120 This draft enables the receiver to indicate what sample aspect ratio 121 it can support without distortion. This may help an encoder to 122 support the different monitors being used today, which support 123 different PAR such as 4:3 and 16:9. 125 2. Requirements notation 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [1]. 131 3. Payload Format Parameters 133 The optional H264 media subtype parameters max-smbps, sar and esar 134 specified below comes in addition to the list of optional H264 media 135 subtype parameters defined in Section 8.1 of RFC 3984 [3]. 137 3.1. Media Type Registration 139 New optional parameters: 141 max-smbps: The value of max-smbps is an integer indicating the 142 maximum static macroblock processing rate in units of static 143 macroblocks per second, under the hypothetical assumption that all 144 macroblocks are static macroblocks. When max-smbps is signalled 145 the MaxMBPS value in Table A-1 of H.264 [4] should be replaced 146 with the result of the following computation: 148 1. If the parameter max-mbps is signalled, set a variable 149 MaxMacroblocksPerSecond to the value of max-mbps. Otherwise, 150 set MaxMacroblocksPerSecond equal to the value of MaxMBPS for 151 the level in Table A-1 of H.264 [4]. 152 2. Set a variable P_non-static to the proportion of non-static 153 macroblocks in picture n. 154 3. Set a variable P_static to the proportion of static 155 macroblocks in picture n. 157 4. The value of MaxMBPS in Table A-1 of H.264 [4] should be 158 considered by the encoder to be equal to: 160 1 161 ----------------------------------------- 162 P_non-static P_static 163 ------------------------- + ----------- 164 MaxMacroblocksPerSecond max-smbps 166 The encoder should recompute this value for each picture. 168 The value of max-smbps MUST be greater than the value of MaxMBPS 169 for the level given in Table A-1 of H.264 [4]. Senders MAY use 170 this knowledge to send pictures of a given size at a higher 171 picture rate than is indicated in the signalled level. 173 sar: The value of this parameter is an integer that indicates 174 support of sample aspect ratios corresponding to H.264 175 aspect_ratio_idc values in the range from 1 to N inclusive, where 176 N is the value of this parameter (see Table E-1 of H.264 [4]). 178 esar: The value of this parameter is 1 or 0. 1 indicates support for 179 all sample aspect ratios which are expressible using the H.264 180 aspect_ratio_idc value of 255 (Extended_SAR, see Table E-1 of 181 H.264 [4]). If the parameter does not exist, its value is 0. 183 4. SDP Parameters 185 4.1. Mapping of the optional parameters to SDP 187 The optional parameters max-smbps, sar and esar when present, MUST be 188 included in the "a=fmtp" line of SDP. These parameters are expressed 189 as a media type string, in the form of a semicolon separated list of 190 paremeter=value pairs. 192 4.2. Usage with SDP offer/answer 194 When H.264 is offered over RTP using SDP in an offer/answer exchange 195 [2] for negotiation of unicast streams, the following limitations and 196 rules applies: 198 The optional parameter max-smbps is treated the same way as max-mbps, 199 when used in both the SDP offer/answer model [2] and declarative 200 session descriptions. Its interpretation depends on the direction 201 attribute. When the direction attribute is sendonly, then the 202 parameters describe the limits of the RTP packets and the NAL unit 203 stream that the sender is capable of producing. When the direction 204 attribute is sendrecv or recvonly, the parameters describe the 205 limitations of what the receiver accepts. The profile-level-id 206 parameter MUST be present in the same receiver capability description 207 that contains this parameter. 209 The interpretation of the optional parameter sar depends on the 210 direction attribute. When the direction attribute is sendonly, then 211 it indicates the range of sample aspect ratios the stream will 212 contain. When the direction attribute is sendrecv or recvonly, the 213 value of this parameter indicates the range of sample ratios that the 214 receiver is able to display without geometric (shape) distortion. 215 The receiver shall still display pictures encoded at other sample 216 aspect ratios (though perhaps with geometric distortion). 218 H.264 compliant encoders should choose to send a SAR which can be 219 displayed without geometric distortion. However, H.264 compliant 220 encoders may choose to send pictures using any SAR. 222 The optional parameter esar is a receiver capability that permits a 223 terminal to signal additional abilities to display any decoded video 224 expressible using the H.264 aspect_ratio_idc value of 255 225 (Extended_SAR, see Table E-1 of H.264 [4]). The actual extended 226 aspect ratio is conveyed using H.264 VUI. 228 4.3. Examples 230 TBD 232 5. IANA Considerations 234 This draft updates RFC 3984 by adding three new optional parameters 235 to the H264 media subtype. The parameters are specified in Section 236 Section 3 of this document. 238 6. Security Considerations 240 No separate considerations introduced in this document. Refer to 241 section 9 of RFC 3984 [3]. 243 7. Normative References 245 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 246 Levels", BCP 14, RFC 2119, March 1997. 248 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 249 Session Description Protocol (SDP)", RFC 3264, June 2002. 251 [3] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and 252 D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, 253 February 2005. 255 [4] International Telecommunications Union, "Advanced video coding 256 for generic audiovisual services", ITU-T Recommendation H.264, 257 March 2005. 259 [5] International Telecommunications Union, "Extended video 260 procedures and control signals for H.300-series terminals", ITU- 261 T Recommendation H.241, May 2006. 263 Appendix A. Change Log 265 draft-kristensen-avt-rtp-h264-params-00: 267 - 2007-06-19: Based on static macroblocks part of 268 draft-kristensen-avt-rtp-h264-extension-00, restructured. Added 269 sample aspect ratio parameter from H.241. 271 draft-ietf-avt-rtp-h264-params-00: 273 - 2007-06-30: Editorial changes. Input from G. Sullivan's review 274 considered. 276 - 2007-07-01: Better descriptions, tightened text. Introduced the 277 term PAR to explicitly distuingish it from SAR. 279 draft-ietf-avt-rtp-h264-params-00 to -01: 281 - 2007-07-03: Moved requirement/acronyms sections to after 282 Introduction. 284 - 2008-01-30: Mainly a keep-alive-submission. Adding missing PAR for 285 the first example with 12:11 SAR in Section 2.2. 287 Authors' Addresses 289 Tom Kristensen (editor) 290 TANDBERG 291 Philip Pedersens vei 22 292 N-1366 Lysaker 293 Norway 295 Phone: +47 67125125 296 Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no 297 URI: http://www.tandberg.com 299 Roni Even 300 Polycom 301 94 Derech Em Hamoshavot 302 Petach Tikva 49130 303 Israel 305 Email: roni.even@polycom.co.il 306 URI: http://www.polycom.com 308 Full Copyright Statement 310 Copyright (C) The IETF Trust (2008). 312 This document is subject to the rights, licenses and restrictions 313 contained in BCP 78, and except as set forth therein, the authors 314 retain all their rights. 316 This document and the information contained herein are provided on an 317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 319 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 320 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 321 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 Intellectual Property 326 The IETF takes no position regarding the validity or scope of any 327 Intellectual Property Rights or other rights that might be claimed to 328 pertain to the implementation or use of the technology described in 329 this document or the extent to which any license under such rights 330 might or might not be available; nor does it represent that it has 331 made any independent effort to identify any such rights. Information 332 on the procedures with respect to rights in RFC documents can be 333 found in BCP 78 and BCP 79. 335 Copies of IPR disclosures made to the IETF Secretariat and any 336 assurances of licenses to be made available, or the result of an 337 attempt made to obtain a general license or permission for the use of 338 such proprietary rights by implementers or users of this 339 specification can be obtained from the IETF on-line IPR repository at 340 http://www.ietf.org/ipr. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at 346 ietf-ipr@ietf.org. 348 Acknowledgment 350 Funding for the RFC Editor function is provided by the IETF 351 Administrative Support Activity (IASA).