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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 14:41:48 -0500

On 1/28/14 6:06 PM, Christian Groves wrote:
> 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.

I'm still not entirely clear what this means.

IIUC, the intent is that if the MCC has N sources, and maxcaptures (or 
number-of-captures) is M, then:
- if N>1 and M=1 then this is a "switched" capture
- if N>1 and M=N then this is a "composed" capture

But - that doesn't say anything about 1<M<N, and it doesn't deal with 
the cases where there are combinations of switching and composition. And 
of course it also doesn't deal with composition where some images are 
smaller than others, and overlapping that hides parts of some captures. 
It also doesn't deal with what will happen if the Configure selects a 
subset of the sources in the MCC.

I see no way to deal with that with a single number. And I don't see any 
compelling reason to do so.

The "switched" and "composed" attributes cover the two extremes, and 
also indicate (when both or neither are specified) that the situation is 
something other than one of the extremes. Does having a number improve 
on that?

	Thanks,
	Paul

> Regards, Christian
>
> On 29/01/2014 4:20 AM, Duckworth, Mark wrote:
>>
>> 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,
>>
>> 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
>>
>> > -----Original Message-----
>>
>> > From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>>
>> > Sent: Wednesday, January 22, 2014 1:33 PM
>>
>> > To: [email-masked]
>>
>> > Subject: Re: [clue] spatial information can't describe video
>> locations within
>>
>> > composed MCC
>>
>> >
>>
>> > On 1/21/14 6:39 PM, Christian Groves wrote:
>>
>> > > 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.
>>
>> >
>>
>> > 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.)
>>
>> >
>>
>> > > 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 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?
>>
>> >
>>
>> > > 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.
>>
>> >
>>
>> > 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
>>
>> >
>>
>> > > Regards, Christian
>>
>> > >
>>
>> > >
>>
>> > > On 21/01/2014 11:54 PM, Duckworth, Mark wrote:
>>
>> > >> 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
>>
>> > >>
>>
>> > >>> -----Original Message-----
>>
>> > >>> From: clue [mailto:[email-masked]] On Behalf Of Christian
>>
>> > >>> Groves
>>
>> > >>> Sent: Monday, January 20, 2014 6:02 PM
>>
>> > >>> To: [email-masked]
>>
>> > >>> Subject: Re: [clue] spatial information can't describe video
>>
>> > >>> locations within composed MCC
>>
>> > >>>
>>
>> > >>> Hello Mark and Paul,
>>
>> > >>>
>>
>> > >>> Please see my responses below.
>>
>> > >>>
>>
>> > >>> Regards, Christian
>>
>> > >>>
>>
>> > >>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote:
>>
>> > >>>> 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.
>>
>> > >>> [CNG] The consumer knows this because the Provider only provides
>> the
>>
>> > >>> spatial information when it makes sense to do so.
>>
>> > >>>
>>
>> > >>>> Mark
>>
>> > >>>>
>>
>> > >>>>> -----Original Message-----
>>
>> > >>>>> From: clue [mailto:[email-masked]] On Behalf Of Paul
>>
>> > >>>>> Kyzivat
>>
>> > >>>>> Sent: Monday, January 20, 2014 12:44 PM
>>
>> > >>>>> To: [email-masked]
>>
>> > >>>>> Subject: Re: [clue] spatial information can't describe video
>>
>> > >>>>> locations within composed MCC
>>
>> > >>>>>
>>
>> > >>>>> On 1/19/14 9:36 PM, Christian Groves wrote:
>>
>> > >>>>>> 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.
>>
>> > >>>>> Yes, we had that in mind when discussing this.
>>
>> > >>>>>
>>
>> > >>>>>> 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.
>>
>> > >>>>> 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.
>>
>> > >>> [CNG] Yes
>>
>> > >>>>> 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.
>>
>> > >>> 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.
>>
>> > >>>>> So we need more info to understand your perspective on this.
>>
>> > >>>>>
>>
>> > >>>>>> 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.
>>
>> > >>>>> 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.
>>
>> > >>> [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
>>
>> > >>>>> 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.
>>
>> > >>> [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 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
>>
>> > >>>>>>
>>
>> > >>>>>> 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
>>
>> > >>>>>>>
>>
>> > >>>>>>>> -----Original Message-----
>>
>> > >>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of
>>
>> > >>>>>>>> Duckworth, Mark
>>
>> > >>>>>>>> Sent: Friday, January 10, 2014 4:04 PM
>>
>> > >>>>>>>> To: Christian Groves; [email-masked]
>>
>> > >>>>>>>> Subject: Re: [clue] spatial information can't describe video
>>
>> > >>>>>>> locations within
>>
>> > >>>>>>>
>>
>> > >>>>>>>> composed MCC
>>
>> > >>>>>>>> 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
>>
>> > >>>>>>>>> -----Original Message-----
>>
>> > >>>>>>>>> From: Christian Groves [mailto:[email-masked]]
>>
>> > >>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM
>>
>> > >>>>>>>>> To: Duckworth, Mark; [email-masked]
>>
>> > >>>>>>>>> Subject: Re: [clue] spatial information can't describe video
>>
>> > >>>>>>> locations
>>
>> > >>>>>>>
>>
>> > >>>>>>>>> within composed MCC
>>
>> > >>>>>>>>> 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
>>
>> > >>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote:
>>
>> > >>>>>>>>>> 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.
>>
>> > >>>>>>>>>>> +-----------------------+---------------------------------+
>>
>> > >>>>>>>>>>> | 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.
>>
>> > >>>>>>>>>>>> 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
>>
>> > >>>>>>>>>>>>
>>
>> > _______________________________________________
>>
>> > >>>>>>>>>>>> clue mailing list
>>
>> > >>>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked]>
>>
>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>>>>>>>> _______________________________________________
>>
>> > >>>>>>>>>>> clue mailing list
>>
>> > >>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>
>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>>>>> _______________________________________________
>>
>> > >>>>>>>> clue mailing list
>>
>> > >>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>
>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>>>>
>>
>> > >>>>>>> _______________________________________________
>>
>> > >>>>>>> clue mailing list
>>
>> > >>>>>>> [email-masked] <mailto:[email-masked]>
>>
>> > >>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>>> _______________________________________________
>>
>> > >>>>>> clue mailing list
>>
>> > >>>>>> [email-masked] <mailto:[email-masked]>
>>
>> > >>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>>>
>>
>> > >>>>> _______________________________________________
>>
>> > >>>>> clue mailing list
>>
>> > >>>>> [email-masked] <mailto:[email-masked]>
>>
>> > >>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>> _______________________________________________
>>
>> > >>>> clue mailing list
>>
>> > >>>> [email-masked] <mailto:[email-masked]>
>>
>> > >>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >>>>
>>
>> > >>> _______________________________________________
>>
>> > >>> clue mailing list
>>
>> > >>> [email-masked] <mailto:[email-masked]>
>>
>> > >>> https://www.ietf.org/mailman/listinfo/clue
>>
>> > >
>>
>> > > _______________________________________________
>>
>> > > clue mailing list
>>
>> > > [email-masked] <mailto:[email-masked]>
>>
>> > > https://www.ietf.org/mailman/listinfo/clue
>>
>> > >
>>
>> >
>>
>> > _______________________________________________
>>
>> > clue mailing list
>>
>> > [email-masked] <mailto:[email-masked]>
>>
>> > https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 5 Feb 2014 14:21:24 -0800

I too am confused about Christian's suggestion for changing or clarifying the maxcaptures attribute.
Christian, can you explain again please?
For now, I think I agree with Paul that there is no reason to change the current description of maxcaptures.

Mark

> Sent: Wednesday, February 05, 2014 2:42 PM
> To: [email-masked]
> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe
> video locations within composed MCC
>
> But - that doesn't say anything about 1<M<N, and it doesn't deal with the
> cases where there are combinations of switching and composition. And of
> course it also doesn't deal with composition where some images are smaller
> than others, and overlapping that hides parts of some captures.
> It also doesn't deal with what will happen if the Configure selects a subset of
> the sources in the MCC.
>
> The "switched" and "composed" attributes cover the two extremes, and also
> indicate (when both or neither are specified) that the situation is something
> other than one of the extremes. Does having a number improve on that?
>
>       Thanks,
>       Paul
>
> > Regards, Christian
> >
> >> Mary and Paul, could you please let us know if consensus is reached
> >> on this topic?
> >>
> >> Yes, but we already did that, and decided it isn't valuable enough to
> >> <http://tools.ietf.org/wg/clue/trac/ticket/5>. I think we should
> >> stick with that decision.
> >>
> >> Mark
> >>
> >> > >>> Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 11:19:36 +1100

Hello Paul and Mark,

The Max-captures attributes currently indicates the maximum number of 
captures that appears in a MCC at any particular point in time.

i.e. MCC(VC1,VC2,VC3),MaxCaptures=3
So a Consumer has to assume because this is a maximum that VC1, VC2, 
VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3)
or (VC1,VC2,VC3) can appear at any point in time.

However the Consumer only ever sends a composition of (VC1,VC2,VC3). It 
is never going to change that combination. It seems to me that in this 
case using MaxCaptures as it is currently defined is semantically 
incorrect.

So what I am suggesting is simply to add a way to correctly indicate 
this "constant number of captures" case, i.e. (VC1,VC2,VC3).

I think Paul is questioning the attribute in general. I do believe that 
knowing the number of sources may be beneficial for a consumer in 
deciding which MCC/Captures to select. There may be tradeoffs vs a MCC 
only showing a limited number (i.e. one source) at a time vs another MCC 
showing multiple sources at a time.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 11:59:11 -0500

> this "constant number of captures" case, i.e. (VC1,VC2,VC3).

So what would happen if the advertisement was: 
MCC(VC1,VC2,VC3),NumCaptures=3
but the Configure requested MCC(V1,V2)?

Since there are now only two captures to send, the NumCaptures is 
violated. Also, what if the intent is to compose three captures from the 
currently most active site, but not all the sites have three sources. 
Then again, sometimes there will less than three captures composed.

I was thinking that the point of MaxCaptures vs. NumCaptures was to 
cover those sorts of cases.

> showing multiple sources at a time.

Originally I thought the intent was that MaxCaptures would replace the 
"switched" and "composed" attributes. It could approximate those:
- if maxcaptures = 1 and #sources > 1 then "switched"
- if maxcaptures = #sources and #sources > 1 then "composed".

In other cases, comparing MaxCaptures to the #sources can make it clear 
that something else is going on. But I think it is insufficient to 
understand *what* is going on in sufficient detail to make much of a 
judgement about which to choose. I suspect that either this wouldn't be 
used, or it would be used together with some extra "knowledge" about how 
the advertiser does things. That would be bad for interoperability.

ISTM that the "switched" and "composed" attributes will provide as much 
as we can reasonably promise in an interoperable way. If we want to do 
more in the future, we could consider doing detailed layouts. But I 
don't want to do that now.

	Thanks,
	Paul

>>> also

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Feb 2014 11:57:23 +1100

Hello Paul,

Please see below.

Regards, Christian

On 7/02/2014 3:59 AM, Paul Kyzivat wrote:
> violated. Also, what if the intent is to compose three captures from 
> the currently most active site, but not all the sites have three 
> sources. Then again, sometimes there will less than three captures 
> composed.
>

[CNG] I wasn't planning a new attribute for this. Simply to update the 
syntax of MaxCaptures to indicate "equal to" or "equal to and less 
than". So this would avoid any conflict between two attributes.

With regards to a configure requesting a sub-set I think we have some 
flexibility in what procedure we implement here. We could have the rule 
that if MaxCapture uses "equal to" that it means that a Consumer can't 
choose a sub-set. Or we could leave the rule as it is today. I think the 
former is probably better as it would give a means to the Advertiser to 
indicate "don't choose a subset".

> - if maxcaptures = #sources and #sources > 1 then "composed".
[CNG] Yes the idea was to replace these two tags with something that 
could be simply or as powerful as you want it.
>
> In other cases, comparing MaxCaptures to the #sources can make it 
> clear that something else is going on. But I think it is insufficient 
> to understand *what* is going on in sufficient detail to make much of 
> a judgement about which to choose. I suspect that either this wouldn't 
> be used, or it would be used together with some extra "knowledge" 
> about how the advertiser does things. That would be bad for 
> interoperability.

> ISTM that the "switched" and "composed" attributes will provide as 
> much as we can reasonably promise in an interoperable way. If we want 
> to do more in the future, we could consider doing detailed layouts. 
> But I don't want to do that now.
[CNG] I don't agree. Having MaxCaptures is a part of the MCC mechanism. 
I see there is benefit in giving the Advertiser and the Consumer the 
means of knowing how many captures will appear in the stream at a time. 
It gives the ability for the Consumer to distinguish between MCCs.
e.g. MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2
      MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4
      MCC3(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=8
If I say:
     MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed
      MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed
      MCC3(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed
How do I distinguish between MCC1, MCC2 or MCC3 in this case? I can't 
use the spatial information because we've disallowed that.