One document matched: draft-alvestrand-rtcweb-vp8-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-alvestrand-rtcweb-vp8-01"
     ipr="trust200902">
  <front>
    <title abbrev="VP8 MTI">VP8 as RTCWEB Mandatory to Implement</title>

    <author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand">
      <organization>Google</organization>

      <address>
        <postal>
          <street>Kungsbron 2</street>

          <city>Stockholm</city>

          <region></region>

          <code>11122</code>

          <country>Sweden</country>
        </postal>

        <email>harald@alvestrand.no</email>
      </address>
    </author>

    <author fullname="Adrian Grange" initials="A." surname="Grange">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1950 Charleston Road</street>

          <city>Mountain View</city>

          <region>CA</region>

          <code>94043</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>agrange@google.com</email>

        <uri></uri>
      </address>
    </author>

    <date day="25" month="February" year="2013" />

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

      <t>This document is not intended for publication as an RFC.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>As described in <xref target="I-D.ietf-rtcweb-overview"></xref>,
      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.</t>

      <t>This memo argues that VP8 should be that codec.</t>

      <t></t>
    </section>

    <section title="Requirements for an MTI codec">
      <t>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:</t>

      <t><list style="symbols">
          <t>Image quality - comparative data was sought, but without defining
          a baseline</t>

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

          <t>Power consumption of hardware and/or software implementations</t>

          <t>Hardware support</t>

          <t>IPR status</t>
        </list>This document lays out the available information in each
      category.</t>
    </section>

    <section title="Definition of VP8">
      <t>VP8 is defined in <xref target="RFC6386"></xref>, and its RTP payload
      is defined in <xref target="I-D.ietf-payload-vp8"></xref> . There are no
      profiles; all decoders are able to decode all valid media streams.</t>
    </section>

    <section title="Image quality evaluations">
      <t>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.</t>

      <t>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.</t>

      <t>As part of the process of submitting VP8 for evaluation in ISO/IEC
      JTC1 SC29 WG11 (MPEG), Google is also commissioning an independent
      subjective quality evaluation effort.</t>
    </section>

    <section title="Performance evaluation">
      <t></t>

      <section title="Software">
        <t>The current reference implementation is libvpx, developed in the
        WebM project.</t>

        <t>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.</t>

        <t>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). .</t>
      </section>

      <section title="Hardware support">
        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Hardware performance">
        <t>Several of the aforementioned hardware implementations are based on
        the WebM video hardware designs described at
        http://www.webmproject.org/hardware/. Performance figures include:</t>

        <t><list style="symbols">
            <t>Decode of 1080p video at 30 fps at less than 100 MHz clock
            frequency</t>

            <t>Decoding more than ten simultaneous SD video streams on a
            single chip</t>

            <t>Less than 25 milliwatts of power for 1080p decoding</t>

            <t>Encoding 1080p video at 30 fps at less than 220 MHz clock
            frequency</t>

            <t>Less than 80 milliwatts of power for HD video encoding</t>
          </list></t>

        <t>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.</t>
      </section>
    </section>

    <section title="IPR status">
      <t>Google has made its position clear with respect to Google-owned IPR
      in its licensing terms,
      http://www.webmproject.org/license/additional/.</t>

      <t>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.</t>

      <t>Google has also submitted VP8 for consideration in ISO/IEC JTC1 SC29
      WG11 (MPEG), in the IVC project (which aims for a royalty-free codec),
      and expects ISO to execute its ordinary process for resolution of IPR
      issues.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>

      <t>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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Several members of the Google VP8 team contributed to this memo.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.6386'?>

      <?rfc include='reference.I-D.ietf-payload-vp8'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc ?>
    </references>
  </back>
</rfc>