[rtcweb] More H.264 vs VP8 tests

Bo Burman <bo.burman@ericsson.com> Sat, 22 June 2013 13:41 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0853C21F8ECE for <rtcweb@ietfa.amsl.com>; Sat, 22 Jun 2013 06:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HIlUbwswTeEy for <rtcweb@ietfa.amsl.com>; Sat, 22 Jun 2013 06:41:14 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id E181711E80FA for <rtcweb@ietf.org>; Sat, 22 Jun 2013 06:41:12 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-91-51c5a975f0f3
Received: from ESESSHC013.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DF.5E.18006.579A5C15; Sat, 22 Jun 2013 15:41:10 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([]) by ESESSHC013.ericsson.se ([]) with mapi id 14.02.0328.009; Sat, 22 Jun 2013 15:41:09 +0200
From: Bo Burman <bo.burman@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: More H.264 vs VP8 tests
Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw==
Date: Sat, 22 Jun 2013 13:41:08 +0000
Message-ID: <BBE9739C2C302046BD34B42713A1E2A22DECC12F@ESESSMB105.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_006_BBE9739C2C302046BD34B42713A1E2A22DECC12FESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM+JvrW7ZyqOBBk1P2C3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxofX/ewF30/wV1z6lt/AuG4CfxcjB4eEgInEtolAJieQKSZx 4d56ti5GLg4hgcOMEituH2WCcJYwSsw/sZIdpIpNQENi/o67jCC2iIC6xOWHF8DiwgIKEk9X 72aFiKtK3Gpbxw5h60ns3v+RGcRmAYrf/7mECcTmFfCV6OjYzQZiMwrIStz/fo8FxGYWEJe4 9WQ+E8RFIhIPL55mg7BFJV4+/scKcbSixPJ+OYjyTInrq1sYIUYKSpyc+YRlAqPQLCSTZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18wQdoTE/CvdUL0WElM/HQCKcwHZwHD5ueU+O0RCUWJK90Mo 21xixvHvcEMnb+tkgmjYyihxavZjVlQNHEC2JdB1ahBhPYnuTV1Q9dsZJW69X8SMaYG9xLa1 OxghbBOJ082T2SAa9jJKvJi0hRVTg6PE6eOvoF4wk3h6fyEjRMNBRom7v9tRvLCAUXIVI3tu YmZOernRJkZgujq45bfqDsY750QOMUpzsCiJ8348tStQSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2NA8OUHl6JrnyjMsxGZnWj/hOVDcp/wFP4bS83VAyI6f2j3SDrwOm7vPM2T8OaUgobU Eb9d13KlzcXNJiTpigQK3pv54Ec0y5sp6Sw6lyf/OekvtJjl6sfQbJVGcfn5j+OCm64/lXxi Z1hieWau0IcfL+dLXWjPunl53lOHBdsuHhK8dqnL9IsSS3FGoqEWc1FxIgC4vzwHJQMAAA==
Subject: [rtcweb] More H.264 vs VP8 tests
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jun 2013 13:41:20 -0000

Hi all, 

We have had a look at Google's comparison between VP8 and H.264 constrained baseline that was posted on April 3rd (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This post contains, as the one mentioned above (and if the attachments make it to the list), information on the exact tools and options used for encoding and should thus be repeatable by anyone interested.

As was already stated by others on this list, one major problem is that Google's test involves the rate control mechanism. Typically codecs are measured with rate control turned off, since it acts as a huge noise on the measurement. Instead we propose to compare the codecs using fixed qp-levels. The qp-level is the quantization parameter that affects the rate/distortion tradeoff. Comparing using fixed qp-levels is what has been used when benchmarking HEVC against H.264 in the JCT-VC standardization, for instance. We are going to select a codec (essentially bit stream format), not a rate control mechanism: Once the codec is selected you can choose whatever rate control mechanism you wish.

We used Google's excellent framework as the baseline and changed the parameter settings in order to make it possible to measure using fixed qp. We used the same sequences, but limited them to the first 10 seconds since they varied from 10 seconds to minutes; this also eased computation time.

We used two H.264 encoder implementations: X264, which is an open-source codec that can operate in everything from real-time to slow, and JM which is the reference implementation that was used to develop H.264. JM is very slow but attempts to be very efficient in terms of bits per quality. The results were as follows:

X264 baseline vs VP8: H.264 wins with 1%
JM baseline vs VP8: H.264 wins with 4%

Running times: 
X264: 1 hour 3 minutes
VP8: 2 hours 0 minutes
JM: order of magnitude slower

It is interesting to note that the measurements are more stable in the new test; the variance of the percentages for the sequences is now around 70, down from around 700 in Google's test of April 3rd.  We believe this is due to the removal of the rate controller, which acts like noise on the measurements. 

We also tried setting H.264 to constrained high (no interlace and no B-pictures, compared to high). The results were then:

X264 constrained high vs VP8: H.264 wins with 25%
JM constrained high vs VP8: H.264 wins with 24%

We also note that the script that Google provided to calculate the rate differences ("BD-rate") does not give exactly the same numbers as the JCT-VC-way of calculating BD-rate. The main difference is that the JM score for constrained high is better (around 29%) if the JCT-VC way of calculating BD-rate is used. 

In summary we think that proper testing can conclude that there is no clear performance advantage to any codec between VP8 and H.264 baseline. When comparing VP8 against H.264 constrained high on the other hand, it seems like there is an advantage for H.264 constrained high.

The attached file includes the files necessary to reproduce the test.

Best Regards,

Bo Burman