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

Varun Singh <vsingh.ietf@gmail.com> Tue, 21 June 2011 07:45 UTC

Return-Path: <vsingh.ietf@gmail.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 E726211E81BE for <rtcweb@ietfa.amsl.com>; Tue, 21 Jun 2011 00:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 O9s6hAyWP1NC for <rtcweb@ietfa.amsl.com>; Tue, 21 Jun 2011 00:45:50 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7311E81E4 for <rtcweb@ietf.org>; Tue, 21 Jun 2011 00:45:49 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1799172wyj.31 for <rtcweb@ietf.org>; Tue, 21 Jun 2011 00:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:message-id:in-reply-to:references :subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=/RlxIAIqt/BWclCL5ZZ6IBDSeN/cVblg9f2DVIvNEJs=; b=WxwxxdBQHJvfu2r2lgdrK81q87S409ZRgn+gmqfIuI+vhC4kpEatFiI8E47jYes/+M wVH8cAUebrHddIFyq6gAz/ebUqQ3SMmlod6zN+vETW5xTXNaALnZVtOfRiLIk6aXr3dx Spjh8ewALdG0fI87OnbQtfQjd5TC942G3Y0b4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; b=vC2hS/9dvnJgiEpKsvrtndINFzB4HPEtK/bfSPDXaTC5w2KLfvqtMFbIa6SU2I3BVJ DfXiq3Kcw2OPPgIrPGJtdwP2BCkVvtvnR02eMfOxPKsSu91ypGUvdejC3/SXKst7auVw TVDDDqHSkapH1AG+vmy5OBX5StpCcK1cgm4dQ=
Received: by 10.216.245.4 with SMTP id n4mr428736wer.83.1308642348624; Tue, 21 Jun 2011 00:45:48 -0700 (PDT)
Received: from varun.local (guest.imtlucca.it [90.147.23.87]) by mx.google.com with ESMTPS id ge4sm3780693wbb.47.2011.06.21.00.45.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 00:45:47 -0700 (PDT)
Date: Tue, 21 Jun 2011 09:45:43 +0200
From: Varun Singh <vsingh.ietf@gmail.com>
To: rtcweb@ietf.org
Message-ID: <2F910F1F060F4EB3979388279209412E@gmail.com>
In-Reply-To: <4DFF550C.2000009@jesup.org>
References: <5DA67EA1-77DC-4F55-850C-E76E0F133A81@cisco.com> <BANLkTi=g13whA3PCXKPW5Q7a2PzEDY3ESg@mail.gmail.com> <4DFF052A.8020202@alvestrand.no> <4DFF550C.2000009@jesup.org>
X-Mailer: sparrow 1.2.1 (build 767.22)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: Tue, 21 Jun 2011 07:45:51 -0000

In case of RTP, RTCP carries network level reception statistics and video/voice metrics (RTCP XR etc). However, there is a no standardized congestion control for RTP (http://tools.ietf.org/html/draft-gharai-avtcore-rtp-tfrc-00 uses packet loss and delay not some of the other cues mentioned in the mail).

Unless we identify a congestion control, I would suggest that the use-case capture that we need an extensible mechanism to carry this type of information and then the sender implements its own congestion control (best to its ability).

-- 
Varun Singh

On Monday, June 20, 2011 at 4:11 PM, Randell Jesup wrote:

> On 6/20/2011 4:30 AM, Harald Alvestrand wrote:
> > On 06/17/11 21:38, Aron Rosenberg wrote:
> > > On Fri, Jun 17, 2011 at 11:09 AM, Cullen Jennings <fluffy@cisco.com (mailto:fluffy@cisco.com) 
> > > <mailto:fluffy@cisco.com>> wrote:
> > > 
> > > 
> > >  Video Size Change.
> > > 
> > >  Alice and Bob are in a video call in their browsers and have
> > >  negotiate a high resolution video. Bob decides to change the size
> > >  of the windows his browser is displaying video to a small size.
> > >  Bob's browser should be able to regenerate the video codec
> > >  parameters with Alice's browser to change the resolution of video
> > >  Alice sends to match the smaller size.
> > > 
> > > 
> > > Changing compression due to a user change in window size is usually 
> > > not done since it has a bad long term effect on video quality. In 
> > > almost all the major video calling systems, video resolution is a 
> > > function of current bandwidth (which changes as the rate control 
> > > system detects differences) and/or constrained by the physical 
> > > device, but not a function of a user dragging the window size. At 
> > > an equivalent bitrate, it is better to compress a larger resolution 
> > > and display it smaller (higher PSNR), then compress a smaller 
> > > resolution if you are within the codec's effective bitrate for that 
> > > larger resolution.
> 
> Don't use "most current systems" as a guide. Just because they don't do 
> it doesn't mean it's a bad idea (it might be, but more proof than their 
> not doing it is needed).
> 
> I would assert that in general, it's better to scale before encoding 
> than to scale after decoding; and one scale operation is generally 
> better than two (at camera->encoder, and decoder->display), given a 
> constant bitrate.
> 
> > Interesting info, but I don't know if it's true in all cases.
> > 
> > If the overall constraint on a conferencing system is bandwidth, the 
> > system might find the saving in average bandwidth saving of encoding 
> > from a base image of 140x200 for "small" windows rather than "HD" 
> > (720x1024?) worth considering, even though the sending of a complete 
> > I-frame to reinitialize the video stream might take some effort.
> > 
> > I like having the use case of "change recipient video window size, and 
> > as a result change sender bandwidth usage"; we might argue about the 
> > exact phrasing of the use case.
> 
> The more general issue here is one of communication: events such as 
> window resize are of interest to the sender, and may cause the sender to 
> change what they're sending. Events could include bandwidth changes, 
> decode resolution changes, decode framerate changes (probably not 
> common, but perhaps for managing battery use), exposure (decode partly- 
> or fully-obscured, or perhaps the user has zoomed in on one portion of 
> the video), etc. How the encoder reacts to that is largely up to the 
> encoder/app (and input from the decoder app on what it wants); 
> transmission of the information to allow decision-making is what I'm 
> concerned with.
> 
> Some of these can/should be spoken to in use-cases.
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org (mailto:randell-ietf@jesup.org)
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org (mailto:rtcweb@ietf.org)
> https://www.ietf.org/mailman/listinfo/rtcweb