idnits 2.17.1 draft-dbenham-webrtc-videomti-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 15, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCweb Working Group D. Benham 3 Internet-Draft C. Jennings 4 Intended status: Informational Cisco 5 Expires: April 18, 2013 D. Singer 6 K. Kolarov 7 Apple 8 October 15, 2012 10 H.264/AVC as Mandatory-to-Implement Video Codec for RTCweb 11 draft-dbenham-webrtc-videomti-00 13 Abstract 15 This memo proposes that H.264/AVC be selected as the mandatory-to- 16 implement (MTI) video codec for RTCweb due to is Adoption Advantage, 17 Quality-Power-Bandwidth advantage, Hardware Acceleration Advantage 18 and Well-established IPR Status. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 18, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. H.264/AVC Adoption Advantage . . . . . . . . . . . . . . . . . 3 57 4. H.264/AVC has the Quality-Power-Bandwidth advantage . . . . . . 4 58 5. Hardware Acceleration Advantage . . . . . . . . . . . . . . . . 5 59 6. Well-Established IPR Status for H.264/AVC . . . . . . . . . . . 6 60 6.1. Disclosed and Publicly Available Lists of Patents . . . . . 6 61 6.2. Royalty Free for Innovation, Low-volume shipments . . . . . 6 62 6.3. Higher H.264/AVC Profile Tools Bundled . . . . . . . . . . 6 63 6.4. Future IPR Status Consideration . . . . . . . . . . . . . . 7 64 7. Questions about IPR Status of VP8 . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This memo offers a proposal that H.264/AVC be selected as the 75 mandatory-to-implement (MTI) video codec for RTCweb. This document 76 asserts that the constrained baseline profile is the likely best 77 choice and uses it to make certain points. However, the author(s) 78 are open to assertions that other H.264/AVC profile(s) should be 79 additionally mandated or recommended. 81 This document is not intended for publication as an RFC. 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. H.264/AVC Adoption Advantage 91 H.264/AVC is widely used for enterprise videoconferencing equipment 92 and services. High-definition (HD), web videoconferencing commonly 93 uses H.264/AVC as well, including Skype. 95 H.264/AVC is becoming the de-facto standard for the Mobile web and 96 3GPP has recommended the H.264/AVC [AVC01] codec along with the 97 mandatory H.263. Apple's iOS, Google's Android, RIM's Blackberry and 98 Ericsson's mobile device platforms all support H.264/AVC. 100 Web (entertainment) video is dominated by H.264/AVC, and increasingly 101 "multi-screen/BYOD" video services from cable companies and telco's 102 are using H.264/AVC over their private web video networks 104 Thus, HTML5 browsers will likely need to have the H.264/AVC codec 105 regardless to remain popular. Internet Explorer and Safari appear to 106 be including H.264/AVC in the set of codecs they ship regardless of 107 the RTCweb video codec MTI decision. And Google's Chrome continues 108 shipping with H.264/AVC today. 110 We assert that the lack of clearly indicating that H.264/AVC was the 111 mandatory video codec for HTML5's video tag has created uncertainty 112 and increased costs for those deploying sites or developing 113 applications trying to cover multiple possible codecs instead. 115 Mandating the H.264/AVC codec for RTCweb is in the best interest of 116 rapid adoption given it is already pervasive deployed and used in 117 real-time communications and web video applications. 119 4. H.264/AVC has the Quality-Power-Bandwidth advantage 121 First, we believe that mobile devices will be important to the 122 success of RTCweb going forward. They generally have slower CPUs 123 than desktop computers and maximizing battery life is extremely 124 important. 126 Second, we assert that the three (3) most important factors to 127 analyze in that context are a) the user experience or perceptual 128 quality of the resultant video images, b) the amount of compute or 129 CPU power applied to do the compression - this correlates with 130 electrical power consumption, and c) the amount of bandwidth 131 available or consumed. All three factors must be considered together 132 as they are interrelated. 134 For a given bitrate, a codec can improve the quality by doing more 135 computation, but that will drain power quicker. While 4G/LTE brings 136 more bandwidth to the equation, error properties of the medium and/or 137 mobile data transmission costs will still put pressure on 138 implementers to minimize bandwidth utilized by RTCweb streams. 139 Throwing bandwidth at the problem is not a good assumption to improve 140 quality while keeping CPU power constant. 142 We quickly captured examples of leading H.264/AVC and VP8 products on 143 popular mobile and desktop platforms and came to the conclusion that 144 H.264 looks better than VP8 when both are run on same platform at the 145 same bitrates. 147 It is very hard in making tests to try and decide what parameters to 148 use for codecs in a way that does not bias tests. So instead, we 149 choose the "best in class" products that we could find to demonstrate 150 performance comparisons. 152 Captures of Mobile Tests; 154 FaceTime using H.264 on an iPhone to linphone on a fast desktop PC. 155 http://dl.dropbox.com/u/17089001/video-samples/facetime.mov 157 Bria using VP8 on iPhone to linphone on a fast desktop PC. http:// 158 dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov 160 Bria using VP8 on Galaxy Nexus to linphone on a fast desktop PC. 161 http://dl.dropbox.com/u/17089001/video-samples/galaxy-nexus.mov 163 Shown side-by-side, Bria using VP8 on iPhone (left) and FaceTime with 164 H.264/AVC on iPhone (right), going to linphone and FaceTime. http:// 165 dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov 166 Captures of Desktop-only Tests; 168 FaceTime H.264/AVC from a fast notebook computer to fast desktop. htt 169 p://dl.dropbox.com/u/17089001/video-samples/facetime-264-desktop.mov 171 -or- http://dl.dropbox.com/u/17089001/video-samples/ 172 facetime-264-desktop.webm 174 Chrome with VP8 from same fast notebook computer to same fast 175 desktop. 176 http://dl.dropbox.com/u/17089001/video-samples/chrome-vp8-desktop.mov 178 -or- http://dl.dropbox.com/u/17089001/video-samples/ 179 chrome-vp8-desktop.webm 181 Two fast notebook computers - one running Chrome and the other 182 running Fictive - both sending to the same desktop computer shown 183 side by side. http://dl.dropbox.com/u/17089001/video-samples/ 184 chrome_and_factime_desktop.mov> 186 -or- http://dl.dropbox.com/u/17089001/video-samples/ 187 chrome_and_factime_desktop.webm 189 The tests and resultant captures were done on a fast wireless network 190 with no other traffic on the wireless network, with the exception of 191 the side by side demo. For the sides by side demo above, both 192 devices were on the same WiFi network but did not seem to be having 193 any losses or coming close to filling the network. The results in 194 the side by side seemed to be the same as when there were run 195 independently so we do not believe that having them both on the same 196 network impacted results. 198 Of course, these results do not preclude implementations improving in 199 the future, but this gives some idea of the current state of the art. 201 Our conclusion is that H.264/AVC is best at delivering on the 202 Quality-Power-Bandwidth optimization. 204 5. Hardware Acceleration Advantage 206 H.264/AVC has a several year head start on hardware/DSP optimization 207 and is already deployed pervasively. For handheld mobile phones, 208 hardware acceleration is a must to maximize Quality-Power-Bandwidth. 210 H.264/AVC hardware is already incredibly inexpensive. Some of the 211 low end consumer cameras will record H.264/AVC video, such as this 212 sub-100 US dollar (<$100) Powershot A810 from Cannon. [AVC07] 214 6. Well-Established IPR Status for H.264/AVC 216 6.1. Disclosed and Publicly Available Lists of Patents 218 As typical with many standards bodies, the joint work of ITU/MPEG 219 that produced H.264/AVC has a common patent policy requiring 220 disclosure by participants and third parties of any known patents or 221 patent applications that may be essential to implement specifications 222 in development. These can be downloaded in spreadsheet format 223 [AVC02]. The policy goes on to ask contributors to pre-agree to 224 either RAND (reasonable & non-discriminatory, but may not be free) or 225 royalty-free licensing of their own company's patents, with or 226 without reciprocal requirements. There is some anecdotal evidence to 227 suggest US courts consider such disclosure requirements [AVC03] in 228 patent lawsuit decisions. 230 While all that alone doesn't guarantee 100% visibility of all 231 possible essential patent claims, H.264/AVC was finished in late 2003 232 and has been commercially shipping at scale for 6-7 years or more 233 which should have brought to light any other patent holders 234 interested in enforcing or collecting on their essential patents. 236 Over 300 patents (more if counting multiple jurisdictions) covering 237 mechanisms spanning several of AVC's profiles are licensed via the 238 MPEG LA H.264/AVC licensing program and are publicly listed [AVC04]. 240 The risk of an unknown, essential patent appearing at this point 241 should be comparatively low, which would be a benefit to selecting a 242 H.264/AVC profile as the mandatory codec. 244 6.2. Royalty Free for Innovation, Low-volume shipments 246 To paraphrase, the MPEG LA license [AVC05] does allow up to 100K 247 units per year, per legal entity/company (type "a" sublicensees in 248 MPEG LA's definition), to be shipped for zero ($0) royalty cost. 249 This should be adequate for many RTCweb innovators or start-ups to 250 try out new implementations on a large set of users before incurring 251 any patent royalty costs, a benefit to selecting a H.264/AVC profile 252 as the mandatory codec. 254 6.3. Higher H.264/AVC Profile Tools Bundled 256 It should be noted that when one licenses the MPEG LA H.264/AVC pool 257 [AVC04], patents for higher profile tools - such as CABAC, 8x8 - are 258 bundled in with those required for the constrained baseline profile. 259 Thus, these could optionally be used by RTCweb implementers to 260 achieve even greater performance or efficiencies than using H.264 261 constrained baseline alone, a benefit to selecting H.264/AVC and 262 RTCweb could also go as far as recommending those higher profiles. 264 6.4. Future IPR Status Consideration 266 For additional informative purposes, the MPEG/IEC/ISO made a call for 267 a royalty-free video coding solution for the Internet. As of its 268 98th meeting, two tracks forward are being pursued; one of which is 269 based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is 270 presently collecting patent licensing declarations that would include 271 patent holder's royalty expectations unbundled from other higher 272 profile mechanisms. Should this effort result in a royalty-free 273 constrained baseline profile, this would benefit RTCweb in the future 274 if H.264/AVC is selected as mandatory today. 276 7. Questions about IPR Status of VP8 278 For the purposes of further illustrating the benefits of the well- 279 known IPR status of H.264/AVC, what follows are some comparisons to 280 the unknowns that surround VP8 as of the writing of this 281 contribution. Information that resolves the open questions below is 282 welcomed. 284 First, Google should be commended for offering their essential 285 patents on VP8 royalty-free. However, other patent holders -- 286 including ones not licensees of VP8/WebM -- may exist as suggested by 287 all the respondents to MPEG LA's call for a VP8 essential patent 288 pool. Also, VP8 was not developed openly in a standards body and 289 thus subjected to the prescribed essential patent disclosures, etc. 291 Second, others have previously advocated that the lack of lawsuits 292 against shipping VP8 implementations to date means all is ok. VP8 293 has been shipping a shorter time compared to H.264/AVC and the finite 294 number of companies that have shipped it to date may have, for 295 example, sufficiently large patent portfolios themselves to have 296 discouraged others from starting such a VP8 lawsuit against them. 297 Bottom line is that it isn't a good argument that no prior lawsuits 298 are an implicit indication of low risk to future patent lawsuit for 299 VP8. 301 +------------------------------------------+-------------+----------+ 302 | Attribute | AVC | VP8 | 303 +------------------------------------------+-------------+----------+ 304 | Developed Openly in Standards Body | Yes | No | 305 | - | | | 306 | Required Patent Disclosures and/or | Yes | No | 307 | predeclared RAND or similar licensing | | | 308 | promise | | | 309 | - | | | 310 | Open Source implementation | Yes | Yes | 311 | - | | | 312 | Patent Royalties | Yes for | None | 313 | | >100KU per | Known | 314 | | yr | (*) | 315 +------------------------------------------+-------------+----------+ 317 Table 1: Comparison of H.264/AVC & VP8 IPR Status Impacting Features 319 (*) A dozen or so companies responded to MPEG LA's call for essential 320 patents on VP8, but a license for that has not been published and 321 fees that may be asked for in the future is unknown. 323 As suggested by Table 1, sufficient time and open, industry 324 development along with the prescribed patent disclosures is 325 beneficial to be more certain of the risks with shipping the chosen 326 mandatory codec. 328 Not having the benefit of a longer deployment duration and open, 329 industry development for VP8, the following questions result; 331 (a) Like MPEG/IEC/ISO, can Google list the present patents covered 332 in its VP8 license (of course it is noted that any future Google 333 owned essential patents are supposed to be included too)? 335 (b) Does Google, or anyone else involved in any patent analysis, 336 know of any third-parties with viable essential patent claims on 337 VP8? c) If any in (b), are they not a concern? Why? 339 (c) If any in (b), are they not a concern? Why? 341 (d) If Google is certain there is no concern regarding (b) & (c), 342 can Google provide some assurance (such as indemnification) to the 343 VP8 licensees and thus indirectly assuring the RTCweb working 344 group? 346 8. Security Considerations 348 TBD. 350 9. IANA Considerations 352 None. 354 10. References 356 10.1. Normative References 358 10.2. Informative References 360 [AVC01] 3GPP, TS 26., "Packet switched conversational multimedia 361 applications; Default codecs", 2008, 362 . 364 [AVC02] ISO, "ISO Standards and Patent\s", April 2006, 365 . 367 [AVC03] US Federal Court, "QUALCOMM INCORPORATED v. BROADCOM 368 CORPORATION", December 2008, 369 . 372 [AVC04] MPEG LA, "MPEG LA H.264 AVC Patent Pool - Attachment 1", 373 August 2012, . 376 [AVC05] MPEG LA, "SUMMARY OF AVC/H.264 LICENSE TERMS", unknown, . 380 [AVC06] MPEG, ISO., "Working Draft 2 of ISO/IEC 14496-29 Web Video 381 Coding", 2012, . 384 [AVC07] Cannon Inc, "Powershot A810 Specifications", 2012, . 388 Authors' Addresses 390 David Benham 391 Cisco 392 170 West Tasman Drive 393 San Jose, CA 95134 394 United States 396 Email: dbenham@cisco.com 398 Cullen 399 Cisco 400 170 West Tasman Drive 401 San Jose, CA 95134 402 United States 404 Email: fluffy@cisco.com 406 David Singer 407 Apple 409 Email: singer@apple.com 411 Krasimir Kolarov 412 Apple 414 Email: kolarov@apple.com