Subject: Re: [clue] Example of MCC

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 2 Oct 2013 09:38:10 -0700

Inline responses to Rob's and Christian's comments.
Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Monday, September 30, 2013 9:59 PM
> To: [email-masked]
> Subject: Re: [clue] Example of MCC
>
> Hello Rob,
>
> Please see my comments below.
>
> Regards, Christian
>
> On 1/10/2013 2:42 AM, Robert Hansen wrote:
> > Hi Mark, Christian,
> >
> > See inline
> >
> > On 27/09/2013 22:41, Christian Groves wrote:
> >> Hello Mark,
> >>
> >> Please see below.
> >>
> >> Regards, Christian
> >>
> >> On 28/09/2013 1:04 AM, Duckworth, Mark wrote:
> >>> 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?
> >
> > [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.
> [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.

[Duckworth, Mark] Sounds good to me.

> > [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.
> [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.

[Duckworth, Mark] I agree this should be a separate discussion topic.

> >>> 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.
> >> [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?

[Duckworth, Mark] I was not talking about a composed MCC.  I think you are saying in this example that MCC4 is the most active speaker, MCC5 is the next most active speaker, etc. and the MCU switches in the appropriate original VC to make this policy happen, is that right?  I'm thinking of the case where the MCU is switching multiple VCs from the same originating endpoint together, like the "site switch" policy we have talked about.  So maybe MCC4, MCC5, and MCC6 contain the three VCs from the active speaker that is in a three-camera room.  Then MCC7 contains the next most active speaker from another room, and MCC8-10 might be the third most active speaker from another three-camera room.  And this mapping of which MCCs are showing portions of the same room can change often.  I thought using multiple scenes with smaller CSEs could help simplify this, which you agreed with below, so I guess we should focus on that rather than this CapScene9 example which has a large CSE with 9 MCCs in it.  But Rob might disagree, so more questions below.

> > [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.
> [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.

[Duckworth, Mark] With the multiple scenes approach, I see the MCU trying to anticipate the consumer's rendering desire only at a very high level.  That is the MCU can provide small sets of captures in a CSE advertised by the MCU, while keeping VCs together in the same MCU CSE that originally come from the same scene from the original endpoint provider.

[Duckworth, Mark] Rob, are you suggesting a better approach is for the renderer to use just the spatial information of the original VCs, and not try to use MCU-generated spatial information about the MCCs?  Basically following the idea above - "The consumer should have enough information to do this if the MCU provides all the original spatial information from each endpoint in the advertisement"

> >>> 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.
> >
> > [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.
> [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)./"
> >
> >>>
> >>> 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?
> >> [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.
> >>>
> >>> Regards,
> >>> Mark
> >>>
> >>>> -----Original Message-----
> >>>> From: Christian Groves [mailto:[email-masked]]
> >>>> Sent: Thursday, September 26, 2013 9:43 PM
> >>>> To: Duckworth, Mark
> >>>> Cc: [email-masked]
> >>>> Subject: Re: Example of MCC
> >>>>
> >>>> Hello Mark,
> >>>>
> >>>> Please see my responses below.
> >>>>
> >>>> Regards, Christian
> >>>>
> >>>> On 27/09/2013 3:29 AM, Duckworth, Mark wrote:
> >>>>> 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.
> >>>> [CNG] Yes that's correct.
> >>>>> 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.
> >>>>
> >>>> 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){Max
> >>>> Captures: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)
> >>>>
> >>>>
> >>>>> 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){Max
> >>>> Captures:1}{Policy1}{Encodinggroup1}
> >>>>
> MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max
> >>>> Captures:1}{Policy1}{Encodinggroup2}
> >>>>
> MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max
> >>>> Captures:1}{Policy1}{Encodinggroup1}
> >>>>>     CSE9(MCC100,MCC101)
> >>>>>     CSE10(MCC102)
> >>>>> 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 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?
> >>>> [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 receiving all 9 MCCs?
> >>>> [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.
> >>>>> 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,
> >>>>>>
> >>>>>> 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
> >>> _______________________________________________
> >>> clue mailing list
> >>> [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
> >
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Thu, 03 Oct 2013 15:30:55 +1000

Hello
..snip..
> [Duckworth, Mark] I was not talking about a composed MCC.  I think you are saying in this example that MCC4 is the most active speaker, MCC5 is the next most active speaker, etc. and the MCU switches in the appropriate original VC to make this policy happen, is that right?
[CNG] Yes
>   I'm thinking of the case where the MCU is switching multiple VCs from the same originating endpoint together, like the "site switch" policy we have talked about.
[CNG] CapScene8 is an example of this.
> So maybe MCC4, MCC5, and MCC6 contain the three VCs from the active speaker that is in a three-camera room.
[CNG] You would could use the syntax of CapScene8 plus a policy 
"ActiveSpeaker".
> Then MCC7 contains the next most active speaker from another room, and MCC8-10 might be the third most active speaker from another three-camera room.  And this mapping of which MCCs are showing portions of the same room can change often.
[CNG] I'm not sure that we're on the same page here, is it something you 
could illustrate through example syntax?... Capture8 synchronises 
between MCC1, MCC2 and MCC3. If one of the single source capture sites 
(i.e.VC13,VC14,V15) become active this is shown as part of MCC2, the 
encoding of MCC1 and MCC3 would be blank.
> I thought using multiple scenes with smaller CSEs could help simplify this, which you agreed with below, so I guess we should focus on that rather than this CapScene9 example which has a large CSE with 9
>   MCCs in it.
[CNG] I agreed it would be possible to use multiple CSEs to illustrate 
different "scenes". Its possible to offer multiple smaller CSEs or large 
ones. I think it depends on what the MCU wants to express/provide.
>   But Rob might disagree, so more questions below.

> [Duckworth, Mark] With the multiple scenes approach, I see the MCU trying to anticipate the consumer's rendering desire only at a very high level.  That is the MCU can provide small sets of capture…
[CNG] I agree