Re: [rtcweb] Resolution negotiation - a contribution

Harald Alvestrand <harald@alvestrand.no> Thu, 12 April 2012 12: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 4E00721F862F for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 05:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 vYxPt7M2-hok for <rtcweb@ietfa.amsl.com>; Thu, 12 Apr 2012 05:47:47 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF5421F865E for <rtcweb@ietf.org>; Thu, 12 Apr 2012 05:47:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9173B39E178; Thu, 12 Apr 2012 14: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 ci1YOwTrtuSw; Thu, 12 Apr 2012 14:47:46 +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 E324F39E082; Thu, 12 Apr 2012 14:47:45 +0200 (CEST)
Message-ID: <4F86CEF1.80708@alvestrand.no>
Date: Thu, 12 Apr 2012 14:47:45 +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: "Timothy B. Terriberry" <tterriberry@mozilla.com>
References: <4F869648.2020605@alvestrand.no> <4F869BD9.6020801@mozilla.com>
In-Reply-To: <4F869BD9.6020801@mozilla.com>
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 12:47:48 -0000

On 04/12/2012 11:09 AM, Timothy B. Terriberry wrote:
> Harald Alvestrand wrote:
>> time. These bounds MAY be renegotiated over the course of the call,
>> but MUST NOT be renegotiated to render any currently transmitted
>> video stream out of bounds; the sending video stream MUST first be
>> changed to be of a resolution that fits within both the old and the
>> new bounds, or halted. <<QUERY: Is this necessary or sufficient
>> restriction???>>
>
> Is this restriction intended to be imposed on the sender only? I.e., 
> can the recipient still attempt renegotiation (using SDP source 
> selection) of a smaller resolution than is currently allowed (e.g., 
> because it's CPU-bound)?

What do you think it should say?

What I was thinking about was the silly state you can get into if you 
have a running 1024x768 stream, based on negotiating "width between 1000 
and 1500", and want to negotiate max resolution down to 480x360 by 
saying "width between 400 and 500".

The possibilities that may make sense on the sender side:

- Negotiate width between 400 and 1500, then change to 480x360, then 
negotiate width 400-500
- Stop the stream, negotiate width between 400 and 500, then turn on 
stream at new size
- Keep sending 1024x768 until negotiation is complete, then change at 
your leisure
- Switch to 480x360 even though it's not allowed by current parameters, 
then renegotiate

The two first look ugly, but are (as I understand) compatible with 
current standards. The two last ones seem to break the "only send what 
you have negotiated" model.

If the negotiation is receiver-initiated, it makes more sense (just 
thinking on the fly here) to say that it can be started at any time, and 
that the sender is free to change resolution to the new params at any 
time after he's decided the offer is acceptable. Perhaps he MUST do so 
before sending the answer?

(This is one particular example of Cullen's "what are the steps to 
change a codec" scenario.....)

                  Harald