Re: [rtcweb] Resolution negotiation - a contribution

Stephan Wenger <> Thu, 12 April 2012 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9622221F871A for <>; Thu, 12 Apr 2012 14:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oHcmbxvlzv0G for <>; Thu, 12 Apr 2012 14:14:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9C1FC21F870E for <>; Thu, 12 Apr 2012 14:14:13 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 12 Apr 2012 21:14:12 +0000
Received: from mail49-va3 (localhost []) by (Postfix) with ESMTP id BC94E4401AA; Thu, 12 Apr 2012 21:14:12 +0000 (UTC)
X-SpamScore: -8
X-BigFish: PS-8(zzbb2dI9371I1432N98dKzz1202h1082kzzz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail49-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail49-va3 (localhost.localdomain []) by mail49-va3 (MessageSwitch) id 1334265249914189_27251; Thu, 12 Apr 2012 21:14:09 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id D4FEA400A7; Thu, 12 Apr 2012 21:14:09 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 12 Apr 2012 21:14:09 +0000
Received: from ([]) by ([]) with mapi id 14.16.0143.004; Thu, 12 Apr 2012 21:13:38 +0000
From: Stephan Wenger <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] Resolution negotiation - a contribution
Thread-Index: AQHNGIi2N3AyBdvLYU+ocbL9B79QTJaXC0UAgACC2AD//622gA==
Date: Thu, 12 Apr 2012 21:13:38 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Resolution negotiation - a contribution
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: Thu, 12 Apr 2012 21:14:14 -0000

On 4.12.2012 12:08 , "Harald Alvestrand" <> wrote:

>On 04/12/2012 08:19 PM, Stephan Wenger wrote:
>> Hi Harald,
>> Thanks for this strawman.  I believe it should work, but I fail to see
>> a two dimensional negotiation requirement (negotiating max values for
>> framerate and image size--which, in turn, also has two-dimensional
>> properties) leads to better interop than a one dimensional negotiation
>> (pixels per second processing requirement).
>I do not see this (or the requirement from the use-cases document) first
>and foremost a decoder complexity negotiation; it is a negotiation of
>how much data it is useful to send, given the recipient's intended use
>of that data.

Then such a negotiation should be executed in addition.  Decoder cycle
requirement do matter in practical implementations.

>For instance, in Google+ Hangouts, we use a similar function to make
>sure the participants who are not currently displayed in large format on
>anyone's screen only send the data needed to display the "thumbnail";
>this represents a huge saving in bandwidth at our central servers.

Oh, absolutely.  I'm all in favor of resolution adaptation based on
receiver (population) requirements.  But only after an upper limit is
established (that could be based on many factors, including screen size,
connectivity, and computational resources (sic!).

>It just happens that the decoding complexity of the VP8 codec is
>sufficiently linear with the number of pixels displayed that we don't
>see any advantage in encumbering the negotiation of that codec with
>extra features like "profiles" - but that's a discussion for PAYLOAD,
>not RTCWEB.

True, agreed, and not what I was arguing about.