Subject: [clue] spatial information can't describe video locations within composed MCC

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 6 Jan 2014 12:54:27 -0800

Framework version 13 says a provider can use spatial information of source media captures to describe how those sources are placed within a composed multiple content capture (MCC).  In general I think this won't work, and I'm not even sure under what specific conditions it might work.  So I propose removing that part, and instead add text to say the spatial information of individual captures does not relate to its relative position within a composed MCC.

>From section 7.2.1:
For example: The spatial related attributes can be further used to determine how the individual captures "appear" within a stream.  A virtual scene could be constructed for the MCC capture with two Video Captures with a "MaxCaptures" attribute set to 2 and an "Area of Capture" attribute provided with an overall area.  Each of the individual Captures could then also include an "Area of Capture" attribute with a sub-set of the overall area.  The Consumer would then know the relative position of the content in the composed stream.

Here are some reasons why I think this will generally not work:

1.       The spatial information for captures is relevant only in relation to the capture scene to which the captures belong.  Spatial information from different scenes has no relation to each other.  So if the individual captures that are part of a composed MCC come from different scenes (source captures from multiple scenes, or source captures from different scenes than the MCC) then the spatial information of one capture has no relation to the spatial information of another capture.

2.       In the example with MaxCaptures = 2, that doesn't mean there will always be 2 contributing captures in the MCC.  It just means maximum of 2, but sometimes there could be 1.  The contents of the MCC could actually be changing over time between 1 and 2 contributing captures.  If it changes between one full screen source image to two source images side by side, then the spatial information wouldn't always indicate the location of the source within the MCC. We have no way for the provider to advertise this level of detail, and I don't think we want to get into this detail in provider advertisements.

3.       Similarly, the MCC could always contain both individual captures, but maybe it is a large image of the one that is talking and a small image of the other.  This would change over time, so again the spatial information wouldn't always indicate the location of the source within the MCC.

4.       Take a slightly different example, where the MCC contains 4 contributing individual captures, but still with MaxCaptures = 2.  So the resulting MCC again will change over time, as the provider is free to choose which 2 out of the 4 to include at any time.  So again the spatial information wouldn't always indicate the location of the source within the MCC.

Regards,
Mark

---

From: Christian Groves <[email-masked]>
Date: Tue, 07 Jan 2014 16:08:09 +1100

Hello Mark,

I agree with respect to the fact that spatial information isn't valid 
across Capture Scenes. i.e. If I have an MCC in one Cap.Scene 
referencing individual captures from other scenes. However I think there 
is a valid case where an MCC can reference Individual captures from the 
same scene as it. In this case I think the use of spatial information is 
valid, i.e.
+-----------------------+---------------------------------+
| Capture Scene #1 | |
+-----------------------|---------------------------------+
| VC1 | CapArea=Left |
| VC2 | CapArea=Right |
| MCC1(VC1, VC2) | |
+---------------------------------------------------------+
or
+-----------------------+---------------------------------+
| Capture Scene #1 | |
+-----------------------|---------------------------------+
| MCC1(VC1) | CapArea=Left |
| MCC2(VC2) | CapArea=Right |
| MCC1(MCC1,MCC2) | |
+---------------------------------------------------------+
where VC1 and VC2 are from different Capture Scenes.

There are of course cases where the spatial information wouldn't be 
valid but in those cases the Provider wouldn't provide them, i.e. where 
the individual captures move. However there will be cases where the 
composition is static and the information would be valid. I don't think 
we can make a general assumption that the spatial information is valid 
or invalid in all cases.

Regards, Christian

On 7/01/2014 7:54 AM, Duckworth, Mark wrote:
>
> Framework version 13 says a provider can use spatial information of 
> source media captures to describe how those sources are placed within 
> a composed multiple content capture (MCC). In general I think this 
> won’t work, and I’m not even sure under what specific conditions it 
> might work. So I propose removing that part, and instead add text to 
> say the spatial information of individual captures does not relate to 
> its relative position within a composed MCC.
>
> From section 7.2.1:
>
> For example: The spatial related attributes can be further used to 
> determine how the individual captures "appear" within a stream. A 
> virtual scene could be constructed for the MCC capture with two Video 
> Captures with a "MaxCaptures" attribute set to 2 and an "Area of 
> Capture" attribute provided with an overall area. Each of the 
> individual Captures could then also include an "Area of Capture" 
> attribute with a sub-set of the overall area. The Consumer would then 
> know the relative position of the content in the composed stream.
>
> 1.The spatial information for captures is relevant only in relation to 
> the capture scene to which the captures belong. Spatial information 
> from different scenes has no relation to each other. So if the 
> individual captures that are part of a composed MCC come from 
> different scenes (source captures from multiple scenes, or source 
> captures from different scenes than the MCC) then the spatial 
> information of one capture has no relation to the spatial information 
> of another capture.
>
> 2.In the example with MaxCaptures = 2, that doesn’t mean there will 
> always be 2 contributing captures in the MCC. It just means maximum of 
> 2, but sometimes there could be 1. The contents of the MCC could 
> actually be changing over time between 1 and 2 contributing captures. 
> If it changes between one full screen source image to two source 
> images side by side, then the spatial information wouldn’t always 
> indicate the location of the source within the MCC. We have no way for 
> the provider to advertise this level of detail, and I don’t think we 
> want to get into this detail in provider advertisements.
>
> 3.Similarly, the MCC could always contain both individual captures, 
> but maybe it is a large image of the one that is talking and a small 
> image of the other. This would change over time, so again the spatial 
> information wouldn’t always indicate the location of the source within 
> the MCC.
>
> 4.Take a slightly different example, where the MCC contains 4 
> contributing individual captures, but still with MaxCaptures = 2. So 
> the resulting MCC again will change over time, as the provider is free 
> to choose which 2 out of the 4 to include at any time. So again the 
> spatial information wouldn’t always indicate the location of the 
> source within the MCC.
>
> Regards,
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 7 Jan 2014 05:18:11 -0800

Hello Christian,

So there are only certain circumstances in which spatial information for components of a composed capture is relevant.  For the case where you think it is important and relevant, can you please propose text for the framework to describe this?  I think the framework should be more clear about when and how the consumer can use this information for composed captures.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, January 07, 2014 12:08 AM
> To: [email-masked]
> Subject: Re: [clue] spatial information can't describe video locations within
> composed MCC
> 
> Hello Mark,
> 
> I agree with respect to the fact that spatial information isn't valid across
> Capture Scenes. i.e. If I have an MCC in one Cap.Scene referencing individual
> captures from other scenes. However I think there is a valid case where an
> MCC can reference Individual captures from the same scene as it. In this case
> I think the use of spatial information is valid, i.e.
> There are of course cases where the spatial information wouldn't be valid but
> in those cases the Provider wouldn't provide them, i.e. where the individual
> captures move. However there will be cases where the composition is static
> and the information would be valid. I don't think we can make a general
> assumption that the spatial information is valid or invalid in all cases.
> 
> Regards, Christian
> 
> > won't work, and I'm not even sure under what specific conditions it
> > 2.In the example with MaxCaptures = 2, that doesn't mean there will
> > images side by side, then the spatial information wouldn't always
> > the provider to advertise this level of detail, and I don't think we
> > information wouldn't always indicate the location of the source within
> > the MCC.
> >
> > spatial information wouldn't always indicate the location of the
> > source within the MCC.
> >
> > Regards,
> >
> > Mark
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2014 11:06:23 -0500

Mark,

As long as the spatial information for source captures is present in the 
advertisement, the client can always attempt to use it to help decide 
how to map the captures it configures to the devices it has available. 
In some cases that information may be more helpful than others. It might 
be useful to give an example where it is useful, but I don't think we 
should try to be exhaustive about this.

If an MCU advertiser assigns spatial coordinates to the MCC captures 
within the (virtual) scene where those captures are declared, the only 
information *it* has to do so are the coordinates of those captures 
within the scenes in which they are received.

So a client of that MCU, given source capture spatial info, can do as 
well as the MCU did. And it might do better, especially if the MCU 
doesn't bother to assign coordinates within the virtual scene. Also, the 
client can take advantage of specifics of its situation. For instance, 
if it is only configuring a subset of the MCC captures.

AFAIK the key cases where any of this matters are with site switching, 
because then it may be possible to preserve the relationships between 
the captures regardless of what site happens to be switched in.

	Thanks,
	Paul	

On 1/6/14 3:54 PM, Duckworth, Mark wrote:
> source media captures to describe how those sources are placed within a
> composed multiple content capture (MCC).  In general I think this won’t
> work, and I’m not even sure under what specific conditions it might
> work.  So I propose removing that part, and instead add text to say the
> spatial information of individual captures does not relate to its
> relative position within a composed MCC.
>
>  From section 7.2.1:
>
> individual captures that are part of a composed MCC come from different
> scenes (source captures from multiple scenes, or source captures from
> different scenes than the MCC) then the spatial information of one
> capture has no relation to the spatial information of another capture.
>
> If it changes between one full screen source image to two source images
> side by side, then the spatial information wouldn’t always indicate the
> location of the source within the MCC. We have no way for the provider
> to advertise this level of detail, and I don’t think we want to get into
> this detail in provider advertisements.
>
> 3.Similarly, the MCC could always contain both individual captures, but
> maybe it is a large image of the one that is talking and a small image
> of the other.  This would change over time, so again the spatial
> spatial information wouldn’t always indicate the location of the source
> within the MCC.
>
> Regards,
>
> Mark
>
>
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 7 Jan 2014 10:36:37 -0800

Hello Paul,

I agree with you, but I think you are talking about something a little different than the point I was trying to make.

I'll try to be more clear.  They key thing is this statement from the framework (which originally came from Christian):
" The Consumer would then know the relative position of the content in the composed stream "
This is saying the MCU is advertising a composed video stream, and the consumer can tell from the advertisement how those individual source video captures are laid out within the composed stream the MCU creates.  Christian says this is possible and useful, and I'm saying there are fairly strict constraints on when this is possible.  I think Christian agrees there are constraints, so we're trying to articulate the constraints.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, January 07, 2014 11:06 AM
> To: [email-masked]
> advertisement, the client can always attempt to use it to help decide how to
> map the captures it configures to the devices it has available.
> In some cases that information may be more helpful than others. It might be
> useful to give an example where it is useful, but I don't think we should try to
> be exhaustive about this.
> 
> If an MCU advertiser assigns spatial coordinates to the MCC captures within
> the (virtual) scene where those captures are declared, the only information
> *it* has to do so are the coordinates of those captures within the scenes in
> which they are received.
> 
> So a client of that MCU, given source capture spatial info, can do as well as
> the MCU did. And it might do better, especially if the MCU doesn't bother to
> assign coordinates within the virtual scene. Also, the client can take
> advantage of specifics of its situation. For instance, if it is only configuring a
> subset of the MCC captures.
> 
> because then it may be possible to preserve the relationships between the
> captures regardless of what site happens to be switched in.
> 
> 	Thanks,
> 	Paul
> 
> 
> 
> > information of one capture has no relation to the spatial information of
> another capture.
> >
> > always be 2 contributing captures in the MCC.  It just means maximum
> > of 2, but sometimes there could be 1.  The contents of the MCC could

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2014 15:11:30 -0500

On 1/7/14 1:36 PM, Duckworth, Mark wrote:
> " The Consumer would then know the relative position of the content in the composed stream"

Oh, sorry! I agree that is something different from what I was talking 
about. And I don't really understand how that would work without some 
sort of leap of faith about how composition is done.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 10 Jan 2014 13:18:45 +1100

Hello Mark,

How about something like the following?

7.2.1. MCC Attributes

    Attributes may be associated with the MCC instance and the Single
    Media Captures that the MCC references.  A provider should avoid
    providing conflicting attribute values between the MCC and Single
    Media Captures. Where there is conflict the attributes of the MCC
    override any that may be present in the individual captures.

    <<When assigning spatial attributes to individual captures within a 
MCC and/or to the MCC itself the Provider should be aware that spatial 
attributes have no relation across Capture Scenes. Therefore if the 
Provider intends to provide a spatial relation between the source 
Captures and the MCC then these MUST be part of the same Capture Scene. 
When assigning spatial information that would cause the spatial 
positioning of the source Capture to move within the MCC, the Provider 
should also be aware that a Consumer may not be able to determine that 
the source captures have moved.>>

  ...

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 10 Jan 2014 13:04:08 -0800

Thanks Christian, that is an improvement.  But I'm still not convinced the consumer can always tell when the spatial attributes are meaningful (even within a scene) for discerning how contributors to a composed MCC are arranged within the MCC.  My concerns 2, 3, and 4 below still apply.

Does anybody else have input to this topic?

Mark

> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, January 09, 2014 9:19 PM
> To: Duckworth, Mark; [email-masked]
>     <<When assigning spatial attributes to individual captures within a MCC
> and/or to the MCC itself the Provider should be aware that spatial attributes
> have no relation across Capture Scenes. Therefore if the Provider intends to
> provide a spatial relation between the source Captures and the MCC then
> these MUST be part of the same Capture Scene.
> When assigning spatial information that would cause the spatial positioning
> of the source Capture to move within the MCC, the Provider should also be
> aware that a Consumer may not be able to determine that the source
> captures have moved.>>
> 
>   ...
> 
> Regards, Christian
> 
> > So there are only certain circumstances in which spatial information for
> components of a composed capture is relevant.  For the case where you
> think it is important and relevant, can you please propose text for the
> framework to describe this?  I think the framework should be more clear
> about when and how the consumer can use this information for composed
> captures.
> >
> > Mark
> >
> >> Subject: Re: [clue] spatial information can't describe video
> >> locations within composed MCC
> >>
> >> Hello Mark,
> >>
> >> referencing individual captures from other scenes. However I think
> >> there is a valid case where an MCC can reference Individual captures
> >> from the same scene as it. In this case I think the use of spatial
> information is valid, i.e.
> >> valid but in those cases the Provider wouldn't provide them, i.e.
> >> where the individual captures move. However there will be cases where
> >> the composition is static and the information would be valid. I don't
> >> think we can make a general assumption that the spatial information is
> valid or invalid in all cases.
> >>
> >> Regards, Christian
> >>
> >>> source media captures to describe how those sources are placed
> >>> within a composed multiple content capture (MCC). In general I think
> >>> this won't work, and I'm not even sure under what specific
> >>> conditions it might work. So I propose removing that part, and
> >>> instead add text to say the spatial information of individual
> >>> captures does not relate to its relative position within a composed MCC.
> >>>
> >>>  From section 7.2.1:
> >>>
> >>> virtual scene could be constructed for the MCC capture with two
> >>> Video Captures with a "MaxCaptures" attribute set to 2 and an "Area
> >>> of Capture" attribute provided with an overall area. Each of the
> >>> attribute with a sub-set of the overall area. The Consumer would
> >>> then know the relative position of the content in the composed stream.
> >>>
> >>> 1.The spatial information for captures is relevant only in relation
> >>> to the capture scene to which the captures belong. Spatial
> >>> information from different scenes has no relation to each other. So
> >>> if the individual captures that are part of a composed MCC come from
> >>> information of one capture has no relation to the spatial
> >>> information of another capture.
> >>>
> >>> indicate the location of the source within the MCC. We have no way
> >>> for the provider to advertise this level of detail, and I don't
> >>> think we want to get into this detail in provider advertisements.
> >>>
> >>> image of the other. This would change over time, so again the
> >>> the resulting MCC again will change over time, as the provider is
> >>> free to choose which 2 out of the 4 to include at any time. So again
> >>> the spatial information wouldn't always indicate the location of the
> >>> source within the MCC.
> >>>
> >>> Regards,
> >>>
> >>> Mark
> >>>
> >>>
> >>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 17 Jan 2014 14:50:39 -0800

We discussed this topic in the design team meeting Jan 14<http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes_140114.txt>.  From the minutes:

"Conclusion 1: Spatial information of the individual captures does not apply inside a composed MCC."

We wanted to bring this topic back to the list to make sure we have consensus before clarifying the framework about this.  Christian, or anybody else, do you still want more discussion?

Regards,
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark

> Sent: Friday, January 10, 2014 4:04 PM

> To: Christian Groves; [email-masked]

> Thanks Christian, that is an improvement.  But I'm still not convinced the

> consumer can always tell when the spatial attributes are meaningful (even

> within a scene) for discerning how contributors to a composed MCC are

> arranged within the MCC.  My concerns 2, 3, and 4 below still apply.

> > Subject: Re: [clue] spatial information can't describe video locations

> > within composed MCC

> >     <<When assigning spatial attributes to individual captures within

> > a MCC and/or to the MCC itself the Provider should be aware that

> > spatial attributes have no relation across Capture Scenes. Therefore

> > if the Provider intends to provide a spatial relation between the

> > source Captures and the MCC then these MUST be part of the same

> Capture Scene.

> > > So there are only certain circumstances in which spatial information

> > > for

> > think it is important and relevant, can you please propose text for

> > the framework to describe this?  I think the framework should be more

> > clear about when and how the consumer can use this information for

> > composed captures.

> > >> From: clue [mailto:[email-masked]] On Behalf Of Christian

> > >> Groves

> > >> I agree with respect to the fact that spatial information isn't

> > >> valid across Capture Scenes. i.e. If I have an MCC in one Cap.Scene

> > >> there is a valid case where an MCC can reference Individual

> > >> captures from the same scene as it. In this case I think the use of

> > >> spatial

> > >> where the individual captures move. However there will be cases

> > >> where the composition is static and the information would be valid.

> > >> I don't think we can make a general assumption that the spatial

> > >> information is

> > >>> Framework version 13 says a provider can use spatial information

> > >>> of source media captures to describe how those sources are placed

> > >>> within a composed multiple content capture (MCC). In general I

> > >>> think this won't work, and I'm not even sure under what specific

> > >>> captures does not relate to its relative position within a composed

> MCC.

> > >>> Video Captures with a "MaxCaptures" attribute set to 2 and an

> > >>> "Area of Capture" attribute provided with an overall area. Each of

> > >>> the individual Captures could then also include an "Area of Capture"

> > >>> then know the relative position of the content in the composed

> stream.

> > >>> 1.The spatial information for captures is relevant only in

> > >>> relation to the capture scene to which the captures belong.

> > >>> Spatial information from different scenes has no relation to each

> > >>> other. So if the individual captures that are part of a composed

> > >>> MCC come from different scenes (source captures from multiple

> > >>> scenes, or source captures from different scenes than the MCC)

> > >>> then the spatial information of one capture has no relation to the

> > >>> spatial information of another capture.

> > >>> 2.In the example with MaxCaptures = 2, that doesn't mean there

> > >>> will always be 2 contributing captures in the MCC. It just means

> > >>> maximum of 2, but sometimes there could be 1. The contents of the

> > >>> MCC could actually be changing over time between 1 and 2

> contributing captures.

> > >>> 3.Similarly, the MCC could always contain both individual

> > >>> captures, but maybe it is a large image of the one that is talking

> > >>> and a small image of the other. This would change over time, so

> > >>> again the spatial information wouldn't always indicate the

> > >>> location of the source within the MCC.

> > >>> contributing individual captures, but still with MaxCaptures = 2.

> > >>> So the resulting MCC again will change over time, as the provider

> > >>> is free to choose which 2 out of the 4 to include at any time. So

> > >>> again the spatial information wouldn't always indicate the

> > >>> location of the source within the MCC.

> > >>> [email-masked]<mailto:[email-masked]>

> > >> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Jan 2014 13:36:56 +1100

Hello Mark,

Sorry for the delayed response. I was on vacation last week. I see 
there's been quite a lot of activity over the last week with respect to 
MCCs and the framework.

I saw the minutes of the meeting and saw there was a mention that I 
should argue :-).

I don't agree with the outcome of the meeting. I think its important to 
note that MCC doesn't equal switching. A MCC may represent a dynamic 
switching case OR a static case. A static case may be that a MCU offers 
a single stream where three captures from an endpoint on separate 
streams are composed into one video stream. I cannot see why in the 
static case spatial information isn't valid? In the static case the 
concerns of 2, 3 and 4 don't apply.

 From the minutes I didn't see an explanation of other people's concerns.

So rather than a complete prohibition of the spatial information 
regarding individual captures I think it would be better to explain that 
the Advertiser has a choice to include the information and that the 
spatial information is only meaningful if the individual capture's 
spatial information is static. That's what I tried to capture in the 
text below.

Regards, Christian

On 18/01/2014 9:50 AM, Duckworth, Mark wrote:
>
> We discussed this topic in the design team meeting Jan 14 
> <http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes_140114.txt>. 
> From the minutes:
>
> “Conclusion 1: Spatial information of the individual captures does not 
> apply inside a composed MCC.”
>
> We wanted to bring this topic back to the list to make sure we have 
> consensus before clarifying the framework about this. Christian, or 
> anybody else, do you still want more discussion?
>
> Regards,
> Mark
>
> locations within
> > > >>> [email-masked] <mailto:[email-masked]>
>
> > > >> [email-masked] <mailto:[email-masked]>
>
> > [email-masked] <mailto:[email-masked]>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2014 12:43:35 -0500

On 1/19/14 9:36 PM, Christian Groves wrote:
> streams are composed into one video stream.

Yes, we had that in mind when discussing this.

> I cannot see why in the

We may not have understood you. We were guessing what you meant.

Suppose there is an MCC that has three input captures, and composes 
them. It could compose them in many ways. It could put the three side by 
side, or one big one and two as picture-in-picture overlays, or ...
And even with three side by side, they could be in any order.

And the source captures could all be from multiple scenes or one, and if 
one, it could be the same one as the MCC or not. The simplest case is 
that they are all from the same scene as the MCC. But even then, the 
coordinates of the source captures are presumably meaningful if they are 
individually configured. We could see no reason to presume that their 
arrangement in the scene has anything to do with their arrangement in 
the MCC.

So we need more info to understand your perspective on this.

> spatial information is static. That's what I tried to capture in the

I already commented on this earlier.
IMO the advertiser MAY provide spatial information on an MCC. That would 
describe a place within the scene of the MCC. IMO that is a suggestion 
by the advertiser, but doesn't have the same physical significance as 
will a non-MCC capture. The consumer could just use this, treating the 
MCC like any other capture. Or, if it is smarter, and the MCC is 
*switched*, it could ignore this and look into the spatial info for the 
source captures.

But none of that has anything to do with the the arrangement of composed 
captures within an MCC.

	Thanks,
	Paul

>> locations

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 20 Jan 2014 13:29:39 -0800

Christian,

I agree with Paul.

Christian wrote: "I cannot see why in the static case spatial information isn't valid? In the static case the concerns of 2, 3 and 4 don't apply."

That might be true, but how is the consumer going to know if it is the "static case" or not?  I don't see any way for the consumer to know this.

Mark

> Sent: Monday, January 20, 2014 12:44 PM
> To: [email-masked]
> > there's been quite a lot of activity over the last week with respect
> > to MCCs and the framework.
> >
> > I don't agree with the outcome of the meeting. I think its important
> > to note that MCC doesn't equal switching. A MCC may represent a
> > dynamic switching case OR a static case. A static case may be that a
> > MCU offers a single stream where three captures from an endpoint on
> > separate streams are composed into one video stream.
>
> Suppose there is an MCC that has three input captures, and composes them.
> It could compose them in many ways. It could put the three side by side, or
> one big one and two as picture-in-picture overlays, or ...
> And the source captures could all be from multiple scenes or one, and if one,
> it could be the same one as the MCC or not. The simplest case is that they are
> all from the same scene as the MCC. But even then, the coordinates of the
> source captures are presumably meaningful if they are individually
> configured. We could see no reason to presume that their arrangement in
> the scene has anything to do with their arrangement in the MCC.
>
> > regarding individual captures I think it would be better to explain
> > that the Advertiser has a choice to include the information and that
> > the spatial information is only meaningful if the individual capture's
> describe a place within the scene of the MCC. IMO that is a suggestion by the
> advertiser, but doesn't have the same physical significance as will a non-MCC
> capture. The consumer could just use this, treating the MCC like any other
> capture. Or, if it is smarter, and the MCC is *switched*, it could ignore this
> and look into the spatial info for the source captures.
>
> >> > > >>> then the spatial information of one capture has no relation
> >> > > >>> to
> >> the
> >>
> >> > > >>> indicate the location of the source within the MCC. We have
> >> > > >>> no
> >> way
> >>

---

From: Christian Groves <[email-masked]>
Date: Tue, 21 Jan 2014 10:02:15 +1100

Hello Mark and Paul,

Please see my responses below.

Regards, Christian

> That might be true, but how is the consumer going to know if it is the "static case" or not?  I don't see any way for the consumer to know this.
[CNG] The consumer knows this because the Provider only provides the 
spatial information when it makes sense to do so.

>> And even with three side by side, they could be in any order.
[CNG] Yes
>> the scene has anything to do with their arrangement in the MCC.
[CNG] Paul you mentioned the idea of a virtual scene before. What I see 
an MCU doing is creating a virtual scene using these source captures. 
Giving Captures spatial co-ordinates within a virtual scene is a valid 
thing to do irrespective of the use of a MCC. The MCU may apply any 
transformation it wants based on the source capture information. I think 
this equally applies to the MCC itself.
Now if the MCU constructs a composed image from several sources using a 
MCC I can't see why it cannot indicate the spatial position of the 
sources in the MCC as they also reside in the virtual space.
>> capture.
[CNG] I don't understand why the spatial information of the MCC has less 
significance than a non-MCC capture? An Advertiser constructs the scene, 
it give the spatial positioning. If the MCC and non-MCC captures are 
part of the same CSE then equal weight should be given.

>> The consumer could just use this, treating the MCC like any other
[CNG] If the MCC is "switched" AND the spatial information changes 
between source captures then this would be the dynamic case. I think the 
advice is that a Advertiser shouldn't provide this information unless it 
also provides a means for the Consumer to determine when the switch 
takes place. If the MCC is "switched" and the source spatial information 
is the same then the Advertiser can simply supply the spatial 
information at the MCC level without the need to set it on the sources.
>> But none of that has anything to do with the the arrangement of composed
[CNG] I don't understand the point. You only focused on the switched 
case. MCC is for switching and composition.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 21 Jan 2014 04:54:16 -0800

Hello Christian,

I still don't see how the consumer can tell anything about how an MCC is composed.  Take this example,

Scene 1
VC1 - left
VC2 - center
VC3 - right
MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3
CSE1 (VC1, VC2, VC3)
CSE2 (MCC1)

Here it is useful to give spatial information for all the captures, so the consumer that chooses the individual captures knows they are spatially related.  But how is the consumer supposed to know how the provider is composing them inside MCC1?  It could be any number of ways, and it could be changing over time.  So my cases 2 and 3 below apply to why the consumer can't tell how the MCC is composed.  Yet it still makes sense for the provider to give spatial information for the captures themselves.

Mark

> Sent: Monday, January 20, 2014 6:02 PM
> To: [email-masked]
> > Christian wrote: "I cannot see why in the static case spatial information isn't
> valid? In the static case the concerns of 2, 3 and 4 don't apply."
> >
> > That might be true, but how is the consumer going to know if it is the "static
> case" or not?  I don't see any way for the consumer to know this.
> them.
> >> It could compose them in many ways. It could put the three side by
> >> And the source captures could all be from multiple scenes or one, and
> >> if one, it could be the same one as the MCC or not. The simplest case
> >> is that they are all from the same scene as the MCC. But even then,
> >> the coordinates of the source captures are presumably meaningful if
> >> they are individually configured. We could see no reason to presume
> >> that their arrangement in the scene has anything to do with their
> arrangement in the MCC.
> [CNG] Paul you mentioned the idea of a virtual scene before. What I see an
> MCU doing is creating a virtual scene using these source captures.
> Giving Captures spatial co-ordinates within a virtual scene is a valid thing to
> do irrespective of the use of a MCC. The MCU may apply any transformation
> it wants based on the source capture information. I think this equally applies
> to the MCC itself.
> MCC I can't see why it cannot indicate the spatial position of the sources in
> the MCC as they also reside in the virtual space.
> >>
> >>> the spatial information is only meaningful if the individual
> >>> capture's spatial information is static. That's what I tried to
> >>> capture in the text below.
> >> IMO the advertiser MAY provide spatial information on an MCC. That
> >> would describe a place within the scene of the MCC. IMO that is a
> >> suggestion by the advertiser, but doesn't have the same physical
> >> significance as will a non-MCC capture.
> significance than a non-MCC capture? An Advertiser constructs the scene, it
> give the spatial positioning. If the MCC and non-MCC captures are part of the
> same CSE then equal weight should be given.
>
> >> capture. Or, if it is smarter, and the MCC is *switched*, it could
> >> ignore this and look into the spatial info for the source captures.
> advice is that a Advertiser shouldn't provide this information unless it also
> provides a means for the Consumer to determine when the switch takes
> place. If the MCC is "switched" and the source spatial information is the same
> then the Advertiser can simply supply the spatial information at the MCC
> level without the need to set it on the sources.
> >>
> >> But none of that has anything to do with the the arrangement of
> >> composed captures within an MCC.
> [CNG] I don't understand the point. You only focused on the switched case.
> MCC is for switching and composition.
> >>
> >>        Thanks,
> >>        Paul
> >>
> >>> Regards, Christian
> >>>
> >>>>> consumer can always tell when the spatial attributes are
> >>>>> meaningful
> >>>> (even
> >>>>
> >>>>> within a scene) for discerning how contributors to a composed MCC
> >>>>> are arranged within the MCC. My concerns 2, 3, and 4 below still
> >>>>> apply.
> >>>>>> the source captures have moved.>> ...
> >>>>>> Regards, Christian
> >>>>>> components of a composed capture is relevant. For the case where
> >>>>>> you think it is important and relevant, can you please propose
> >>>>>> text for the framework to describe this? I think the framework
> >>>>>> should be more clear about when and how the consumer can use
> this
> >>>>>> information for composed captures.
> >>>>>>> Mark
> >>>>>>>> locations within composed MCC Hello Mark, I agree with respect
> >>>>>>>> to the fact that spatial information isn't valid across Capture
> >>>>>>>> Scenes. i.e. If I have an MCC in one
> >>>> Cap.Scene
> >>>>
> >>>>>>>> referencing individual captures from other scenes. However I
> >>>>>>>> think there is a valid case where an MCC can reference
> >>>>>>>> Individual captures from the same scene as it. In this case I
> >>>>>>>> think the
> >>>> use of
> >>>>
> >>>>>>>> spatial
> >>>>>>>>> Framework version 13 says a provider can use spatial
> >>>>>>>>> information of source media captures to describe how those
> >>>>>>>>> sources are placed within a composed multiple content capture
> >>>>>>>>> (MCC). In general I think this won't work, and I'm not even
> >>>>>>>>> sure under what specific conditions it might work. So I
> >>>>>>>>> propose removing that part, and instead add text to say the
> >>>>>>>>> spatial information of individual captures does not relate to
> >>>>>>>>> its relative position within a
> >>>> composed
> >>>>
> >>>>> MCC.
> >>>>>>>>>  From section 7.2.1:
> >>>>>>>>> determine how the individual captures "appear" within a
> >>>>>>>>> stream. A virtual scene could be constructed for the MCC
> >>>>>>>>> capture with two Video Captures with a "MaxCaptures" attribute
> >>>>>>>>> set to 2 and an "Area of Capture" attribute provided with an
> >>>>>>>>> overall area.
> >>>> Each of
> >>>>
> >>>>>>>>> attribute with a sub-set of the overall area. The Consumer
> >>>>>>>>> would then know the relative position of the content in the
> >>>>>>>>> composed
> >>>>> stream.
> >>>>>>>>> Spatial information from different scenes has no relation to
> >>>>>>>>> each other. So if the individual captures that are part of a
> >>>>>>>>> composed MCC come from different scenes (source captures
> from
> >>>>>>>>> multiple scenes, or source captures from different scenes than
> >>>>>>>>> the
> >>>>>>>>> MCC)
> >>>>>>>>> will always be 2 contributing captures in the MCC. It just
> >>>>>>>>> means maximum of 2, but sometimes there could be 1. The
> >>>>>>>>> contents of the MCC could actually be changing over time
> >>>>>>>>> between 1 and 2
> >>>>> contributing captures.
> >>>>>>>>> If it changes between one full screen source image to two
> >>>>>>>>> source images side by side, then the spatial information
> >>>>>>>>> wouldn't always indicate the location of the source within the
> >>>>>>>>> MCC. We have no
> >>>> way
> >>>>
> >>>>>>>>> for the provider to advertise this level of detail, and I
> >>>>>>>>> don't think we want to get into this detail in provider
> >>>>>>>>> advertisements.
> >>>>>>>>> and a small image of the other. This would change over time,
> >>>>>>>>> so again the spatial information wouldn't always indicate the
> >>>>>>>>> So the resulting MCC again will change over time, as the
> >>>>>>>>> provider is free to choose which 2 out of the 4 to include at
> >>>>>>>>> any time. So again the spatial information wouldn't always
> >>>>>>>>> indicate the location of the source within the MCC.
> >>>>>>>>> Regards,
> >>>>>>>>> Mark

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Jan 2014 10:39:07 +1100

Hello Mark,

I think I know where the disconnect is between us. Its to do with the 
encodings. In my examples I've been assumed that Provider only provides 
the encoding for MCC1 not the constituent captures. Whereas you've been 
assuming that encodings are being provided for the individual and MCC 
captures.

In the case of the encoding only being on the MCC the consumer knows 
because the VCs and MCC belong to the same Capture Scene. The Advertiser 
has provided the spatial positions of VC1 being left. VC2 being centre 
and VC3 being right. That is their position in the composition.

In the case of multiple encodings the spatial information associated 
with an individual capture is likely to be a difference between the 
individual encodings and the MCC encoding.

So perhaps the way to address this is to allow spatial information in 
individual encodings in MCCs only when those individual encodings are MCCs?

E.g. taking your example below.

Scene 1
VC1 - left
VC2 - center
VC3 - right
MCC2(VC1) - left-composed
MCC3(VC2) - center-composed
MCC4(VC3) - right-composed
MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3
CSE1 (VC1, VC2, VC3)
CSE2 (MCC1)

In order to address the maxCaptures issue perhaps we need to modify 
"MaxCaptures" slightly so that it becomes "NumberofCaptures" where we 
could say NumberofCaptures=3 or NumberofCaptures<=3. This would give 
more certainty to the Consumer about what will actually be sent.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jan 2014 13:33:11 -0500

> and VC3 being right. That is their position in the composition.

That at best seems like a hack. It is repurposing the spatial info of 
the captures without encodings for an entirely different purpose.

And it doesn't work right if you want to have multiple MCCs that compose 
the same sources differently. (Unless you introduce another layer of 
indirection, such as you do in example below. Yet another hack.)

> MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3

In effect what you have now done is introduce an explicit encoding for 
the positions of the sources of a composition. (But used an obscure and 
confusing notation.)

If we really want that, then I suggest we just add syntax to the 
declaration of the MCC to explicitly do it.

But I don't really see the point of doing so. What can the consumer do 
when it has this info that it wouldn't be able to do without it?

> more certainty to the Consumer about what will actually be sent.

That is just another step towards describing the complete layout of the 
composition.

Lets first discuss if having this information would provide significant 
value. If so then we can discuss how to provide it.

	Thanks,
	Paul

>> Here it is useful to give spatial information for all the captures, so
>> the consumer that chooses the individual captures knows they are
>> spatially related.  But how is the consumer supposed to know how the
>> provider is composing them inside MCC1?  It could be any number of
>> ways, and it could be changing over time.  So my cases 2 and 3 below
>> apply to why the consumer can't tell how the MCC is composed.  Yet it
>> still makes sense for the provider to give spatial information for the
>> captures themselves.
>>
>> Mark
>>
>>> sources in

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 22 Jan 2014 16:16:13 -0800

Hi Paul,

Paul wrote: "Lets first discuss if having this information would provide significant value. If so then we can discuss how to provide it."

Yes, but we already did that, and decided it isn't valuable enough to work on as part of CLUE.  This was Ticket #5<http://tools.ietf.org/wg/clue/trac/ticket/5>.  I think we should stick with that decision.

Mark

> Sent: Wednesday, January 22, 2014 1:33 PM

> > encodings. In my examples I've been assumed that Provider only

> > provides the encoding for MCC1 not the constituent captures. Whereas

> > you've been assuming that encodings are being provided for the

> > individual and MCC captures.

> > because the VCs and MCC belong to the same Capture Scene. The

> > Advertiser has provided the spatial positions of VC1 being left. VC2

> > being centre and VC3 being right. That is their position in the composition.

> That at best seems like a hack. It is repurposing the spatial info of the

> captures without encodings for an entirely different purpose.

> > individual encodings in MCCs only when those individual encodings are

> MCCs?

> In effect what you have now done is introduce an explicit encoding for the

> positions of the sources of a composition. (But used an obscure and

> If we really want that, then I suggest we just add syntax to the declaration of

> the MCC to explicitly do it.

> But I don't really see the point of doing so. What can the consumer do when

> it has this info that it wouldn't be able to do without it?

> Lets first discuss if having this information would provide significant value. If

> so then we can discuss how to provide it.

> >> I still don't see how the consumer can tell anything about how an MCC

> >> is composed.  Take this example,

> >> Here it is useful to give spatial information for all the captures,

> >> so the consumer that chooses the individual captures knows they are

> >> still makes sense for the provider to give spatial information for

> >> the captures themselves.

> >>>> Christian wrote: "I cannot see why in the static case spatial

> >>>> information isn't

> >>>> That might be true, but how is the consumer going to know if it is

> >>>> the "static

> >>>>> From: clue [mailto:[email-masked]] On Behalf Of Paul

> >>>>> Kyzivat

> >>>>>> Sorry for the delayed response. I was on vacation last week. I

> >>>>>> see there's been quite a lot of activity over the last week with

> >>>>>> respect to MCCs and the framework.

> >>>>>> I saw the minutes of the meeting and saw there was a mention that

> >>>>>> I should argue :-).

> >>>>>> I don't agree with the outcome of the meeting. I think its

> >>>>>> important to note that MCC doesn't equal switching. A MCC may

> >>>>>> represent a dynamic switching case OR a static case. A static

> >>>>>> case may be that a MCU offers a single stream where three

> >>>>>> captures from an endpoint on separate streams are composed into

> one video stream.

> >>>>>> static case spatial information isn't valid? In the static case

> >>>>>> the concerns of 2, 3 and 4 don't apply.

> >>>>> We may not have understood you. We were guessing what you

> meant.

> >>>>> Suppose there is an MCC that has three input captures, and

> >>>>> composes

> >>>>> And the source captures could all be from multiple scenes or one,

> >>>>> and if one, it could be the same one as the MCC or not. The

> >>>>> simplest case is that they are all from the same scene as the MCC.

> >>>>> But even then, the coordinates of the source captures are

> >>>>> presumably meaningful if they are individually configured. We

> >>>>> could see no reason to presume that their arrangement in the scene

> >>>>> has anything to do with their

> >>> [CNG] Paul you mentioned the idea of a virtual scene before. What I

> >>> see an MCU doing is creating a virtual scene using these source

> >>> Giving Captures spatial co-ordinates within a virtual scene is a

> >>> valid thing to do irrespective of the use of a MCC. The MCU may

> >>> apply any transformation it wants based on the source capture

> >>> information. I think this equally applies to the MCC itself.

> >>> Now if the MCU constructs a composed image from several sources

> >>> using a MCC I can't see why it cannot indicate the spatial position

> >>> of the sources in the MCC as they also reside in the virtual space.

> >>>>>>    From the minutes I didn't see an explanation of other people's

> >>> concerns.

> >>>>>> regarding individual captures I think it would be better to

> >>>>>> explain that the Advertiser has a choice to include the

> >>>>>> information and that the spatial information is only meaningful

> >>>>>> if the individual capture's spatial information is static. That's

> >>>>>> what I tried to capture in the text below.

> >>> [CNG] I don't understand why the spatial information of the MCC has

> >>> less significance than a non-MCC capture? An Advertiser constructs

> >>> the scene, it give the spatial positioning. If the MCC and non-MCC

> >>> captures are part of the same CSE then equal weight should be given.

> >>> between source captures then this would be the dynamic case. I think

> >>> the advice is that a Advertiser shouldn't provide this information

> >>> unless it also provides a means for the Consumer to determine when

> >>> the switch takes place. If the MCC is "switched" and the source

> >>> spatial information is the same then the Advertiser can simply

> >>> supply the spatial information at the MCC level without the need to

> >>> set it on the sources.

> >>> case.

> >>>>>>> <http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-

> >>>>> Team/minutes_140114.txt>.

> >>>>>>> "Conclusion 1: Spatial information of the individual captures

> >>>>>>> does not apply inside a composed MCC."

> >>>>>>> We wanted to bring this topic back to the list to make sure we

> >>>>>>> have consensus before clarifying the framework about this.

> >>>>>>> Christian, or anybody else, do you still want more discussion?

> >>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of

> >>>>>>>> Duckworth, Mark

> >>>>>>>> Thanks Christian, that is an improvement. But I'm still not

> >>>>>>> convinced the

> >>>>>>>> within a scene) for discerning how contributors to a composed

> >>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 below

> >>>>>>>> still apply.

> >>>>>>>>> Attributes may be associated with the MCC instance and the

> >>>>>>>>> Single Media Captures that the MCC references. A provider

> >>>>>>>>> should avoid providing conflicting attribute values between

> >>>>>>>>> the MCC and Single Media Captures. Where there is conflict the

> >>>>>>>>> attributes of the MCC override any that may be present in the

> individual captures.

> >>>>>>>>> <<When assigning spatial attributes to individual captures

> >>>>>>>>> within a MCC and/or to the MCC itself the Provider should be

> >>>>>>>>> aware that spatial attributes have no relation across Capture

> Scenes.

> >>>>>>>>> Therefore

> >>>>>>>>> if the Provider intends to provide a spatial relation between

> >>>>>>>>> the source Captures and the MCC then these MUST be part of

> >>>>>>>>> same

> >>>>>>>>> When assigning spatial information that would cause the

> >>>>>>>>> spatial positioning of the source Capture to move within the

> >>>>>>>>> MCC, the

> >>>>>>> Provider

> >>>>>>>>> should also be aware that a Consumer may not be able to

> >>>>>>>>> determine

> >>>>>>> that

> >>>>>>>>>> So there are only certain circumstances in which spatial

> >>>>>>> information

> >>>>>>>>> components of a composed capture is relevant. For the case

> >>>>>>>>> where you think it is important and relevant, can you please

> >>>>>>>>> propose text for the framework to describe this? I think the

> >>>>>>>>> framework should be more clear about when and how the

> consumer

> >>>>>>>>> can use

> >>>>>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of

> >>>>>>>>>>> Christian Groves

> >>>>>>>>>>> locations within composed MCC Hello Mark, I agree with

> >>>>>>>>>>> respect to the fact that spatial information isn't valid

> >>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one

> >>>>>>>>>>> Individual captures from the same scene as it. In this case

> >>>>>>>>>>> I think the

> >>>>>>>>>>> There are of course cases where the spatial information

> >>>>>>> wouldn't be

> >>>>>>>>>>> valid but in those cases the Provider wouldn't provide them,

> >>>>>>>>>>> i.e.

> >>>>>>>>>>> where the individual captures move. However there will be

> >>>>>>>>>>> cases where the composition is static and the information

> >>>>>>>>>>> would be

> >>>>>>> valid.

> >>>>>>>>>>> I don't think we can make a general assumption that the

> >>>>>>>>>>> spatial information is

> >>>>>>>>>>>> sources are placed within a composed multiple content

> >>>>>>>>>>>> capture (MCC). In general I think this won't work, and I'm

> >>>>>>>>>>>> not even sure under what specific conditions it might work.

> >>>>>>>>>>>> So I propose removing that part, and instead add text to

> >>>>>>>>>>>> say the spatial information of individual captures does not

> >>>>>>>>>>>> relate to its relative position within a

> >>>>>>>>>>>> For example: The spatial related attributes can be further

> >>>>>>> used to

> >>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures"

> >>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute

> >>>>>>>>>>>> provided with an overall area.

> >>>>>>>>>>>> the individual Captures could then also include an "Area of

> >>>>>>> Capture"

> >>>>>>>>>>>> Here are some reasons why I think this will generally not

> work:

> >>>>>>>>>>>> Spatial information from different scenes has no relation

> >>>>>>>>>>>> to each other. So if the individual captures that are part

> >>>>>>>>>>>> of a composed MCC come from different scenes (source

> >>>>>>>>>>>> captures

> >>>>>>>>>>>> multiple scenes, or source captures from different scenes

> >>>>>>>>>>>> than the

> >>>>>>>>>>>> 2.In the example with MaxCaptures = 2, that doesn't mean

> >>>>>>>>>>>> there will always be 2 contributing captures in the MCC. It

> >>>>>>>>>>>> just means maximum of 2, but sometimes there could be 1.

> >>>>>>>>>>>> The contents of the MCC could actually be changing over

> >>>>>>>>>>>> time between 1 and 2

> >>>>>>>>>>>> wouldn't always indicate the location of the source within

> >>>>>>>>>>>> the MCC. We have no

> >>>>>>>>>>>> captures, but maybe it is a large image of the one that is

> >>>>>>> talking

> >>>>>>>>>>>> and a small image of the other. This would change over

> >>>>>>>>>>>> time, so again the spatial information wouldn't always

> >>>>>>>>>>>> 4.Take a slightly different example, where the MCC contains

> >>>>>>>>>>>> 4 contributing individual captures, but still with

> >>>>>>>>>>>> MaxCaptures = 2.

> >>>>>>>>>>>> provider is free to choose which 2 out of the 4 to include

> >>>>>>>>>>>> at any time. So again the spatial information wouldn't

> >>>>>>>>>>>> always indicate the location of the source within the MCC.

> >>>>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> >>>>>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> >>>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Jan 2014 14:46:16 +1100

Hello Paul,

Please see below.

Regards, Christian

> the captures without encodings for an entirely different purpose.
[CNG] Its still spatial information of the captures in the scene so I 
can't see how its a "hack".

>
> And it doesn't work right if you want to have multiple MCCs that 
> compose the same sources differently. (Unless you introduce another 
> layer of indirection, such as you do in example below. Yet another hack.)
>
> the positions of the sources of a composition. (But used an obscure 
> and confusing notation.)
>
> That is just another step towards describing the complete layout of 
> the composition.
[CNG] I don't agree with that. I think that independent of any spatial 
arrangement its worthwhile for a Consumer to know whether its always 
going to receive the same number of sources (e.g.=) or whether it could 
get a changing number (e.g.<=).

>
> Lets first discuss if having this information would provide 
> significant value. If so then we can discuss how to provide it.
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>>
>>>>>>> important
>>>>>> and
>>>> see an
>>>> valid thing to
>>>> using a
>>>> less
>>>>>>>> have
>>>>>>>>>> Single
>>>>>>>>>> within
>>>>>>>>>>>> cases
>>>>>>>>>>>>> attribute
>>>>>>>>>>>>> than
>>>>>>>>>>>>> then the spatial information of one capture has no 
>>>>>>>>>>>>> relation to
>>>>>>>> the
>>>>>>>>
>>>>>>>>>>>>> there

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 28 Jan 2014 09:20:42 -0800

Mary and Paul, could you please let us know if consensus is reached on this topic?

At the interim meeting Jan 27, we reaffirmed the decision noted in Ticket #5<http://tools.ietf.org/wg/clue/trac/ticket/5>, meaning the group does not want to attempt to use CLUE to describe composed captures, particularly the layout of individual video images within a composed image.

I think Christian is still opposed to this outcome from the interim meeting.

Regards,
Mark
From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: Wednesday, January 22, 2014 7:16 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [clue] spatial information can't describe video locations within composed MCC

Hi Paul,

Mark

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jan 2014 10:06:33 +1100

Hello Mark,

I was simply replying to Paul. I wasn't seeking to over turn any 
decision on spatial parameters (not that I was aware of the outcome of 
the meeting).

An issue was brought up several times about the maxcaptures parameter 
meaning any number of sources up to a value and that this caused 
uncertainty to the consumer. This parameter is independent of any 
spatial parameters thus my reply to Paul. I was suggesting a 
modification by apply this parameter to say "=" in addition to "<=" to 
this to solve that problem. If the Advertiser is only going to send a 
MCC with a fixed number of captures then it seems to me that its 
semantically incorrect t =o imply less may be sent.

Regards, Christian

On 29/01/2014 4:20 AM, Duckworth, Mark wrote:
> At the interim meeting Jan 27, we reaffirmed the decision noted in 
> Ticket #5 <http://tools.ietf.org/wg/clue/trac/ticket/5>, meaning the 
> group does not want to attempt to use CLUE to describe composed 
> captures, particularly the layout of individual video images within a 
> composed image.
>
> *From:*clue [mailto:[email-masked]] *On Behalf Of *Duckworth, Mark
> *Sent:* Wednesday, January 22, 2014 7:16 PM
> *To:* Paul Kyzivat; [email-masked]
> *Subject:* Re: [clue] spatial information can't describe video 
> Paul wrote: "Lets first discuss if having this information would 
> provide significant value. If so then we can discuss how to provide it."
>
> Yes, but we already did that, and decided it isn’t valuable enough to 
> work on as part of CLUE. This was Ticket #5 
> <http://tools.ietf.org/wg/clue/trac/ticket/5>. I think we should stick 
> with that decision.
>
> Mark
>
> declaration of
> significant value. If
> > >>>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>
> > >>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>
> > >>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>