[rtcweb] 答复: Cross-check of Google VP8 vs H.264 comparison

邓灵莉/Lingli Deng <denglingli@chinamobile.com> Fri, 15 March 2013 12:55 UTC

Return-Path: <denglingli@chinamobile.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CB21F9142 for <rtcweb@ietfa.amsl.com>; Fri, 15 Mar 2013 05:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.076
X-Spam-Level:
X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a493QKydcy6m for <rtcweb@ietfa.amsl.com>; Fri, 15 Mar 2013 05:55:33 -0700 (PDT)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 2C56821F913E for <rtcweb@ietf.org>; Fri, 15 Mar 2013 05:55:31 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151431a24915-12915; Fri, 15 Mar 2013 20:55:00 +0800 (CST)
X-RM-TRANSID: 2ee151431a24915-12915
Received: from cmccPC (unknown[172.16.20.82]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351431a1d91d-406e2; Fri, 15 Mar 2013 20:54:59 +0800 (CST)
X-RM-TRANSID: 2ee351431a1d91d-406e2
From: 邓灵莉/Lingli Deng <denglingli@chinamobile.com>
To: 'Harald Alvestrand' <harald@alvestrand.no>, 'Bo Burman' <bo.burman@ericsson.com>, rtcweb@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22DE321F7@ESESSMB105.ericsson.se> <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
In-Reply-To: <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
Date: Fri, 15 Mar 2013 20:55:17 +0800
Message-ID: <037501ce217c$59727e20$0c577a60$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0376_01CE21BF.6795BE20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4hdnhjUXO6aYJDRd6tXlbpNM1tMgAAWqDQ
Content-Language: zh-cn
Subject: [rtcweb] 答复: Cross-check of Google VP8 vs H.264 comparison
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: Fri, 15 Mar 2013 12:55:34 -0000

Hi Bo and Harald,

 

To be honest, from the perspective of a user, I really don’t see real difference between these two or the reason to do further quality tests. (PSNR is not the best choice to do objective tests, let alone objective tests are not to be replaced by subjective tests.)

 

I am not a codec expert either. But I have both seen cool face-time and bad voip apps using software H.264, as well as really cool RCS app demos using VP8 (not as bad as yesterday’s show). And I am sure Google would cover it up for mobile devices should VP8 was chose to be MTI.

 

I voted for H.264 yesterday. And here are my thoughts:

 

First of all, I would definitely not go with no MTI option. Since we have seen real-time transcoding simply for audio calls can eat up to 75% throughput of an interop gateway in our network. No one would expect anything better for high-quality video transcoding, I suppose. That’s expensive~

 

On the top of my list in considering the suitable MTI codec would be: 

1)       To VP8, my concern is whether or not the other patent holders would hold me responsible if I provide the service?

2)       To H.264, my concern is  whether or not the device platforms would open sufficient API for browsers to allow good-quality video communication? And of course if the patent holders would hold me responsible if I provide the service?

3)       To both, a further concern is whether or not the cost for interop with legacy systems is easy and cheap?

 

Since no clear answers are provided for questions 1) or 2), I chose to go with the answer to 3). Because the most existing systems and end-points supports H.264. At this moment, I have no choice but to live with it, at least for some time unless someone resolves questions 1) or 2) for me^^

 

BR

Lingli

China Mobile

 

发件人: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 代表 Harald Alvestrand
发送时间: 2013年3月15日 18:19
收件人: Bo Burman; rtcweb@ietf.org
主题: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison

 

Bo, did you run tests on our clips or your own clips, and with the rest of the settings our way or your way? Clip selection seems to matter a lot - which is why we published ours.

Bo Burman <bo.burman@ericsson.com> wrote:


Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs H.264 comparison. Google reported bit rate gains for VP8 of 19%. However, the H.264 was at an unfair advantage due to the fact that the --tune psnr flag was not used in x264. This should of course be used when doing psnr-measurements. For vp8, this flag is set to psnr by default. 

When re-running the tests with --tune psnr for x264, and using version 130 of x264 instead of version 128 that was used in the Google test, the difference disappeared (1% difference). 

Cheers,
Bo

  _____  


rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.