Re: [rtcweb] More H.264 vs VP8 tests

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Thu, 27 June 2013 11:55 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 C8F8E21F9A92 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 04:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level:
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 P1mngSOSJsA1 for <rtcweb@ietfa.amsl.com>; Thu, 27 Jun 2013 04:55:46 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E321F9A83 for <rtcweb@ietf.org>; Thu, 27 Jun 2013 04:55:46 -0700 (PDT)
X-AuditID: c1b4fb38-b7fc16d000004a21-e3-51cc28408204
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.E2.18977.0482CC15; Thu, 27 Jun 2013 13:55:45 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 13:55:45 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: John Koleszar <jkoleszar@google.com>
Thread-Topic: [rtcweb] More H.264 vs VP8 tests
Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw==
Date: Thu, 27 Jun 2013 11:55:44 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30766B@ESESSMB209.ericsson.se>
References: <BBE9739C2C302046BD34B42713A1E2A22DECC12F@ESESSMB105.ericsson.se> <CAAvHm8P5w_sy_cRScudpg7RytxZJRhxykmHtw1dFMB42BYF5-g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra6jxplAg+MPeC1+r9zIarH2Xzu7 A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgypi3exFzwXquitnnXrE1MG7m6GLk5JAQMJE4 1HyYDcIWk7hwbz2QzcUhJHCUUWL+5YksEM4iRol/HYsYQarYBAIltu5bANYhIqAh0bF9IjOI zSzgLbG+ew4LiC0soCvRcHwNVI2exMLnL1hg7N37P4LVswioSsy/1A0W5xXwlXh5ZS0zxLIp jBI9Zx6CNTMCnfT91BomiAXiEreezGeCOFVAYsme88wQtqjEy8f/WCFsRYmdZ9uhDtKTuDF1 ChuErS2xbOFrZohlghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7i1OKk3HQjg02MwHg4 uOW3xQ7Gy39tDjFKc7AoifPyAONESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Ppt4Muz3ad uHF8Gu8ZMc4ma/uOJTO0V/PH31y9ZIl6S2SB3T9mlztNj+7UuwgvXhyY8rzjxw6BsguSDOb6 zIpHdOUeXGZk73LolbVzXLXzB9fmwLTnt/fzRyjMVajTZRU3Phx+wKvyYtHho9Y75obnnN6b eaYubHbU4dcXOO9+VH27KGdHZ4wSS3FGoqEWc1FxIgAvS7clVQIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Thu, 27 Jun 2013 11:55:53 -0000

On 2013-06-25 17:36, John Koleszar wrote:
> On Sat, Jun 22, 2013 at 6:41 AM, Bo Burman <bo.burman@ericsson.com>;
> wrote:
>> Hi all,
...
>>
> [...]
>
>  Another unexpected
> behavior for people trying this mode is that making libvpx bump up
> against the lower quantizer without setting an approximately correct
> target bitrate can also put the encoder into its "over quant" mode,
> where it'll throw away additional residual trying to hit the target
> bitrate.

To make sure that this is not an issue we checked the bit rate for a 
sequence compressed with our settings. Then we encoded the same sequence 
three times; once with --target-bitrate set to well below this bit rate, 
once with --target-bitrate set to this bit rate, and once with 
--target-bitrate set to well above this bit rate. In all three cases we 
ended up with exactly the same bit rate and PSNR. In fact the resulting 
.webm files were bit-identical. So I think we can rule out the 
possibility that setting the target bitrate incorrectly can affect the 
results.

Again, we have put a lot of effort into selecting these parameters and 
those for X264/JM, but since this is a complex issue we welcome feedback.