Subject: [clue] MCC with CSE

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Sep 2013 19:23:50 +0000

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 26 Sep 2013 13:04:25 -0700

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,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Sep 2013 20:13:26 +0000

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

Hi,

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Sep 2013 10:57:00 +1000

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:
> 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] [[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)).
>
> 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]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 11:59:34 +0000

Hi,

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.

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,

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 27 Sep 2013 07:25:35 -0700

Hi Christer,
I don't understand why in your example the MCU would want to advertise an MCC at all.  Comments below.
Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, September 27, 2013 8:00 AM
To: Christian Groves; [email-masked]
Subject: Re: [clue] MCC with CSE

Hi,

Take an example:

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

Regards,

Christer

Regards, Christian

On 27/09/2013 6:13 AM, Christer Holmberg wrote:
> *From:* [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of
> 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
> MCCs), which doesn't make sense to me, so I suggest we just avoid this
> shorthand.
>
> Mark
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 15:30:10 +0000

Hi Mark,

Se comments inline.

Take an example:

[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

Regards,

Christer

Regards, Christian

---

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

Hello Christer,

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.

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

Regards,
Christian

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/*
>
> *//*
>
> 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]
> > *From:* [email-masked] <mailto:[email-masked]> 
> [[email-masked]] on behalf of
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Sep 2013 11:57:14 +0000

Hi,

>time based on who is the active speaker, that is main and slides.

Correct.

>CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=1 (i.e. switched),Policy=active

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?

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

---

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

Hello Christer,

Please see below.

Regards, Christian

On 28/09/2013 9:57 PM, Christer Holmberg wrote:
> 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.)
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
>
>
>
>