Re: [rtcweb] Resolution negotiation - a contribution

Harald Alvestrand <harald@alvestrand.no> Thu, 12 April 2012 19:08 UTC

Return-Path: <harald@alvestrand.no>
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 5F7AA21F8686 for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 12:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 1oCYnTjSGqSi for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 12:08:09 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5321F854A for <rtcweb@ietf.org>; Thu, 12 Apr 2012 12:08:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2139939E0A7; Thu, 12 Apr 2012 21:08:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXOp0xxHAGz4; Thu, 12 Apr 2012 21:08:06 +0200 (CEST)
Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6D4CD39E082; Thu, 12 Apr 2012 21:08:06 +0200 (CEST)
Message-ID: <4F872816.6080309@alvestrand.no>
Date: Thu, 12 Apr 2012 21:08:06 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <CBAC66CB.85BB5%stewe@stewe.org>
In-Reply-To: <CBAC66CB.85BB5%stewe@stewe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Resolution negotiation - a contribution
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, 12 Apr 2012 19:08:10 -0000

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 how
> 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).
Stephan,

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.

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.

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.