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

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 5 Mar 2012 11:16:26 -0800

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.

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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 5 Mar 2012 23:58:01 -0500

Mark,

Not sure if I am getting this properly.  There seems to be only a couple
concepts.
Let me feed back to you in my terms and see if I am missing some key point.

An atomic level (no lower subcomponents) media capture can be either a
video capture (VC) or an audio capture (AC).
A capture scene is an aggregation with structural meta-data that includes:
- zero or more AC, or (logical meaning also "and")
- zero or more VC, or
- zero or more capture scenes, i.e. it aggregates iteratively.
The capture scene can be constructed by either the media provider or the
media consumer.

That last point seems to be implied by "provider arranges" and "consumer
can choose" but would be good to verify.
I would think that what the sender does prior or what the receiver does
subsequent to receipt might be secondary.

Miss anything?
Mike

On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark
<[email-masked]>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.****
>
> ** **
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 6 Mar 2012 10:23:20 +0200

Hi Mark,

I do not care how we call it. What I am missing is the top level.

Does a provider advertise one capture scene composed of multiple capture
scene entries. My understanding so far was that there can be  more than one
if we substitute set with scene.

Can there be more than one capture scene in the advertisement in which case
how do you differentiate between them, is there a scene identifier and how
does the consumer know what is the scene.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: Monday, March 05, 2012 9:16 PM
To: [email-masked]
Subject: [clue] Proposal to combine capture scene and capture set

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.

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

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Tue, 6 Mar 2012 02:10:58 -0800

Hey Roni,

I think this is just a vocabulary change-multiple capture scenes are
still allowed.  The idea was that the 'purpose' attribute of the capture
scene would be used to differentiate them.

-Brian 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Tuesday, March 06, 2012 12:23 AM
To: 'Duckworth, Mark'; [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

Hi Mark,

Does a provider advertise one capture scene composed of multiple capture
scene entries. My understanding so far was that there can be  more than
one if we substitute set with scene.

Can there be more than one capture scene in the advertisement in which
case how do you differentiate between them, is there a scene identifier
and how does the consumer know what is the scene.

Roni Even

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:

captures.  

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

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.  

Regards,

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 15:07:09 -0500

On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote:
> Hey Roni,
>
> I think this is just a vocabulary change—multiple capture scenes are
> still allowed. The idea was that the ‘purpose’ attribute of the capture

A scene represents a physical (or virtually physical) space that is 
represented by one or more captures. If an endpoint has available and 
wants to advertise representations of more than one such space then it 
will be including more than one capture scene in its advertisement. The 
'purpose' attribute won't always be sufficient to disambiguate the scenes.

One case where 'purpose' *would* be enough is when one scene is 'main' 
representing a single room, and another is 'presentation'.

A case where it *isn't* enough is when the endpoint is an MCU and it 
wants to offer to "pass through" a scene for each connected room. In 
that case, each of those scenes will probably have purpose 'main'. There 
probably needs to be some other attribute that describes the scene - 
perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom 
Andover", ...) Or there could be a more complex attribute that describes 
location.

	Thanks,
	Paul

> -Brian
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Roni Even
> *Sent:* Tuesday, March 06, 2012 12:23 AM
> *To:* 'Duckworth, Mark'; [email-masked]
> *Subject:* Re: [clue] Proposal to combine capture scene and capture set
>
> Hi Mark,
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
> *On Behalf Of *Duckworth, Mark
> *Sent:* Monday, March 05, 2012 9:16 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [clue] Proposal to combine capture scene and capture set
>
> concepts of “capture scene” and “capture set” into a single concept. So
> “capture scene” to replace the previous term “capture set”, and
> 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.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 15:31:14 -0500

> 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

---

From: Roni even <[email-masked]>
Date: Tue, 06 Mar 2012 21:56:24 +0000

Hi Paul,
I think that the MCU case you described should be handled differently. In current solutions if the MCU wants to provide information about all the meeting participants it is done using the conferencing event package. This helps with addressing large messages and also work with partial notification when a user joins or leave as specified in the XCON conference event package.

Roni Even

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Tuesday, March 06, 2012 22:07
To: [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 17:30:22 -0500

> I think that the MCU case you described should be handled differently. In current solutions if the MCU wants to provide information about all the meeting participants it is done using the conferenc…

While I understand that the conference event package is applicable, I 
don't see how it is a substitute for what I described.

If the MCU is the recipient of captures from multiple scenes (and it 
always will be), then what does it advertise? I guess there are multiple 
answers to that:

- it can create a single scene representing a "virtual room", with a 
single coordinate space. It can then map all the captures onto that 
coordinate space. In that case it only needs one scene, for the 'main' 
stuff. And I guess it could do that for other purposes as well, creating 
one virtual scene per purpose.

- it can do as I suggested, offering up each of the scenes it has 
received. Thus there can be several scenes for each purpose.

	Thanks,
	Paul

>> *From:[email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
>> *To:* [email-masked]<mailto:[email-masked]>

---

From: Roni even <[email-masked]>
Date: Wed, 07 Mar 2012 07:50:31 +0000

Hi Paul,
I understand what you are trying to describe but my view is that the MCU does not need to advertise all rooms using CLUE protocol, maybe it is also a transport discussion but look at current multipoint solutions.

The MCU offers what you call a "virtual room" that has a common mode. It does not offer all the participants and all potential RTP streams, it may send another offer if the "virtual room" capabilities has changed. The participants list and the way to ask to view a specific participant or a specific composition is done using XCON.

It already looks like we have some consensus that CLUE will not describe the available composition options and leave it to the MCU to decide what it wants to send to the participants. The selection by a participant of whom to view or what composition to use should be part of XCON extensions. 

I think this is the right direction since it will make the CLUE message and transport simpler and I do not think that we should have CLUE do everything if it can be done by other means. Most calls are point to point and the multipoint case should not make the CLUE support more complicated.

Roni Even 

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Wednesday, March 07, 2012 0:30
To: Roni even
Cc: [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

        Thanks,
        Paul

---

From: "Robert Hansen (rohanse2)" <[email-masked]>
Date: Wed, 7 Mar 2012 11:13:22 +0100

To expand a bit and concur with Roni, I don't see the scenario of an MCU
advertising the participants available to it as separate scenes as
necessarily invalid, but it poses a number of problems.

In this case the MCU would need to re-advertise its available scenes
every time someone left or joined the conference - in all but small
conferences these messages would rapidly become very large (as the MCU
is essentially aggregating all the advertisements it has received).

Further, while it gives the ability for a consumer to select exactly
which participant(s) it wishes to receive, in practise endpoints
generally want to receive the most 'relevant' participant(s), usually
determined by something like audio activity levels; in the scenario
where the consumer has to explicitly select which participants to view
using CLUE I'm not sure how this could be implemented.

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni even
Sent: 07 March 2012 08:51
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

Hi Paul,
I understand what you are trying to describe but my view is that the MCU
does not need to advertise all rooms using CLUE protocol, maybe it is
also a transport discussion but look at current multipoint solutions.

The MCU offers what you call a "virtual room" that has a common mode. It
does not offer all the participants and all potential RTP streams, it
may send another offer if the "virtual room" capabilities has changed.
The participants list and the way to ask to view a specific participant
or a specific composition is done using XCON.

It already looks like we have some consensus that CLUE will not describe
the available composition options and leave it to the MCU to decide what
it wants to send to the participants. The selection by a participant of
whom to view or what composition to use should be part of XCON
extensions. 

I think this is the right direction since it will make the CLUE message
and transport simpler and I do not think that we should have CLUE do
everything if it can be done by other means. Most calls are point to
point and the multipoint case should not make the CLUE support more
complicated.

Roni Even 

On 3/6/12 4:56 PM, Roni even wrote:
> Hi Paul,
> I think that the MCU case you described should be handled differently.
In current solutions if the MCU wants to provide information about all
the meeting participants it is done using the conferencing event
package. This helps with addressing large messages and also work with
partial notification when a user joins or leave as specified in the XCON
conference event package.

        Thanks,
        Paul

> Roni Even
entries

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2012 10:40:06 -0500

Responding to both Roni and Rob:

I certainly understand that not all MCUs will want to pass through all 
the scenes they receive. But ISTM that doing so should be possible.

In any case the original question was whether an advertisement could 
contain more than one scene. Since all captures in a scene share a 
common coordinate space, it seems clear that it must be possible to have 
multiple scenes just to handle the captures that fall within the "room" 
coordinate space and those that are for presentations that don't share 
that same coordinate space.

The only added complication for an MCU passing through scenes from 
multiple rooms is having a way to distinguish two scenes with the same 
purpose.

Re the size of advertisements: as long as the clue protocol is capable 
of passing large messages I think we can leave this to the discretion of 
the MCU to decide. It can pass through or fabricate new scenes as it 
sees fit.

I would really appreciate seeing an example of what a "virtual room" 
constructed by an MCU will look like. What sort of coordinate system 
will it use that can accommodate switched and/or mixed captures 
assembled from multiple rooms?

	Thanks,
	Paul

---

From: Roni even <[email-masked]>
Date: Thu, 08 Mar 2012 00:15:14 +0000

Hi Paul,
First having just the CLUE information from multi[le sites is not enough since you need the full offer (SDP) to send and receive the media and if not going through the MCU you may need to use ICE to establish the connection
As for the virtual room. We have two use cases
For Segment switch the co-ordinate are constructed by the MCU and have no scale
For Site switch it will need to send the co-ordinates of the room that he is now sending. This can be done as a message when switching or a better way it can be available as roster information using the conference event package which is updated when a user joins or drops.  Note that the XCON event package supports partial notifications
Roni
________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Wednesday, March 07, 2012 17:40
To: Robert Hansen (rohanse2)
Cc: Roni even; [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

        Thanks,
        Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 8 Mar 2012 12:58:22 -0800

Hi Mike,

I don't think anybody responded to this specifically.  I put some comments below.

Mark

From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, March 05, 2012 11:58 PM
To: Duckworth, Mark
Cc: [email-masked]
Subject: Re: [clue] Proposal to combine capture scene and capture set

Mark,

Not sure if I am getting this properly.  There seems to be only a couple concepts.
Let me feed back to you in my terms and see if I am missing some key point.

An atomic level (no lower subcomponents) media capture can be either a video capture (VC) or an audio capture (AC).
[Duckworth, Mark] correct.

A capture scene is an aggregation with structural meta-data that includes:
- zero or more AC, or (logical meaning also "and")
- zero or more VC, or
[Duckworth, Mark] Yes it includes other media captures (not restricted to audio and video).  But these other media captures are grouped into "capture scene entries".  So the hierarchy is: A provider advertisement includes capture scenes.  A capture scene includes capture scene entries.  A capture scene entry includes media captures.

- zero or more capture scenes, i.e. it aggregates iteratively.
[Duckworth, Mark] No, not iterative.

The capture scene can be constructed by either the media provider or the media consumer.
[Duckworth, Mark] No, the media provider constructs capture scenes, which it includes in the provider advertisement it sends to the consumer.

That last point seems to be implied by "provider arranges" and "consumer can choose" but would be good to verify.
[Duckworth, Mark] The consumer can choose from among various things the provider advertises, but the consumer does not construct a capture scene out of this.

I would think that what the sender does prior or what the receiver does subsequent to receipt might be secondary.

Miss anything?
Mike

On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark <[email-masked]<mailto:[email-masked]>> 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:

Regards,
Mark

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Michael Hammer <[email-masked]>
Date: Thu, 8 Mar 2012 17:06:46 -0500

Thanks.  That makes it much clearer for me.

Mike

On Thu, Mar 8, 2012 at 3:58 PM, Duckworth, Mark
<[email-masked]>wrote:

> Hi Mike,****
>
> ** **
>
> I don’t think anybody responded to this specifically.  I put some comments
> below.****
>
> ** **
>
> Mark****
>
> ** **
>
> *From:* Michael Hammer [mailto:[email-masked]]
> *Sent:* Monday, March 05, 2012 11:58 PM
> *To:* Duckworth, Mark
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Proposal to combine capture scene and capture set***
> *
>
> ** **
>
> Mark,****
>
> ** **
>
> concepts.****
> ****
> video capture (VC) or an audio capture (AC).****
>
> *[Duckworth, Mark] correct.*
>
> ** **
>
> ****
> - zero or more AC, or (logical meaning also "and")****
>
> - zero or more VC, or****
>
> *[Duckworth, Mark] Yes it includes other media captures (not restricted
> to audio and video).  But these other media captures are grouped into
> “capture scene entries”.  So the hierarchy is: A provider advertisement
> includes capture scenes.  A capture scene includes capture scene entries.
> A capture scene entry includes media captures.*
>
> ** **
>
> - zero or more capture scenes, i.e. it aggregates iteratively.****
>
> *[Duckworth, Mark] No, not iterative.*
>
> ** **
>
> media consumer.****
> *[Duckworth, Mark] No, the media provider constructs capture scenes,
> which it includes in the provider advertisement it sends to the consumer.*
> ****
>
> ** **
>
> can choose" but would be good to verify.****
>
> *[Duckworth, Mark] The consumer can choose from among various things the
> provider advertises, but the consumer does not construct a capture scene
> out of this.*
>
> ** **
>
> subsequent to receipt might be secondary.****
>
> ** **
>
> Miss anything?****
>
> Mike****
>
> ** **
>
> ** **
>
> On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark <
> [email-masked]> wrote:****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 12:10:15 -0500

> First having just the CLUE information from multi[le sites is not enough since you need the full offer (SDP) to send and receive the media and if not going through the MCU you may need to use ICE t…

You need the SDP for those streams you select, but not for those you 
don't select. If your point is about the size of the SDP, its possible 
that the SDP could be reasonably small even for many selected captures.

> For Segment switch the co-ordinate are constructed by the MCU and have no scale

I suppose that works if all the advertised captures in the scene are 
segment switched.

> For Site switch it will need to send the co-ordinates of the room that he is now sending. This can be done as a message when switching or a better way it can be available as roster information usin…

That seems to require some machinery that hasn't yet been discussed.
It seems to trash the notion of having a single coordinate system per 
scene, unless "site switching" is really "scene switching" (which it may 
well be), and there is some way to define a scene as containing other 
scenes.

This "message when switching" - you mean within the clue protocol? Like 
a new advertisement? But if it was an advertisement, then it would 
require a new selection, ... and wouldn't be very timely. If it were to 
work that way then ISTM that it would need to be some other sort of 
message, as yet not investigated.

What about *mixed* captures, where the input to the mix is captures from 
other scenes?

ISTM that these use cases need to be worked out in considerably more 
detail to identify exactly what machinery is needed to represent them.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Fri, 9 Mar 2012 15:21:36 -0600

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 <[email-masked]> wrote:

> "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.
>
> 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.
>
> 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
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 17:08:38 -0500

On 3/9/12 4:21 PM, Mary Barnes wrote:
> 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)

Sorry for not making it clear. I have indeed been speaking as an 
individual in this discussion.

> 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?

I very much am in favor of Capture Scene replacing Capture Set.
As far as I am concerned that can happen and we can continue to discuss 
the nuances of what is in a Capture Scene.

Another related question was whether there can be more than one Capture 
Scene per advertisement. But I think it has now been settled that there can.

The rest may be a tempest in a tea pot. I'm surprised there seems to be 
so much controversy. Its about how many and what sort of Capture Scenes 
might appear in an advertisement from an MCU. Of course we don't really 
have to settle that now, or ever. I've been arguing that when there are 
multiple Scenes in an advertisement there should be some added 
attribute(s) available to help distinguish them. But we don't have to 
settle that soon either.

	Thanks,
	Paul

> Thanks,
> Mary.
> - as WG co-chair
>
> On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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.
>
>     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.
>
>     that the thing being named is not sufficiently defined and likely
>     can be factored into more meaningful pieces.
>
>             Thanks,
>             Paul
>
>         _________________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>

---

From: Roni even <[email-masked]>
Date: Fri, 09 Mar 2012 22:40:43 +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: [email-masked] [[email-masked]] on behalf of Mary Barnes [[email-masked]]
Sent: Friday, March 09, 2012 23:21
To: Paul Kyzivat
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Definitions:

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.

- Advertisement

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

Regards,

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 18:34:20 -0500

On 3/9/12 5:40 PM, Roni even wrote:
> 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 simultaneouscapabilitiesand 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

That sort of source selection works once the media is being sent to you. 
But I don't see how its helpful for decoding an advertisement and 
deciding what captures you want to receive.

Or are you a tight coupling between that draft and CLUE, so that it 
provides the select functionality?

	Thanks,
	Paul

> Roni Even
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of Mary
> Barnes [[email-masked]]
> *Sent:* Friday, March 09, 2012 23:21
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> "capture scene" using the definitions that Mark has below. Paul, can you
> please clarify two things for the WG:
> to have a more information than just capture scene entries. Is that correct?
>
> Thanks,
> Mary.
> - as WG co-chair
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 9 Mar 2012 17:28:41 -0800

Thanks Paul and Mary for re-focusing on the specific proposal.  I agree there are still other issues regarding capture scenes, that we can continue to discuss.

So as the framework editor, I would like to hear from you as co-chairs whether or not I should update the document according to the proposal here:
http://www.ietf.org/mail-archive/web/clue/current/msg01141.html

If you say go ahead, I should be able to do it before the Monday deadline.

Thanks,
Mark

> Paul Kyzivat
> Sent: Friday, March 09, 2012 5:09 PM
> To: Mary Barnes
> Cc: [email-masked]
> > 1) That you are speaking as an individual in the threads (i.e., you
> > are not trying to evaluate the thread for consensus)
> 
> Sorry for not making it clear. I have indeed been speaking as an individual in
> this discussion.
> 
> > 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?
> 
> As far as I am concerned that can happen and we can continue to discuss the
> nuances of what is in a Capture Scene.
> 
> The rest may be a tempest in a tea pot. I'm surprised there seems to be so
> much controversy. Its about how many and what sort of Capture Scenes
> attribute(s) available to help distinguish them. But we don't have to settle
> that soon either.
> 
> 	Thanks,
> 	Paul
> 
> 
> > Thanks,
> > Mary.
> > - as WG co-chair
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Mar 2012 20:50:46 -0500

> http://www.ietf.org/mail-archive/web/clue/current/msg01141.html

I think you should go ahead with this. Lets see if Mary agrees.

	Thanks,
	Paul

>>> On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat<[email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Sat, 10 Mar 2012 13:44:16 -0600

Yes, I agree.

Thanks,
Mary.

On Fri, Mar 9, 2012 at 7:50 PM, Paul Kyzivat <[email-masked]> wrote:

>> Thanks Paul and Mary for re-focusing on the specific proposal.  I agree
>> there are still other issues regarding capture scenes, that we can continue
>> to discuss.
>>
>> So as the framework editor, I would like to hear from you as co-chairs
>> whether or not I should update the document according to the proposal here:
>> http://www.ietf.org/mail-**archive/web/clue/current/**msg01141.html<http://www.ietf.org/mail-archive/web/clue/current/msg01141.html>
>>
>
>>> so
>>> settle
>>>> <mailto:[email-masked]>**>  wrote:
>>>>
>>>>         ______________________________**___________________
>>>>         clue mailing list
>>>>         [email-masked]<mailto:clue@**ietf.org <[email-masked]>>
>>>>         https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>>>         <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>> >
>>>>
>>>>
>>>>     ______________________________**___________________
>>>>     clue mailing list
>>>>     [email-masked]<mailto:clue@**ietf.org <[email-masked]>>
>>>>     https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue>
>>>>     <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>> >
>>>>
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Mar 2012 11:10:09 -0400

On 3/8/12 3:58 PM, Duckworth, Mark wrote:

> */[Duckworth, Mark] No, the media provider constructs capture scenes,
> which it includes in the provider advertisement it sends to the consumer./*
>
> */[Duckworth, Mark] The consumer can choose from among various things
> the provider advertises, but the consumer does not construct a capture
> scene out of this./*

Well, an MCU is a consumer of scenes from the endpoints attached to it.
And it can then construct new scenes from the media received from them.

But I don't think this was the point Mike was trying to make.

	Thanks,
	Paul