idnits 2.17.00 (12 Aug 2021) /tmp/idnits36703/draft-lennox-avt-h264-source-fmtp-00.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 16. -- 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3984, but the abstract doesn't seem to mention this, which it should. 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 (November 11, 2007) is 5298 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) == Outdated reference: draft-ietf-avt-rtp-svc has been published as RFC 6190 ** Obsolete normative reference: RFC 3984 (Obsoleted by RFC 6184) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT J. Lennox 3 Internet-Draft Vidyo 4 Updates: 3984 (if approved) November 11, 2007 5 Intended status: Standards Track 6 Expires: May 14, 2008 8 Source-Specific Media Format Parameters for H.264 and H.264 SVC 9 draft-lennox-avt-h264-source-fmtp-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 When used in the Session Description Protocol Offer/Answer model, 43 several of the media format parameters for the H.264 video format, 44 and for its Scalabile Video Codec (SVC) extension, describe 45 characterics of the stream an endpoint is prepared to send, not of 46 streams it is prepared to receive. If an endpoint wishes to send 47 multiple streams, these parameters may be incompatible. This 48 document defines how such media format parameters may be given on a 49 per-source basis, using SDP source-specific fmtp attributes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Mapping of MIME parameters to SDP source attributes . . . . . . 4 57 4.1. Parameter Sets . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Packetization Mode 2 Parameters . . . . . . . . . . . . . . 5 59 4.3. Capability Parameters . . . . . . . . . . . . . . . . . . . 5 60 4.4. H264 SVC Parameters . . . . . . . . . . . . . . . . . . . . 5 61 4.5. Other Parameters . . . . . . . . . . . . . . . . . . . . . 6 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 Unlike many media packetization formats for the Real-Time Transport 73 Protocol (RTP) [RFC3550], the the RTP packetization specifications 74 for H.264 [RFC3984] and for H.264's Scalable Video Coding extension 75 [I-D.ietf-avt-rtp-svc] define a number of MIME media type parameters 76 that, when encoded in SDP [RFC4566], define characteristics of the 77 media stream an endpoint is prepared to send, not of the streams it 78 is prepared to receive. Most notably, streams' parameter sets 79 (initial data required to correctly initialize a decoder) are encoded 80 in SDP messages and sent out-of-band, to ensure that they are 81 reliably received by a decoder before decoding begins. 83 Because RTP is fundamentally a group communication protocol, however, 84 an RTP session may contain many different media streams. In this 85 case, different H.264 and H.264 SVC streams in an RTP session may 86 need to be described by different and incompatible values for these 87 MIME media type parameters. For example, an endpoint may be 88 switching between video streams encoded by separate video encoders. 89 In this case, it is not possible, using only the mechanisms of 90 [RFC3984], to describe all the sources and to send their parameter 91 sets out-of-band. An endpoint must instead fall back to sending 92 parameter sets in-band, and retransmitting them with high enough 93 frequency that there is a reasonably high likelihood of their being 94 receceived successfully. 96 To solve this difficulty, this document uses the framework introduced 97 by [I-D.lennox-mmusic-sdp-source-attributes] to describe MIME media 98 format parameters of individual H.264 sources in SDP. This enables 99 all the benefits of out-of-band H.264 source description in the case 100 when multiple H.264 sources will be sent in an RTP session. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119] and 107 indicate requirement levels for compliant implementations. 109 3. Overview 111 When used with the SDP [RFC4566] offer/answer model [RFC3264], 112 several of the media format parameters of H.264 [RFC3984] and H.264 113 SVC [I-D.ietf-avt-rtp-svc] define characteristics of an RTP stream 114 (media source) to be sent, not of a session receiver's capabilities. 115 When multiple media sources are in use, it is sometimes useful to 116 describe source characteristics individually for each source. 118 Per-source media format parameters are defined using the fmtp source 119 parameter [I-D.lennox-mmusic-sdp-source-attributes]. This document 120 updates the MIME type registration of video/H264 in [RFC3984] and of 121 video/H264-SVC in [I-D.ietf-avt-rtp-svc] to specify the encoding of 122 the MIME media format parameters into the fmtp source attribute. 124 4. Mapping of MIME parameters to SDP source attributes 126 H.264 MIME media format parmaeters applicable to a specific source 127 are are encoded into an "fmtp" source attribute for the H.264 payload 128 type and the source being described. These parameters are expressed 129 in the form of a semicolon-separated list of parameter=value pairs, 130 the same syntax as the media-level fmtp value. For the purposes of 131 discussion in this document, MIME media format parameters encoded 132 into a source-specific fmtp attribute are called "source-specific 133 parameters", while MIME media format parameters encoded into a media- 134 level format attribute are called "media parameters". 136 Source-specific parameters only describe characteristics of a 137 specific source might send, while media parameters describe all 138 sources of a stream. Source-specific parameters do not override 139 media parameters, though they do in some cases further constrain them 140 or provide additional information. 142 4.1. Parameter Sets 144 The "sprop-parameter-sets" parameter encodes H.264 sequence parameter 145 set (SPS) and picture parameter set (PPS) Network Adaptation Layer 146 NAL) units. These parameter sets provide essential information 147 necessary to decode an H.264 bitstream; encoding them in SDP ensures 148 that they are delivered reliably. 150 The "sprop-parameter-sets" parameter MAY be encoded as a source 151 parameter. However, if the sprop-parameter-sets parameter is also 152 present as a media parameter, the H.264 parameter sets described for 153 each source MUST include all the H.264 parameter set described for 154 the media. 156 In an SDP answer, the "sprop-parameter-sets" for a source MUST follow 157 the same constraints as for the media. I.e., the parameter sets for 158 a source described in an answer MUST be a superset of the parameter 159 sets for the media in the offer, and if an offer indicates 160 "parameter-add=0" (false) for the media, the corresponding answer 161 MUST NOT add additonal parameter sets for any source. 163 4.2. Packetization Mode 2 Parameters 165 The "sprop-deint-buf-req", "sprop-interleaving-depth", "sprop-max- 166 don-diff", and "sprop-init-buf-time" parameters describe 167 characteristics of H.264 media streams using packetization mode 2 168 (interleaved mode). According to [RFC3984], the first two are 169 mandatory for packetization mode 2 streams; the other two are 170 optional. They specify the maximum size and time of the debuffering 171 needed to deinterleave streams sent in interleaved mode. 173 These parameters MAY be included as source parameters, overriding any 174 corresponding values at the media level for the source. However, if 175 they are, they MUST be less than or equal to the value specified for 176 the parameter (if any) at the media level. All constraints for these 177 values specified by [RFC3984] still apply. 179 4.3. Capability Parameters 181 As defined in [RFC3984], the meaning of the capability parameters 182 ("max-mbps", "max-fs", "max-cpb", "max-dpb", "max-br", "redundant- 183 pic-cap", and "max-rcmd-nalu-size") at the media level depends on a 184 media stream's "direction" attribute. When the "direction" attribute 185 is "sendonly", then the parameters describe the limits of media 186 sources that the sender is capable of producing. When the 187 "direction" attribute is "sendrecv" or "recvonly", then the 188 parameters describe the limitations of what the receiver accepts. 190 When encoded as source parameters, these parameters always describe 191 the limits of the source being described. In media streams whose 192 "direction" is "sendonly", these parameters MUST be less than or 193 equal to the values (if any) in the media parameters. In media 194 streams whose "direction" is "sendrecv", source parameters for these 195 values are unconstrained by stream's media parameters (which describe 196 what the endpoint is willing to receive). However, in offer/answer 197 mode, the values of these source parameters MUST be less than or 198 equal to the values given in media parameters in the most recent 199 (accepted) offer or answer for the stream. 201 (Media streams whose "direction" is "recvonly" do not encode any 202 sources.) 204 4.4. H264 SVC Parameters 206 The H.264 SVC parameters "sprop-scalability-info" and "sprop-layer- 207 ids" are defined in [I-D.ietf-avt-rtp-svc]. They describe the 208 scalability structure of an H.264 Scalable Video Codec stream. 210 These parameters MUST NOT be given both as source parameters and 211 media parameters. They MUST be specified at one level at most. 213 4.5. Other Parameters 215 The parameters "profile-level-id", "packetization-mode", and 216 "parameter-add" MUST NOT be used as a source parameters. 218 5. Examples 220 This section gives examples of SDP descriptions of media sessions 221 containing H.264 source parameters. For brevity, only the media 222 sections of the descriptions are given. 224 m=video 49170 RTP/AVP 96 225 a=rtpmap:96 H264/90000 226 a=fmtp:96 packetization-mode=1 227 a=ssrc:12345 cname:cif-stream@example.com 228 a=ssrc:12345 fmtp:96 sprop-parameter-sets=J0LgDZWWFglk,KM4Ecg== 229 a=ssrc:67890 cname:vga-stream@example.com 230 a=ssrc:67890 fmtp:96 sprop-parameter-sets=J0LgDZWWCgPZ,KM4Ecg== 232 Figure 1: Example: declaration of two sources with different 233 parameter sets 235 The example in Figure 1 shows two H.264 streams with different, 236 incompatbile parameter sets. (Specifically, the two streams encode 237 different image sizes.) 239 (TODO: add more examples.) 241 6. Backward Compatibility 243 Unless a sender knows via some mechanism (not specified here or in 244 [I-D.lennox-mmusic-sdp-source-attributes]) that a receiver definitely 245 understands source parameters, it MUST send any parameter sets 246 specified in sprop-parameter-sets source attributes in-band in the 247 media stream as well. These parameter sets SHOULD be transmitted 248 frequently enough that a receiver has a high probability of receiving 249 them even in the presence of packet loss. 251 For H.264 SVC streams, the scalability information Supplemental 252 Encoder Information (SEI) message encoded in an sprop-scalability- 253 info parameter set SHOULD be similarly transmitted in-band as well. 255 7. Security Considerations 257 Source-specific encoding of media format parameters does not add any 258 additional security considerations beyond those of [RFC3984] and 259 [I-D.ietf-avt-rtp-svc]. 261 8. IANA Considerations 263 This document updates the SDP encoding of the video/H264 MIME media 264 type specified in [RFC3984], and of the video/H264-SVC MIME media 265 type specified in [I-D.ietf-avt-rtp-svc]. 267 9. Normative References 269 [I-D.ietf-avt-rtp-svc] 270 Wenger, S., "RTP Payload Format for SVC Video", 271 draft-ietf-avt-rtp-svc-02 (work in progress), July 2007. 273 [I-D.lennox-mmusic-sdp-source-attributes] 274 Lennox, J., "Source-Specific Media Attributes in the 275 Session Description Protocol (SDP)", 276 draft-lennox-mmusic-sdp-source-attributes-01 (work in 277 progress), July 2007. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 283 with Session Description Protocol (SDP)", RFC 3264, 284 June 2002. 286 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 287 Jacobson, "RTP: A Transport Protocol for Real-Time 288 Applications", STD 64, RFC 3550, July 2003. 290 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 291 M., and D. Singer, "RTP Payload Format for H.264 Video", 292 RFC 3984, February 2005. 294 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 295 Description Protocol", RFC 4566, July 2006. 297 Author's Address 299 Jonathan Lennox 300 Vidyo, Inc. 301 433 Hackensack Avenue 302 Sixth Floor 303 Hackensack, NJ 07601 304 US 306 Email: jonathan@vidyo.com 308 Full Copyright Statement 310 Copyright (C) The IETF Trust (2007). 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).