Subject: Re: [clue] comments to framework 09 - simultaneous sets

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Mar 2013 19:26:00 +0800

On 2/28/13 8:04 PM, Roberta Presta wrote:

> My proposal is, instead of listing all the captures, using capture scene
> identifiers and capture scene entry identifiers, and building
> simultaneous sets as:
> - CSB, CSC, CSE3_A, CSE1_A
> - CSB, CSC, CSE3_A, CSE2_A

This is more concise, and may partially satisfy Christer :-)

It does imply that the identifiers for CSs must be unique from those for 
CSEs. (There is a single namespace shared by both CS ids and CSE ids.) I 
haven't looked at the latest data model yet to see if that is guaranteed.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Mar 2013 15:18:47 +0000

Hi,

> This is more concise, and may partially satisfy Christer :-)

I'm listening :)

>haven't looked at the latest data model yet to see if that is guaranteed.

Just for my clarification, what does it mean to indicate a CS?

A CS does not have any captures. A CS is always represented by at least one CSE, and the CSE contains captures.

So, taking your example, does CSB indicate that I can provide ANY CSE associated with CSB, or that I can provide ALL CSEs associated with CSB?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 03 Mar 2013 03:49:02 +0800

> So, taking your example, does CSB indicate that I can provide ANY CSE associated with CSB, or that I can provide ALL CSEs associated with CSB?

I was a little jetlagged when I wrote that. (Still am, so take this with 
a grain of salt.)

I guess perhaps I misinterpreted Roberta.
But what I was thinking of was being able to list CSEs and/or individual 
captures in a simultaneous set.

And in spite of what I said before, that may not require the identities 
of both to be in the same namespace. It depends on how the XML is 
constructed.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 3 Mar 2013 08:29:46 +0000

Hi,

> captures in a simultaneous set.

I can live with that :)

We probably need to think about some rules for that, but one thing (based on your other reply to me): if I indicate support of CSE_1, then I don't think I should be allowed - within the same set - to list any captures associated with CSE_1 in the same set. Because, CSE_1 already means that I can provide all associated captures.

Example:

CSE_1 has the following captures: CS_1A, CS_1B and CS_1C
CSE_2 has the following captures: CS_2A, CS_2B, CS_2C

Allowed set:

CSE_1, CS_2B, CS_2C   <------ CS_2B and CS_2C are not associated with CSE_1 

NOT allowed:

CSE_1, CS_1A               <------ CS_1A is associated with CSE_1

>of both to be in the same namespace. It depends on how the XML is

Yes.

Regards,

Christer

---

From: Roberta Presta <[email-masked]>
Date: Sun, 03 Mar 2013 19:50:26 +0100

Hi Christer,

>> So, taking your example, does CSB indicate that I can provide ANY CSE associated with CSB, or that I can provide ALL CSEs associated with CSB?

Listing a capture scene identifier like CSB in a simultaneous set should 
mean the provider is able to send simultaneously all the captures within 
the capture scene entries associated with that capture scene.
Or, at least, that was what I had in mind.
It is in line with the current definition of the simultaneous sets 
(Simultaneous transmission sets are expressed as sets of the Media 
Captures that could physically be transmitted at the same time).
Regards,

Roberta

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Mar 2013 12:43:33 +0800

> CSE_1, CS_1A               <------ CS_1A is associated with CSE_1

This is just a matter of philosophy about errors.
Specifying a single capture more than once in a simultaneous set is 
clearly redundant and unnecessary, but also harmless.
I don't feel strongly whether that should be considered an error.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Mar 2013 13:13:30 +0800

On 3/4/13 2:50 AM, Roberta Presta wrote:
>>> So, taking your example, does CSB indicate that I can provide ANY CSE
>>> associated with CSB, or that I can provide ALL CSEs associated with CSB?
>

Ah, ok - that makes sense.

So referencing a CSE means all the captures in it, and referencing a CS 
means all the CSEs in it. With that interpretation, then referencing a 
CS could implicitly reference a single capture more than once. So a 
corollary is that referencing a single capture more than once is not an 
error.

This does make a lot very concise to describe some common kinds of 
simultaneous sets.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Mar 2013 09:04:48 +0000

Hi,

>>>>> My proposal is, instead of listing all the captures, using capture 
>>>>> scene identifiers and capture scene entry identifiers, and building 
>>>>> simultaneous sets as:
>>>> So, taking your example, does CSB indicate that I can provide ANY 
>>>> CSE associated with CSB, or that I can provide ALL CSEs associated with CSB?
>>
>> Listing a capture scene identifier like CSB in a simultaneous set 
>> should mean the provider is able to send simultaneously all the 
>> captures within the capture scene entries associated with that capture scene.
> So referencing a CSE means all the captures in it, and referencing a CS means all the CSEs in it. With that interpretation, then referencing a CS could implicitly reference a single capture more than once. So a corollary is that referencing 
> a single capture more than once is not an error.

I agree. If you reference a CS, and some capture is used in multiple associated CSEs, it means that you are able to provide multiple "instances" of the capture - one for each CSE where it is used.

The same thing would apply if you reference a CSE, and a capture within it: it means you are able to provide two "instances" of the capture.

So, while I can't think of any use-case at the moment, I agree that we should not consider it an error case. But, we need to make sure it's clearly documented :)

Regards,

Christer

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 6 Mar 2013 06:20:59 -0800

Christer wrote:
> I agree. If you reference a CS, and some capture is used in multiple
> associated CSEs, it means that you are able to provide multiple "instances" of
> the capture - one for each CSE where it is used.

This does not make sense to me.  Simultaneous Transmission Sets should not be used to indicate how many "instances" (I think you mean Capture Encodings) of a Media Capture a Provider can provide.  That information is in the Encoding Group associated with the Media Capture.

I think if a Media Capture appears more than once in a Simultaneous Transmission Set, directly or indirectly, it means the same thing as if it appeared only once.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christer Holmberg
> Sent: Monday, March 04, 2013 4:05 AM
> To: Paul Kyzivat; Roberta Presta
> Cc: [email-masked]
> Subject: Re: [clue] comments to framework 09 - simultaneous sets
> 
> Hi,
> 
> >>>>> scene identifiers and capture scene entry identifiers, and
> >>>>> building simultaneous sets as:
> > So referencing a CSE means all the captures in it, and referencing a
> > CS means all the CSEs in it. With that interpretation, then referencing a CS
> could implicitly reference a single capture more than once. So a corollary is
> that referencing a single capture more than once is not an error.
> 
> I agree. If you reference a CS, and some capture is used in multiple
> associated CSEs, it means that you are able to provide multiple "instances" of
> the capture - one for each CSE where it is used.
> 
> The same thing would apply if you reference a CSE, and a capture within it: it
> means you are able to provide two "instances" of the capture.
> 
> So, while I can't think of any use-case at the moment, I agree that we should
> not consider it an error case. But, we need to make sure it's clearly
> documented :)
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 6 Mar 2013 06:32:39 -0800

I will try to summarize what I think the conclusions are from this thread.

Point 1 - we generally agree simultaneity restrictions are not just about physical constraints, there are other reasons.

Point 2 - we should remove the bit about "may not make sense to do so".

Point 3 - we generally agree it would be good to allow expressing Simultaneous Transmission Sets as lists of Capture Sets, Capture Set Entries, as well as Media Captures that the Provider can provide simultaneously.

Point 4 - we generally agree (again) we do not want to define other ways of expressing Simultaneous Transmission Sets, such as by mutual exclusion or with logical operators.

Regards,
Mark

> Roberta Presta
> Sent: Wednesday, February 27, 2013 1:47 PM
> To: [email-masked]
> Subject: [clue] comments to framework 09 - simultaneous sets
> 
> Hi all,
> 
> sorry for boring you always with the same things :)
> 
> When I read Section 6.3 "Simultaneous Transmission Set Constraint", I
> noticed a couple of things:
> 
> 1) the only motivation that has been provided to justify the definition of
> simultaneous sets is the fact that captures generated from the same device
> cannot be sent simultaneously. However, there can be other motivations
> behind the need of expressing simultaneity constraints (leaving resource
> constraints handled by encoding groups and other stuff such as max-
> encoding- and so on).
> Citing Andy Pepperel in
> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html,
> simultaneous sets can be used by MCUs that might not want to be obliged to
> provide some capture simultaneously, in order to avoid overloading.
> I think that these other motivations should be explicitely mentioned in the
> framework document to explain that simultaneity limitations may not be due
> only to physical constraints.
> 
> 2)  Copying from the document:  "Simultaneous transmission sets are
> expressed as sets of the Media Captures that could physically be transmitted
> at the same time (though it may not make sense to do so). "
> Does it mean that even if there is a large set of captures able to be sent
> simultaneously, it may not make sense, from the consumer's perspective, to
> receive them all together? Maybe rewording is needed here.
> 
> 3) Again, on the design (and definition) of the simultaneous sets.
> 
> Simultaneous sets, as defined in the framework, are *all* the groups of
> *captures* that can be sent together.
> The consumer presumably has to check if the set of captures he wants is fully
> *included* in almost one of the listed ones.
> If not, he has to re-structure the configure to fit simultaneity constraints
> expressed by the provider.
> (Is that the expected behavior of the consumer?)
> 
> I was thinking that each set can be expressed also in terms of capture scene
> entries, or capture scene as a whole, for example:
> 1) CSE1, CSE2, CS3, VC1, CS5
> 2) CSE1, CSE4, CS3, VC1, CS5
> ....
> Where CSE* identifies a capture scene entry, and CS* identifies a capture
> scene.
> That can allow to make simultaneous sets more synthetic by exploiting the
> capture aggregates the framework envisions. It can be particularly useful to
> MCUs that want to offer just subsets of the complete list of capture scenes
> they receive from multiple contributors.
> 
> 
> 4) Some further reasoning.
> 
> In some cases it can be more efficient to express only mutual exclusion
> constraints.
> We could discuss about envisioning a section of information named
> "simultaneity constraints" that can include a list of simultaneous sets and a
> list of mutual exclusion conditions to be checked on the consumer's side.
> For example, if a media provider offers many captures, and has only 4 mutual
> exclusion conditions, instead of listing all the possible simultaneous sets, he
> can just provide the 4 mutual exclusion conditions to the consumer.
> 
> Another alternative is also Christer Holmberg's proposal in
> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, where
> simultaneity constraints are logical conditions that the consumer has to verify
> before issuing a configure to the provider.
> The example was:
> 
> "(CSE-X AND CSE-Y) OR CSE-Z.
> 
> This means that the provider can provide CSE-X and CSE Y (and all captures
> associated with CSE-X and CSE-Y) simultaneously, or that the provider can
> provide CSE-Z (and all captures associated with CSE-Z)."
> 
> Do you think we should stuck on the framework solution or also consider the
> aforementioned alternatives?
> I promise I stop thinking about it!
> 
> RP
> 
> --
> Roberta Presta, Ph.D. Student
> Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione
> (DIETI) Universita' degli Studi di Napoli "Federico II"
> Via Claudio 21 -- 80125 Napoli (Italy)
> Phone: +390817683821 - Fax: +390817683816
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Mar 2013 14:47:53 +0000

Hi,

>> associated CSEs, it means that you are able to provide multiple 
>> "instances" of the capture - one for each CSE where it is used.
>
> This does not make sense to me.  Simultaneous Transmission Sets should not be used to indicate how 
> many "instances" (I think you mean Capture Encodings) of a Media Capture a Provider can provide.  That information is in the Encoding Group associated with the Media Capture.
>

I can live with that, but it STILL needs to be clearly specified :)

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Christer Holmberg
> >>>>> My proposal is, instead of listing all the captures, using 
> >>>>> capture scene identifiers and capture scene entry identifiers, 
> >>>>> and building simultaneous sets as:
> >>>> CSE associated with CSB, or that I can provide ALL CSEs 
> >>>> associated with
> CSB?
> >>
> >> captures within the capture scene entries associated with that 
> >> capture
> scene.
> could implicitly reference a single capture more than once. So a 
> corollary is that referencing a single capture more than once is not an error.
> 
> associated CSEs, it means that you are able to provide multiple 
> "instances" of the capture - one for each CSE where it is used.
> 
> The same thing would apply if you reference a CSE, and a capture 
> within it: it means you are able to provide two "instances" of the capture.
> 
> So, while I can't think of any use-case at the moment, I agree that we 
> should not consider it an error case. But, we need to make sure it's 
> clearly documented :)
> 
> Regards,
> 
> Christer
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 23:13:06 +0800

Mark,

I agree with all you say below.

But this does lead to another related issue that needs some 
consideration. Until now I think we have said that a single simultaneous 
set should mention only a single medium - voice or video. When we permit 
it to reference a complete scene it will have entries for different 
kinds of media. So what does that mean?

Having simultaneous sets only reference a single medium implies that 
simultaneity across media types is implicit. I wonder if that is really 
true.

Some possible resolutions to this:

1) keep the current assumption that a simultaneous set applies to only 
one medium, and to preserve that forbid the inclusion of a complete CS 
if it contains more than one type of medium.

2) keep the current assumption that a simultaneous set applies to only 
one medium. If a set contains references to CSs, factor those by media 
type, and create multiple sets - one for each medium.

3) forbid references to CSs in simultaneous sets

4) change the definition of simultaneous sets so that they explicitly 
define permitted simultaneity among multiple media types.

I haven't decided my own preference among the above.

	Thanks,
	Paul

---

From: Roberta Presta <[email-masked]>
Date: Wed, 06 Mar 2013 17:05:18 +0100

Hi Paul,

Il 06/03/2013 16:13, Paul Kyzivat ha scritto:
>
> Until now I think we have said that a single simultaneous set should 
> mention only a single medium - voice or video.
>

Even if simultaneous sets examples in the framework document only deal 
with video captures, it is not stated anywhere that they refer only to a 
single medium.
The current definition says only that they are lists of generic media 
captures.
That's why we put in the  data model example both audio and video 
captures in the simultaneous sets.
I don't know if I have missed some thread about it. If so, I apologize.

Building separated simultaneous sets on the basis of the captures' 
medium could bring in some cases the benefit of having shorter lists of 
captures.
However, I think that having the possibility of expressing simultaneous 
sets by using capture scene identifiers can be useful especially to MCUs 
dealing with a bulk of contributions from different sites. They can 
easily and briefly advertise simultaneous aggregates of captures 
(arranged in capture scenes) according to their internal policies.

What are your feelings about it?

Roberta

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Mar 2013 00:51:00 +0800

> What are your feelings about it?

I generally expressed my thinking in the list of possibilities I provided.

I guess that theoretically I would prefer that the simultaneous sets 
include multiple media. But from a practical perspective that might be 
cumbersome to specify. Allowing reference of CSEs and CSs is likely to 
make it less cumbersome in many cases.

But I am interested to hear if anyone sees realistic case where the 
simultaneous sets involving multiple media would be impractically large.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 6 Mar 2013 10:48:16 -0800

Roberta wrote:
> with video captures, it is not stated anywhere that they refer only to a single
> medium.

It is stated in section 6.3:
"This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time."

This is supposed to mean each Simultaneous Transmission Set includes only one media type.  If this isn't clear, we can make it more clear.

Mark

> Sent: Wednesday, March 06, 2013 11:05 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> with video captures, it is not stated anywhere that they refer only to a single
> medium.
> The current definition says only that they are lists of generic media captures.
> That's why we put in the  data model example both audio and video captures
> in the simultaneous sets.
> However, I think that having the possibility of expressing simultaneous sets
> by using capture scene identifiers can be useful especially to MCUs dealing
> with a bulk of contributions from different sites. They can easily and briefly
> advertise simultaneous aggregates of captures (arranged in capture scenes)
> according to their internal policies.
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 6 Mar 2013 10:58:16 -0800

Hi Paul,

I was assuming your item 2 is what we would do.  But it could be open for discussion.

> 2) keep the current assumption that a simultaneous set applies to only one
> medium. If a set contains references to CSs, factor those by media type, and
> create multiple sets - one for each medium.

Mark

> Paul Kyzivat
> Sent: Wednesday, March 06, 2013 10:13 AM
> To: [email-masked]
> But this does lead to another related issue that needs some consideration.
> Until now I think we have said that a single simultaneous set should mention
> only a single medium - voice or video. When we permit it to reference a
> complete scene it will have entries for different kinds of media. So what does
> that mean?
> 
> simultaneity across media types is implicit. I wonder if that is really true.
> 
> 1) keep the current assumption that a simultaneous set applies to only one
> medium, and to preserve that forbid the inclusion of a complete CS if it
> contains more than one type of medium.
> 
> 2) keep the current assumption that a simultaneous set applies to only one
> medium. If a set contains references to CSs, factor those by media type, and
> create multiple sets - one for each medium.
> 
> 4) change the definition of simultaneous sets so that they explicitly define
> permitted simultaneity among multiple media types.
> 
> > Point 1 - we generally agree simultaneity restrictions are not just about
> physical constraints, there are other reasons.
> >
> > Point 3 - we generally agree it would be good to allow expressing
> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set Entries,
> as well as Media Captures that the Provider can provide simultaneously.
> >
> > Point 4 - we generally agree (again) we do not want to define other ways of
> expressing Simultaneous Transmission Sets, such as by mutual exclusion or
> with logical operators.
> >
> > Regards,
> > Mark
> >
> >> Of Roberta Presta
> >> 1) the only motivation that has been provided to justify the
> >> definition of simultaneous sets is the fact that captures generated
> >> from the same device cannot be sent simultaneously. However, there
> >> can be other motivations behind the need of expressing simultaneity
> >> constraints (leaving resource constraints handled by encoding groups
> >> and other stuff such as max-
> >> encoding- and so on).
> >> Citing Andy Pepperel in
> >> simultaneous sets can be used by MCUs that might not want to be
> >> obliged to provide some capture simultaneously, in order to avoid
> overloading.
> >> I think that these other motivations should be explicitely mentioned
> >> in the framework document to explain that simultaneity limitations
> >> may not be due only to physical constraints.
> >>
> >> expressed as sets of the Media Captures that could physically be
> >> transmitted at the same time (though it may not make sense to do so). "
> >> Does it mean that even if there is a large set of captures able to be
> >> sent simultaneously, it may not make sense, from the consumer's
> >> perspective, to receive them all together? Maybe rewording is needed
> here.
> >>
> >> If not, he has to re-structure the configure to fit simultaneity
> >> constraints expressed by the provider.
> >> I was thinking that each set can be expressed also in terms of
> >> capture scene entries, or capture scene as a whole, for example:
> >> Where CSE* identifies a capture scene entry, and CS* identifies a
> >> capture scene.
> >> That can allow to make simultaneous sets more synthetic by exploiting
> >> the capture aggregates the framework envisions. It can be
> >> particularly useful to MCUs that want to offer just subsets of the
> >> complete list of capture scenes they receive from multiple contributors.
> >>
> >>
> >> In some cases it can be more efficient to express only mutual
> >> exclusion constraints.
> >> "simultaneity constraints" that can include a list of simultaneous
> >> sets and a list of mutual exclusion conditions to be checked on the
> consumer's side.
> >> For example, if a media provider offers many captures, and has only 4
> >> mutual exclusion conditions, instead of listing all the possible
> >> simultaneous sets, he can just provide the 4 mutual exclusion conditions
> to the consumer.
> >>
> >> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html,
> >> where simultaneity constraints are logical conditions that the
> >> consumer has to verify before issuing a configure to the provider.
> >> The example was:
> >>
> >> This means that the provider can provide CSE-X and CSE Y (and all
> >> captures associated with CSE-X and CSE-Y) simultaneously, or that the
> >> provider can provide CSE-Z (and all captures associated with CSE-Z)."
> >>
> >> Do you think we should stuck on the framework solution or also
> >> consider the aforementioned alternatives?

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Mar 2013 15:52:21 +1100

Hello,

I agree with Mark's original conclusions. I also tend to agree with item 
2 below.

Regards, Christian

---

From: "Roni Even" <[email-masked]>
Date: Thu, 7 Mar 2013 14:45:18 +0200

Hi,
I agree about the single media type.
Still we can use capture scene entry as a shorthand in the simultaneous set.

A Scene has capture scene entries where, as far as I understand, the entries
are not simultaneous, you can choose one or part of one, so you cannot have
a whole scene as a simultaneous set.

Capture scene entry has media of same type.

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Groves
Sent: 07 March, 2013 6:52 AM
To: [email-masked]
Subject: Re: [clue] comments to framework 09 - simultaneous sets

Hello,

Regards, Christian

On 7/03/2013 5:58 AM, Duckworth, Mark wrote:
>> 2) keep the current assumption that a simultaneous set applies to 
>> only one medium. If a set contains references to CSs, factor those by 
>> media type, and create multiple sets - one for each medium.
> Mark
>
>> Of Paul Kyzivat
consideration.
>> mention only a single medium - voice or video. When we permit it to 
>> reference a complete scene it will have entries for different kinds 
>> of media. So what does that mean?
>>
true.
>> 1) keep the current assumption that a simultaneous set applies to 
>> only one medium, and to preserve that forbid the inclusion of a 
>> complete CS if it contains more than one type of medium.
>>
>> 2) keep the current assumption that a simultaneous set applies to 
>> only one medium. If a set contains references to CSs, factor those by 
>> media type, and create multiple sets - one for each medium.
>>
>> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set 
>> Entries, as well as Media Captures that the Provider can provide
simultaneously.
>> expressing Simultaneous Transmission Sets, such as by mutual 
>> exclusion or with logical operators.
>>> Regards,
>>> Mark
>>>
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Roberta Presta
>>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", 
>>>> I noticed a couple of things:
>>>>
>>>> constraints (leaving resource constraints handled by encoding 
>>>> groups and other stuff such as max-
>>>> encoding- and so on).
>>>> Citing Andy Pepperel in
>>>> I think that these other motivations should be explicitely 
>>>> mentioned in the framework document to explain that simultaneity 
>>>> limitations may not be due only to physical constraints.
>>>>
>>>> Does it mean that even if there is a large set of captures able to 
>>>> be sent simultaneously, it may not make sense, from the consumer's 
>>>> That can allow to make simultaneous sets more synthetic by 
>>>> exploiting the capture aggregates the framework envisions. It can 
>>>> be particularly useful to MCUs that want to offer just subsets of 
>>>> the complete list of capture scenes they receive from multiple
contributors.
>>>> For example, if a media provider offers many captures, and has only 
>>>> 4 mutual exclusion conditions, instead of listing all the possible 
>>>> captures associated with CSE-X and CSE-Y) simultaneously, or that 
>>>> the provider can provide CSE-Z (and all captures associated with
CSE-Z)."

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 12:49:32 +0000

Hi,

Do we assume there is a one-to-one mapping between video and audio captures?

For example, assume one video capture has the role "manager".

That doesn't mean that there will be an audio capture with the same role, because the audio capture may cover a bigger area, including many persons.

So, if I show the manager on my screen, how do I know which audio capture to choose?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 7. maaliskuuta 2013 14:45
To: 'Christian Groves'; [email-masked]
Subject: Re: [clue] comments to framework 09 - simultaneous sets

Hi,

A Scene has capture scene entries where, as far as I understand, the entries are not simultaneous, you can choose one or part of one, so you cannot have a whole scene as a simultaneous set.

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 07 March, 2013 6:52 AM
To: [email-masked]
Subject: Re: [clue] comments to framework 09 - simultaneous sets

Hello,

Regards, Christian

On 7/03/2013 5:58 AM, Duckworth, Mark wrote:
> Hi Paul,
>
> I was assuming your item 2 is what we would do.  But it could be open 
> for
discussion.
consideration.
true.
simultaneously.
contributors.
CSE-Z)."

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Mar 2013 23:44:48 +0800

> a whole scene as a simultaneous set.

IMO putting a whole scene in a simultaneous set is just a shorthand for 
putting all the captures in that scene into the simultaneous set. I 
think that should be ok when it is true. In some cases it may be true, 
and in other cases not.

The complication with putting in the whole scene is that it will contain 
both audio and video entries. So what does that mean? If we want, we 
could say that a simultaneous set with both audio and video entries is 
just shorthand for two sets - one with the audio entries and one with 
the video entries.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Mar 2013 23:47:26 +0800

> So, if I show the manager on my screen, how do I know which audio capture to choose?

I too have wondered about this, and have no great answer.

The simple answer is use spatial coordinates. But I'm not at all 
convinced that is a complete answer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 16:51:04 +0000

Hi,

> convinced that is a complete answer.

Also, you can have multiple video CSEs, and multiple audio CSEs, and the choise of audio CSE may depend on the choise of video CSE. So, is there a reason why we can't put different media types in the same CSE, if they are associated? I think it would help alot.

But, that still doesn't solve the problem about, though, if you e.g. from a CSE only choose a specific set of video captures, and also want the corresponding audio captures. Maybe spatial coordinates helps there.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 01:14:08 +0800

> But, that still doesn't solve the problem about, though, if you e.g. from a CSE only choose a specific set of video captures, and also want the corresponding audio captures. Maybe spatial coordinat…

I agree that this seems to be an issue that deserves more study.
Is somebody willing to think hard about it and come back with an analysis?

It certainly would be possible to redefine CSEs so that they contain 
captures of different media types. The good of it is that it mostly 
solves the problem you present.

The bad of it is that it will increase the number of CSEs. (If under the 
current scheme there are N audio CSEs and M video CSEs (total N+M) then 
under this new approach there would be N*M CSEs, and each would be 
bigger.) But for common cases this may still be manageable.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 17:30:10 +0000

Hi,

> It certainly would be possible to redefine CSEs so that they contain captures of different media types. The good of it is that it mostly solves the problem you present.

It helps picking CSEs, but it still does not map individual captures :)

>The bad of it is that it will increase the number of CSEs. (If under the current scheme there are N audio CSEs and M video CSEs (total N+M) then under this new approach there would be N*M CSEs, and each would be

Another way would be to keep them separate, but assign an identifier for each CSE, and then e.g. in each video CSE list the identifiers of all audio CSEs that can be used with that particular video CSE.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Mar 2013 14:14:41 +1100

Hello Christer,

 From an application level I think the capture attributes should provide 
a means to select the audio captures. There may or may not be a one to 
one mapping. For example a video may have multiple audio feeds (i.e. 
different languages). The consumer can chose one or more of these audio 
feeds.

In the role case there's no reason why both the audio and video captures 
can't be labelled with the role.

Linking the video and audio captures with an ID could provide more 
explicit information. The ids would have to be consistent with the 
capture attributes. I guess we could say if these additional Audio CSEs 
aren't included in the Video CSE then it means to use the default 
behaviour we already defined?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Mar 2013 11:43:49 +0000

Hi,

>From an application level I think the capture attributes should provide a means to select the audio captures. There may or may not be a one to one mapping. For example a video may have multiple audio feeds (i.e. 
>different languages). The consumer can chose one or more of these audio feeds.
>
>In the role case there's no reason why both the audio and video captures can't be labelled with the role.
>
>Linking the video and audio captures with an ID could provide more explicit information. The ids would have to be 
>consistent with the capture attributes. I guess we could say if these additional Audio CSEs aren't included in the 
>Video CSE then it means to use the default behaviour we already defined?

Assume there are two video captures: "Christian" and "Paul".

Then, there is a single audio capture, which provides audio for both "Christian" and "Paul". 

Now, the role of that audio capture can not be "Christian" alone, and it can not be "Paul" alone.

Of course, it CAN be "Christian" AND "Paul", if we allow a capture to have multiple roles. Maybe that is already allowed, so my apologies if I've missed it :)

Regards,

Christer

On 8/03/2013 4:30 AM, Christer Holmberg wrote:
>> The bad of it is that it will increase the number of CSEs. (If under 
>> the current scheme there are N audio CSEs and M video CSEs (total 
>> N+M) then under this new approach there would be N*M CSEs, and each 
>> would be

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 23:10:52 +0800

ISTM that there is an issue around correlating audio and video captures.
Do others think so?

	Thanks,
	Paul

On 3/8/13 11:14 AM, Christian Groves wrote:
>>>>>> That doesn't mean that there will be an audio capture with the
>>>>>> same role, because the audio capture may cover a bigger area,
>>>>>> including many persons.
>>>>>>
>>>> Also, you can have multiple video CSEs, and multiple audio CSEs, and
>>>> the choise of audio CSE may depend on the choise of video CSE. So,
>>>> is there a reason why we can't put different media types in the same
>>>> CSE, if they are associated? I think it would help alot.
>>>>
>>>> But, that still doesn't solve the problem about, though, if you e.g.
>>>> from a CSE only choose a specific set of video captures, and also
>>>> want the corresponding audio captures. Maybe spatial coordinates
>>>> helps there.
>> Another way would be to keep them separate, but assign an identifier
>> for each CSE, and then e.g. in each video CSE list the identifiers of
>> all audio CSEs that can be used with that particular video CSE.
>>
>> Regards,
>>
>> Christer
>>
>>

---

From: Christian Groves <[email-masked]>
Date: Tue, 12 Mar 2013 09:01:17 +1100

Hello Christer,

If there's only one audio capture then there's no real need to assign 
roles as it's that only choice. However I do take the point that capture 
could have multiple roles.

Regards, Christian