Subject: [clue] Framework updates

From: Christian Groves <[email-masked]>
Date: Mon, 11 Feb 2013 16:15:28 +1100

Given that the deadline for submissions for the Orlando coming I thought 
I spend some time going back through some threads on the framework.

During the discussions of the concepts of scene, capture scene, capture 
scene entry etc. I think we came up with several places where the 
framework should be updated. These weren't picked up in the v8 update of 
the framework. I've outlined them below:

1. MCU terminating CLUE
-----------------------
(thread: MCU terminating CLUE, or passing through?  was:  Capture scene 
clarifications)
There was some discussion whether it was assumed that MCUs passed 
messages through or MCUs terminated the CLUE signalling. It appeared 
that the people thought (Stephen W words):
  "that it is the responsibility of an MCU to consolidate room 
information it has received from receiving rooms and provide, based on 
its unified view, sensible choices for things like the selection of 
Capture scenes."

I believe something like the above text should be added to the framework.

2. Capture Scene Clarifications
-------------------------------
I made some proposals to clarify the capture scene concept that appeared 
to be accepted by the Mark. See "Re: [clue] Capture scene clarifications 
2/12/2012".

 > 1) Introduce a new definition for "Scene". The capture scene 
definition and
 > several places mention "scene" but there's no explanation. I propose the
 > following definition to be added to section 3 of the draft:
 > Scene: Represents an area where the capture devices are spatially 
related.
 > Non-spatially related devices exist in different scenes.

 > 2) Update the definition of "Capture scene entry" to make it clearer 
that it
 > represents an entire scene. Proposed text is:
 > *Capture Scene Entry: a list of media captures of the same media type
 >     that together form one representation of an entire capture scene.

 > 3) Update section 6.2 on Capture scenes to reflect the above intents.
 > Changes proposals are:
 > - Section 6.2 2nd paragraph:
 > "A capture scene is a structure representing the <<entire>> scene that is
 >     captured by a collection of<<spatially related>>capture devices.  
A capture
 > scene..."

 > - Section 6.2 3rd paragraph:
 >   "A provider may advertise multiple capture scenes or just a single
 >     capture scene.<<What constitutes an entire scene is up to the 
provider.>>
 > A media provider might typically use one capture
 >     scene for main participant media and another capture scene for a
 >     computer generated presentation...."

 > 4) The framework uses the terms "media provider" and "provider". We
 > probably should be consistent in the use of the term throughout the
 > framework.

3. Prioritisation
-----------------
There was some discussion regarding whether any prioritization could be 
assumed from the order of captures (or any other element) in the 
structures in the framework. I think it was agreed that the framework 
didn't consider this. I think it should be clarified in the framework 
that no prioritisation is assumed.

4. Captures in more than one capture scene entry
------------------------------------------------
The framework doesn't explicitly state that the same capture can be in 
more than one capture scene entry. The examples seem to suggest only one 
capture scene entry at a time. I assume though that a capture may reside 
in multiple capture scene entries. Explicit text should be added for 
clarity.

5. Are simultaneous set mandatory?
----------------------------------
Simultaneous sets are defined in the framework but there is no explicit 
text indicating whether they are mandatory or optional for the 
Advertiser to send. Consumer side procedures would need to align with 
being mandatory or optional.
I proposed some "hybrid" behaviour which seemed to have some support, i.e.

"For a particular media type the consumer should choose one capture scene
entry. If the advertiser has provided a simultaneous transmission set, the
consumer may choose individual captures taking in account any simultaneity
requirements".

This support may need to be confirmed.

6. Sending a configure
----------------------
(See thread [clue] Sending a configure 13/12/2012)
There is some confusion regarding autonomous sending of configure 
messages. In response to the comments I propose to add the following:
"Once the consumer has received an advertisement it may change its 
configuration of the provider's encodings any number of times during the 
call in response to signalling or other event by sending a new configure 
message."

7. Capture Attributes
---------------------
I'll address the addition of capture attributes in another email.

Framework editors, how to proceed to address the above items?

Regards, Christian

---

From: Mary Barnes <[email-masked]>
Date: Mon, 11 Feb 2013 10:55:00 -0600

On Sun, Feb 10, 2013 at 11:15 PM, Christian Groves
<[email-masked]> wrote:
> Given that the deadline for submissions for the Orlando coming I thought I
> spend some time going back through some threads on the framework.
>
> scene entry etc. I think we came up with several places where the framework
> should be updated. These weren't picked up in the v8 update of the
> framework. I've outlined them below:
>
> 1. MCU terminating CLUE
> -----------------------
> There was some discussion whether it was assumed that MCUs passed messages
> through or MCUs terminated the CLUE signalling. It appeared that the people
> thought (Stephen W words):
>  "that it is the responsibility of an MCU to consolidate room information it
> has received from receiving rooms and provide, based on its unified view,
> sensible choices for things like the selection of Capture scenes."
>
> I made some proposals to clarify the capture scene concept that appeared to
> be accepted by the Mark. See "Re: [clue] Capture scene clarifications
> 2/12/2012".
>
>> 1) Introduce a new definition for "Scene". The capture scene definition
>> and
>> Scene: Represents an area where the capture devices are spatially related.
>> 2) Update the definition of "Capture scene entry" to make it clearer that
>> it
>>     captured by a collection of<<spatially related>>capture devices.  A
>> capture
>> scene..."
>
> assumed from the order of captures (or any other element) in the structures
> in the framework. I think it was agreed that the framework didn't consider
> this. I think it should be clarified in the framework that no prioritisation
> is assumed.
>
> The framework doesn't explicitly state that the same capture can be in more
> than one capture scene entry. The examples seem to suggest only one capture
> scene entry at a time. I assume though that a capture may reside in multiple
> capture scene entries. Explicit text should be added for clarity.
>
> Simultaneous sets are defined in the framework but there is no explicit text
> indicating whether they are mandatory or optional for the Advertiser to
> send. Consumer side procedures would need to align with being mandatory or
> optional.
> There is some confusion regarding autonomous sending of configure messages.
> In response to the comments I propose to add the following:
[MB] We actually need the WG to agree with the proposed changes before
the FW editors should make changes (that's the IETF model for WG
documents).

Therefore, we really need CLUE WG participants to review this and
respond so the FW editors can make any necessary changes before the
draft deadline. [/MB]
>
> Regards, Christian
>
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Feb 2013 16:20:23 -0500

(Replying as an individual)

>> framework. I've outlined them below:

+1

>> 2. Capture Scene Clarifications

+1

>>>      that together form one representation of an entire capture scene.

+1

>>>      computer generated presentation...."

+1

>>> probably should be consistent in the use of the term throughout the

+1

>> 3. Prioritisation

+1

(And then we put in a priority attribute to provide a mechanism for 
*explicit* prioritization.)

>> 4. Captures in more than one capture scene entry

+1

It is my understanding that a cature *may* be present in more than one 
CSE. (But a capture may only be present in *one* *scene*.)

>> 5. Are simultaneous set mandatory?

I didn't get the feeling that we reached consensus on this.
Personally I liked the idea that the CSEs provide some
implicit simultaneous set information. So it would be convenient for it 
not to be necessary to state the same information explicitly.
But that isn't enough for more complex cases.

>> 6. Sending a configure

I agree with the intent. And the wording isn't bad. I'm not entirely 
comfortable with that use of "encodings", but don't have a better 
suggestion at the moment.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 12 Feb 2013 06:57:39 -0800

Hi Christian,

Thank you very much for the reminders and specific suggestions.
I thought some of these items had already reached consensus on some of these items, which are already included in our working draft for the next version of the framework.

I'll comment on each particular item below.

Mark

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Sunday, February 10, 2013 9:15 PM
> To: [email-masked]
> Cc: Duckworth, Mark
> Subject: Framework updates
> 
> messages through or MCUs terminated the CLUE signalling. It appeared that
> the people thought (Stephen W words):

[Duckworth, Mark]  I agree that was always the intent, that the MCU terminated the CLUE signaling.  We can add clarification as you suggested.

> and  > several places mention "scene" but there's no explanation. I propose
> the  > following definition to be added to section 3 of the draft:
>  > 2) Update the definition of "Capture scene entry" to make it clearer that it
>  > 4) The framework uses the terms "media provider" and "provider". We  >
> probably should be consistent in the use of the term throughout the  >
> framework.

[Duckworth, Mark] based on email list discussion, I did not create a new definition for "scene", but I have these updated definitions:

Capture Scene: a structure representing a spatial region containing one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a scene may or may not correspond to a real region in physical space, such as a room.  A capture scene includes attributes and 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 entire capture scene.

Do you think there is still a need to add a definition for "scene"?

I did update section 6.2 to be more consistent with these new definitions.

> this. I think it should be clarified in the framework that no prioritisation is
> assumed.

[Duckworth, Mark] agreed, and this is in the next version.

> than one capture scene entry. The examples seem to suggest only one
> capture scene entry at a time. I assume though that a capture may reside in
> multiple capture scene entries. Explicit text should be added for clarity.

[Duckworth, Mark] agreed, and this is in the next version.

> send. Consumer side procedures would need to align with being mandatory
> or optional.

[Duckworth, Mark] based on our previous email list discussions, here is what I have in the next version:

A media provider optionally includes the simultaneous sets in its provider advertisement.  These simultaneous set constraints apply across all the capture scenes in the advertisement.  The simultaneous transmission sets MUST allow all the media captures in any particular capture scene entry to be used simultaneously.

If an advertisement does not include Simultaneous Transmission Sets, then all capture scenes can be provided simultaneously.  If multiple capture scene entries are in a capture scene then the media consumer may choose at most one capture scene entry per scene for each media type.

If an advertisement includes multiple capture scene entries in a capture scene then the consumer SHOULD choose one capture scene entry for each media type, but may choose captures based on the Simultaneous Transmission Sets

> 6. Sending a configure
> ----------------------
> (See thread [clue] Sending a configure 13/12/2012) There is some confusion
> regarding autonomous sending of configure messages. In response to the
> comments I propose to add the following:
> configuration of the provider's encodings any number of times during the call
> in response to signalling or other event by sending a new configure
> message."

[Duckworth, Mark] The framework already says "The consumer is able to change its configuration of the provider's encodings any number of times during the call, either in response to a new capture advertisement from the provider or autonomously."   We could add "by sending a new configure message" to make it more clear.

---

From: John Leslie <[email-masked]>
Date: Tue, 12 Feb 2013 18:02:44 -0500

Duckworth, Mark <[email-masked]> wrote:
> To: Christian Groves <[email-masked]>
> 
>>> and several places mention "scene" but there's no explanation. I propose
>>> the following definition to be added to section 3 of the draft:
>>  
>>...
> based on email list discussion, I did not create a new definition for
> "scene", but I have these updated definitions:
> 
> Capture Scene: a structure representing a spatial region containing one
> or more Capture Devices, each capturing media representing a portion of
> the region. The spatial region represented by a scene may or may not
> correspond to a real region in physical space, such as a room. A capture
> scene includes attributes and 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 entire capture scene.
> 

   Generally, replacing "scene" with "region" where it appears alone is
sufficient: but there are quite a few cases. For example:

4. Overview of the Framework/Model 
A provider organizes its media captures that represent the same _scene_ into capture scenes.

6.2. Capture Scene 
A capture scene is a structure representing the _scene_ that is captured by a collection of capture devices.
...
When a provider advertises a capture scene with multiple entries, it is essentially signaling that there are multiple representations of the same _scene_ available.
...
The inclusion of the audio capture in the same capture scene indicates that AC0 is associated with those video captures, meaning it comes from the same _scene_.

6.2.1. Capture scene attributes 
Area of _Scene_ attribute: The area of _scene_ attribute for a capture scene has the same format as the area of capture attribute for a media capture. If the provider does not specify the area of _scene_, but does specify areas of capture, then the consumer may assume the area of _scene_ is greater than or equal to the outer extents of the individual areas of capture.
...
Scale attribute: An optional attribute indicating if the numbers used for area of _scene_, area of capture and point of capture are in terms of millimeters, unknown scale factor, or not any scale, as described in Section 5.

6.2.2. Capture scene entry attributes 
_Scene_-switch-policy: {site-switch, segment-switch}...

11.1. Three screen endpoint media provider 
Capture Scenes: The following table represents the capture scenes for this 
provider. Recall that a capture scene is composed of alternative capture scene entries covering the same _scene_.

--
John Leslie <[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Feb 2013 13:16:24 +1100

Hello Mark,

Please see my responses below.

Regards, Christian

On 13/02/2013 1:57 AM, Duckworth, Mark wrote:
> ..snip..
[CNG] I agree with John's response on this. We don't need to define it 
if it isn't used. I.e. either use "region" or "capture scene" as 
appropriate.
> ..snip..
[CNG] i'd prefer to use something other than "may choose" because to me 
at least it gives the option to do something else. Also need to say "per 
<capture> scene for each media type."
>
> If an advertisement includes multiple capture scene entries in a capture scene then the consumer SHOULD choose one capture scene entry for each media type, but may choose captures based on the Simultaneous Transmission Sets.
[CNG] I suggest .... but may choose <individual> captures based...>

Other wise OK.

> [Duckworth, Mark] The framework already says "The consumer is able to change its configuration of the provider's encodings any number of times during the call, either in response to a new capture a…
[CNG] How about?
"The consumer is able to change its configuration any number of time 
during a CLUE channel association. Any change in configuration should be 
within the bounds of the information received in a prior Advertisement. 
The change may be in response to a newly received Advertisement or a 
local event. The change is communicated from to the provider in the form 
of a new configure message."

Rather than one long sentence I've proposed to break each "requirement" 
into a separate sentence. I've also changed "call" to "CLUE channel 
association". This may not be the best formulation but I think its 
important to separate the two things. A CLUE channel may or may not be 
up for the life of a multimedia session. A consumer can only update CLUE 
information during whilst the CLUE channel is established.