idnits 2.17.1 draft-ietf-rtcweb-video-00.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 (July 01, 2014) is 3559 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 268, but no explicit reference was found in the text == Unused Reference: 'RFC4421' is defined on line 271, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'H264' -- Possible downref: Non-RFC (?) normative reference: ref. 'H265' ** Downref: Normative reference to an Informational draft: draft-grange-vp9-bitstream (ref. 'I-D.grange-vp9-bitstream') == Outdated reference: A later version (-15) exists of draft-ietf-payload-rtp-h265-04 == Outdated reference: A later version (-17) exists of draft-ietf-payload-vp8-11 ** Downref: Normative reference to an Informational RFC: RFC 6386 == 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: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 July 01, 2014 5 Expires: January 02, 2015 7 WebRTC Video Processing and Codec Requirements 8 draft-ietf-rtcweb-video-00 10 Abstract 12 This specification provides the requirements and consideration for 13 WebRTC applications to send and receive video across a network. It 14 specifies the video processing that is required, codecs and their 15 parameters, and types of RTP packetization that need to be supported. 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 January 02, 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. Codec Considerations . . . . . . . . . . . . . . . . . . . . 3 57 4.1. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.2. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.3. VP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.4. H.265 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Dealing with Packet Loss . . . . . . . . . . . . . . . . . . 4 62 6. Mandatory to Implement Video Codec . . . . . . . . . . . . . 4 63 6.1. Temperature of Working Group . . . . . . . . . . . . . . 4 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 One of the major functions of WebRTC endpoints is the ability to send 75 and receive interactive video. The video might come from a camera, a 76 screen recording, a stored file, or some other source. This 77 specification defines how the video is used and discusses special 78 considerations for processing the video. It also covers the video- 79 related algorithms WebRTC devices need to support. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Pre and Post Processing 89 This section provides guidance on pre- or post-processing of video 90 streams. 92 Unless specified otherwise by the SDP or Codec, the color space 93 SHOULD be TBD. 95 TODO: What color space is our default? 97 3.1. Camera Source Video 99 To support a quality experience with no application level adjustment 100 from the Javascript running in the browsers, WebRTC endpoints are 101 REQUIRED to support: 103 o Automatic focus, if applicable for the camera in use 105 o Automatic white balance 107 o Automatic light level control 109 TODO: What other processing should be specified here? 111 3.2. Screen Source Video 113 If the video source is some portion of a computer screen (e.g., 114 desktop or application sharing), then the considerations in this 115 section also apply. 117 TODO: What do we need to specify here? 119 4. Codec Considerations 121 WebRTC endpoints are not required to support all the codecs in this 122 section. 124 However, to foster interoperability between endpoints that have 125 codecs in common, if they do support one of the listed codecs, then 126 they need to meet the requirements specified in the subsection for 127 that codec. 129 All codecs MUST support at least 10 frames per second (fps) and 130 SHOULD support 30 fps. All codecs MUST support a minimum resolution 131 of 320X240. 133 TODO: These are strawman values. Are they adequate? 135 4.1. VP8 137 If VP8, defined in [RFC6386], is supported, then the endpoint MUST 138 support the payload formats defined in [I-D.ietf-payload-vp8]. In 139 addition it MUST support the 'bilinear' and 'none' reconstruction 140 filters. 142 4.2. H.264 143 If [H264] is supported, then the device MUST support the payload 144 formats defined in [RFC6184]. In addition, they MUST support 145 Constrained Baseline Profile Level 1.2, and they SHOULD support H.264 146 Constrained High Profile Level 1.3. 148 TODO: What packetization modes MUST be supported? 150 4.3. VP9 152 If VP9, as defined in [I-D.grange-vp9-bitstream], is supported, then 153 the device MUST support the payload formats defined in TODO. 155 TODO: The grange-vp9-bitstream draft does not really specify VP9 at 156 all, is there a better reference? 158 4.4. H.265 160 If [H265] is supported, then the device MUST support the payload 161 formats defined in [I-D.ietf-payload-rtp-h265]. 163 5. Dealing with Packet Loss 165 This section provides recommendations on how to encode video to be 166 robust to packet loss. 168 TODO: What do we want to require in terms of FEC, RTX, interleaving, 169 etc? 171 6. Mandatory to Implement Video Codec 173 Note: This section is here purely as a placeholder and there is not 174 yet WG Consensus on Mandatory to Implement video codecs. The WG has 175 agreed not to discuss this topic until September 29, 2014 so that the 176 WG can focus on getting other work done. Please, save your comments 177 on this topic until that time. 179 The currently recorded working group consensus is that all 180 implementations MUST support a single, specified mandatory-to- 181 implement codec. The remaining decision point is a selection of this 182 single codec. 184 6.1. Temperature of Working Group 185 To capture the conversation so far, this section summarizes the 186 result of a straw poll that the working group undertook in December 187 2013 and January 2014. Respondants were asked to answer "Yes," 188 "Acceptable," or "No" for each option. The options were collected 189 from the working group at large prior to the initiation of the straw 190 poll. 192 Yes Acc No 193 --- --- --- 194 1. All entities MUST support H.264 48% 11% 41% 195 2. All entities MUST support VP8 41% 17% 42% 196 3. All entities MUST support both H.264 and VP8 9% 38% 53% 197 4. Browsers MUST support both H.264 and VP8, other 198 entities MUST support at least one of H.264 199 and VP8 11% 34% 55% 200 5. All entities MUST support at least one of 201 H.264 and VP8 10% 16% 74% 202 6. All entities MUST support H.261 5% 23% 72% 203 7. There is no MTI video codec 12% 30% 58% 204 8. All entities MUST support H.261 and allentities 205 MUST support at least one of H.264 and VP8 4% 28% 68% 206 9. All entities MUST support Theora 7% 26% 67% 207 10. All entities MUST implement at least two of 208 {VP8, H.264, H.261} 5% 30% 65% 209 11. All entities MUST implement at least two of 210 {VP8, H.264, H.263} 5% 25% 70% 211 12. All entities MUST support decoding using both 212 H.264 and VP8, and MUST support encoding using 213 at least one of H.264 or VP8 7% 20% 73% 214 13. All entities MUST support H.263 6% 19% 75% 215 14. All entities MUST implement at least two of 216 {VP8, H.264, Theora} 6% 27% 67% 217 15. All entities MUST support decoding using Theora 1% 15% 84% 218 16. All entities MUST support Motion JPEG 1% 25% 74% 220 7. Security Considerations 222 This specification does not introduce any new mechanisms or security 223 concerns beyond what the other documents it references. In WebRTC, 224 video is protected using DTLS/SRTP. A complete discussion of the 225 security can be found in [I-D.ietf-rtcweb-security] and 226 [I-D.ietf-rtcweb-security-arch]. Implementers should consider 227 whether the use of variable bit rate video codecs are appropriate for 228 their application based on [RFC6562]. 230 8. IANA Considerations 231 This document requires no actions from IANA. 233 9. Acknowledgements 235 The authors would like to thank . Thanks to Cullen Jennings for providing text and review. 237 This draft includes text from draft-cbran-rtcweb-codec. 239 10. References 241 10.1. Normative References 243 [H264] ITU-T Recommendation H.264, "Advanced video coding for 244 generic audiovisual services", April 2013. 246 [H265] ITU-T Recommendation H.265, "High efficiency video 247 coding", April 2013. 249 [I-D.grange-vp9-bitstream] 250 Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview", 251 draft-grange-vp9-bitstream-00 (work in progress), February 252 2013. 254 [I-D.ietf-payload-rtp-h265] 255 Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 256 Hannuksela, "RTP Payload Format for High Efficiency Video 257 Coding", draft-ietf-payload-rtp-h265-04 (work in 258 progress), May 2014. 260 [I-D.ietf-payload-vp8] 261 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 262 Galligan, "RTP Payload Format for VP8 Video", draft-ietf- 263 payload-vp8-11 (work in progress), February 2014. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 269 Uncompressed Video", RFC 4175, September 2005. 271 [RFC4421] Perkins, C., "RTP Payload Format for Uncompressed Video: 272 Additional Colour Sampling Modes", RFC 4421, February 273 2006. 275 [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP 276 Payload Format for H.264 Video", RFC 6184, May 2011. 278 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 279 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 280 Guide", RFC 6386, November 2011. 282 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 283 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 284 2012. 286 10.2. Informative References 288 [I-D.ietf-rtcweb-security-arch] 289 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 290 rtcweb-security-arch-09 (work in progress), February 2014. 292 [I-D.ietf-rtcweb-security] 293 Rescorla, E., "Security Considerations for WebRTC", draft- 294 ietf-rtcweb-security-06 (work in progress), January 2014. 296 Author's Address 298 Adam Roach 299 Mozilla 300 \ 301 Dallas 302 US 304 Phone: +1 650 903 0800 x863 305 Email: adam@nostrum.com