Re: [rtcweb] VP8 vs H.264 - the core issue

"Matthew Kaufman (SKYPE)" <> Thu, 24 October 2013 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BA3811E8367 for <>; Thu, 24 Oct 2013 09:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aDbp51N5y5ti for <>; Thu, 24 Oct 2013 09:09:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98F8121F99F4 for <>; Thu, 24 Oct 2013 09:03:33 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 24 Oct 2013 16:03:24 +0000
Received: from (2a01:111:f400:7c10::188) by (2a01:111:e400:2c2c::28) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Thu, 24 Oct 2013 16:03:24 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Thu, 24 Oct 2013 16:03:23 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.002; Thu, 24 Oct 2013 16:02:38 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Bo Burman <>, Harald Alvestrand <>, "" <>
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Date: Thu, 24 Oct 2013 16:02:37 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08TK5EX14MBXC266r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454002)(479174003)(53434003)(189002)(199002)(377454003)(84326002)(31966008)(85306002)(81686001)(74366001)(16236675002)(76482001)(76796001)(76786001)(74662001)(81816001)(56776001)(20776003)(63696002)(54316002)(55846006)(47446002)(74502001)(56816003)(77096001)(79102001)(80022001)(80976001)(65816001)(66066001)(44976005)(19580405001)(83322001)(15975445006)(19580395003)(53806001)(51856001)(19300405004)(54356001)(46102001)(6806004)(15202345003)(74706001)(4396001)(69226001)(16297215004)(74876001)(81342001)(71186001)(47976001)(47736001)(49866001)(50986001)(512954002)(77982001)(59766001)(81542001)(33656001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB237;; CLIP:; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 000947967F
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2013 16:09:46 -0000

On the IPR issue, Google reached agreement with 11 patent holders. There are at least 31 companies in the MPEG-LA H.264 pool. There is considerable technical overlap between VP8 and H.264.

My employer is one of those in the H.264 pool, and wasn't one of the 11 companies Google reached an agreement with.

Draw your own conclusions and take your own IPR risks.

Personally I'd rather the IPR devil I know vs. the IPR devil I don't know.

Google could fix this for most potential users (through indemnification, similar to what Oracle offers its Linux licensees) but has chosen not to. You can draw your own conclusion there, too.

Matthew Kaufman

From: [] On Behalf Of Bo Burman
Sent: Thursday, October 24, 2013 6:27 AM
To: Harald Alvestrand;
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in terms of video quality. But do not forget that Constrained Baseline's twin sister H.264 Constrained High outperforms VP8 by a huge margin. This is also relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where we tried to make a fair comparison to evaluate the extraordinary claims from Google that VP8 is 70 or 40 percent better than x264. We found serious issues with the way Google performed the test, maybe the most striking were the use of padding (+8% for x264) and excessive number of threads (+10% to +40% for x264) to add overhead to x264. That Google managed to remember the threading parameter only when it helped
VP8 (the speed test) is also quite remarkable.

3) Regarding IPR, this is a difficult topic, but we're not at all convinced that VP8 is royalty free. For example, there is an IETF IPR disclosure ( where the IPR holder seems unwilling to license (on any terms), and and show that there are in fact ongoing litigations regarding VP8 - and this is only skimming the surface of what is available in public space.


From:<> [] On Behalf Of Harald Alvestrand
Sent: den 24 oktober 2013 13:12
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:

Just a reminder:

The back-and-forth of numbers doesn't change the core question of this


Both codecs are capable of high quality video encoding, and performance

numbers are comparable.

The real core question is the IPR issue.

The tradition of the IETF says that allowing only business models that

can sustain royalty agreements and royalty payments is Bad for the Internet.

The dominant video codec, H.264, is a royalty-required codec.

Do we switch now, or do we give up and live with royalties forever?


I would like to see some references to the tradition of the IETF that

you've quoted.

For the record, I agree with the sentiment, but I'd like to be able to

back up the claim itself with references or explicit decisions that were

made in that regard.  I'm not trying to be a thorn in your side, just

looking for citations to back up the arguments, both on and off list.

Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:

8.  Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known IPR

   claims or, for technologies with claims against them, an offer of

   royalty-free licensing.  But IETF working groups have the discretion

   to adopt technology with a commitment of fair and non-discriminatory

   terms, or even with no licensing commitment, if they feel that this

   technology is superior enough to alternatives with fewer IPR claims

   or free licensing to outweigh the potential cost of the licenses.

The complete section gives some more details, but this is the central quote.

You may also enjoy reading the section of RFC 6569 (the guidelines that were followed in the OPUS work) that deals with IPR:


Surveillance is pervasive. Go Dark.