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

"Eggert, Lars" <> Wed, 26 June 2013 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C670B11E80EF for <>; Wed, 26 Jun 2013 08:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.466
X-Spam-Status: No, score=-4.466 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 75D4byfEngUD for <>; Wed, 26 Jun 2013 08:35:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2817911E811B for <>; Wed, 26 Jun 2013 08:35:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,945,1363158000"; d="scan'208";a="29697413"
Received: from ([]) by with ESMTP; 26 Jun 2013 08:35:09 -0700
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 08:35:09 -0700
From: "Eggert, Lars" <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] More H.264 vs VP8 tests
Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVwCHVgWAAFcimAA=
Date: Wed, 26 Jun 2013 15:35:08 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:35:15 -0000


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.