idnits 2.17.1 draft-ietf-rtcweb-video-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (November 25, 2014) is 3440 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4175' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC4421' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC5104' is defined on line 322, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'H264' -- Possible downref: Non-RFC (?) normative reference: ref. 'HSUP1' == Outdated reference: A later version (-17) exists of draft-ietf-payload-vp8-11 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-12 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC23001-8' ** Downref: Normative reference to an Informational RFC: RFC 6386 -- Possible downref: Non-RFC (?) normative reference: ref. 'SRGB' == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A.B. Roach 3 Internet-Draft Mozilla 4 Intended status: Standards Track November 25, 2014 5 Expires: May 29, 2015 7 WebRTC Video Processing and Codec Requirements 8 draft-ietf-rtcweb-video-03 10 Abstract 12 This specification provides the requirements and considerations for 13 WebRTC applications to send and receive video across a network. It 14 specifies the video processing that is required, as well as video 15 codecs and their parameters. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 29, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Pre and Post Processing . . . . . . . . . . . . . . . . . . . 2 54 3.1. Camera Source Video . . . . . . . . . . . . . . . . . . . 3 55 3.2. Screen Source Video . . . . . . . . . . . . . . . . . . . 3 56 4. Stream Orientation . . . . . . . . . . . . . . . . . . . . . 3 57 5. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 58 6. Codec-Specific Considerations . . . . . . . . . . . . . . . . 5 59 6.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 10.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 One of the major functions of WebRTC endpoints is the ability to send 72 and receive interactive video. The video might come from a camera, a 73 screen recording, a stored file, or some other source. This 74 specification defines how the video is used and discusses special 75 considerations for processing the video. It also covers the video- 76 related algorithms WebRTC devices need to support. 78 Note that this document only discusses those issues dealing with 79 video codec handling. Issues that are related to transport of media 80 streams across the network are specified in 81 [I-D.ietf-rtcweb-rtp-usage]. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Pre and Post Processing 91 This section provides guidance on pre- or post-processing of video 92 streams. 94 Unless specified otherwise by the SDP or codec, the color space 95 SHOULD be sRGB [SRGB]. 97 TODO: I'm just throwing this out there to see if a specific proposal, 98 even if wrong, might draw more comment than "TBD". If you don't like 99 sRGB for this purpose, comment on the rtcweb@ietf.org mailing list. 100 It has been suggested that the MPEG "Coding independent media 101 description code points" specification [IEC23001-8] may have 102 applicability here. 104 3.1. Camera Source Video 106 This document imposes no normative requirements on camera capture; 107 however, implementors are encouraged to take advantage of the 108 following features, if feasible for their platform: 110 o Automatic focus, if applicable for the camera in use 112 o Automatic white balance 114 o Automatic light level control 116 3.2. Screen Source Video 118 If the video source is some portion of a computer screen (e.g., 119 desktop or application sharing), then the considerations in this 120 section also apply. 122 Because screen-sourced video can change resolution (due to, e.g., 123 window resizing and similar operations), WebRTC video recipients MUST 124 be prepared to handle mid-stream resolution changes in a way that 125 preserves their utility. Precise handling (e.g., resizing the 126 element a video is rendered in versus scaling down the received 127 stream; decisions around letter/pillarboxing) is left to the 128 discretion of the application. 130 Additionally, attention is drawn to the requirements in 131 [I-D.ietf-rtcweb-security-arch] section 5.2 and the considerations in 132 [I-D.ietf-rtcweb-security] section 4.1.1. 134 4. Stream Orientation 136 In some circumstances - and notably those involving mobile devices - 137 the orientation of the camera may not match the orientation used by 138 the encoder. Of more importance, the orientation may change over the 139 course of a call, requiring the receiver to change the orientation in 140 which it renders the stream. 142 While the sender may elect to simply change the pre-encoding 143 orientation of frames, this may not be practical or efficient (in 144 particular, in cases where the interface to the camera returns pre- 145 compressed video frames). Note that the potential for this behavior 146 adds another set of circumstances under which the resolution of a 147 screen might change in the middle of a video stream, in addition to 148 those mentioned under "Screen Sourced Video," above. 150 To accommodate these circumstances, RTCWEB implementations that can 151 generate media in orientations other than the default MUST support 152 generating the R0 and R1 bits of the Coordination of Video 153 Orientation (CVO) mechanism described in section 7.4.5 of [TS26.114], 154 and MUST send them for all orientations when the peer indicates 155 support for the mechanism. They MAY support sending the other bits 156 in the CVO extension, including the higher-resolution rotation bits. 157 All implementations SHOULD support interpretation of the R0 and R1 158 bits, and MAY support the other CVO bits. 160 Further, some codecs support in-band signaling of orientation (for 161 example, the SEI "Display Orientation" messages in H.264 and H.265). 162 If CVO has been negotiated, then the sender MUST NOT make use of such 163 codec-specific mechanisms. However, when support for CVO is not 164 signaled in the SDP, then such implementations MAY make use of the 165 codec-specific mechanisms instead. 167 5. Mandatory to Implement Video Codec 169 For the definitions of "WebRTC Brower," "WebRTC Non-Browser", and 170 "WebRTC-Compatible Endpoint" as they are used in this section, please 171 refer to [I-D.ietf-rtcweb-overview]. 173 WebRTC Browsers MUST implement the VP8 video codec as described in 174 [RFC6386] and H.264 as described in [H264]. 176 WebRTC Non-Browsers that support transmitting and/or receiving video 177 MUST implement the VP8 video codec as described in [RFC6386] and 178 H.264 as described in [H264]. 180 To promote the use of non-royalty bearing video codecs, 181 participants in the RTCWEB working group, and any successor 182 working groups in the IETF, intend to monitor the evolving 183 licensing landscape as it pertains to the two mandatory-to- 184 implement codecs. If compelling evidence arises that one of the 185 codecs is available for use on a royalty-free basis, the working 186 group plans to revisit the question of which codecs are required 187 for Non-Browsers, with the intention being that the royalty-free 188 codec will remain mandatory to implement, and the other will 189 become optional. 191 These provisions apply to WebRTC Non-Browsers only. There is no 192 plan to revisit the codecs required for WebRTC Browsers. 194 "WebRTC-compatible endpoints" are free to implement any video codecs 195 they see fit. This follows logically from the definition of "WebRTC- 196 compatible endpoint." It is, of course, advisable to implement at 197 least one of the video codecs that is mandated for WebRTC Browsers, 198 and implementors are encouraged to do so. 200 6. Codec-Specific Considerations 202 SDP allows for codec-independent indication of preferred video 203 resolutions using the mechanism described in [RFC6236]. If a 204 recipient of video indicates a receiving resolution, the sender 205 SHOULD accommodate this resolution, as the receiver may not be 206 capable of handling higher resolutions. 208 Additionally, codecs may include codec-specific means of signaling 209 maximum receiver abilities with regards to resolution, frame rate, 210 and bitrate. 212 Unless otherwise signaled in SDP, recipients of video streams are 213 MUST be able to decode video at a rate of at least 20 fps at a 214 resolution of at least 320x240. These values are selected based on 215 the recommendations in [HSUP1]. 217 Encoders are encouraged to support encoding media with at least the 218 same resolution and frame rates cited above. 220 6.1. VP8 222 For the VP8 codec, defined in [RFC6386], endpoints MUST support the 223 payload formats defined in [I-D.ietf-payload-vp8]. In addition they 224 MUST support the 'bilinear' and 'none' reconstruction filters. 226 TODO: There have been claims that VP8 already requires supporting 227 both filters; if true, these do not need to be reiterated here. 229 In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the 230 streams they send to conform to the values indicated by receivers in 231 the corresponding max-fr and max-fs SDP attributes. 233 6.2. H.264 235 For the [H264] codec, endpoints MUST support the payload formats 236 defined in [RFC6184]. In addition, they MUST support Constrained 237 Baseline Profile Level 1.2, and they SHOULD support H.264 Constrained 238 High Profile Level 1.3. 240 Implementations of the H.264 codec have utilized a wide variety of 241 optional parameters. To improve interoperability the following 242 parameter settings are specified: 244 packetization-mode: Packetization-mode 1 MUST be supported. Other 245 modes MAY be negotiated and used. 247 profile-level-id: Implementations MUST include this parameter within 248 SDP and SHOULD interpret it when receiving it. 250 max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These par 251 ameters allow the implementation to specify that they can support 252 certain features of H.264 at higher rates and values than those 253 signalled by their level (set with profile-level-id). 254 Implementations MAY include these parameters in their SDP, but 255 SHOULD interpret them when receiving them, allowing them to send 256 the highest quality of video possible. 258 sprop-parameter-sets: H.264 allows sequence and picture information 259 to be sent both in-band, and out-of-band. WebRTC implementations 260 MUST signal this information in-band; as a result, this parameter 261 will not be present in SDP. 263 TODO: Do we need to require the handling of specific SEI messages? 264 One example that has been raised is freeze-frame messages. 266 7. Security Considerations 268 This specification does not introduce any new mechanisms or security 269 concerns beyond what the other documents it references. In WebRTC, 270 video is protected using DTLS/SRTP. A complete discussion of the 271 security can be found in [I-D.ietf-rtcweb-security] and 272 [I-D.ietf-rtcweb-security-arch]. Implementers should consider 273 whether the use of variable bit rate video codecs are appropriate for 274 their application based on [RFC6562]. 276 8. IANA Considerations 278 This document requires no actions from IANA. 280 9. Acknowledgements 282 The authors would like to thank Gaelle Martin-Cocher, Stephan Wenger, 283 and Bernard Aboba for their detailed feedback and assistance with 284 this document. Thanks to Cullen Jennings for providing text and 285 review. This draft includes text from draft-cbran-rtcweb-codec. 287 10. References 289 10.1. Normative References 291 [H264] ITU-T Recommendation H.264, "Advanced video coding for 292 generic audiovisual services", April 2013. 294 [HSUP1] ITU-T Recommendation H.Sup1, "Application profile - Sign 295 language and lip-reading real-time conversation using low 296 bit rate video communication", May 1999. 298 [I-D.ietf-payload-vp8] 299 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 300 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 301 payload-vp8-11 (work in progress), February 2014. 303 [I-D.ietf-rtcweb-overview] 304 Alvestrand, H., "Overview: Real Time Protocols for 305 Browser-based Applications", draft-ietf-rtcweb-overview-12 306 (work in progress), October 2014. 308 [IEC23001-8] 309 ISO/IEC 23001-8:2013/DCOR1, "Coding independent media 310 description code points", 2013. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 316 Uncompressed Video", RFC 4175, September 2005. 318 [RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: 319 Additional Colour Sampling Modes", RFC 4421, February 320 2006. 322 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 323 "Codec Control Messages in the RTP Audio-Visual Profile 324 with Feedback (AVPF)", RFC 5104, February 2008. 326 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP 327 Payload Format for H.264 Video", RFC 6184, May 2011. 329 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 330 Attributes in the Session Description Protocol (SDP)", RFC 331 6236, May 2011. 333 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 334 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 335 Guide", RFC 6386, November 2011. 337 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 338 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 339 2012. 341 [SRGB] IEC 61966-2-1, "Multimedia systems and equipment - Colour 342 measurement and management - Part 2-1: Colour management - 343 Default RGB colour space - sRGB.", October 1999. 345 [TS26.114] 346 3GPP TS 26.114 V12.7.0, "3rd Generation Partnership 347 Project; Technical Specification Group Services and System 348 Aspects; IP Multimedia Subsystem (IMS); Multimedia 349 Telephony; Media handling and interaction (Release 12)", 350 September 2014. 352 10.2. Informative References 354 [I-D.ietf-rtcweb-rtp-usage] 355 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 356 Communication (WebRTC): Media Transport and Use of RTP", 357 draft-ietf-rtcweb-rtp-usage-06 (work in progress), 358 February 2013. 360 [I-D.ietf-rtcweb-security-arch] 361 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 362 rtcweb-security-arch-09 (work in progress), February 2014. 364 [I-D.ietf-rtcweb-security] 365 Rescorla, E., "Security Considerations for WebRTC", draft- 366 ietf-rtcweb-security-06 (work in progress), January 2014. 368 Author's Address 370 Adam Roach 371 Mozilla 372 \ 373 Dallas 374 US 376 Phone: +1 650 903 0800 x863 377 Email: adam@nostrum.com