Re: [rtcweb] Resolution negotiation - mandatory / advisory resolutions

Harald Alvestrand <harald@alvestrand.no> Thu, 19 April 2012 08:47 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 3371921F84C9 for <rtcweb@ietfa.amsl.com>; Thu, 19 Apr 2012 01:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.49
X-Spam-Level:
X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 SYmoxvqkwynT for <rtcweb@ietfa.amsl.com>; Thu, 19 Apr 2012 01:47:47 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C64D921F85C3 for <rtcweb@ietf.org>; Thu, 19 Apr 2012 01:47:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03AC639E0CD; Thu, 19 Apr 2012 10:47:46 +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 0uA02NzHwUXQ; Thu, 19 Apr 2012 10:47: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 5FF3439E098; Thu, 19 Apr 2012 10:47:41 +0200 (CEST)
Message-ID: <4F8FD12C.9070703@alvestrand.no>
Date: Thu, 19 Apr 2012 10:47: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: Roni Even <ron.even.tlv@gmail.com>
References: <4F869648.2020605@alvestrand.no> <4F8FC2E0.60701@alvestrand.no> <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com>
In-Reply-To: <4f8fcab8.c268b40a.7fe1.ffffb433@mx.google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
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 08:47:51 -0000

On 04/19/2012 10:18 AM, Roni Even wrote:
> Hi Harald,
> The reason for the language was that this is really what the receiver wished
> to receive.
The strength of his wish may be the issue here....
>   The issue is that at least for H.264 there is no mandatory
> requirement for the encoder to support all resolutions within the supported
> level. The receiver must be able to crop and scale.
I couldn't parse that.

Does the sender have to (MUST) send a resolution within the boundaries 
of the "recv" spec, or can he send something outside it? (ie if the 
receiver sends recv [x=320,y=200], can the sender send something with 
x=320,y=240, or is he completely constrained?)

What does the receiver have to be able to do?

                    Harald
>
> Roni Even
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Harald Alvestrand
>> Sent: Thursday, April 19, 2012 10:47 AM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Resolution negotiation - mandatory / advisory
>> resolutions
>>
>> 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 mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>