Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions
Harald Alvestrand <harald@alvestrand.no> Thu, 19 April 2012 07:46 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 8C82421F84E4 for <rtcweb@ietfa.amsl.com>; Thu, 19 Apr 2012 00:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.479
X-Spam-Level:
X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 SobqStF8AjAR for <rtcweb@ietfa.amsl.com>; Thu, 19 Apr 2012 00:46:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBB21F84C4 for <rtcweb@ietf.org>; Thu, 19 Apr 2012 00:46:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E66539E0CD for <rtcweb@ietf.org>; Thu, 19 Apr 2012 09:46:41 +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 o96krT68Y0pV for <rtcweb@ietf.org>; Thu, 19 Apr 2012 09:46:41 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id ED6C339E098 for <rtcweb@ietf.org>; Thu, 19 Apr 2012 09:46:40 +0200 (CEST)
Message-ID: <4F8FC2E0.60701@alvestrand.no>
Date: Thu, 19 Apr 2012 09:46:40 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F869648.2020605@alvestrand.no>
In-Reply-To: <4F869648.2020605@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions
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, 19 Apr 2012 07:46:43 -0000
When discussing the issue of resolution negotiation locally, we found a quandary: We have two different negotiation needs: - Maximum resolution that's possible to use in a given context - The preferred resolution for a given context The current imageattr= spec (RFC 6236) doesn't specify clearly whether the result of the negotiation is to be considered mandatory or advisory (it uses the term "wishes" a lot), but the description reads most consistently if one assumes that it is a "MUST" type request. One interpretation is that the highest functionality available in the spec is the "limit", while the highest q value is the "preference", thus: recv [x=320,y=200,q=1.0] [x=200:1024,y=160:768,q=0.1] would indicate that the receiver is capable of 200x160 to 1024x768, but wants 320x200. This maps reasonably to the capabilities spec's talk about "mandatory" vs "optional" capabilities. Does this interpretation make sense? Harald On 04/12/2012 10:46 AM, Harald Alvestrand wrote: > Hello folks, > > after the IETF, I've attempted to gather together information about > resolution negotiation and what we might need to do there. > > I pulled together the paragraphs below - this may want to be > incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go > somewhere else. Chairs' guidance is appreciated. > > At the moment, I have it in xml2rfc format, so it should be easy to do > cut-and-paste on it, but don't want to push it as a separate I-D > unless that's what the chairs desire. > Note - there are some QUERY sections in there - I'm unsure what those > should be resolved to. > > Comments? > > Harald > > 2. Requirements > > The relevant requirement for video resolution negotiation from the > RTCWEB use cases document > [I-D.ietf-rtcweb-use-cases-and-requirements] is: > > o F25 The browser SHOULD use encoding of streams suitable for the > current rendering (e.g. video display size) and SHOULD change > parameters if the rendering changes during the session. > > The resulting need is: > > o To negotiate a maximum spatial resolution for all videos at call > setup time > > o To negotiate a maximum temporal resolution ("frame rate") across > all videos at call setup time > > o To indicate the desire of the recipient for a particular spatial > or temporal resolution on a particular video source > > o To indicate the intent of the sender to send a video source in a > particular spatial or temporal resolution > > This document does not mention other requirements.
- [rtcweb] Resolution negotiation - a contribution Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Timothy B. Terriberry
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Marshall Eubanks
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - a contribut… Stephan Wenger
- Re: [rtcweb] Resolution negotiation - a contribut… Harald Alvestrand
- [rtcweb] VP8 payload, decoder processing capabili… Stephan Wenger
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Yuepeiyu (Roy)
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- Re: [rtcweb] Resolution negotiation - mandatory /… Harald Alvestrand
- Re: [rtcweb] Resolution negotiation - mandatory /… Roni Even
- [rtcweb] Alternative Proposal for Dynamic Codec P… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Timothy B. Terriberry
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Bernard Aboba
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Harald Alvestrand
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Justin Uberti
- Re: [rtcweb] Alternative Proposal for Dynamic Cod… Magnus Westerlund
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Cullen Jennings (fluffy)
- Re: [rtcweb] [payload] VP8 payload, decoder proce… Harald Alvestrand