Network Working Group H. T. Alvestrand
Internet-Draft A. Grange
Intended status: Informational Google
Expires: April 16, 2013 October 15, 2012

VP8 as RTCWEB Mandatory to Implement


This document recommends that the RTCWEB working group choose the VP8 specification as a mandatory to implement video codec for RTCWEB implementations.

This document is not intended for publication as an RFC.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 16, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

As described in [I-D.ietf-rtcweb-overview], successful interoperable deployment of RTCWEB requires that implementations share a video codec. Not requiring a video codec will mean that this decision is left to processes outside the standards process, and risks the spectre of fragmented deployment.

This memo argues that VP8 should be that codec.

2. Requirements for an MTI codec

As outlined by the presentation given at the IETF meeting at IETF 84 in Vancouver, it is unclear what the hard requirements for a video codec are, but the items that it was suggested that proposals give information on were:

This document lays out the available information in each category.

3. Definition of VP8

VP8 is defined in [RFC6386], and its RTP payload is defined in [I-D.ietf-payload-vp8] . There are no profiles; all decoders are able to decode all valid media streams.

4. Image quality evaluations

In tests carried out by Google on a set of ten sample video clips containing typical video-conference content, VP8 outperformed the x264 H.264 codec running the constrained baseline profile by on average 37.2%. That is, at the same quality, measured by PSNR, VP8 produced 37.2% fewer bits on average than H.264. VP8 outperformed H.264 on all ten of the test clips by between 19% and 64%. Both codecs were configured in one-pass mode using settings conducive to real-time operation, and the ten clips varied in size between 640x360 pixels and 1280x720 pixels.

An independent evaluation by Christian Feller and Mohammed Raad, presented to ISO/IEC SC29 WG11 in July 2012, showed that VP8 performed better than the (H.264 baseline) anchors for the IVC project on a majority of the cases.

5. Performance evaluation

5.1. Software

The current reference implementation is libvpx, developed in the WebM project.

The encoding speed in software depends on the quality setting. On a stock PC platform using an Intel Xeon CPU at 2.67 GHz, in a test using extremely difficult 720p material and encoding at a target data rate of 2 Mbit/sec, VP8's encoding speed varied from 48.4 fps (at the setting used in WebRTC today) to 96.2 fps (at the fastest setting), using a single thread. This variation in encode speed is achieved by changing the configuration of VP8 encoding tools in a deterministic way to trade-off encoding speed with output quality.

On a stock PC platform using an Intel Xeon CPU with 8 cores at 2.27GHz, tests using difficult 720p material encoded at 2 Mbit/sec show that using a single thread VP8 can decode at 200.50 fps (in comparison H.264, baseline profile, achieves 107.95 fps), using four threads VP8 decodes at 519.96 fps (H.264 achieves 363.73 fps), and using sixteen threads VP8 decodes at 1,076.49 fps (H.264 achieves 807.11 fps). .

5.2. Hardware support

To date, Google has licensed VP8 hardware accelerators to over 50 chip manufacturers, and VP8 hardware IP cores have also been made available by Imagination Technologies, Verisilicon and Chips & Media. Furthermore, Google is aware of several 3rd party implementations of VP8 decoders and encoders from the world’s leading semiconductor companies.

At the time of this writing, more than a dozen of chip manufacturers have announced chips with 1080p VP8 support, including Samsung (Exynos 5), NVIDIA (Tegra 3), Marvell (Armada 1500), Broadcom (BCM28150), Texas Instruments (OMAP54xx), Freescale (i.MX 6), ST-Ericsson (NovaThor L9540), LG Electronics, Hisilicon (K3v2), Rockchip (RK2918, RK3066), Nufront (NS115), Ziilabs (ZMS40) and Allwinner (A10). Google estimates that a clear majority of leading mobile chipsets in 2013 will contain VP8 hardware support.

5.3. Hardware performance

Several of the aforementioned hardware implementations are based on the WebM video hardware designs described at Performance figures include:

Based on the Hantro G1 multiformat decoder implementation, the VP8 hardware decoder is 45% smaller in silicon area than the H.264 High Profile decoder. VP8 also requires 18% less DRAM bandwidth than H.264 as it does not use bidirectional inter prediction, allowing significant reductions in the overall decoding system power consumption.

6. IPR status

Google has made its position clear with respect to Google-owned IPR in its licensing terms,

As of this moment (October 5, 2012), Google's royalty-free license commitment is the only IPR statement filed against RFC 6386 in the IETF disclosures database.

7. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

8. Security Considerations

Codec definitions do not in themselves comprise security risks, as long as there is no means of embedding active content in their datastream. VP8 does not contain such active content.

Codec implementations have frequently been the cause of security concerns. The reference implementation of VP8 has been extensively tested by Google security experts, and is believed to be free from exploitable vulnerabilities. There is a continuous program in place to ensure that any vulnerabilities identified are repaired as quickly as possible.

9. Acknowledgements

Several members of the Google VP8 team contributed to this memo.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P. and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, November 2011.
[I-D.ietf-payload-vp8] Westin, P, Lundin, H, Glover, M, Uberti, J and F Galligan, "RTP Payload Format for VP8 Video", Internet-Draft draft-ietf-payload-vp8-01, July 2011.

10.2. Informative References

[I-D.ietf-rtcweb-overview] Alvestrand, H, "Overview: Real Time Protocols for Brower-based Applications", Internet-Draft draft-ietf-rtcweb-overview-01, August 2011.

Authors' Addresses

Harald Alvestrand Google Kungsbron 2 Stockholm, 11122 Sweden EMail:
Adrian Grange Google 1950 Charleston Road Mountain View, CA 94043 USA EMail: