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

"Mo Zanaty (mzanaty)" <> Wed, 26 June 2013 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3A0121F9DBB for <>; Wed, 26 Jun 2013 10:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hGFkLYrbjryh for <>; Wed, 26 Jun 2013 10:41:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E546421F99AC for <>; Wed, 26 Jun 2013 10:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3017; q=dns/txt; s=iport; t=1372268499; x=1373478099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tBIQ9hSC3mJKiVpRpb5Tt2zTyp3k7ZmMmBF4DTosY3M=; b=b9IDKu6dhiqaO9vE5Z9O60jKMZlZRCA9sJPDtD0hSJKb78/4eHaSlDmM MYVsjJ1BLMB5nPwE1w1Cpore6FtmtgGOhTir8I1hKMgTQgNBGDMR8JHoc /dNesnYCrpCqu7xQguJxN05yZdYzmGdH0Ls0mY0KJEQyLkdoXnAFOZUhG U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227804959"
Received: from ([]) by with ESMTP; 26 Jun 2013 17:41:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5QHfLMA028196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 17:41:21 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 12:41:21 -0500
From: "Mo Zanaty (mzanaty)" <>
To: "Eggert, Lars" <>
Thread-Topic: [rtcweb] More H.264 vs VP8 tests
Thread-Index: Ac5ylF52K8Kw3CTuSzmtIg91KzwPfw==
Date: Wed, 26 Jun 2013 17:41:20 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
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 17:41:43 -0000

Rate control is typically a different beast from congestion control, and any coupling is typically very loose. Rate control is primarily adaptive quantization to optimize perceptual quality based on content statistics, with little or no coupling to transport statistics. Any such coupling is often loose, like a target average bit rate over coarse timescales inappropriate for congestion control like seconds or longer. Constraining rate control to also perform congestion control over tight timescales like a frame time will result in suboptimal video quality, because content statistics are inherently uncorrelated with transport statistics, so forcing any coupling degrades perceptual quality. Hence why congestion control is often implemented as a pacer/shaper outside the encoder rate control, with a slower feedback loop to adapt the target rate of the encoder rate control less frequently than congestion controlled packet transmission.

Anyone interested in congestion control or its coupling to rate control should participate in RMCAT.


On Jun 26, 2013, at 11:35 AM, "Eggert, Lars" <> wrote:


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.

rtcweb mailing list