Re: [rtcweb] Changing video size (Re: use case:)

Cullen Jennings <fluffy@cisco.com> Thu, 07 July 2011 04:04 UTC

Return-Path: <fluffy@cisco.com>
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 B267E21F864F for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 21:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.642
X-Spam-Level:
X-Spam-Status: No, score=-105.642 tagged_above=-999 required=5 tests=[AWL=-3.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FneHDUqoQ3bN for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 21:04:59 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 10BC021F862D for <rtcweb@ietf.org>; Wed, 6 Jul 2011 21:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=780; q=dns/txt; s=iport; t=1310011499; x=1311221099; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E5MsYL+EJQU8l7uyDBqqLlsw2Mbne9GSIbYaGsG9yN4=; b=Xqg96EHk/oSEQiFK0ucyeIyw+cb/8DBVWefzu+VkcdXDfJRrR3FvfKNv GB1k2zv4yvNcRBTBTjhmijMrQ8oaJdK6VZ89ErO2goxlaUfc0Sq+i1rvL TXnElzUiuFtQEnK/VMOpBv+jJqNqOtONYWPkTgR5ci76Gj22+9ffOmNzq A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAM4vFU6rRDoG/2dsb2JhbABTqBd3iHulB519hjcEh0mKfYR9i2M
X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="521397"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2011 04:04:58 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6744vXZ013339; Thu, 7 Jul 2011 04:04:57 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E13CE93.9070402@jesup.org>
Date: Wed, 06 Jul 2011 22:04:56 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F868CF6E-AB6B-4EA6-8367-E2D13F442488@cisco.com>
References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <BANLkTi=g13whA3PCXKPW5Q7a2PzEDY3ESg@mail.gmail.com> <4DFF052A.8020202@alvestrand.no> <01A17A75-0700-416E-A4D4-C6EB97265F8B@cisco.com> <46A1DF3F04371240B504290A071B4DB601301A2E@SZXEML501-MBS.china.huawei.com> <BANLkTik=N6qtPRUesk3mi62rV1Lvixu54w@mail.gmail.com> <46A1DF3F04371240B504290A071B4DB601301A8D@SZXEML501-MBS.china.huawei.com> <BBF498F2D030E84AB1179E24D1AC41D6147C4DA4CE@ESESSCMS0362.eemea.ericsson.se> <4D8B4033-8A5E-464E-82E7-983386498064@cisco.com> <4E13CE93.9070402@jesup.org>
To: Randell Jesup <randell1@jesup.org>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Changing video size (Re: use case:)
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, 07 Jul 2011 04:04:59 -0000

On Jul 5, 2011, at 8:55 PM, Randell Jesup wrote:

> RFC 6236 certainly looks like a reasonable option to consider; in fact I'd consider it to be the
> defacto choice barring some problematic limitation.  

yah, make sense to me

> There *might* be an argument for also describing the portions of the decoded window that aren't visible
> (per the previous conversation).

I worry about too much "optimization" :-)

> 
> My biggest issue is that they assume it can only be changed via UPDATE or re-INVITE.  Maybe that's
> reasonable, but I have to say I'd lean towards solutions that are direct end-to-end in-call to cut overhead
> and lower reaction time.

It one of the arguments people make in favor of the "low path". Or perhaps H.245 :-)