[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                      H. Alvestrand
Internet-Draft                                                 A. Grange
Intended status: Informational                                    Google
Expires: April 9, 2014                                   October 6, 2013


                  VP8 as RTCWEB Mandatory to Implement
                     draft-alvestrand-rtcweb-vp8-02

Abstract

   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://datatracker.ietf.org/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 9, 2014.

Copyright Notice

   Copyright (c) 2013 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://trustee.ietf.org/license-info) in effect on the date of



Alvestrand & Grange       Expires April 9, 2014                 [Page 1]


Internet-Draft                   VP8 MTI                    October 2013


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements for an MTI codec  . . . . . . . . . . . . . . . .  3
   3.  Specification status . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  VP8 standardization status . . . . . . . . . . . . . . . .  3
   4.  Deployment status  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Image quality evaluations  . . . . . . . . . . . . . . . . . .  4
     5.1.  Objective evaluations  . . . . . . . . . . . . . . . . . .  4
     5.2.  Subjective evaluations . . . . . . . . . . . . . . . . . .  5
   6.  Performance evaluation . . . . . . . . . . . . . . . . . . . .  5
     6.1.  Software . . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.2.  Hardware support . . . . . . . . . . . . . . . . . . . . .  6
     6.3.  Hardware performance . . . . . . . . . . . . . . . . . . .  6
   7.  IPR status . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2. Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





















Alvestrand & Grange       Expires April 9, 2014                 [Page 2]


Internet-Draft                   VP8 MTI                    October 2013


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:

   o  Image quality - comparative data was sought, but without defining
      a baseline

   o  Performance - what resolutions / frame rates can be achieved in
      software on some common systems

   o  Power consumption of hardware and/or software implementations

   o  Hardware support

   o  IPR status

   This document lays out the available information in each category.


3.  Specification status

   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.

   In the time since the original RFC publication, and indeed since the
   first publication of the VP8 bitstream format, there have been no
   changes to the decoder that broke bitstream compatibility.

3.1.  VP8 standardization status

   The VP8 codec has been proposed as a basis for standardization in
   MPEG, in response to its Call for Proposals for a royalty-free video
   codec.  At its meeting in Vienna, Austria in July 2013, following the



Alvestrand & Grange       Expires April 9, 2014                 [Page 3]


Internet-Draft                   VP8 MTI                    October 2013


   presentation of subjective and objective quality evaluation results,
   and a focused discussion of possible IPR issues, MPEG passed a
   resolution calling for the creation of a new project (Video Coding
   for Browsers, or VCB), with the aim of producing a final DIS document
   (FDIS) by July 2014.  (MPEG output document w13648).

   At the meeting of the US National Body of MPEG in October 013, the
   USNB passed a resolution supporting this work, and expressing a
   preference for "options that maintain a native VP8 mode" - that is,
   no incompatible changes.


4.  Deployment status

   The VP8 codec has been extensively deployed in production services:

   o  Skype (now part of Microsoft) used the codec extensively in its
      video conferencing software.

   o  Google Hangouts is now fully converted to using VP8 on the various
      PC platforms.  This platform now offers free videoconferencing in
      HD quality to everyone.

   o  Google Remote Desktop uses VP8.

   o  Google Chromecast uses VP8, showing what can be achieved with
      hardware decoding support.

   o  Both the Firefox and Chrome WebRTC implementations use VP8
      exclusively.


5.  Image quality evaluations

5.1.  Objective 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.

   The software and the clips are available via the WEBM project's GIT
   repository:



Alvestrand & Grange       Expires April 9, 2014                 [Page 4]


Internet-Draft                   VP8 MTI                    October 2013


   http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git

   Note: Tests run by Ericsson have demonstrated that it is possible to
   reduce the VP8 performance to be very close to that of baseline by
   running in "fixed QP" mode - selecting a single QP value in order to
   achieve a given bitrate.  We believe this VP8 mode is an unrealistic
   mode for production use, and not what we should be evaluating.

5.2.  Subjective evaluations

   As part of the process of submitting VP8 for evaluation in ISO/IEC
   JTC1 SC29 WG11 (MPEG), the VP8 codec has been subjected to subjective
   and objective quality evaluations; the input reports are in WG11
   documents N13775 (Vienna, MPEG 105 meeting, subjective numbers for
   VP8 performed by Vittorio Baroncini), M29364 (Incheon, subjective
   comparision between VP8 and IVC) and M28182 (Geneva, MPEG 103
   meeting), respectively.

   These tests were performed at the laboratories of Vittori Baronici,
   who is also a chair of the Testing subgroup of MPEG, and has
   performed many of the subjective tests done as part of the HEVC
   effort.

   Together with the tests presented in document M29364, we also asked
   Vittorio Baroncini to do a subjective evaluation of VP8 compared to
   the AVC Baseline; the results of this evaluation are given in a
   separate presentation.

   In all these cases, VP8 performed adequately in subjective
   evaluations; the numbers can be interpreted as showing that VP8 in
   "realtime" mode performed better than the "anchors" on both tests,
   but due to the amount of discussion occuring in the meetings about
   whether the precise parameters chosen for the tests made it a "fair"
   comparision, we will not state flatly that VP8 performed better than
   the anchors (AVC Baseline and AVC High Profile, respectively), but we
   will state flatly that there is no evicence that the anchors
   performed significantly better than VP8.


6.  Performance evaluation

6.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



Alvestrand & Grange       Expires April 9, 2014                 [Page 5]


Internet-Draft                   VP8 MTI                    October 2013


   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).

6.2.  Hardware support

   NOTE: This section contains mostly information that was valid as of
   October 2012.  It will be updated.

   As of October 2012, 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.

   As of October 2012, more than a dozen chip manufacturers had
   announced chips with 1080p VP8 support, including Samsung (Exynos 5),
   NVIDIA (Tegra 3, Tegra 4), 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.  (Nvidia Tegra4
   info added after October 2012).

   The encoder chip produced by Quanta has allowed OEMs to integrate
   hardware HD VP8 encoding into their video camera hardware; this chip
   is available now.  More suppliers have such a chip coming.

   The ChromeCast device, which is selling in significant numbers in the
   US, has VP8 hardware decode.

6.3.  Hardware performance

   Several of the aforementioned hardware implementations are based on
   the WebM video hardware designs described at



Alvestrand & Grange       Expires April 9, 2014                 [Page 6]


Internet-Draft                   VP8 MTI                    October 2013


   http://www.webmproject.org/hardware/.  Performance figures include:

   o  Decode of 1080p video at 30 fps at less than 100 MHz clock
      frequency

   o  Decoding more than ten simultaneous SD video streams on a single
      chip

   o  Less than 25 milliwatts of power for 1080p decoding

   o  Encoding 1080p video at 30 fps at less than 220 MHz clock
      frequency

   o  Less than 80 milliwatts of power for HD video encoding

   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.


7.  IPR status

   The IETF has a long tradition of preferring non-encumbered IPR
   whenever possible, and especially to avoid IPR where using the
   technoogy requires making agreements with and payments to third
   parties as part of the cost of doing business.  Among the reasons for
   this tradition is that the requirement for IPR agreements severely
   distorts the competitive landscape, and especially that it seriously
   hampers people attempting to implement standards in open source, or
   other business models where counting the number of installations or
   users is difficult, expensive or simply impossible.

   As of this moment (October 4, 2013), the following IPR disclosures
   are filed in the IETF IPR database:

   o  https://datatracker.ietf.org/ipr/1571/ - by Google, declaring that
      the technology is royalty-free.

   o  https://datatracker.ietf.org/ipr/2035/ - by Nokia, which does not
      declare a royalty-free license.

   The licensing terms for Google's IPR are available at
   http://www.webmproject.org/license/additional/.

   The Nokia IPR mentioned above includes IPR that has been asserted in



Alvestrand & Grange       Expires April 9, 2014                 [Page 7]


Internet-Draft                   VP8 MTI                    October 2013


   ongoing litigation in Germany (Nokia v.  HTC, District Court in
   Mannheim, Germany. 7 O 201/12); on one of the patents, the court has
   ruled that the phones in question (which support VP8) are not
   infringing.  As mentioned in
   http://blog.webmproject.org/2013/08/good-news-from-germany.html?m=0;
   the case is still ongoing.

   The following companies have asserted that any IPR relevant to VP8
   they might have is available for licensing by Google under a royalty
   free license; the licensing terms are available at
   http://www.webm-ccl.org/vp8/agreement/, as well as details on the
   licensors:

   o  CIF Licensing LLC

   o  France Telecom

   o  Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung
      e.V.

   o  Fujitsu Limited

   o  Koninklijke Philips Electronics N.V.

   o  LG Electronics Inc.

   o  Mitsubishi Electric Corporation

   o  MPEG LA, LLC

   o  NTT DOCOMO, INC

   o  Panasonic Corporation

   o  Samsung Electronics Co., Ltd.

   o  Siemens Corporation

   The license can be executed on-line from the link given above.


8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed if this document is
   ever published as an RFC.




Alvestrand & Grange       Expires April 9, 2014                 [Page 8]


Internet-Draft                   VP8 MTI                    October 2013


9.  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.


10.  Acknowledgements

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

   In addition, we wish to thank the people from the X264 mailing list
   who came forward with suggested improvements in the codec settings
   for the objective performance evaluations, Bo Burmann who re-ran the
   tests entirely independently of Google, Mohammed Raad and Lazar
   Bivolarski who prepared the materials for the subjective evaluation
   tests and Vittorio Baronici who performed them, and all the countless
   members of the RTCWEB working group who have debated extensively the
   matter of mandatory to implement video codecs.


11.  References

11.1.  Normative References

   [I-D.ietf-payload-vp8]
              Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
              Galligan, "RTP Payload Format for VP8 Video",
              draft-ietf-payload-vp8-09 (work in progress), July 2013.

   [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.

11.2.  Informative References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-



Alvestrand & Grange       Expires April 9, 2014                 [Page 9]


Internet-Draft                   VP8 MTI                    October 2013


              based Applications", draft-ietf-rtcweb-overview-08 (work
              in progress), September 2013.


Authors' Addresses

   Harald Alvestrand
   Google
   Kungsbron 2
   Stockholm,   11122
   Sweden

   Email: harald@alvestrand.no


   Adrian Grange
   Google
   1950 Charleston Road
   Mountain View, CA  94043
   USA

   Phone:
   Fax:
   Email: agrange@google.com
   URI:


























Alvestrand & Grange       Expires April 9, 2014                [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/