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

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 29 Feb 2012 14:43:09 -0800

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 1 Mar 2012 01:08:03 +0200

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.

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

The provider specifies this with the following video capture attribute
values:

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: "Duckworth, Mark" <[email-masked]>
Date: Wed, 29 Feb 2012 15:48:02 -0800

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

      {VC0, VC2, VC5, VC6}

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

Mark

---

From: "Roni Even" <[email-masked]>
Date: Thu, 1 Mar 2012 02:11:48 +0200

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.

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

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}

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,

      {VC0, VC2, VC5, VC6}

Roni

 

Mark

---

From: "Roni Even" <[email-masked]>
Date: Thu, 1 Mar 2012 02:41:29 +0200

Mark,

Just to be precise you are the editors not the authors, this is a WG draft.

Roni

Mark

---

From: Christian Groves <[email-masked]>
Date: Thu, 01 Mar 2012 14:04:11 +1100

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