Subject: Re: [clue] MCC with CSE

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Oct 2013 08:08:58 +0000

Hi,

>>>I had the same reaction as Mark, if the consumer doesn't want to know 
>>>about the sources then the MCU could simply just advertise a VC 
>>>(main, slide) to represent the single stream from each site.
>>>
>>>A minimal implementation for switching could just specify 
>>>MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker. This 
>>>would say the capture is a switched capture showing one capture at a 
>>>time based on who is the active speaker, that is main and slides.
>>
>> Correct.
>>
>>
>>>If you did want the whole source information in this case you are 
>>>doing composition and switching so multiple MCCs would be needed.
>>>
>>>E.g. CaptureScene1 VC1(Main),VC2(Slides) 
>>>MCC1(VC1,VC2,Maxcaptures=2(i.e. composed)
>>>CaptureScene2 VC3(Main),VC4(Slides)
>>>MCC2(VC3,VC4,Maxcaptures=2(i.e. composed)
>>>CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=1 (i.e. 
>>>switched),Policy=active speaker),encodinggroup
>>
>> I don't necessarily want the source information. But, I may want to 
>> know e.g. which sites are used to compose the MCC content. But, maybe 
>> such "metadata" can be provided using some composed attribute, or 
>> something?
>>
>[CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right.
>To capture the metadata for each "site" in an MCC:
>
>CaptureScene1(Description=SiteA,VC1)
>CaptureScene2(Description=SiteB,VC2)
>CaptrueScene3(Description=SiteC,VC3)
>etc.
>MCC(VC1,VC2,VC3,etc.)

That works fine if the MCU always uses the same VC of each site to create the MCC. 

But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site.

So, again, I am not really interested in which VC of each site is used to create the MCC, I am only interested to know that it represents the active speaker, and/or the slides, etc.

Maybe something like:

CaptureSceneMCU(Description=SiteA,SiteB,SiteC, MCC1)
MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker

Regards,

Christer

Because each of the VCs is in it's own CaptureScene this allows site level metadata to be communicated to the consumer.The MCU may have received wildly different Advertisements from each of those sites. e.g. 
those advertisements could have 10s of captures. The MCU has decided only to send very basic information to the consumer as to the sources of the MCC.

> Also, I assume that an MCC doesn't necessarily have to be generated by 
> an MCU. An endpoint could also advertise an MCC, e.g. the one in my 
> example with main and slide.
>
> Regards,
>
> Christer
>
>
>
>
> On 28/09/2013 1:30 AM, Christer Holmberg wrote:
> >
> > Hi Mark,
> >
> > Se comments inline.
> >
> > The currently proposal works when the content of an MCC is one or 
> > more individual VCs, which the receiver can choose. That works fine 
> > when the MCU does switching.
> >
> > But, in my opinion it does not work for composed MCCs, where the 
> > content of the MCC can be built based on multiple
> >
> > Take an example:
> >
> > - in a conference, each site provides a CSE which contains two VCs:
> > one with main video, and one with slides/screen sharing.
> >
> > - the MCU wants to provide, at any given time, one of these CSEs 
> > (the selection might be based on active speaker, or whatever) is a 
> > single stream towards an endpoint. So, it advertises an "main-slide 
> > CSE from the site with the active speaker site" MCC.
> >
> > Now, I don't want the receiver to receive all the VCs, from the 
> > different sites, and try to figure out which belong toghether etc.
> > And, the more VCs an CSE consist of, the more complicated it gets.
> >
> > *//*
> >
> > */[Duckworth, Mark] If the MCU does not want to advertise anything 
> > about the other endpoint's VCs, then what is the point of using an 
> > MCC at all? In this case, the MCU should simply advertise a composed 
> > VC./*
> >
> > *//*
> >
> > */[Christer] Sure, the MCU could do that. /*
> >
> > *//*
> >
> > */However, there are more to sites than the VCs. For example, I may 
> > want to advertise which sites are used to compose the MCC content.
> > (however, CSE may not be the best way to do that)./*
> >
> > *//*
> >
> > */Also, perhaps the MCU wants to advertise what type of video (e.g.
> > main and slide) the VC is composed of. I guess I could do something 
> > like MCC(MCC_Main, MCC_Slide), or something like that.../*
> >
> > *//*
> >
> > */Regards,/*
> >
> > *//*
> >
> > */Christer/*
> >
> > *//*
> >
> > Now, having said that, I DO agree that we should try to keep the 
> > "hiearchy".
> >
> > So, in this case, maybe we should introduce a Mixed CSE (MCSE) 
> > concept. The MCU could then offer a "most active site" MCSE, in 
> > which it lists the MCC. Something like: MCSE1(MCC1{Policy
> > SceneWithTheActiveSpeaker})
> >
> > Regards,
> >
> > Christer
> >
> > --------------------------------------------------------------------
> > ----
> >
> > *From:[email-masked] [[email-masked]] on behalf of 
> > Christian Groves [[email-masked]]
> > *Sent:* Friday, 27 September 2013 3:57 AM
> > *To:* [email-masked]
> > *Subject:* Re: [clue] MCC with CSE
> >
> > Hello Christer,
> >
> > I had considered this issue when putting together the proposal and 
> > decided that a CSE should be in a MCC. The idea behind the MCC was 
> > that it was a capture. Captures go in CSEs not the other way around. 
> > As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e.
> > CS,CSE,MCC,CSE.
> >
> > Also CSEs have a certain semantic that is that all the captures in 
> > the CSE make up one representation of a scene. It shouldn't be seen 
> > (pardon the pun) that CSEs is a syntax shorthand. I think there are 
> > other options for minimising message size.
> >
> > Regards, Christian
> >
> > On 27/09/2013 6:13 AM, Christer Holmberg wrote:
> > >
> > > Hi,
> > >
> > > It's up to the advertiser to make sure it doesn't advertise things 
> > > that it can't provide.
> > >
> > > The MCU may request a specific CSE from an endpoint, and then 
> > > advertise that as a composed MCC to another endpoint. I don't see 
> > > why the MCU should have to advertise the VCs associated with that 
> > > CSE, when it can simply advertise the CSE.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > > 
> ----------------------------------------------------------------------
> --
> > > *From:* [email-masked] <mailto:[email-masked]>
> > [[email-masked]] on behalf of
> > > Duckworth, Mark [[email-masked]]
> > > *Sent:* Thursday, 26 September 2013 11:04 PM
> > > *To:* CLUE
> > > *Subject:* Re: [clue] MCC with CSE
> > >
> > > I think it would add complication and confusion to allow this. If 
> > > allowed, it would be just a shorthand for saying "all the media 
> > > captures in this CSE can be included in this MCC". But it also 
> > > opens the door for nested MCCs (MCC includes a CSE that includes 
> > > other MCCs), which doesn't make sense to me, so I suggest we just 
> > > avoid this shorthand.
> > >
> > > Mark
> > >
> > > *From:[email-masked] [mailto:[email-masked]] *On 
> > > Behalf Of *Christer Holmberg
> > > *Sent:* Thursday, September 26, 2013 3:24 PM
> > > *To:* CLUE
> > > *Subject:* [clue] MCC with CSE
> > >
> > > Hi,
> > >
> > > There are some examples of CSEs which contain MCCs (e.g.
> > > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to 
> > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).
> > >
> > > An example is when the MCC is composed of a whole capture scene entry.
> > >
> > > This is related to the discussion we previously had about 
> > > simultaneous sets, where I said that it should be possible to 
> > > advertise, and select, an CSE, rather than having to advertise and 
> > > select each individual capture within.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > >
> > > _______________________________________________
> > > 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: Christian Groves <[email-masked]>
Date: Wed, 02 Oct 2013 10:57:07 +1000

Hello Christer,

..snip..

> That works fine if the MCU always uses the same VC of each site to create the MCC.
[CNG] VC1 is just a logical representation, it doesn't have to be one of 
the source captures that the MCU received.
> But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site.
[CNG] No it doesn't. The VC in this case is only used as a logical 
entity to represent the site. There's no capture encoding. The MCU may 
wish to advertise all the source captures or produce its own captures 
based on the source information.
> MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker
[CNG] I guess you mean MCC1() in the 2nd line? It could work although 
"Description" currently doesn't allow multiple values and is an 
unstructured string so the consumer may not understand that there are 
essentially multiple values.
regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Oct 2013 07:54:12 +0000

Hi,

I guess I've missed the "logical capture" concept. If we want to use that, I think we need to have a clear description and definition of what it means, and when it is used. 

Regards,

Christer

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 2. lokakuuta 2013 3:57
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [clue] MCC with CSE

Hello Christer,

..snip..

> That works fine if the MCU always uses the same VC of each site to create the MCC.
[CNG] VC1 is just a logical representation, it doesn't have to be one of the source captures that the MCU received.
> But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site.
[CNG] No it doesn't. The VC in this case is only used as a logical entity to represent the site. There's no capture encoding. The MCU may wish to advertise all the source captures or produce its own captures based on the source information.
> MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker
[CNG] I guess you mean MCC1() in the 2nd line? It could work although "Description" currently doesn't allow multiple values and is an unstructured string so the consumer may not understand that there are essentially multiple values.
regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 03 Oct 2013 14:03:56 +1000

Hello Christer,

When I used the term "logical" capture it was really just to illustrate 
that an MCU does not need to slavishly copy the source captures. It can 
provide any sort of processing to these source captures and then 
advertise what it wants.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 06:57:05 +0000

Hi Christian,

>When I used the term "logical" capture it was really just to illustrate that an MCU does not need to slavishly copy the source captures. It can provide any sort of processing to these source captures and then advertise what it wants.

That is fine.

My point is that we should not add some "dummy" VC. If we see a need for "logical" VCs, that e.g. represent a whole site, rather than an individual VC of that site, it should be possible to indicate so.

Regards,

Christer

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 03 Oct 2013 17:06:35 +1000

Hello Christer,

Its not a "dummy" VC. A MCU can take two captures VC1 and VC2 (i.e. two 
streams) from a site and turn this into a VC3 (i.e. a single stream 
providing a signal video with the picture and slides). In this case the 
MCU has chosen to represent the site through a single VC and not through 
the source captures.

Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 07:17:37 +0000

Hi,

> Its not a "dummy" VC. A MCU can take two captures VC1 and VC2 (i.e. two streams) from a site and turn this into a VC3 (i.e. a single stream providing a signal 
> video with the picture and slides). In this case the MCU has chosen to represent the site through a single VC and not through the source captures.

In that case, aren't we talking about an MCC?

In other words: the MCU advertises an MCC, which includes a number of MCCs - each representing a site.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Thu, 03 Oct 2013 17:44:31 +1000

Hello Christer,

Yes you can use an MCC. However the MCU would only use an MCC if it 
wanted to maintain information about the source captures or provide some 
information about the multiple content i.e. policy. Otherwise the MCU 
can simply use a normal VC as per the example below.

Christian