Re: [clue] Proposal to combine capture scene and capture set

Roni even <Even.roni@huawei.com> Fri, 09 March 2012 22:40 UTC

Return-Path: <Even.roni@huawei.com>
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 E80F221E80A6 for <clue@ietfa.amsl.com>; Fri, 9 Mar 2012 14:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.738
X-Spam-Level:
X-Spam-Status: No, score=-105.738 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, 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 fIXtZ1XDP2sv for <clue@ietfa.amsl.com>; Fri, 9 Mar 2012 14:40:51 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06A21E805F for <clue@ietf.org>; Fri, 9 Mar 2012 14:40:51 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N00FHY30220@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:40:50 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N009L53028P@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:40:50 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ46737; Sat, 10 Mar 2012 06:40:49 +0800
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 10 Mar 2012 06:40:28 +0800
Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Sat, 10 Mar 2012 06:40:45 +0800
Date: Fri, 09 Mar 2012 22:40:43 +0000
From: Roni even <Even.roni@huawei.com>
In-reply-to: <CAHBDyN5P3obwdbbsPLgAJUg4ju8xvbifx-B9UbKww8O85m1_6A@mail.gmail.com>
X-Originating-IP: [172.24.1.67]
To: Mary Barnes <mary.ietf.barnes@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-id: <EADCEEE0AE4A7F46BD61061696794D9807722071@szxeml536-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Ce1bKhXx7J1vGTRr06Zytg)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [clue] Proposal to combine capture scene and capture set
Thread-index: Acz7BEjU/dWlSEAnQuC91hY5WY2g+gAkLwwAAJiiIAAAE12OYA==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> <CAHBDyN5P3obwdbbsPLgAJUg4ju8xvbifx-B9UbKww8O85m1_6A@mail.gmail.com>
Cc: "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] Proposal to combine capture scene and capture set
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: Fri, 09 Mar 2012 22:40:53 -0000

Mary,

I have no problem with having just capture scene and taking out the capture set. This is a very minor issue in the discussion.



I hope we can have an agreed text on simultaneous capabilities and capture scene entries and how a consumer selects a configuration



As for the MCU case you mention, my view is that this is not a CLUE issue but a general MCU problem of source selection by participants and you can see some discussion in draft-lennox-mmusic-sdp-source-selection-03



Roni Even

________________________________
From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Friday, March 09, 2012 23:21
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: [clue] Proposal to combine capture scene and capture set

Paul,

I'm trying to discern if we have consensus on the basic question of whether people are okay with replacing the term "capture set" with "capture scene" using the definitions that Mark has below.    Paul, can you please clarify two things for the WG:
1) That you are speaking as an individual in the threads (i.e., you are not trying to evaluate the thread for consensus)
2)  I *think* you are disagreeing with Mark's proposal, but that's not clear to me.  I think you are suggesting that "Capture Scene" be defined to have a more information than just capture scene entries.  Is that correct?

Thanks,
Mary.
- as WG co-chair

On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
On 3/5/12 2:16 PM, Duckworth, Mark wrote:
At the interim meeting, there was some support for combining the
concepts of “capture scene” and “capture set” into a single concept. So
here is a rough proposal for doing that, essentially using the term
“capture scene” to replace the previous term “capture set”, and
eliminating the original separate capture scene concept.

Definitions:

*Capture Scene: a structure representing the scene that is captured by a
collection of capture devices. A capture scene includes one or more
capture scene entries, with each entry including one or more media
captures.

*Capture Scene Entry: a list of media captures of the same media type
that together form one way to represent the capture scene.

One of the reasons I preferred "Capture Scene" to "Capture Set" is that "set" implied to me that it is *only* a set of captures. But in fact there are already other attributes in addition to the set of captures (such as the purpose), and there will probably be more as we proceed.

To me, "Capture Scene Entry" conveys some of that same assumption. Namely, that a Capture Scene" is made up of a number of Capture Scene Entries, which seems to exclude other attributes that are not Capture Scene Entries.

It would feel more natural to me to have a Capture Set that is a set of media captures. (That is, what was previously called a Capture Set Entry.) And then define another term for a grouping of these Capture Sets. I'm having trouble coming up with a term for that which matches the intent well, but as a swag, how about Capture Set Alternatives.

So then you would have a logical structure something like:

- Advertisement
 - Capture Scene (one or more)
   - Description
   - Purpose
   - Area of Scene
   - Capture Set Alternatives (one or more)
     - Capture Set (one or more)
       - Capture

I don't think Capture Set Alternatives is the right term. I think I am hampered in finding a better term by not really having a crisp understanding of the reason for having this grouping. Its partly about alternatives in that there is an expectation that for a particular medium you would choose only one. But its not about alternatives in that you need to choose audio and video independently. Also, that is only an approximation - there seem to be expected cases when entries from more than one video entry would be chosen.

In my experience, when its hard to find a good term it usually means that the thing being named is not sufficiently defined and likely can be factored into more meaningful pieces.

       Thanks,
       Paul

Text for section 6.2 Capture Scene (was 6.2 Capture Set):

A capture scene represents, for example, the video image of a group of
people seated next to each other, along with the sound of their voices,
which could be represented by some number of VCs and ACs in the capture
scene entries. A middle box may also express capture scenes that it
constructs from media streams it receives.

A media provider arranges media captures in a capture scene to help the
media consumer choose which captures it wants. The capture scene entries
in a capture scene are different alternatives the provider is suggesting
for representing the capture scene. The media consumer can choose to
receive all media captures from one capture scene entry for each media
type (e.g. audio and video), or it can pick and choose media captures
regardless of how the provider arranges them in capture scene entries.

A capture scene may include more than one type of media. For example, a
capture scene can include several capture scene entries for video
captures, and several capture scene entries for audio captures.

(This text would be worked into section 6.2, not replace it completely.
Other things in section 6.2 and elsewhere would need to be edited to be
consistent with the new terminology in this proposal)

Regards,

Mark



_______________________________________________
clue mailing list
clue@ietf.org<mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org<mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue