One document matched: draft-alvestrand-rtcweb-vp8-02.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-02"
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="6" month="October" 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="Specification status">
<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>
<t>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.</t>
<section title="VP8 standardization status">
<t>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
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).</t>
<t>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.</t>
</section>
</section>
<section title="Deployment status">
<t>The VP8 codec has been extensively deployed in production
services:</t>
<t><list style="symbols">
<t>Skype (now part of Microsoft) used the codec extensively in its
video conferencing software.</t>
<t>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.</t>
<t>Google Remote Desktop uses VP8.</t>
<t>Google Chromecast uses VP8, showing what can be achieved with
hardware decoding support.</t>
<t>Both the Firefox and Chrome WebRTC implementations use VP8
exclusively.</t>
</list></t>
</section>
<section title="Image quality evaluations">
<t></t>
<section title="Objective 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>The software and the clips are available via the WEBM project's GIT
repository:
http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git</t>
<t>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.</t>
</section>
<section title="Subjective evaluations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</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>NOTE: This section contains mostly information that was valid as of
October 2012. It will be updated.</t>
<t>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.</t>
<t>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).</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>
<t>The ChromeCast device, which is selling in significant numbers in
the US, has VP8 hardware decode.</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>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.</t>
<t>As of this moment (October 4, 2013), the following IPR disclosures
are filed in the IETF IPR database:</t>
<t><list style="symbols">
<t>https://datatracker.ietf.org/ipr/1571/ - by Google, declaring
that the technology is royalty-free.</t>
<t>https://datatracker.ietf.org/ipr/2035/ - by Nokia, which does not
declare a royalty-free license.</t>
</list></t>
<t>The licensing terms for Google's IPR are available at
http://www.webmproject.org/license/additional/.</t>
<t>The Nokia IPR mentioned above includes IPR that has been asserted in
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.</t>
<t>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:</t>
<t><list style="symbols">
<t>CIF Licensing LLC</t>
<t>France Telecom</t>
<t>Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung
e.V.</t>
<t>Fujitsu Limited</t>
<t>Koninklijke Philips Electronics N.V.</t>
<t>LG Electronics Inc.</t>
<t>Mitsubishi Electric Corporation</t>
<t>MPEG LA, LLC</t>
<t>NTT DOCOMO, INC</t>
<t>Panasonic Corporation</t>
<t>Samsung Electronics Co., Ltd.</t>
<t>Siemens Corporation</t>
</list></t>
<t>The license can be executed on-line from the link given above.</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 if this document is
ever published 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>
<t>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.</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>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:15 |