Re: [clue] #2: Use cases for selecting composed captures

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 11 January 2012 19:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DF911E8094 for <clue@ietfa.amsl.com>; Wed, 11 Jan 2012 11:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 uZszK2BW2T8f for <clue@ietfa.amsl.com>; Wed, 11 Jan 2012 11:12:34 -0800 (PST)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C511E8073 for <clue@ietf.org>; Wed, 11 Jan 2012 11:12:33 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id LJu51i0040Fqzac56KCagj; Wed, 11 Jan 2012 19:12:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id LKCZ1i00R07duvL3UKCZuF; Wed, 11 Jan 2012 19:12:34 +0000
Message-ID: <4F0DDF21.2070706@alum.mit.edu>
Date: Wed, 11 Jan 2012 14:12:33 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roni even <Even.roni@huawei.com>
References: <063.9b81af3c175d186140d57829d721bd2b@trac.tools.ietf.org> <EADCEEE0AE4A7F46BD61061696794D98F9240C@SZXEML519-MBS.china.huawei.com>
In-Reply-To: <EADCEEE0AE4A7F46BD61061696794D98F9240C@SZXEML519-MBS.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] #2: Use cases for selecting composed captures
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jan 2012 19:12:35 -0000

On 1/10/12 2:26 PM, Roni even wrote:
> Hi,
> I do not understand why you this issue is still on my name. I sent previous emails to the list about the use cases. I hope this is my last email for the tracker on the issue and it will start the discussion.

 From the minutes on the discussion of the framework in Taipei:

| Selecting Composed Captures:
|
| Options-
|
| ·      do nothing
|
| ·      attempt to define a few specific policies
|
| Charles Eckel - "hints" in prev. framework draft may be sufficient.
|
| Jonathan Lennox - do we have details on policies?
|
| Stephen Botzko - lots of different conference/composition policies, 
very difficult to structure this information meaningfully.
|
| Allyn Romanow - agrees this is difficult, would rather postpone this
|
| Roni Even - sees distinction between requesting and selecting
|
| Mary Barnes - "Policy" word is scary, XCON struggled with a similar issue.
|
| Action - Roni Even to provide use cases on list for discussion.
|
| Conclusion: there is agreement that source selection work needs to 
continue, at least as requirements. Actual mechanism might be handed off 
to another group.

This is the source of the action item. The option to do nothing was 
discarded, leaving the need to do something more. I don't find anything 
on the list subsequent to this session directly addressing this subject.

The goal was to initiate more discussion towards what to specify.

Maybe this mail will at least start that discussion.

	Thanks,
	Paul

> The current description of composed in section 5.4.2 is
> "A Boolean variable to indicate whether the MC is a mix or composition
>     of other MCs or Streams.  (This could indicate for example a
>     continuous presence view of multiple images in a grid, or a large
>     image with smaller picture-in-picture images in it.  When applied to
>     an audio capture, it indicates a composition of ACs by some mixing
>     algorithm)
>     This attribute is not intended to differentiate between different
>     ways of composing or mixing images.  For possible extension of the
>     framework, additional attributes could be defined to distinguish
>     between different ways of composing or mixing captures.  For example,
>     with different video layout arrangements of composing multiple images
>     into one, or different audio mixing algorithms."
>
> Note that it says that there can be different composition options and the editors decided that the attribute should not differentiate between them and do it only in extensions. So the issue is not what are the use cases since the draft talk about different cases but whether the cases should be specified here and provide more options for the provider to propose different mixes allowing the consumer to select between them.
>
> I can give again the most obvious use case which is the support for site switch and segment switch modes that are part of the use cases draft.
> The provider should be able to specify if the video capture is based on site switch or segment switch or say that it can support one of them or both. The consumer should be able to ask for a specific view based on the mixed policy.
>
> For point to point calls that use case for the provider to specify what is being offered. Examples of different options may be a view of current speaker with a PiP that has the previous speaker, or the whole room or a mix of the other capture devices. Another option is a mix of the active speaker with the center capture device if the speaker is not in the center.
> All these options cannot be specified by a Boolean called composed.
>
> The current description of auto switch in term of capture area does not provide any information about the actual size of each view. Note that auto switch algorithm is not defined and is not meant to be unique. (voice activated is an option) other options are switch input every 30 seconds, ...
>
> Roni Even
>
> ________________________________________
> From: clue issue tracker [trac+clue@gamay.tools.ietf.org]
> Sent: Tuesday, January 10, 2012 20:15
> To: pkyzivat@alum.mit.edu
> Cc: clue@ietf.org; Roni even
> Subject: [clue] #2: Use cases for selecting composed captures
>
> #2: Use cases for selecting composed captures
>
>   Roni Even to post use cases for selecting composed captures, on the
>   mailing list.
>
> --
> ------------------------------------+-----------------------
>   Reporter:  pkyzivat@…              |      Owner:  Roni Even
>       Type:  task                    |     Status:  new
>   Priority:  major                   |  Milestone:
> Component:  telepresence-use-cases  |    Version:
>   Severity:  Active WG Document      |   Keywords:
> ------------------------------------+-----------------------
>
> Ticket URL:<http://trac.tools.ietf.org/wg/clue/trac/ticket/2>
> clue<http://tools.ietf.org/wg/clue/>