Subject: [clue] Ticket #7 composed attribute

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 5 Mar 2012 10:25:40 -0800

>From the interim meeting minutes:
"3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issue - Boolean is as far as CLUE should go."

My recollection is that the people in the meeting generally agreed on this.  So it seems to me this is the resolution of ticket #7.  Is that correct?

Mark

---

From: Roni even <[email-masked]>
Date: Mon, 05 Mar 2012 18:31:59 +0000

Hi Mark,

This is not my recollection. It is OK to have a Boolean as long as we have an attribute that provide information about the composition in the framework document or we need to change the composed attribute.

Roni

________________________________
From: [email-masked] [[email-masked]] on behalf of Duckworth, Mark [[email-masked]]
Sent: Monday, March 05, 2012 20:25
To: [email-masked]
Subject: [clue] Ticket #7 composed attribute

>From the interim meeting minutes:
“3.2.6 Is “Composed” a Boolean, or a data structure? Based on previous issue – Boolean is as far as CLUE should go.”

Mark

---

From: "Roni Even" <[email-masked]>
Date: Mon, 5 Mar 2012 20:47:10 +0200

Hi,

I did not support this and this was added to the action item when I was not
present.

The discussion in the meeting was about allowing the provider to offer more
than one composed option that will allow the consumer to select from. There
was no agreement during the session as far as I can see from the notes and
the summary does not reflect the discussion.

BTW: These are rough notes and there is no meeting summary yet from the WG
chairs

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: Monday, March 05, 2012 8:26 PM
To: [email-masked]
Subject: [clue] Ticket #7 composed attribute

>From the interim meeting minutes:

"3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issue
- Boolean is as far as CLUE should go."

My recollection is that the people in the meeting generally agreed on this.
So it seems to me this is the resolution of ticket #7.  Is that correct?

Mark

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 5 Mar 2012 23:20:12 +0100

During the discussions we did not find any clear use case that must be
handled in CLUE that involves more than announcing a single composited
alternative. Even if there are use cases where that could be possible we
discussed them as outside out the scope of version 1 of CLUE. 

One example we decided to keep out was the video layout as specified in
the XCON data model [1]. As presented multiple video-layout alternative
can be listed as a single multi value attribute with all options listed
and still keep the number of captures the same. 

The example use case we used where a triple camera system that can do, I
only list the single capture alternatives. 

a)      A manually selected alternative, left, center or right 

b)      A switched alternative; based on voice activity 

c)       A composited alternative; by media source choosing. 

In this case its sufficient to use a flag to separate alternative b and
c, and we concluded that a basic flag was sufficient. Vendors are free
to extend on the basic model with more details if they think that is
needed. 

-Espen 

[1] http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: 5. mars 2012 19:47
To: 'Duckworth, Mark'; [email-masked]
Subject: Re: [clue] Ticket #7 composed attribute

Hi,

I did not support this and this was added to the action item when I was
not present.

The discussion in the meeting was about allowing the provider to offer
more than one composed option that will allow the consumer to select
from. There was no agreement during the session as far as I can see from
the notes and the summary does not reflect the discussion.

BTW: These are rough notes and there is no meeting summary yet from the
WG chairs

Roni Even

>From the interim meeting minutes:

"3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous
issue - Boolean is as far as CLUE should go."

My recollection is that the people in the meeting generally agreed on
this.  So it seems to me this is the resolution of ticket #7.  Is that
correct?

Mark

---

From: "Roni Even" <[email-masked]>
Date: Tue, 6 Mar 2012 09:40:28 +0200

Hi Espen,

I am not arguing that we can decide that CLUE will not specify the
composition or switched policy. If this is what we will have than the text
should be clear about it. 

This will mean that CLUE does not provide a way for the provider to specify
what is composed and mixed and thus the consumer cannot use CLUE to select a
specific mix or switch. Currently this can be available using other menas
like XCON protocol.

In your email

"The example use case we used where a triple camera system that can do, I
only list the single capture alternatives. 

c)       A composited alternative; by media source choosing. "

Is not correct if switched and composed are Booleans. It should be

"

b)      A switched alternative; that may based on voice activity  or any
other switching policy base on the media source decision

 

I am OK with the specification in section 6.1.1 of the framework but prefer
adding text to the composed and switched attribute that mechanism based on
draft-ietf-xcon-event-package can be used to learn the content of the
stream.

Also in section 11.1 based in the definition of composed and switched the
following is not correct:

" o  VC3- (the loudest panel stream), encoding group=EG1,

      purpose=main;auto-switched:yes

   o  VC4- (the loudest panel stream with PiPs), encoding group=EG1,

      purpose=main; composed=true; auto-switched:yes

"

In order not to set some assumptions for the readers who did not follow the
discussion it should be

"o  VC3- (may be the loudest panel stream based on producer policy),
encoding group=EG1,

      purpose=main;auto-switched:yes

   o  VC4- (may be the loudest panel stream with PiPs based on producer
policy), encoding group=EG1,

      purpose=main; composed=true; auto-switched:yes

"

Note that in section 11.1 you use auto-switch as the attribute name instead
of switched as specified in section 6.1.1, I assume it is a typo.

Roni Even

 

From: Espen Berger (espeberg) [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2012 12:20 AM
To: Roni Even; Duckworth, Mark; [email-masked]
Subject: RE: [clue] Ticket #7 composed attribute

One example we decided to keep out was the video layout as specified in the
XCON data model [1]. As presented multiple video-layout alternative can be
listed as a single multi value attribute with all options listed and still
keep the number of captures the same. 

d)      A manually selected alternative, left, center or right 

e)      A switched alternative; based on voice activity 

f)       A composited alternative; by media source choosing. 

In this case its sufficient to use a flag to separate alternative b and c,
and we concluded that a basic flag was sufficient. Vendors are free to
extend on the basic model with more details if they think that is needed. 

-Espen 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: 5. mars 2012 19:47
To: 'Duckworth, Mark'; [email-masked]
Subject: Re: [clue] Ticket #7 composed attribute

Hi,

Roni Even

Mark

  _____

---

From: John Leslie <[email-masked]>
Date: Tue, 6 Mar 2012 11:14:39 -0500

Roni even <[email-masked]> wrote:
> [[email-masked] wrote:]
>> 
> This is not my recollection. It is OK to have a Boolean as long as we
> have an attribute that provide information about the composition in the
> framework document or we need to change the composed attribute.

   I see little value in anything between a simple boolean and a list of
elements composing the stream; but I would like to have an option to specify
that list defined.

--
John Leslie <[email-masked]>