VP8 as RTCWEB Mandatory to Implement
Google
Kungsbron 2
Stockholm
11122
Sweden
harald@alvestrand.no
Google
1950 Charleston Road
Mountain View
CA
94043
USA
agrange@google.com
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.
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.
As described in ,
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.
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:
Image quality - comparative data was sought, but without defining
a baseline
Performance - what resolutions / frame rates can be achieved in
software on some common systems
Power consumption of hardware and/or software implementations
Hardware support
IPR status
This document lays out the available information in each
category.
VP8 is defined in , and its RTP payload
is defined in . There are no
profiles; all decoders are able to decode all valid media streams.
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.
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.
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). .
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.
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.
Several of the aforementioned hardware implementations are based on
the WebM video hardware designs described at
http://www.webmproject.org/hardware/. Performance figures include:
Decode of 1080p video at 30 fps at less than 100 MHz clock
frequency
Decoding more than ten simultaneous SD video streams on a
single chip
Less than 25 milliwatts of power for 1080p decoding
Encoding 1080p video at 30 fps at less than 220 MHz clock
frequency
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.
Google has made its position clear with respect to Google-owned IPR
in its licensing terms,
http://www.webmproject.org/license/additional/.
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.
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.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
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.
Several members of the Google VP8 team contributed to this memo.