Subject: [clue] Example of MCC

From: Christian Groves <[email-masked]>
Date: Wed, 18 Sep 2013 13:15:30 +1000

Hello Mark,

At yesterday's interim you asked if I could use the MCC concept 
(draft-groves-clue-multi-content-00) to support the example in your 
draft ( draft-duckworth-clue-switching-example-01). I assume that you 
were talking about the scenario in section 2.

I think it is worthwhile to consider the “Endpoint” advertisements also. 
>From a CLUE perspective how an endpoint chooses to render the received 
encodings is largely irrelevant as it is up to the local policy.

I would assume the source Advertisements would be something like:

Endpoint A - 4 screens, 3 cameras
Endpoint B - 3 screens, 3 cameras
Endpoint C - 3 screens, 3 cameras
Endpoint D - 3 screens, 3 cameras

Endpoints A-D:
CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)]

Endpoints E-G:
CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)]

Note: The endpoints would be likely to use the same IDs in their 
respective Advertisements.

Rather than considering what is displayed the MCC concepts concentrates 
more on what the MCU/Mixer sends. The mixer doesn’t know anything about 
the number of screens an endpoint has.

My assumption from the figures is that if the 3 main screens are “site” 
switching that there is one capture encoding/media stream for each. The 
MCU switches in the applicable media into the stream based on voice 
activity [policy1]. I assume endpoint A will not see a capture from 
itself. The descriptions are just for information.

Using the MCC concept the MCU would Advertise to endpoint A:
-----------------------------------------------------------

CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)]

CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)]

CapScene4[Description=Endpoint D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)]

CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)]

CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)]

CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)]

// The above part effectively is the same as the input advertisements. 
There are no capture encodings associated with them.

CapScene8[Description=Output3streammix,
MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1}
{Encodinggroup1}
MCC2(VC5,VC8,VC11,VC13,VC14,VC15)
{Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1}
{Encodinggroup2}
MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1}
{Encodinggroup3}
CSE8(MCC1,MCC2,MCC3)

// The above part describes the switched 3 main streams that relate to 
site switching. MaxCaptures:1 indicates that only one capture from the 
MCC is sent at a particular time. The default if it wasn't included is 1 
so it doesn't need to be sent but included for clarity. Sync-id:1 
indicates that the source sending is synchronised. Therefore when MCC2 
contains VC13,VC14,VC15 nothing will be sent in the other MCCs.

CapScene9[Description=Output9streams,
MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4}

MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5}

MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6}

MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7}

MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8}

MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9}

MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10}

MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11}

MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12}

CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}]

// The above part indicates that there are 9 capture encodings. Each of 
the capture encodings may contain any captures from any source site with 
a maximum of one capture at a time. Which capture is present is 
determined by Policy2.

If the MCU wanted to provide a composed capture encoding of the 9 
captures it could Advertise in addition:
CapScene10[Description=NineTiles,
MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,
VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13}
CSE(MCC13)
// As maxcaptures is 9 it indicates that the capture encoding contains 
information from up to 9 sources at a time.

[CNG] The above arrangement allows a Consumer to understand how the 
captures relate to the source sites. It means a Consumer can choose not 
to receive information from a particular source. This is not possible 
according to the “one big scene” approach below.

The Advertisement for Endpoint B in your draft would be identical to the 
above other than the captures from Endpoint A would be added and the 
captures from Endpoint B would be removed.

I hope this provides some clarification.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 26 Sep 2013 10:29:35 -0700

Hello Christian,

Thanks for the example, this is a good basis for discussion.

One new key concept here is that CapScene2 through CapScene7 include media captures that are not associated with any encoding group.  This indicates the consumer cannot ask for these captures directly in a configure message, because there is no way for the consumer to ask for a capture encoding of any of these captures directly.  I have considered this idea before, and it does seem useful.  This MCC example is taking this approach with the MCU advertising all the other endpoints' captures, to give information about them, but not for directly putting into capture encodings sent from the MCU.

However, there could be issues in scaling to large conferences.  Here are two points from draft-duckworth-clue-switching-example-01 (originally from draft-hansen-clue-consumer-layout):

1. The mixer could advertise all the other endpoint's captures, but as the size of the conference increases the number of captures that must be advertised will quickly become impractical.
2. If the renderer had all the spatial information about all possible original source captures it might receive, it would enable correct spatial rendering. But as the number of captures per endpoint and the number of endpoints in a conference rise caching all the data becomes impractical.

I'm not sure what the practical limit on conference size would be.  Maybe there are reasonable ways to do this in large conferences.  This needs further thought.

CapScene8 below is essentially the same idea as the "advertising multiple scenes" example in draft-duckworth-clue-switching-example-01, section 3.2.  CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft.  I assume CapScene8 would include spatial information for MCC1, MCC2, and MCC3.  And also I suggest CapScene8 could include other CSEs with fewer captures, such as:
  MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1}
  MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup2}
  MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1}
  CSE9(MCC100,MCC101)
  CSE10(MCC102)
These CSEs would be useful for one or two screen consumers.

I have questions about how to use CapScene9 in the example below.  Would MCC4 through MCC12 have any spatial information?  If so, what would it be?  Or does the consumer rely solely on the spatial information of VC4 through VC15, along with some way of knowing which specific VC it is receiving (within an MCC encoding) at any given time?

Would CapScene9 also include other CSEs with fewer  media captures in them, indicating a consumer could choose fewer media captures and still get a "representation of the whole scene" without receiving all 9 MCCs?

Regards,
Mark

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2013 11:16 PM
> To: Duckworth, Mark; [email-masked]
> Subject: Example of MCC
> 
> Hello Mark,
> 
> (draft-groves-clue-multi-content-00) to support the example in your draft (
> draft-duckworth-clue-switching-example-01). I assume that you were talking
> about the scenario in section 2.
> 
> I think it is worthwhile to consider the "Endpoint" advertisements also.
> Note: The endpoints would be likely to use the same IDs in their respective
> Advertisements.
> 
> more on what the MCU/Mixer sends. The mixer doesn't know anything
> about the number of screens an endpoint has.
> 
> My assumption from the figures is that if the 3 main screens are "site"
> MCU switches in the applicable media into the stream based on voice activity
> [policy1]. I assume endpoint A will not see a capture from itself. The
> descriptions are just for information.
> 
> // The above part describes the switched 3 main streams that relate to site
> switching. MaxCaptures:1 indicates that only one capture from the MCC is
> sent at a particular time. The default if it wasn't included is 1 so it doesn't
> need to be sent but included for clarity. Sync-id:1 indicates that the source
> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15
> nothing will be sent in the other MCCs.
> 
> // The above part indicates that there are 9 capture encodings. Each of the
> capture encodings may contain any captures from any source site with a
> maximum of one capture at a time. Which capture is present is determined
> by Policy2.
> 
> captures relate to the source sites. It means a Consumer can choose not to
> receive information from a particular source. This is not possible according to
> the "one big scene" approach below.
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Sep 2013 11:43:03 +1000

Hello Mark,

Please see my responses below.

Regards, Christian

> One new key concept here is that CapScene2 through CapScene7 include media captures that are not associated with any encoding group.  This indicates the consumer cannot ask for these captures direc…
[CNG] Yes that's correct.
> 2. If the renderer had all the spatial information about all possible original source captures it might receive, it would enable correct spatial rendering. But as the number of captures per endpoin…
[CNG] I think the above are just a natural consequence that as the 
number of endpoints increase so will the amount of information that 
needs to be signalled. I think the key point is that with the MCC 
concept the MCU has to choice to provide as much or as little 
information as it wants. It doesn't have to pass on all the information 
that it receives in the source captures, it can filter or manipulate the 
information as it sees fit.

With regards to the 2nd point the MCC concept allows the MCU to provide 
"harmonised" spatial information regarding the MCC which means the a 
Consumer could use this information rather than source spatial 
information if conference size becomes a problem.
> I'm not sure what the practical limit on conference size would be.  Maybe there are reasonable ways to do this in large conferences.  This needs further thought.
[CNG] I don't see that CLUE needs to place any limits on the conference 
size. I think its largely an endpoint decision on the amount of 
information it wants to provide. I think there are potential 
optimisation we can do in the coding of CLUE that will minimise the size 
of messages. For example introducing a "range" concept to CSEs/MCCs/STSs 
that could allow to specify a group of captures without specifying every 
one.

MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1}
could be signalled as:
MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1}

Likewise a CSE for CaptureScene9
CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12)
could be signalled as:
CSE(MCC4-MCC12)

> These CSEs would be useful for one or two screen consumers.
[CNG] Yes multiple Capture Scenes are used so this aspect parallels 
section 3.2 in your draft. Yes I agree that Capture8 could include CSEs 
with fewer captures as you suggest.

> I have questions about how to use CapScene9 in the example below.  Would MCC4 through MCC12 have any spatial information?  If so, what would it be?  Or does the consumer rely solely on the spatial…
[CNG] Potentially MCC4 through MCC12 could have spatial information. An 
advertiser could supply the same "virtual" capture area on each MCC 
(i.e. a MCU may do some image processing to ensure they captures are the 
same size) that way the consumer knows the MCCs are the same size. 
Alternatively the MCC could change the location of the capture areas in 
virtual space to suggest some sort of layout to a consumer. The 3rd 
option is not to send spatial information. The above would be the 
switching case.

In a composition case the Advertiser could provide a "harmonised" 
virtual capture area on the MCC and it could provide capture area 
information on the individual VCs to give their layout in the 
"harmonised" capture area.

> Would CapScene9 also include other CSEs with fewer  media captures in them, indicating a consumer could choose fewer media captures and still get a "representation of the whole scene" without recei…
[CNG] CapScene9 could include CSEs with fewer captures. It would come 
down to whether the Advertiser considers MCC4-MCC12 (or a subset of) as 
representations of the overall scene or just as individual supplementary 
streams.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 27 Sep 2013 08:04:14 -0700

Hi Christian,

I agree the MCU provider can choose to provide as much or as little information as it wants.  And I agree there could be optimizations to reduce CLUE message sizes.  Given this, maybe it is enough to address the concerns about scaling to large conferences?  What do others think?

About CapScene9, I have more questions.  You suggested the MCU could do some image processing to ensure captures are the same size, and indicate this by using the same virtual area of capture for each of the MCCs.  I agree, but I was not too concerned about the relative sizes of the captures from different endpoints.  I am more concerned about the spatial relationship between captures from the same endpoint in terms of how to order them next to each other for proper rendering.  The consumer should have enough information to do this if the MCU provides all the original spatial information from each endpoint in the advertisement, do you agree?

One downside to this approach is that every change the MCU makes in how it assigns contributing VCs to an MCC (e.g. make a switch based on current talker) could result in the consumer renderer needing to change how it maps decoder output to display locations.  I need to think more about if this would really be a problem or not.  In my example (section 3.2 of my draft) I attempted to address this by using multiple scenes, where each scene had fewer VCs (these could become MCCs) in each CSE, with some spatial information the MCU would adhere to when switching.  I'm still leaning toward this multiple scene idea.  I think combining it with the MCC concept will be an improvement.

Still about CapScene9, you wrote "the MCC could change the location of the capture areas in virtual space to suggest some sort of layout to a consumer. The 3rd option is not to send spatial information."  I don't understand what you mean, could you expand on this please?

Regards,
Mark

> Sent: Thursday, September 26, 2013 9:43 PM
> To: Duckworth, Mark
> Cc: [email-masked]
> Subject: Re: Example of MCC
> 
> Hello Mark,
> 
> > One new key concept here is that CapScene2 through CapScene7 include
> media captures that are not associated with any encoding group.  This
> indicates the consumer cannot ask for these captures directly in a configure
> message, because there is no way for the consumer to ask for a capture
> encoding of any of these captures directly.  I have considered this idea
> before, and it does seem useful.  This MCC example is taking this approach
> with the MCU advertising all the other endpoints' captures, to give
> information about them, but not for directly putting into capture encodings
> sent from the MCU.
> > However, there could be issues in scaling to large conferences.  Here are
> two points from draft-duckworth-clue-switching-example-01 (originally from
> draft-hansen-clue-consumer-layout):
> >
> > 1. The mixer could advertise all the other endpoint's captures, but as the
> size of the conference increases the number of captures that must be
> advertised will quickly become impractical.
> > 2. If the renderer had all the spatial information about all possible original
> source captures it might receive, it would enable correct spatial rendering.
> But as the number of captures per endpoint and the number of endpoints in
> a conference rise caching all the data becomes impractical.
> [CNG] I think the above are just a natural consequence that as the number of
> endpoints increase so will the amount of information that needs to be
> signalled. I think the key point is that with the MCC concept the MCU has to
> choice to provide as much or as little information as it wants. It doesn't have
> to pass on all the information that it receives in the source captures, it can
> filter or manipulate the information as it sees fit.
> 
> Consumer could use this information rather than source spatial information if
> conference size becomes a problem.
> >
> > I'm not sure what the practical limit on conference size would be.  Maybe
> there are reasonable ways to do this in large conferences.  This needs further
> thought.
> [CNG] I don't see that CLUE needs to place any limits on the conference size.
> I think its largely an endpoint decision on the amount of information it wants
> to provide. I think there are potential optimisation we can do in the coding of
> CLUE that will minimise the size of messages. For example introducing a
> "range" concept to CSEs/MCCs/STSs that could allow to specify a group of
> captures without specifying every one.
> 
> > CapScene8 below is essentially the same idea as the "advertising multiple
> scenes" example in draft-duckworth-clue-switching-example-01, section 3.2.
> CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft.  I assume
> CapScene8 would include spatial information for MCC1, MCC2, and MCC3.
> And also I suggest CapScene8 could include other CSEs with fewer captures,
> such as:
> >
> [CNG] Yes multiple Capture Scenes are used so this aspect parallels section
> 3.2 in your draft. Yes I agree that Capture8 could include CSEs with fewer
> captures as you suggest.
> 
> >
> > I have questions about how to use CapScene9 in the example below.
> Would MCC4 through MCC12 have any spatial information?  If so, what would
> it be?  Or does the consumer rely solely on the spatial information of VC4
> through VC15, along with some way of knowing which specific VC it is
> receiving (within an MCC encoding) at any given time?
> > Would CapScene9 also include other CSEs with fewer  media captures in
> them, indicating a consumer could choose fewer media captures and still get
> a "representation of the whole scene" without receiving all 9 MCCs?
> activity
> site
> the
> to

---

From: Christian Groves <[email-masked]>
Date: Sat, 28 Sep 2013 07:41:57 +1000

Hello Mark,

Please see below.

Regards, Christian

> About CapScene9, I have more questions.  You suggested the MCU could do some image processing to ensure captures are the same size, and indicate this by using the same virtual area of capture for e…
[CNG]Yes I agree.
>
> One downside to this approach is that every change the MCU makes in how it assigns contributing VCs to an MCC (e.g. make a switch based on current talker) could result in the consumer renderer needing to change how it maps decoder output to display locations.  I need to think more about if this would really be a problem or not.
[CNG] For this switching case I would think that a consumer would use 
the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would 
always present the active speaker from the list of VC using the same 
co-ordinates. Or are you talking about switching the positions in a 
composed MCC?

> In my example (section 3.2 of my draft) I attempted to address this by using multiple scenes, where each scene had fewer VCs (these could become MCCs) in each CSE, with some spatial information the MCU would adhere to when switching.  I'm still leaning toward this multiple scene idea.  I think combining it with the MCC concept will be an improvement.
[CNG] I think the multiple scenes is the way to go.
> Still about CapScene9, you wrote "the MCC could change the location of the capture areas in virtual space to suggest some sort of layout to a consumer. The 3rd option is not to send spatial informa…
[CNG] The first part of the sentence refers to be capability to order 
them next to each other as you mention above. The 3rd option is to only 
send spatial information related to the MCC and not the VCs. In that 
case the consumer only knows the overall capture area of the MCC not the 
spatial area of the components.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Robert Hansen <[email-masked]>
Date: Mon, 30 Sep 2013 17:42:42 +0100

Hi Mark, Christian,

See inline

On 27/09/2013 22:41, Christian Groves wrote:
>> I agree the MCU provider can choose to provide as much or as little
>> information as it wants.  And I agree there could be optimizations to
>> reduce CLUE message sizes.  Given this, maybe it is enough to address
>> the concerns about scaling to large conferences?  What do others think?

[RH] I think so long as the provider isn't *required* to provide a 
capture corresponding to every participant in the conference then 
message sizing is much less of an issue, as it allows the MCU to make 
sensible choices about how much information to pass on.

[RH] I do think that if we adopt this approach it'll necessitate 
switching to a model where new advertisment messages are deltas of the 
previous, as opposed to complete refreshes (a la RFC 4575's partial/full 
update mechanism), so that if the MCU does want to send all participant 
capture information in a particularly large conference it has a 
mechanism for doing so without being required to send a vast XML 
document every time anyone leaves or joins.

>> About CapScene9, I have more questions.  You suggested the MCU could
>> do some image processing to ensure captures are the same size, and
>> indicate this by using the same virtual area of capture for each of
>> the MCCs.  I agree, but I was not too concerned about the relative
>> sizes of the captures from different endpoints.  I am more concerned
>> about the spatial relationship between captures from the same endpoint
>> in terms of how to order them next to each other for proper
>> rendering.  The consumer should have enough information to do this if
>> the MCU provides all the original spatial information from each
>> endpoint in the advertisement, do you agree?
> [CNG]Yes I agree.
>>
>> One downside to this approach is that every change the MCU makes in
>> how it assigns contributing VCs to an MCC (e.g. make a switch based on
>> current talker) could result in the consumer renderer needing to
>> change how it maps decoder output to display locations.  I need to
>> think more about if this would really be a problem or not.

[RH] My issue with using the spatial coordinates of the MCC is that it 
requires the MCU to anticipate the rendering desires of the endpoint, as 
the MCU will need to advertise MCCs with spatial coordinates that allow 
the endpoint to do what it wants to do. My concern has always been that 
this may lead to huge numbers of MCCs and capture scene entries if the 
MCU is trying to anticipate potential layouts by the endpoint.

>> In my example (section 3.2 of my draft) I attempted to address this by
>> using multiple scenes, where each scene had fewer VCs (these could
>> become MCCs) in each CSE, with some spatial information the MCU would
>> adhere to when switching.  I'm still leaning toward this multiple
>> scene idea.  I think combining it with the MCC concept will be an
>> improvement.

[RH] In terms of our definition of 'scene' it makes sense for the 
originating VCs to be seperate scenes (since in reality they are indeed 
seperate rooms), but as far as our current syntax goes then there is an 
issue with the fact that MCCs would want to reference VCs from different 
scenes.

>>
>> Still about CapScene9, you wrote "the MCC could change the location of
>> the capture areas in virtual space to suggest some sort of layout to a
>> consumer. The 3rd option is not to send spatial information."  I don't
>> understand what you mean, could you expand on this please?
>>> number of
>>> section
>>>>> draft
>>> (
>>>>> receive information from a particular source. This is not possible
>>>>> according
>>> to

---

From: Christian Groves <[email-masked]>
Date: Tue, 01 Oct 2013 11:59:12 +1000

Hello Rob,

Please see my comments below.

Regards, Christian

> sensible choices about how much information to pass on.
[CNG] No intention to require the provider to provide a capture 
corresponding to every participant. The intention is to have one 
mechanism to allow both simple and complex scenarios.
> previous, as opposed to complete refreshes (a la RFC 4575's 
> partial/full update mechanism), so that if the MCU does want to send 
> all participant capture information in a particularly large conference 
> it has a mechanism for doing so without being required to send a vast 
> XML document every time anyone leaves or joins.
[CNG] What do you see as the message size threshold to take us from a 
complete refresh approach to a delta approach? Perhaps we should start 
another thread on this topic? It was mentioned at the virtual interim 
that we'll go with the complete refresh approach but I think that was 
partially due to that it hasn't received any real discussion.

> requires the MCU to anticipate the rendering desires of the endpoint, 
> as the MCU will need to advertise MCCs with spatial coordinates that 
> allow the endpoint to do what it wants to do. My concern has always 
> been that this may lead to huge numbers of MCCs and capture scene 
> entries if the MCU is trying to anticipate potential layouts by the 
> endpoint.
[CNG] A consumer can choose to render how it sees fit. The spatial 
information is a guide. If the MCU advertises a switched MCC showing the 
most active speaker in the left position and a MCC showing the second 
most active speaker in the right position there's nothing stopping the 
consumer from swapping the positions when rendering. I don't think its 
up to an Advertiser to provide every conceivable spatial layout.
> originating VCs to be seperate scenes (since in reality they are 
> indeed seperate rooms), but as far as our current syntax goes then 
> there is an issue with the fact that MCCs would want to reference VCs 
> from different scenes.
[CNG] Yes I agree, this is detailed in my draft, sect 3.1.2 "/Note: 
Section 6.1/[I-D.ietf-clue-framework] indicates that "A Media Capture is 
associated with exactly one Capture Scene".  For MCC this could be 
further clarified to indicate that "A Media Capture is defined in a 
capture scene and is given an advertisement unique identity.  The 
identity may be referenced outside the Capture Scene//
// that defines it through a multiple content capture (MCC)./"