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

Stefan Håkansson LK <> Wed, 26 June 2013 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D38B121F9F84 for <>; Wed, 26 Jun 2013 10:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CO738re76hJ2 for <>; Wed, 26 Jun 2013 10:50:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3691221F9F4C for <>; Wed, 26 Jun 2013 10:50:54 -0700 (PDT)
X-AuditID: c1b4fb30-b7fab6d00000040c-d9-51cb29fc5300
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C4.99.01036.CF92BC15; Wed, 26 Jun 2013 19:50:52 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 19:50:52 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
To: "Eggert, Lars" <>
Thread-Topic: [rtcweb] More H.264 vs VP8 tests
Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw==
Date: Wed, 26 Jun 2013 17:50:51 +0000
Message-ID: <>
References: <> <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre4fzdOBBjs/a1oc6+tis3jxuofF Yu2/dnYHZo8rE66weixZ8pPJY8anL2wBzFFcNimpOZllqUX6dglcGTdezmIumCRcsfk2TwPj U/4uRk4OCQETiZe321kgbDGJC/fWs3UxcnEICRxmlNj59wGUs4hRYvmcc0wgVWwCgRJb9y1g A7FFBFQkNs8/zQ5iMwuESqydsAIsLiygK9FwfA1UjZ7EwucvWGDs3fs/MoPYLAKqErN2bwSz eQV8Jc6ufgy1bD2TxLKzz8EaGIFO+n5qDRPEAnGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaS xI8Nl1gg6vUkbkydwgZha0ssW/gaapmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcx Mye93HwTIzBCDm75bbCDcdN9sUOM0hwsSuK8n07tChQSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAmLNd58U8/vPeX9TTVFy3uf9cGfNOR72y/s3pxM2ap+5XZcfe3ee349H6eL7AfSLzWBcf Mky9d7LQLlFCWov/cD9L/1PtI2tjRR06vX1ltetqElbaird8ynzC/TPj+w29yyUfer1MUrW5 g5NDHe8u5Ho466jeyz9JOsUV/RGzP73cvPjAdL1gJZbijERDLeai4kQA1QF23F4CAAA=
Cc: "<>" <>
Subject: Re: [rtcweb] More H.264 vs VP8 tests
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: Wed, 26 Jun 2013 17:51:01 -0000

On 2013-06-26 17:35, Eggert, Lars wrote:
> Hi,
> On Jun 25, 2013, at 0:00, Harald Alvestrand <>
> wrote:
>> This would seem to me to be an argument for including the rate
>> control.... what we are looking for is the codec where people can
>> demonstrate the best performance for our specific situations, not
>> the codec that is best able to fulfil a set of conditions that are
>> inappropriate for Real Life.
> I'd agree with this argument *if* we actually had some idea of what
> congestion control algorithm(s) RMCAT will propose. If we did,
> looking at congestion-controlled output quality would make a lot of
> sense.
> But, we don't know what RMCAT will recommend, and - with my RMCAT
> chair hat on - progress is slow, because participation is not exactly
> stellar. RTCWEB folks with an interest in this topic should start
> participating in RMCAT. Pretty please.
> But, I digressed. Since we don't know what algorithm RMCAT will
> recommend, comparing different codec/congestion-control pairs makes
> it very hard to figure out whether quality differences are due to the
> codec, or due to the congestion controller.
> So as a baseline, it would make sense to eliminate the congestion
> controller from this comparison, at least initially. Once we have
> some candidate congestion controllers on the table in RMCAT,
> comparing encoder-controller pairs makes sense, e.g., VP8 with
> controller A against MPEG with controller A, VP8 with controller B
> against MPEG with controller B, etc.
> Because in the end, as you say, congestion-controlled output quality
> is what matters in the real world. So IMO any final decision on a
> codec needs to wait until we know what the congestion controller is
> doing.

If this was only about video quality I would agree, but as things stand 
now I would say that the data we have available indicate that VP8 and 
h.264 baseline are comparable regarding video quality, and that possible 
MTI selection would come down to other things (like licensing, current 
deployment etc.)

> Lars _______________________________________________ rtcweb mailing
> list