Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 1 Mar 2012 07:08:12 -0800

We were trying to address the concern raised on Wednesday morning at the interim meeting about the representation of simultaneous sets becoming unwieldy in some cases.  From the meeting minutes Paul published:
"We're concerned about Simultaneous Sets becoming combinatorial (for large numbers of participants with multiple complex capture sets). We don't have a use case for these types of environments yet. Do we need them?"

So if the group thinks we don't really need to worry about this, and the current simultaneous set concept in draft-ietf-clue-framework-03 is fine the way it is, that is okay with me.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Wednesday, February 29, 2012 10:04 PM
> To: [email-masked]
> Subject: Re: [clue] propose "mutually exclusive" attribute to replace
> simutaneous sets
> 
> Hello Mark,
> 
>  From a readability point of view I do find simultaneous sets easier to
> understand. I think that from an interop point of view it may be better the
> capturer to say "here's the combinations I support" rather than "I support
> everything except these combinations". The capturer and provider may not
> have the same view of "everything".
> 
>  From the mutually exclusive examples there does seem to be some
> duplication. The mutually exclusive pairs seem to be listed twice i.e.
> VC1,{VC3} and VC3,{VC1}. Could it not be deduced from a single pair that
> they can't be used at the same time?
> 
> Regards, Christian
> 
> On 1/03/2012 9:43 AM, Duckworth, Mark wrote:
> >
> > This is a proposal from all the framework authors. Please review.
> >
> > We propose removing the concept of "simultaneous sets" and replacing
> > it with a new media capture attribute called "mutually exclusive". The
> > purpose is to have a more concise way to indicate which media captures
> > cannot be used at the same time, which we believe scales better than
> > the simultaneous set idea when there are multiple mutually exclusive
> > constraints. This is in response to concerns discussed at the interim
> > meeting about scalability of simultaneous sets, and confusion between
> > simultaneous sets and capture set entries.
> >
> > New Media Capture attribute:
> >
> > Mutually-exclusive: {list of MCs that cannot be used at same time as
> > this MC}
> >
> > Consider the example of a room system where there are 3 cameras each
> >
> > of which can send a separate capture covering 2 persons each- VC0,
> >
> > VC1, VC2. The middle camera can also zoom out and show all 6
> >
> > persons, VC3. But the middle camera cannot be used in both modes at
> >
> > the same time - it has to either show the space where 2 participants
> >
> > sit or the whole 6 seats, but not both at the same time.
> >
> > The provider specifies this with the following video capture attribute
> > values:
> >
> > VC1 - mutually-exclusive={VC3}
> >
> > VC3 - mutually-exclusive={VC1}
> >
> > A provider must advertise mutually exclusive attributes that allow all
> > the media captures in a capture set entry to be used at the same time.
> >
> > Section 6.3 "Simultaneous Transmission Set Constraints" can be removed.
> >
> > We will update the example in section 11.1 to show the new attribute
> > rather than the simultaneous sets.
> >
> > Mark
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 12:25:26 -0500

This discussion is an example of why its helpful to separate a 
conceptual discussion of the required information from the discussion of 
how that information will be encoded for exchange.

If the conceptual data seems bloated and redundant then we can explore 
optimization techniques for transmitting it.

	Thanks,
	Paul

On 2/29/12 10:04 PM, Christian Groves wrote:
> understand. I think that from an interop point of view it may be better
> the capturer to say "here's the combinations I support" rather than "I
> support everything except these combinations". The capturer and provider
> may not have the same view of "everything".
>
>> We propose removing the concept of “simultaneous sets” and replacing
>> it with a new media capture attribute called “mutually exclusive”. The
>> VC1 – mutually-exclusive={VC3}
>>
>> VC3 – mutually-exclusive={VC1}
>>
>> Section 6.3 “Simultaneous Transmission Set Constraints” can be removed.
>>

---

From: "Johan Ludvig Nielsen (johaniel)" <[email-masked]>
Date: Fri, 2 Mar 2012 16:42:52 +0100

Hi

I think it would be useful to include audio and connection between audio
and video in this discussion. 

Can the simultaneous  or mutually-exclusive sets be used to specify
which audio captures can be used with which video captures, and which
cannot?

This could solve the case in 11.1 where the connection through the
capture area is insufficient for some captures, as I have pointed out in
an earlier post on the spatial relationships.

Regards

Johan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: 1. mars 2012 00:48
To: Roni Even; [email-masked]
Subject: Re: [clue] propose "mutually exclusive" attribute toreplace
simutaneous sets

Hi,

For this example it would be a little simpler like this:

VC1 - mutually-exclusive={VC5}

VC3 - mutually-exclusive={VC5}

VC4 - mutually-exclusive={VC5}

VC5- mutually-exclusive={VC1,VC3,VC4}

The point for scalability was to simplify a case like this:

VC1 - mutually-exclusive={VC2}

VC2 - mutually-exclusive={VC1}

VC3 - mutually-exclusive={VC4}

VC4 - mutually-exclusive={VC3}

VC5 - mutually-exclusive={VC6}

VC6 - mutually-exclusive={VC5}

In simultaneous sets it would have been:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

Adding another mutually exclusive pair would expand the simultaneous
sets to 16 sets of 4 VCs each.

I agree the framework should clarify that capture set entries are the
provider's suggestion to the consumer about which media captures would
be most useful to receive together.

I agree the framework should clarify that the consumer can choose just
part of a capture set entry.

The consumer can also pick and choose media captures from different
capture set entries, and for this case the mutually exclusive
information becomes important.

Mark

From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, February 29, 2012 6:08 PM
To: Duckworth, Mark; [email-masked]
Subject: RE: [clue] propose "mutually exclusive" attribute to replace
simutaneous sets

Hi,

I do not think that changes anything since this is the complement of the
simultaneous set and will be less condensed.

For example taking the example from the framework in section 11.1

   The physical simultaneity information is:

      {VC0, VC1, VC2, VC3, VC4, VC6}

      {VC0, VC2, VC5, VC6}

Your proposal will require

VC1 - mutually-exclusive={VC5}

VC5- mutually-exclusive={VC1}

VC3 - mutually-exclusive={VC5}

VC5- mutually-exclusive={VC3}

VC4 - mutually-exclusive={VC5}

VC5- mutually-exclusive={VC4}

And the result is the same since it can be translated to the current
description.

My proposal was to clarify in the framework that  the capture set
entries are the preferred mode as proposed by the provider. Also to say
that a consumer can select part of a capture set entry or simultaneous
set.

Roni

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: Thursday, March 01, 2012 12:43 AM
To: [email-masked]
Subject: [clue] propose "mutually exclusive" attribute to replace
simutaneous sets

We propose removing the concept of "simultaneous sets" and replacing it
with a new media capture attribute called "mutually exclusive".  The
purpose is to have a more concise way to indicate which media captures
cannot be used at the same time, which we believe scales better than the
simultaneous set idea when there are multiple mutually exclusive
constraints.  This is in response to concerns discussed at the interim
meeting about scalability of simultaneous sets, and confusion between
simultaneous sets and capture set entries.

Mark

---

From: "Roni Even" <[email-masked]>
Date: Fri, 2 Mar 2012 21:51:55 +0200

Hi,

The simultaneous discussion is about describing physical constrains while
audio and video connection is application connection.

I am not sure if the audio video should be part of the physical constrains.
Also note that the SDP grouping already provides for it, but if you want it
in CLUE it should be s different attribute.

Roni Even

From: Johan Ludvig Nielsen (johaniel) [mailto:[email-masked]] 
Sent: Friday, March 02, 2012 5:43 PM
To: Duckworth, Mark; Roni Even; [email-masked]
Subject: RE: [clue] propose "mutually exclusive" attribute toreplace
simutaneous sets

Hi

I think it would be useful to include audio and connection between audio and
video in this discussion. 

Can the simultaneous  or mutually-exclusive sets be used to specify which
audio captures can be used with which video captures, and which cannot?

This could solve the case in 11.1 where the connection through the capture
area is insufficient for some captures, as I have pointed out in an earlier
post on the spatial relationships.

Regards

Johan

Hi,

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

Adding another mutually exclusive pair would expand the simultaneous sets to
16 sets of 4 VCs each.

I agree the framework should clarify that capture set entries are the
provider's suggestion to the consumer about which media captures would be
most useful to receive together.

I agree the framework should clarify that the consumer can choose just part
of a capture set entry.

The consumer can also pick and choose media captures from different capture
set entries, and for this case the mutually exclusive information becomes
important.

Mark

Hi,

      {VC0, VC2, VC5, VC6}

My proposal was to clarify in the framework that  the capture set entries
are the preferred mode as proposed by the provider. Also to say that a
consumer can select part of a capture set entry or simultaneous set.

Roni

 

We propose removing the concept of "simultaneous sets" and replacing it with
a new media capture attribute called "mutually exclusive".  The purpose is
to have a more concise way to indicate which media captures cannot be used
at the same time, which we believe scales better than the simultaneous set
idea when there are multiple mutually exclusive constraints.  This is in
response to concerns discussed at the interim meeting about scalability of
simultaneous sets, and confusion between simultaneous sets and capture set
entries.

Mutually-exclusive: {list of MCs that cannot be used at same time as this
MC}

A provider must advertise mutually exclusive attributes that allow all the
media captures in a capture set entry to be used at the same time.

We will update the example in section 11.1 to show the new attribute rather
than the simultaneous sets.

Mark

---

From: "Johan Ludvig Nielsen (johaniel)" <[email-masked]>
Date: Tue, 6 Mar 2012 14:43:33 +0100

OK, good point.

Johan

From: Roni Even [mailto:[email-masked]] 
Sent: 2. mars 2012 20:52
To: Johan Ludvig Nielsen (johaniel); 'Duckworth, Mark'; [email-masked]
Subject: RE: [clue] propose "mutually exclusive" attribute toreplace
simutaneous sets

Hi,

The simultaneous discussion is about describing physical constrains
while audio and video connection is application connection.

I am not sure if the audio video should be part of the physical
constrains. Also note that the SDP grouping already provides for it, but
if you want it in CLUE it should be s different attribute.

Roni Even

Hi

Regards

Johan

Hi,

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

Mark

Hi,

      {VC0, VC2, VC5, VC6}

Roni

 

Mark

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 6 Mar 2012 08:10:17 -0800

Hi Roni,

I think that your note really hits the nail on the head.

As Mark said, the purpose of moving simultaneous set info into the media
capture attributes was two fold - first to be more parsimonious, and
secondly to avoid confusion.

By having both capture sets and simultaneous transmission sets, we have
created confusion as to how the consumer chooses sets. 

We had meant it to be that the consumer chooses based on capture set,
and applies the rules from the simultaneous set to that choice. But this
was not a good idea. People could look at the 2 sets of captures and
say, I'm going to ignore capture set and just use the simultaneous set.
So it really wasn't a good idea to have two sets of captures. 

The information that needs to be conveyed falls easily within the notion
of an attribute of a media capture. That way there is no confusion with
two sets of captures, but the necessary mutual exclusivity is
communicated.

I'll respond to your comments below-

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Wednesday, February 29, 2012 4:12 PM
To: 'Duckworth, Mark'; [email-masked]
Subject: Re: [clue] propose "mutually exclusive" attribute toreplace
simutaneous sets

Mark,

The simultaneous case in the example that I listed are in the document
and are built on a use case, this example has two lines for simultaneous
sets and 4 using the mutually exclusive description . 

I am not sure what use case you are describing.

Anyhow, like I said before these two option are complements to one
another and my view is that simultaneous sets make more sense in term of
readability and I see no reason to change the current description.

AR- As I described above the reason to change is to avoid confusion
about consumer choice. An additional reason is parsimoniousness (is that
a word?), which Mark has argued in previous emails.

You did not address the point I made about clarifying that a consumer
can select part of the capture set entry or request one that is not
defined as long as it does not contradict the simultaneously regardless
of which presentation we select.  If this is correct is simpler to
construct the allowed sets from the current presentations since you just
select a simultaneous set or part of it.

AR- A consumer can select part of the capture set entry - unfortunately.
Unfortunately because each entry is a representation of the scene, so it
would be better to choose a full representation. But, we didn't think it
right to restrict the ability of the consumer to choose from an entry.

As for requesting something that is not defined.. no- not correct-
that's not included. The consumer can't request an entry not defined.  I
probably don't know what you mean, as how could it  request an undefined
capture?  In terms of an undefined entry.. what does tat mean?..  the
consumer can pick and choose any of the captures in the capture set as
long as it stays within the exclusivity rules (however they are
expressed). The entries are the information from the provider that this
group of captures represents the scene.

Regards,

Allyn

Roni 

From: Duckworth, Mark [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 1:48 AM
To: Roni Even; [email-masked]
Subject: RE: [clue] propose "mutually exclusive" attribute to replace
simutaneous sets

Hi,

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

Mark

Hi,

      {VC0, VC2, VC5, VC6}

Roni

 

Mark