idnits 2.17.1 draft-alvestrand-rtcweb-vp8-01.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 (February 25, 2013) is 4076 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-08 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-05 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: August 29, 2013 February 25, 2013 7 VP8 as RTCWEB Mandatory to Implement 8 draft-alvestrand-rtcweb-vp8-01 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 August 29, 2013. 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. Definition of VP8 . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Image quality evaluations . . . . . . . . . . . . . . . . . . . 3 62 5. Performance evaluation . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. Hardware support . . . . . . . . . . . . . . . . . . . . . 4 65 5.3. Hardware performance . . . . . . . . . . . . . . . . . . . 5 66 6. IPR status . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 As described in [I-D.ietf-rtcweb-overview], successful interoperable 78 deployment of RTCWEB requires that implementations share a video 79 codec. Not requiring a video codec will mean that this decision is 80 left to processes outside the standards process, and risks the 81 spectre of fragmented deployment. 83 This memo argues that VP8 should be that codec. 85 2. Requirements for an MTI codec 87 As outlined by the presentation given at the IETF meeting at IETF 84 88 in Vancouver, it is unclear what the hard requirements for a video 89 codec are, but the items that it was suggested that proposals give 90 information on were: 92 o Image quality - comparative data was sought, but without defining 93 a baseline 95 o Performance - what resolutions / frame rates can be achieved in 96 software on some common systems 98 o Power consumption of hardware and/or software implementations 100 o Hardware support 102 o IPR status 104 This document lays out the available information in each category. 106 3. Definition of VP8 108 VP8 is defined in [RFC6386], and its RTP payload is defined in 109 [I-D.ietf-payload-vp8] . There are no profiles; all decoders are 110 able to decode all valid media streams. 112 4. Image quality evaluations 114 In tests carried out by Google on a set of ten sample video clips 115 containing typical video-conference content, VP8 outperformed the 116 x264 H.264 codec running the constrained baseline profile by on 117 average 37.2%. That is, at the same quality, measured by PSNR, VP8 118 produced 37.2% fewer bits on average than H.264. VP8 outperformed 119 H.264 on all ten of the test clips by between 19% and 64%. Both 120 codecs were configured in one-pass mode using settings conducive to 121 real-time operation, and the ten clips varied in size between 640x360 122 pixels and 1280x720 pixels. 124 An independent evaluation by Christian Feller and Mohammed Raad, 125 presented to ISO/IEC SC29 WG11 in July 2012, showed that VP8 126 performed better than the (H.264 baseline) anchors for the IVC 127 project on a majority of the cases. 129 As part of the process of submitting VP8 for evaluation in ISO/IEC 130 JTC1 SC29 WG11 (MPEG), Google is also commissioning an independent 131 subjective quality evaluation effort. 133 5. Performance evaluation 135 5.1. Software 137 The current reference implementation is libvpx, developed in the WebM 138 project. 140 The encoding speed in software depends on the quality setting. On a 141 stock PC platform using an Intel Xeon CPU at 2.67 GHz, in a test 142 using extremely difficult 720p material and encoding at a target data 143 rate of 2 Mbit/sec, VP8's encoding speed varied from 48.4 fps (at the 144 setting used in WebRTC today) to 96.2 fps (at the fastest setting), 145 using a single thread. This variation in encode speed is achieved by 146 changing the configuration of VP8 encoding tools in a deterministic 147 way to trade-off encoding speed with output quality. 149 On a stock PC platform using an Intel Xeon CPU with 8 cores at 150 2.27GHz, tests using difficult 720p material encoded at 2 Mbit/sec 151 show that using a single thread VP8 can decode at 200.50 fps (in 152 comparison H.264, baseline profile, achieves 107.95 fps), using four 153 threads VP8 decodes at 519.96 fps (H.264 achieves 363.73 fps), and 154 using sixteen threads VP8 decodes at 1,076.49 fps (H.264 achieves 155 807.11 fps). . 157 5.2. Hardware support 159 To date, Google has licensed VP8 hardware accelerators to over 50 160 chip manufacturers, and VP8 hardware IP cores have also been made 161 available by Imagination Technologies, Verisilicon and Chips & Media. 162 Furthermore, Google is aware of several 3rd party implementations of 163 VP8 decoders and encoders from the world's leading semiconductor 164 companies. 166 At the time of this writing, more than a dozen of chip manufacturers 167 have announced chips with 1080p VP8 support, including Samsung 168 (Exynos 5), NVIDIA (Tegra 3), Marvell (Armada 1500), Broadcom 169 (BCM28150), Texas Instruments (OMAP54xx), Freescale (i.MX 6), ST- 170 Ericsson (NovaThor L9540), LG Electronics, Hisilicon (K3v2), Rockchip 171 (RK2918, RK3066), Nufront (NS115), Ziilabs (ZMS40) and Allwinner 172 (A10). Google estimates that a clear majority of leading mobile 173 chipsets in 2013 will contain VP8 hardware support. 175 The encoder chip produced by Quanta has allowed OEMs to integrate 176 hardware HD VP8 encoding into their video camera hardware; this chip 177 is available now. More suppliers have such a chip coming. 179 5.3. Hardware performance 181 Several of the aforementioned hardware implementations are based on 182 the WebM video hardware designs described at 183 http://www.webmproject.org/hardware/. Performance figures include: 185 o Decode of 1080p video at 30 fps at less than 100 MHz clock 186 frequency 188 o Decoding more than ten simultaneous SD video streams on a single 189 chip 191 o Less than 25 milliwatts of power for 1080p decoding 193 o Encoding 1080p video at 30 fps at less than 220 MHz clock 194 frequency 196 o Less than 80 milliwatts of power for HD video encoding 198 Based on the Hantro G1 multiformat decoder implementation, the VP8 199 hardware decoder is 45% smaller in silicon area than the H.264 High 200 Profile decoder. VP8 also requires 18% less DRAM bandwidth than 201 H.264 as it does not use bidirectional inter prediction, allowing 202 significant reductions in the overall decoding system power 203 consumption. 205 6. IPR status 207 Google has made its position clear with respect to Google-owned IPR 208 in its licensing terms, 209 http://www.webmproject.org/license/additional/. 211 As of this moment (October 5, 2012), Google's royalty-free license 212 commitment is the only IPR statement filed against RFC 6386 in the 213 IETF disclosures database. 215 Google has also submitted VP8 for consideration in ISO/IEC JTC1 SC29 216 WG11 (MPEG), in the IVC project (which aims for a royalty-free 217 codec), and expects ISO to execute its ordinary process for 218 resolution of IPR issues. 220 7. IANA Considerations 222 This document makes no request of IANA. 224 Note to RFC Editor: this section may be removed on publication as an 225 RFC. 227 8. Security Considerations 229 Codec definitions do not in themselves comprise security risks, as 230 long as there is no means of embedding active content in their 231 datastream. VP8 does not contain such active content. 233 Codec implementations have frequently been the cause of security 234 concerns. The reference implementation of VP8 has been extensively 235 tested by Google security experts, and is believed to be free from 236 exploitable vulnerabilities. There is a continuous program in place 237 to ensure that any vulnerabilities identified are repaired as quickly 238 as possible. 240 9. Acknowledgements 242 Several members of the Google VP8 team contributed to this memo. 244 10. References 246 10.1. Normative References 248 [I-D.ietf-payload-vp8] 249 Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 250 Galligan, "RTP Payload Format for VP8 Video", 251 draft-ietf-payload-vp8-08 (work in progress), 252 January 2013. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 258 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 259 Guide", RFC 6386, November 2011. 261 10.2. Informative References 263 [I-D.ietf-rtcweb-overview] 264 Alvestrand, H., "Overview: Real Time Protocols for Brower- 265 based Applications", draft-ietf-rtcweb-overview-05 (work 266 in progress), December 2012. 268 Authors' Addresses 270 Harald Alvestrand 271 Google 272 Kungsbron 2 273 Stockholm, 11122 274 Sweden 276 Email: harald@alvestrand.no 278 Adrian Grange 279 Google 280 1950 Charleston Road 281 Mountain View, CA 94043 282 USA 284 Phone: 285 Fax: 286 Email: agrange@google.com 287 URI: