idnits 2.17.1 draft-alvestrand-rtcweb-vp8-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 6, 2013) is 3852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-payload-vp8-09 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft A. Grange 4 Intended status: Informational Google 5 Expires: April 9, 2014 October 6, 2013 7 VP8 as RTCWEB Mandatory to Implement 8 draft-alvestrand-rtcweb-vp8-02 10 Abstract 12 This document recommends that the RTCWEB working group choose the VP8 13 specification as a mandatory to implement video codec for RTCWEB 14 implementations. 16 This document is not intended for publication as an RFC. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 9, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements for an MTI codec . . . . . . . . . . . . . . . . 3 60 3. Specification status . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. VP8 standardization status . . . . . . . . . . . . . . . . 3 62 4. Deployment status . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Image quality evaluations . . . . . . . . . . . . . . . . . . 4 64 5.1. Objective evaluations . . . . . . . . . . . . . . . . . . 4 65 5.2. Subjective evaluations . . . . . . . . . . . . . . . . . . 5 66 6. Performance evaluation . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.2. Hardware support . . . . . . . . . . . . . . . . . . . . . 6 69 6.3. Hardware performance . . . . . . . . . . . . . . . . . . . 6 70 7. IPR status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 As described in [I-D.ietf-rtcweb-overview], successful interoperable 82 deployment of RTCWEB requires that implementations share a video 83 codec. Not requiring a video codec will mean that this decision is 84 left to processes outside the standards process, and risks the 85 spectre of fragmented deployment. 87 This memo argues that VP8 should be that codec. 89 2. Requirements for an MTI codec 91 As outlined by the presentation given at the IETF meeting at IETF 84 92 in Vancouver, it is unclear what the hard requirements for a video 93 codec are, but the items that it was suggested that proposals give 94 information on were: 96 o Image quality - comparative data was sought, but without defining 97 a baseline 99 o Performance - what resolutions / frame rates can be achieved in 100 software on some common systems 102 o Power consumption of hardware and/or software implementations 104 o Hardware support 106 o IPR status 108 This document lays out the available information in each category. 110 3. Specification status 112 VP8 is defined in [RFC6386], and its RTP payload is defined in 113 [I-D.ietf-payload-vp8] . There are no profiles; all decoders are 114 able to decode all valid media streams. 116 In the time since the original RFC publication, and indeed since the 117 first publication of the VP8 bitstream format, there have been no 118 changes to the decoder that broke bitstream compatibility. 120 3.1. VP8 standardization status 122 The VP8 codec has been proposed as a basis for standardization in 123 MPEG, in response to its Call for Proposals for a royalty-free video 124 codec. At its meeting in Vienna, Austria in July 2013, following the 125 presentation of subjective and objective quality evaluation results, 126 and a focused discussion of possible IPR issues, MPEG passed a 127 resolution calling for the creation of a new project (Video Coding 128 for Browsers, or VCB), with the aim of producing a final DIS document 129 (FDIS) by July 2014. (MPEG output document w13648). 131 At the meeting of the US National Body of MPEG in October 013, the 132 USNB passed a resolution supporting this work, and expressing a 133 preference for "options that maintain a native VP8 mode" - that is, 134 no incompatible changes. 136 4. Deployment status 138 The VP8 codec has been extensively deployed in production services: 140 o Skype (now part of Microsoft) used the codec extensively in its 141 video conferencing software. 143 o Google Hangouts is now fully converted to using VP8 on the various 144 PC platforms. This platform now offers free videoconferencing in 145 HD quality to everyone. 147 o Google Remote Desktop uses VP8. 149 o Google Chromecast uses VP8, showing what can be achieved with 150 hardware decoding support. 152 o Both the Firefox and Chrome WebRTC implementations use VP8 153 exclusively. 155 5. Image quality evaluations 157 5.1. Objective evaluations 159 In tests carried out by Google on a set of ten sample video clips 160 containing typical video-conference content, VP8 outperformed the 161 x264 H.264 codec running the constrained baseline profile by on 162 average 37.2%. That is, at the same quality, measured by PSNR, VP8 163 produced 37.2% fewer bits on average than H.264. VP8 outperformed 164 H.264 on all ten of the test clips by between 19% and 64%. Both 165 codecs were configured in one-pass mode using settings conducive to 166 real-time operation, and the ten clips varied in size between 640x360 167 pixels and 1280x720 pixels. 169 The software and the clips are available via the WEBM project's GIT 170 repository: 172 http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git 174 Note: Tests run by Ericsson have demonstrated that it is possible to 175 reduce the VP8 performance to be very close to that of baseline by 176 running in "fixed QP" mode - selecting a single QP value in order to 177 achieve a given bitrate. We believe this VP8 mode is an unrealistic 178 mode for production use, and not what we should be evaluating. 180 5.2. Subjective evaluations 182 As part of the process of submitting VP8 for evaluation in ISO/IEC 183 JTC1 SC29 WG11 (MPEG), the VP8 codec has been subjected to subjective 184 and objective quality evaluations; the input reports are in WG11 185 documents N13775 (Vienna, MPEG 105 meeting, subjective numbers for 186 VP8 performed by Vittorio Baroncini), M29364 (Incheon, subjective 187 comparision between VP8 and IVC) and M28182 (Geneva, MPEG 103 188 meeting), respectively. 190 These tests were performed at the laboratories of Vittori Baronici, 191 who is also a chair of the Testing subgroup of MPEG, and has 192 performed many of the subjective tests done as part of the HEVC 193 effort. 195 Together with the tests presented in document M29364, we also asked 196 Vittorio Baroncini to do a subjective evaluation of VP8 compared to 197 the AVC Baseline; the results of this evaluation are given in a 198 separate presentation. 200 In all these cases, VP8 performed adequately in subjective 201 evaluations; the numbers can be interpreted as showing that VP8 in 202 "realtime" mode performed better than the "anchors" on both tests, 203 but due to the amount of discussion occuring in the meetings about 204 whether the precise parameters chosen for the tests made it a "fair" 205 comparision, we will not state flatly that VP8 performed better than 206 the anchors (AVC Baseline and AVC High Profile, respectively), but we 207 will state flatly that there is no evicence that the anchors 208 performed significantly better than VP8. 210 6. Performance evaluation 212 6.1. Software 214 The current reference implementation is libvpx, developed in the WebM 215 project. 217 The encoding speed in software depends on the quality setting. On a 218 stock PC platform using an Intel Xeon CPU at 2.67 GHz, in a test 219 using extremely difficult 720p material and encoding at a target data 220 rate of 2 Mbit/sec, VP8's encoding speed varied from 48.4 fps (at the 221 setting used in WebRTC today) to 96.2 fps (at the fastest setting), 222 using a single thread. This variation in encode speed is achieved by 223 changing the configuration of VP8 encoding tools in a deterministic 224 way to trade-off encoding speed with output quality. 226 On a stock PC platform using an Intel Xeon CPU with 8 cores at 227 2.27GHz, tests using difficult 720p material encoded at 2 Mbit/sec 228 show that using a single thread VP8 can decode at 200.50 fps (in 229 comparison H.264, baseline profile, achieves 107.95 fps), using four 230 threads VP8 decodes at 519.96 fps (H.264 achieves 363.73 fps), and 231 using sixteen threads VP8 decodes at 1,076.49 fps (H.264 achieves 232 807.11 fps). 234 6.2. Hardware support 236 NOTE: This section contains mostly information that was valid as of 237 October 2012. It will be updated. 239 As of October 2012, Google has licensed VP8 hardware accelerators to 240 over 50 chip manufacturers, and VP8 hardware IP cores have also been 241 made available by Imagination Technologies, Verisilicon and Chips & 242 Media. Furthermore, Google is aware of several 3rd party 243 implementations of VP8 decoders and encoders from the world's leading 244 semiconductor companies. 246 As of October 2012, more than a dozen chip manufacturers had 247 announced chips with 1080p VP8 support, including Samsung (Exynos 5), 248 NVIDIA (Tegra 3, Tegra 4), Marvell (Armada 1500), Broadcom 249 (BCM28150), Texas Instruments (OMAP54xx), Freescale (i.MX 6), ST- 250 Ericsson (NovaThor L9540), LG Electronics, Hisilicon (K3v2), Rockchip 251 (RK2918, RK3066), Nufront (NS115), Ziilabs (ZMS40) and Allwinner 252 (A10). Google estimates that a clear majority of leading mobile 253 chipsets in 2013 will contain VP8 hardware support. (Nvidia Tegra4 254 info added after October 2012). 256 The encoder chip produced by Quanta has allowed OEMs to integrate 257 hardware HD VP8 encoding into their video camera hardware; this chip 258 is available now. More suppliers have such a chip coming. 260 The ChromeCast device, which is selling in significant numbers in the 261 US, has VP8 hardware decode. 263 6.3. Hardware performance 265 Several of the aforementioned hardware implementations are based on 266 the WebM video hardware designs described at 267 http://www.webmproject.org/hardware/. Performance figures include: 269 o Decode of 1080p video at 30 fps at less than 100 MHz clock 270 frequency 272 o Decoding more than ten simultaneous SD video streams on a single 273 chip 275 o Less than 25 milliwatts of power for 1080p decoding 277 o Encoding 1080p video at 30 fps at less than 220 MHz clock 278 frequency 280 o Less than 80 milliwatts of power for HD video encoding 282 Based on the Hantro G1 multiformat decoder implementation, the VP8 283 hardware decoder is 45% smaller in silicon area than the H.264 High 284 Profile decoder. VP8 also requires 18% less DRAM bandwidth than 285 H.264 as it does not use bidirectional inter prediction, allowing 286 significant reductions in the overall decoding system power 287 consumption. 289 7. IPR status 291 The IETF has a long tradition of preferring non-encumbered IPR 292 whenever possible, and especially to avoid IPR where using the 293 technoogy requires making agreements with and payments to third 294 parties as part of the cost of doing business. Among the reasons for 295 this tradition is that the requirement for IPR agreements severely 296 distorts the competitive landscape, and especially that it seriously 297 hampers people attempting to implement standards in open source, or 298 other business models where counting the number of installations or 299 users is difficult, expensive or simply impossible. 301 As of this moment (October 4, 2013), the following IPR disclosures 302 are filed in the IETF IPR database: 304 o https://datatracker.ietf.org/ipr/1571/ - by Google, declaring that 305 the technology is royalty-free. 307 o https://datatracker.ietf.org/ipr/2035/ - by Nokia, which does not 308 declare a royalty-free license. 310 The licensing terms for Google's IPR are available at 311 http://www.webmproject.org/license/additional/. 313 The Nokia IPR mentioned above includes IPR that has been asserted in 314 ongoing litigation in Germany (Nokia v. HTC, District Court in 315 Mannheim, Germany. 7 O 201/12); on one of the patents, the court has 316 ruled that the phones in question (which support VP8) are not 317 infringing. As mentioned in 318 http://blog.webmproject.org/2013/08/good-news-from-germany.html?m=0; 319 the case is still ongoing. 321 The following companies have asserted that any IPR relevant to VP8 322 they might have is available for licensing by Google under a royalty 323 free license; the licensing terms are available at 324 http://www.webm-ccl.org/vp8/agreement/, as well as details on the 325 licensors: 327 o CIF Licensing LLC 329 o France Telecom 331 o Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung 332 e.V. 334 o Fujitsu Limited 336 o Koninklijke Philips Electronics N.V. 338 o LG Electronics Inc. 340 o Mitsubishi Electric Corporation 342 o MPEG LA, LLC 344 o NTT DOCOMO, INC 346 o Panasonic Corporation 348 o Samsung Electronics Co., Ltd. 350 o Siemens Corporation 352 The license can be executed on-line from the link given above. 354 8. IANA Considerations 356 This document makes no request of IANA. 358 Note to RFC Editor: this section may be removed if this document is 359 ever published as an RFC. 361 9. Security Considerations 363 Codec definitions do not in themselves comprise security risks, as 364 long as there is no means of embedding active content in their 365 datastream. VP8 does not contain such active content. 367 Codec implementations have frequently been the cause of security 368 concerns. The reference implementation of VP8 has been extensively 369 tested by Google security experts, and is believed to be free from 370 exploitable vulnerabilities. There is a continuous program in place 371 to ensure that any vulnerabilities identified are repaired as quickly 372 as possible. 374 10. Acknowledgements 376 Several members of the Google VP8 team contributed to this memo. 378 In addition, we wish to thank the people from the X264 mailing list 379 who came forward with suggested improvements in the codec settings 380 for the objective performance evaluations, Bo Burmann who re-ran the 381 tests entirely independently of Google, Mohammed Raad and Lazar 382 Bivolarski who prepared the materials for the subjective evaluation 383 tests and Vittorio Baronici who performed them, and all the countless 384 members of the RTCWEB working group who have debated extensively the 385 matter of mandatory to implement video codecs. 387 11. References 389 11.1. Normative References 391 [I-D.ietf-payload-vp8] 392 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 393 Galligan, "RTP Payload Format for VP8 Video", 394 draft-ietf-payload-vp8-09 (work in progress), July 2013. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 400 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 401 Guide", RFC 6386, November 2011. 403 11.2. Informative References 405 [I-D.ietf-rtcweb-overview] 406 Alvestrand, H., "Overview: Real Time Protocols for Brower- 407 based Applications", draft-ietf-rtcweb-overview-08 (work 408 in progress), September 2013. 410 Authors' Addresses 412 Harald Alvestrand 413 Google 414 Kungsbron 2 415 Stockholm, 11122 416 Sweden 418 Email: harald@alvestrand.no 420 Adrian Grange 421 Google 422 1950 Charleston Road 423 Mountain View, CA 94043 424 USA 426 Phone: 427 Fax: 428 Email: agrange@google.com 429 URI: