Subject: Re: [clue] CLUE and Simulcast - ticket #47

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 3 Nov 2014 09:52:02 -0800

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, October 27, 2014 8:56 PM
> To: [email-masked]
> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> 
> Hello Roni,
> 
> As I mentioned in my original reply I think the RTP based simulcast
> method is probably the cleanest approach. There would be nothing
> stopping a CLUE endpoint implementing it when it becomes available (like
> many other RTP features). Using CLUE for simulcast I think is possible
> for most scenarios. The more complicated the scenarios the more
> MCs/encodings an endpoint will need to describe the situation.
> 
> Please see my response below.
> 
> Regards, Christian
> 
> On 27/10/2014 9:20 PM, Roni Even wrote:
> > Hi Paul,
> >
> > If we want to be able to differentiate between simulcast and switched
> > capture, for example if we have a three camera system that can send three
> > MCs each with two encodings (simulcast) and a switched capture (loudest
> > speaker or two loudest speakers out of three) using the same simulcast
> > option for the each MC currently sent. In this case we can have an MC with
> > two encodings and an MCC with the three MCs. This will require us to
> clarify
> > that having multiple individual encodings in MC is simulcast and not
> > switched and in MCC it is switched and not simulcast.
> [CNG] I don't understand exactly what the issue is here? Could you use
> some pseudo syntax to explain what you're wanting to advertise? You say
> in the first sentence the switched capture uses simulcast but then in
> the last sentence you say the MCC is switched and not simulcast. I would
> think that an MCC can still be switched and simulcast, i.e. the endpoint
> simulcasts whatever source is switched into the media stream.
> If you want a pure switched MCC just set maxCaptureEncodings to 1
> against the MCC.
> If you want a simultcast MCC just set maxCaptureEncodings to >=2 against
> the MCC.

[Duckworth, Mark] I agree with Christian.

> >
> > Now what may complicate the advertisement is if the individual MCs can
> > simulcast two encodings while the MCC (switched) is only with one
> encoding,
> > this may require different MCs for MCC or individual MCs case.
> [CNG] Probably.

[Duckworth, Mark] I don't see any problem.  I don't understand what "may require different MCs for MCC or individual MCs case" means.

> > As for the data model draft, the example
> > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-
> 26
> > may be confusing.
> > It has for VC0, VC1 and VC2
> <maxCaptureEncodings>2</maxCaptureEncodings>
> > while the EG0 has only three encID so if it was meant to support simulcast
> > it will require six encID for Scene View SE1.
> [CNG] Yes I think you're right. Its worth clarifying this. We could add
> some text in the introduction of the example saying simulcast is used.
> >
> > Roni
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: 27 October, 2014 1:37 AM
> >> To: Roni Even; [email-masked]
> >> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> >>
> >> On 10/26/14 6:00 PM, Roni Even wrote:
> >>> Paul,
> >>> How does the consumer know that he can configure an MC with two
> >>> encodings, and which of the encodings are allowed to co-exist?
> >> Look at the data model definition of a capture. It has a field
> >> <maxCaptureEncodings>. That says how many simultaneous encodings of
> the
> >> capture are allowed.
> >>
> >> So, if the encoding group for the capture includes more than one
> encoding,
> > and
> >> maxCaptureEncodings is greater than one, then the consumer can
> configure
> >> simulcast.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>
> >>> Roni
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat [mailto:[email-masked]]
> >>>> Sent: 26 October, 2014 11:34 PM
> >>>> To: Roni Even; [email-masked]
> >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> >>>>
> >>>> On 10/25/14 10:53 AM, Roni Even wrote:
> >>>>> Hi Paul,
> >>>>> Inline
> >>>>> Roni
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> >>>>>> Sent: 24 October, 2014 7:57 PM
> >>>>>> To: [email-masked]
> >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> >>>>>>
> >>>>>> I agree with Mark here.
> >>>>>>
> >>>>>> Consider a plausible use case in clue:
> >>>>>>
> >>>>>> The advertiser has a number of captures, and has a number of
> > encoders.
> >>>>>> It can create an encoding group with all the encoders in it - some
> >>>>>> do
> >>>>> hi-res
> >>>>>> video, some do small videos. It puts all of those in an encoding
> >>>>>> group and associates all the captures with that group.
> >>>>>>
> >>>>>> A "normal" consumer might configure a few of the captures with the
> >>>>>> hi-res encodings, and some of the other captures with the small
> >>>>>> encodings. There would be no simulcast in this case.
> >>>>>>
> >>>>>> Some other consumer (e.g., an MCC) may decide it wants one of the
> >>>>>> captures in both big and small versions of one of the MCCs. It can
> >>>>>> simply do an appropriate configuration and get that. Now we have
> >>>>>> *simulcast*! The advertiser didn't have to do anything special -
> >>>>>> didn't have to think about simulcast at all.
> >>>>> [Roni Even] How does the consumer know that these MCs are
> different
> >>>>> potential encodings of the same source.
> >>>>> Marks, suggested different encoding group for each encoding so he
> >>>>> can advertise MC1 with ENC1 and ENC2, in this case the encoding
> >>>>> groups will represent different encoding parameters but will need to
> >>>>> be defined accordingly, for example one encoding group that has CIF
> >>>>> resolutions and the other with only HD resolutions
> >>>> This works when the advertisement assigns the capture to an encoding
> >>>> group containing multiple encodings. When the consumer configures
> the
> >>>> same encoding twice, using different encodings from the encoding
> >>>> group, then he knows - by definition - they are simulcasts.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul
> >>>>
> >>>>>> If an advertiser *wants* to use
> >>>>>> draft-westerlund-avtcore-rtp-simulcast
> >>>>>> then I see no reason to prevent that. But I would hate to force
> >>>>>> that
> >>>>> (especially
> >>>>>> since it isn't approved yet).
> >>>>>>
> >>>>>> 	Thanks,
> >>>>>> 	Paul
> >>>>>>
> >>>>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote:
> >>>>>>> Hello Roni and Christian,
> >>>>>>>
> >>>>>>> I believe CLUE already supports simulcast today, basically as
> >>>>>>> Christian
> >>>>>> describes.
> >>>>>>> More below.
> >>>>>>>
> >>>>>>> (trying to use both the "correct indentation with > > symbols",
> >>>>>>> and also marking comments with my name :-)
> >>>>>>>
> >>>>>>> Mark
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of Roni Even
> >>>>>>>> Sent: Friday, October 24, 2014 8:19 AM
> >>>>>>>> To: 'Christian Groves'; [email-masked]
> >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> >>>>>>>>
> >>>>>>>> Hi Christian,
> >>>>>>>> Inline
> >>>>>>>> Roni
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of
> Christian
> >>>>>>>>> Groves
> >>>>>>>>> Sent: 24 October, 2014 4:59 AM
> >>>>>>>>> To: [email-masked]
> >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> >>>>>>>>>
> >>>>>>>>> Hello Roni,
> >>>>>>>>>
> >>>>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04
> >>>>>>>>> <http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-
> simulca
> >>>>>>>>> st
> >>>>>>>>> -0
> >>>>>>>>> 4> seems like the most straight forward approach as it keeps
> >>>>>>>>> 4> things
> >>>>>>>>> at the encoding level, which is really where simulcast belongs.
> >>>>>>> [Duckworth, Mark] Does CLUE really need to say anything about
> this?
> >>>>>>> Isn't this separate from CLUE, and can be used with CLUE without
> >>>>>>> any further specification in CLUE documents?
> >>>>>>>
> >>>>>>>>> For a CLUE based solution I don't think we need to revert to
> MCCs.
> >>>>>>>>> The purpose of simulcast is to provide different encoding
> >>>>>>>>> options for a particular media stream. A media provider can
> >>>>>>>>> Advertise a MC
> >>>>> with
> >>>>>> multiple encoding groups.
> >>>>>>>>> A media consumer if it wants to receive multiple encodings for
> >>>>>>>>> the same MC can simply choose multiple capture encodings e.g.
> >>>>>>>>> MC1/Encoding1
> >>>>>>>>> MC1/Encoding2 etc.
> >>>>>>> [Duckworth, Mark] Yes, a media provider can support multiple
> >>>>>>> encodings for the same MC, and a consumer can choose to
> configure
> >>>>>>> multiple encodings for the same MC.  You don't even need multiple
> >>>>>>> encoding groups to do this, you can do it with just one group that
> >>>>>>> contains
> >>>>> multiple
> >>>>>> encodings.
> >>>>>>>> [Roni Even] How does the media consumer know that these are
> >>>>>>>> alternatives of a simulcast stream and know how many can be
> used
> >>>>>>>> at the
> >>>>>> same time.
> >>>>>>> [Duckworth, Mark] By the MC attribute "max capture encodings".
> >>>>>>> Any encodings in the MC's encoding groups can be configured for a
> >>>>>>> particular MC, simultaneously, up to the value of "max capture
> >>>>> encodings".
> >>>>>>>> You also lose here the option of the total BW that is an encoding
> >>>>>>>> group
> >>>>>> attribute.
> >>>>>>> [Duckworth, Mark] You can still use that by advertising an MC with
> >>>>>>> a single encoding group, with multiple encodings in the group.
> >>>>>>>
> >>>>>>>> All these means that we need some changes to CLUE and we can
> look
> >>>>>>>> at what will make the best solution using MCs or MMCs.
> >>>>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all
> >>>>>>> this is already supported.
> >>>>>>>
> >>>>>>>> Still the question is if we say that we will use the SDP based
> >>>>>>>> solution even though it is not a WG draft, having it as a
> >>>>>>>> normative reference will delay the publication of the CLUE draft
> >>>>>>>>
> >>>>>>>>> Regards, Christian
> >>>>>>>>>
> >>>>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> During our weekly design team meeting we discussed simulcast
> >>>>>>>>>> support in CLUE.
> >>>>>>>>>>
> >>>>>>>>>> Here is my take on the options, my description may not be
> >>>>>>>>>> accurate and the purpose here is to continue the discussion
> >>>>>>>>>> allowing us to have a better view of the options.
> >>>>>>>>>>
> >>>>>>>>>> Looking at the state of simulcast support in other WGs, there
> >>>>>>>>>> is an individual draft
> >>>>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-
> simulca
> >>>>>>>>>> st
> >>>>>>>>>> -0
> >>>>>>>>>> 4 that being discussed. The proposed solution is based on the
> >>>>>>>>>> unified plan where all encoded streams composing alternatives
> >>>>>>>>>> of a simulcast stream are in the same m-line. The alternatives
> >>>>>>>>>> are described using an SDP media level attribute "a=simulcast".
> >>>>>>>>>> This attribute is not defined for SDP session level.
> >>>>>>>>>>
> >>>>>>>>>> The first question we had is if we should base CLUE simulcast
> >>>>>>>>>> support on this individual draft based on CLUE timeline or try
> >>>>>>>>>> to define a different multicast solution at the CLUE protocol
> > level.
> >>>>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04
> >>>>>>>>>> document the advertisement will include an individual
> encoding
> >>>>>>>>>> that will relate to optional multiple simulcast encoding and
> >>>>>>>>>> the configure will select such encoding. The actual number of
> >>>>>>>>>> different stream that will compose the simulcast stream will be
> >>>>>>>>>> negotiated using Offer/Answer as described in the above
> >>>>>>>>>> document. The risk here is that this is an individual draft and
> >>>>>>>>>> we may need to review the CLUE support if it changes. The
> >>>>>>>>>> advantage is that we will have simulcast the same for CLUE and
> > non-
> >> CLUE systems.
> >>>>>>>>>> The other option for simulcast support in the CLUE protocol can
> >>>>>>>>>> be based on having separate Media Capture for each of the
> >>>>>>>>>> different simulcast encoding and use MCC to compose the
> >>>>>>>>>> simulcast
> >>>> alternatives.
> >>>>>>>>>> We will need some way to escribe that this MCC is for simulcast
> >>>>>>>>>> description and to provide the actual allowed individual
> >>>>>>>>>> encodes combinations for the Configuration by the consumer.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>> Roni
> >>>>>>> _______________________________________________
> >>>>>>> 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: "Roni Even" <[email-masked]>
Date: Tue, 4 Nov 2014 00:51:55 +0200

> Sent: 28 October, 2014 2:56 AM
> To: [email-masked]
> As I mentioned in my original reply I think the RTP based simulcast method
is
> probably the cleanest approach. There would be nothing stopping a CLUE
> endpoint implementing it when it becomes available (like many other RTP
> features). Using CLUE for simulcast I think is possible for most
scenarios. The
> more complicated the scenarios the more MCs/encodings an endpoint will
> need to describe the situation.
> 
> > capture, for example if we have a three camera system that can send
> > three MCs each with two encodings (simulcast) and a switched capture
> > (loudest speaker or two loudest speakers out of three) using the same
> > simulcast option for the each MC currently sent. In this case we can
> > have an MC with two encodings and an MCC with the three MCs. This will
> > require us to clarify that having multiple individual encodings in MC
> > is simulcast and not switched and in MCC it is switched and not
simulcast.
> [CNG] I don't understand exactly what the issue is here? Could you use
some
> pseudo syntax to explain what you're wanting to advertise? You say in the
first
> sentence the switched capture uses simulcast but then in the last sentence
you
> say the MCC is switched and not simulcast. I would think that an MCC can
still
> be switched and simulcast, i.e. the endpoint simulcasts whatever source is
> switched into the media stream.
> If you want a pure switched MCC just set maxCaptureEncodings to 1 against
the
> MCC.
the
> MCC.

[Roni Even] The thing is that I am not sure how to advertise this example. 

The advertisement has two scene views:
 1. Scene view with VC0, VC1, VC2 each with two simulcast streams
2. Scene view MCC3 as represented bellow

The different MCs will be:

VC0- (the left camera stream), encoding group=EG0, view=table, MaxCaptures=2

 VC1- (the center camera stream), encoding group=EG0, view=table,
MaxCaptures=2

 VC2- (the right camera stream), encoding group=EG0, view=table.
MaxCaptures=2

  MCC3 (VC0, VC1, VC2) - encoding group=EG0,    view=room, MaxCaptures=2

Now it may be implied here that VC0, VC1, VC2 are simulcast.
What  about MCC3?
Is it multicast from one of the cameras or is it 2 MCs out of the three? (I
assume it is the first since the view is room)
What if in the above example  MaxCaptures=4 can it be for example VC0, VC1
each with two simulcast streams or is it VC0, VC1, VC2 and one of them is
simulcast? 

What I am trying to say is that using implied simulcast require text
explaining when a consumer can understand that the advertisement is
simulcast and not something else. 
The other approach may be to have an attribute for an MC and MCC that will
explicitly say that this is a simulcast offer.

BTW: I think that the implied solution works when the individual encodings
are the same (spatial or different codces) what if we the provider can send
H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four different
encodings but not all combinations allowed. How to represent it in an
advertisement? Is it :

VC0- (the left camera stream), encoding group=EG0, view=table, MaxCaptures=2

 VC1- (the center camera stream), encoding group=EG0, view=table,
MaxCaptures=2

 VC2- (the right camera stream), encoding group=EG0, view=table.
MaxCaptures=2

VC3- (the left camera stream), encoding group=EG1, view=table, MaxCaptures=2

 VC4- (the center camera stream), encoding group=EG1, view=table,
MaxCaptures=2

 VC5- (the right camera stream), encoding group=EG1, view=table.
MaxCaptures=2

Where EG0 will be for H.264 and EG1 will be for VP8 and two scene views
(VC0,VC1,VC2) (VC3, VC4, VC5)?

> > encoding, this may require different MCs for MCC or individual MCs case.
> [CNG] Probably.
> >
> > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#secti
> > on-26
> > may be confusing.
> > while the EG0 has only three encID so if it was meant to support
> > simulcast it will require six encID for Scene View SE1.
some text
> in the introduction of the example saying simulcast is used.
> >
> > Roni
> >
> >> the capture are allowed.
> >> configure simulcast.
> >>>>>> It can create an encoding group with all the encoders in it -
> >>>>>> some do
> >>>>> hi-res
> >>>>>> A "normal" consumer might configure a few of the captures with
> >>>>>> the hi-res encodings, and some of the other captures with the
> >>>>>> small encodings. There would be no simulcast in this case.
> >>>>>>
> >>>>>> captures in both big and small versions of one of the MCCs. It
> >>>>>> can simply do an appropriate configuration and get that. Now we
> >>>>>> have *simulcast*! The advertiser didn't have to do anything
> >>>>>> special - didn't have to think about simulcast at all.
> >>>>> different potential encodings of the same source.
> >>>>> groups will represent different encoding parameters but will need
> >>>>> to be defined accordingly, for example one encoding group that has
> >>>>> CIF resolutions and the other with only HD resolutions
> >>>> This works when the advertisement assigns the capture to an
> >>>> encoding group containing multiple encodings. When the consumer
> >>>> configures the same encoding twice, using different encodings from
> >>>> the encoding group, then he knows - by definition - they are
simulcasts.
> >>>>>>>>> Christian Groves
> >>>>>>>>> <http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simul
> >>>>>>>>> ca
> >>>>>>>>> st
> >>>>>>>>> -0
this?
MCCs.
> >>>>>>> configure multiple encodings for the same MC.  You don't even
> >>>>>>> need multiple encoding groups to do this, you can do it with
> >>>>>>> just one group that contains
> >>>>> multiple
> >>>>>> encodings.
> >>>>>>>> used at the
> >>>>>>> Any encodings in the MC's encoding groups can be configured for
> >>>>>>> a particular MC, simultaneously, up to the value of "max capture
> >>>>> encodings".
> >>>>>>>> You also lose here the option of the total BW that is an
> >>>>>>>> encoding group
> >>>>>> attribute.
> >>>>>>> [Duckworth, Mark] You can still use that by advertising an MC
> >>>>>>> with a single encoding group, with multiple encodings in the
group.
> >>>>>>>> look at what will make the best solution using MCs or MMCs.
> >>>>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE,
> >>>>>>> all this is already supported.
> >>>>>>>
> >>>>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simul
> >>>>>>>>>> ca
> >>>>>>>>>> st
> >>>>>>>>>> -0
> >>>>>>>>>> of a simulcast stream are in the same m-line. The
> >>>>>>>>>> alternatives are described using an SDP media level attribute
> "a=simulcast".
> >>>>>>>>>> support on this individual draft based on CLUE timeline or
> >>>>>>>>>> try to define a different multicast solution at the CLUE
> >>>>>>>>>> protocol
> > level.
> >>>>>>>>>> encoding that will relate to optional multiple simulcast
> >>>>>>>>>> encoding and the configure will select such encoding. The
> >>>>>>>>>> actual number of different stream that will compose the
> >>>>>>>>>> simulcast stream will be negotiated using Offer/Answer as
> >>>>>>>>>> described in the above document. The risk here is that this
> >>>>>>>>>> is an individual draft and we may need to review the CLUE
> >>>>>>>>>> support if it changes. The advantage is that we will have
> >>>>>>>>>> simulcast the same for CLUE and
> > non-
> >> CLUE systems.
> >>>>>>>>>> The other option for simulcast support in the CLUE protocol
> >>>>>>>>>> can be based on having separate Media Capture for each of the
> >>>>>>>>>> We will need some way to escribe that this MCC is for
> >>>>>>>>>> simulcast description and to provide the actual allowed
> >>>>>>>>>> individual encodes combinations for the Configuration by the
> consumer.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>> Roni

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 3 Nov 2014 19:52:13 -0800

> Sent: Monday, November 03, 2014 5:52 PM
> > > is simulcast and not switched and in MCC it is switched and not simulcast.
> > [CNG] I don't understand exactly what the issue is here? Could you use some
> > pseudo syntax to explain what you're wanting to advertise? You say in the first
> > sentence the switched capture uses simulcast but then in the last sentence you
> > say the MCC is switched and not simulcast. I would think that an MCC can  still
> > If you want a pure switched MCC just set maxCaptureEncodings to 1 against the
> > MCC.
> > If you want a simultcast MCC just set maxCaptureEncodings to >=2 against the
> > MCC.
> 

[Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture Encodings"?
Don't confuse this with the MCC attribute MaxCaptures which means "Max number
of Captures within a MCC".

>   MCC3 (VC0, VC1, VC2) - encoding group=EG0,    view=room, MaxCaptures=2

[Duckworth, Mark] It isn't clear if you really mean "max capture encodings" or
"max number of captures within a MCC".  Those are two different things.

> Now it may be implied here that VC0, VC1, VC2 are simulcast.

[Duckworth, Mark] It depends how the consumer configures it.  The provider advertisement
says it supports simulcast, so the consumer can decide to use it or not.

> assume it is the first since the view is room)

[Duckworth, Mark] MCC3 can provide 2 MCs out of the three simultaneously only if it is composed,
not if it is switched.  The provider can give more information, if it wants to, with the
MCC attribute "max number of captures within a MCC".

> each with two simulcast streams or is it VC0, VC1, VC2 and one of them is simulcast?

[Duckworth, Mark] Neither.  The MCC3 provides a single "conceptual" capture.
It sounds like you are talking about a switched case, not a composed case, so 
let's say MCC3 has the attribute "max number of captures within a MCC" = 1.
Now let's also suppose MCC3 has "max capture encodings" = 2.  Then the consumer
can ask for, say, MCC3 at 720p and SIF, for the two encodings.  Then the provider
decides when to switch among VC0, VC1, and VC2, and whichever one the provider
is sending for MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at those
two resolutions.

> explicitly say that this is a simulcast offer.

[Duckworth, Mark] I think the advertisement is clear to the consumer without
any additional text or attributes added to the framework.  It is already explicit,
with the attribute "max capture encodings".  If it is >1, then the advertisement
is offering simulcast.

> encodings but not all combinations allowed. How to represent it in an

[Duckworth, Mark] I can consider this case after we get the first case
above cleared up.

> (VC0,VC1,VC2) (VC3, VC4, VC5)?
 ... snip ...

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Nov 2014 11:45:17 -0800

Hi Roni,
Do you still have questions about the way simulcast is handled in the framework,
regarding the attribute "Max capture encodings" and configuring multiple
encodings per capture?  I was hoping we could resolve it on the list, or do you
think we need to talk about it in Honolulu?
Regards,
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
> Sent: Monday, November 03, 2014 10:52 PM
> To: Roni Even; 'Christian Groves'; [email-masked]
> method
> against the

---

From: "Roni Even" <[email-masked]>
Date: Wed, 12 Nov 2014 22:35:45 +0200

Hi,
This will work when we have a single encoding per m-line in the SDP and I
think it requires that each simulcast set will be in separate encoding group
. Still it will provide less functionality than the one proposed in the
simulcast proposal that will be discussed in MMUSIC
If simulcast in SDP will progress using the unified plan where we have all
encodings in one m-line we will need to specify that if an MC have max
capture encoding >1 will it mean that it will map to two m-lines or will it
use a configuration from an SDP description a=simulcast.

We will need to see how it works with retransmission if we specify a
retransmission RTP stream as an individual encoding.

Roni

> From: Duckworth, Mark [mailto:[email-masked]]
> Sent: 06 November, 2014 9:45 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: RE: [clue] CLUE and Simulcast - ticket #47
> 
> Hi Roni,
> Do you still have questions about the way simulcast is handled in the
> framework, regarding the attribute "Max capture encodings" and configuring
> multiple encodings per capture?  I was hoping we could resolve it on the
list, or
> do you think we need to talk about it in Honolulu?
> Regards,
> Mark
> 
> > > > probably the cleanest approach. There would be nothing stopping a
> > > > CLUE endpoint implementing it when it becomes available (like many
> > > > other RTP features). Using CLUE for simulcast I think is possible
> > > > for most
> > > scenarios. The
> > > > > If we want to be able to differentiate between simulcast and
> > > > > switched capture, for example if we have a three camera system
> > > > > that can send three MCs each with two encodings (simulcast) and
> > > > > a switched capture (loudest speaker or two loudest speakers out
> > > > > of three) using the same simulcast option for the each MC
> > > > > currently sent. In this case we can have an MC with two
> > > > > encodings and an MCC with the three MCs. This
> > will
> > > > > require us to clarify that having multiple individual encodings
> > > > > in MC is simulcast and not switched and in MCC it is switched
> > > > > and not
> > simulcast.
> > > > pseudo syntax to explain what you're wanting to advertise? You say
> > > > in
> > the first
> > > > be switched and simulcast, i.e. the endpoint simulcasts whatever
> > > > source
> > is
> > >  1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2.
> > > Scene view MCC3 as represented bellow
> > >
> > Don't confuse this with the MCC attribute MaxCaptures which means "Max
> > number of Captures within a MCC".
> >
> > [Duckworth, Mark] It isn't clear if you really mean "max capture
encodings"
> > or
> > [Duckworth, Mark] It depends how the consumer configures it.  The
> > provider advertisement says it supports simulcast, so the consumer can
> > decide to use it or not.
> >
> > > What  about MCC3?
> > > Is it multicast from one of the cameras or is it 2 MCs out of the
> > > three? (I assume it is the first since the view is room)
> >
> > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three
> > simultaneously only if it is composed, not if it is switched.  The
> > provider can give more information, if it wants to, with the MCC
> > attribute "max number of captures within a MCC".
> >
> > > What if in the above example  MaxCaptures=4 can it be for example
> > > VC0,
> > VC1
> > It sounds like you are talking about a switched case, not a composed
> > case, so let's say MCC3 has the attribute "max number of captures within
a
> MCC" = 1.
> > Now let's also suppose MCC3 has "max capture encodings" = 2.  Then the
> > consumer can ask for, say, MCC3 at 720p and SIF, for the two
> > encodings.  Then the provider decides when to switch among VC0, VC1,
> > and VC2, and whichever one the provider is sending for MCC3 it sends
> > it at both SIF and 720p, so MCC3 is simulcast at those two
> > resolutions.
> >
> > > The other approach may be to have an attribute for an MC and MCC
> > > that
> > will
> > [Duckworth, Mark] I think the advertisement is clear to the consumer
> > without any additional text or attributes added to the framework.  It
> > is already explicit, with the attribute "max capture encodings".  If
> > it is >1, then the advertisement is offering simulcast.
> >
> > > BTW: I think that the implied solution works when the individual
> > > encodings are the same (spatial or different codces) what if we the
> > > provider can send
> > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four
> > > different encodings but not all combinations allowed. How to
> > > represent it in an advertisement? Is it :
> >

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Nov 2014 12:54:20 -0800

Hi,

I don't understand why simulcast would need separate encoding groups.

Whether an MC maps to two m-lines or one m-line with a=simulcast is up to the consumer, and specified in the configure message sent from consumer to provider.  The mapping is done via the encoding ID labels which link media captures to m-lines.  At least that is how I see it.

Would you say retransmission streams are a separate issue from simulcast?  Or are they similar enough that it is really the same issue?  Do SVC layered codec streams also fall into this category?

Sounds like we do need some more discussion about this.  My first thought is we should cover this in the signaling document.

Mark

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2014 10:36 AM
> To: Duckworth, Mark
> Cc: [email-masked]
> > > > > more complicated the scenarios the more MCs/encodings an
> endpoint
> > > will

---

From: "Robert Hansen (rohanse2)" <[email-masked]>
Date: Wed, 12 Nov 2014 21:02:43 +0000

Yes, I'd have thought ideally multiple simulcast qualities, repair streams etc would be defined under a single m-line and hence be a single encoding from CLUE's perspective. That matches the unified plan and the proposal in draft-burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would mean that negotiating simulcast qualities, repair flows etc would be purely an SDP issue and wouldn't impact CLUE.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: 12 November 2014 10:54
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] CLUE and Simulcast - ticket #47

Hi,

Mark

> This will work when we have a single encoding per m-line in the SDP 
> and I think it requires that each simulcast set will be in separate 
> encoding group . Still it will provide less functionality than the one 
> proposed in the simulcast proposal that will be discussed in MMUSIC If 
> simulcast in SDP will progress using the unified plan where we have 
> all encodings in one m-line we will need to specify that if an MC have 
> max capture encoding >1 will it mean that it will map to two m-lines 
> or will it use a configuration from an SDP description a=simulcast.
> 
> > Do you still have questions about the way simulcast is handled in 
> > the framework, regarding the attribute "Max capture encodings" and
> configuring
> > > > > probably the cleanest approach. There would be nothing 
> > > > > stopping a CLUE endpoint implementing it when it becomes 
> > > > > available (like many other RTP features). Using CLUE for 
> > > > > simulcast I think is possible for most
> > > > scenarios. The
> > > > > > switched capture, for example if we have a three camera 
> > > > > > system that can send three MCs each with two encodings 
> > > > > > (simulcast) and a switched capture (loudest speaker or two 
> > > > > > loudest speakers out of three) using the same simulcast 
> > > > > > option for the each MC currently sent. In this case we can 
> > > > > > have an MC with two encodings and an MCC with the three MCs. 
> > > > > > This
> > > will
> > > > > > require us to clarify that having multiple individual 
> > > > > > encodings in MC is simulcast and not switched and in MCC it 
> > > > > > is switched and not
> > > simulcast.
> > > > > pseudo syntax to explain what you're wanting to advertise? You 
> > > > > say in
> > > the first
> > > > > sentence the switched capture uses simulcast but then in the 
> > > > > last
> > > sentence you
> > > > > be switched and simulcast, i.e. the endpoint simulcasts 
> > > > > whatever source
> > > is
> > > > > If you want a simultcast MCC just set maxCaptureEncodings to 
> > > > > >=2
> > > against the
> > > > > MCC.
> > > >
> > > > [Roni Even] The thing is that I am not sure how to advertise 
> > > > this
> example.
> > > >
> > > provider advertisement says it supports simulcast, so the consumer 
> > > can decide to use it or not.
> > >
> > > > What  about MCC3?
> > > > Is it multicast from one of the cameras or is it 2 MCs out of 
> > > > the three? (I assume it is the first since the view is room)
> > >
> > > > What if in the above example  MaxCaptures=4 can it be for 
> > > > example VC0,
> > > VC1
> > > It sounds like you are talking about a switched case, not a 
> > > composed case, so let's say MCC3 has the attribute "max number of 
> > > captures within
> a
> > MCC" = 1.
> > > Now let's also suppose MCC3 has "max capture encodings" = 2.  Then 
> > > the consumer can ask for, say, MCC3 at 720p and SIF, for the two 
> > > encodings.  Then the provider decides when to switch among VC0, 
> > > VC1, and VC2, and whichever one the provider is sending for MCC3 
> > > it sends it at both SIF and 720p, so MCC3 is simulcast at those 
> > > two resolutions.
> > >
> > > > What I am trying to say is that using implied simulcast require 
> > > > text explaining when a consumer can understand that the 
> > > > advertisement is simulcast and not something else.
> > >
> > > [Duckworth, Mark] I think the advertisement is clear to the 
> > > consumer without any additional text or attributes added to the 
> > > framework.  It is already explicit, with the attribute "max 
> > > capture encodings".  If it is >1, then the advertisement is offering simulcast.
> > >
> > > > encodings are the same (spatial or different codces) what if we 
> > > > the provider can send
> > > [Duckworth, Mark] I can consider this case after we get the first 
> > > case above cleared up.
> > >

---

From: "Roni Even" <[email-masked]>
Date: Thu, 13 Nov 2014 01:29:52 +0200

Hi,
This is what started the discussion. If we do not have SDP based simulcast
based on unified plan, the only semantics is an encoding per m-line. We
started the discussion based on this assumption that we can do simulcast in
CLUE using an encoding per m-line and can bundle them
Roni

> From: Robert Hansen (rohanse2) [mailto:[email-masked]]
> Sent: 12 November, 2014 11:03 PM
> To: Duckworth, Mark; Roni Even
> Cc: [email-masked]
> Yes, I'd have thought ideally multiple simulcast qualities, repair streams
etc
> would be defined under a single m-line and hence be a single encoding from
> CLUE's perspective. That matches the unified plan and the proposal in
draft-
> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would mean
> that negotiating simulcast qualities, repair flows etc would be purely an
SDP
> issue and wouldn't impact CLUE.
> 
> Rob
> 
> Whether an MC maps to two m-lines or one m-line with a=simulcast is up to
> the consumer, and specified in the configure message sent from consumer to
> provider.  The mapping is done via the encoding ID labels which link media
> captures to m-lines.  At least that is how I see it.
> 
> Would you say retransmission streams are a separate issue from simulcast?
Or
> are they similar enough that it is really the same issue?  Do SVC layered
codec
> streams also fall into this category?
> 
> Sounds like we do need some more discussion about this.  My first thought
is
> we should cover this in the signaling document.
> 
> Mark
> 
2.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Nov 2014 17:25:37 -1000

If an sdp-based mechanism is published that allows simulcast in a single 
m-line, then clue gets to take advantage of that *for free*. I don't 
know that we need to say anything about that.

The question we have to ask is: do we want to remove the clue-specific 
mechanism that is already present in our data model?

To that I will add the corollary question: is there any cost to having 
that option in there?

I can't see any cost.
- Advertisers don't have to use it in their advertisements.
- Consumers can't use it in Configure if it wasn't in the advertisement
- Consumers don't have to use it if it is in the advertisement.

So I see no harm in leaving it in. And some potential benefit to having 
it there.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 21 Nov 2014 14:24:55 +1100

What's the status of the simultcast issue after the meeting? I saw some 
meeting notes to suggest that it would be removed from CLUE. I certainly 
didn't expect that from the discussions on the list.

Regards, Christian

On 13/11/2014 2:25 PM, Paul Kyzivat wrote:
> If an sdp-based mechanism is published that allows simulcast in a 
> single m-line, then clue gets to take advantage of that *for free*. I 
> don't know that we need to say anything about that.
>
> So I see no harm in leaving it in. And some potential benefit to 
> having it there.
>
>     Thanks,
>     Paul
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Nov 2014 05:58:54 +0000

Hi,

The generic simulcast draft was adopted in MMUSIC, and the idea is that it will be used also if someone wants to provide simulcast for CLUE.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 21 November 2014 05:25
To: [email-masked]
Subject: Re: [clue] CLUE and Simulcast - ticket #47

What's the status of the simultcast issue after the meeting? I saw some meeting notes to suggest that it would be removed from CLUE. I certainly didn't expect that from the discussions on the list.

Regards, Christian

On 13/11/2014 2:25 PM, Paul Kyzivat wrote:
>> This is what started the discussion. If we do not have SDP based 
>> simulcast based on unified plan, the only semantics is an encoding 
>> per m-line. We started the discussion based on this assumption that 
>> we can do simulcast in CLUE using an encoding per m-line and can 
>> bundle them Roni
>>
>>> would be defined under a single m-line and hence be a single 
>>> encoding from CLUE's perspective. That matches the unified plan and 
>>> the proposal in
>> draft-
>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would 
>>> mean that negotiating simulcast qualities, repair flows etc would be 
>>> purely an
>> SDP
>>> Whether an MC maps to two m-lines or one m-line with a=simulcast is 
>>> up to the consumer, and specified in the configure message sent from 
>>> consumer to provider.  The mapping is done via the encoding ID 
>>> labels which link media captures to m-lines.  At least that is how I 
>>> see it.
>>>
>>>> encoding group . Still it will provide less functionality than the 
>>>> one proposed in the simulcast proposal that will be discussed in 
>>>> MMUSIC If simulcast in SDP will progress using the unified plan 
>>>> where we have all encodings in one m-line we will need to specify 
>>>> that if an MC have max capture encoding >1 will it mean that it 
>>>> will map to two m-lines or will it use a configuration from an SDP description a=simulcast.
>>>>
>>>> We will need to see how it works with retransmission if we specify 
>>>> a retransmission RTP stream as an individual encoding.
>>>>
>>>> Roni
>>>>
>>>>>>>> probably the cleanest approach. There would be nothing stopping 
>>>>>>>> a CLUE endpoint implementing it when it becomes available (like 
>>>>>>>> many other RTP features). Using CLUE for simulcast I think is 
>>>>>>>> possible for most
>>>>>>> scenarios. The
>>>>>>>>> that can send three MCs each with two encodings
>>>>>>>>> loudest speakers out of three) using the same simulcast option 
>>>>>>>>> for the each MC currently sent. In this case we can have an MC 
>>>>>>>>> with two encodings and an MCC with the three MCs.
>>>>>>>>> This
>>>>>> will
>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it is 
>>>>>>>>> switched and not
>>>>>> simulcast.
>>>>>> provider advertisement says it supports simulcast, so the 
>>>>>> consumer can decide to use it or not.
>>>>>>
>>>>>>> What  about MCC3?
>>>>>> simultaneously only if it is composed, not if it is switched.  
>>>>>> The provider can give more information, if it wants to, with the 
>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2.  
>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for the 
>>>>>> two encodings.  Then the provider decides when to switch among 
>>>>>> VC0, VC1, and VC2, and whichever one the provider is sending for 
>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at 
>>>>>> those two resolutions.
>>>>>>
>>>>>> capture encodings".  If it is >1, then the advertisement is 
>>>>>> offering
>>> simulcast.
>>>>>>

---

From: Christian Groves <[email-masked]>
Date: Fri, 21 Nov 2014 17:03:56 +1100

Hello Christer,

Yes, I thought the assumption was nothing in CLUE prevented the use of 
the generic simulcast draft. I'm wondering why the adoption of that 
meant part of CLUE was removed (at least as I understand from the notes)?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Nov 2014 06:21:05 +0000

Hi,

>Yes, I thought the assumption was nothing in CLUE prevented the use of the generic >simulcast draft.

It was more a timing issue, as we didn't want to delay the CLUE work when it was unsure whether the simulcast was going to be adopted.

>I'm wondering why the adoption of that meant part of CLUE was removed (at least >as I understand from the notes)?

As far as I remember, yes. Nobody could come up with a reason why it should be kept.

Regards,

Christer

On 21/11/2014 4:58 PM, Christer Holmberg wrote:
>> The question we have to ask is: do we want to remove the 
>> clue-specific mechanism that is already present in our data model?
>>
>> To that I will add the corollary question: is there any cost to 
>> having that option in there?
>>
>> I can't see any cost.
>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it 
>>>> would mean that negotiating simulcast qualities, repair flows etc 
>>>> would be purely an
>>> SDP
>>>> up to the consumer, and specified in the configure message sent 
>>>> from consumer to provider.  The mapping is done via the encoding ID 
>>>> labels which link media captures to m-lines.  At least that is how 
>>>> I see it.
>>>>
>>>>> This will work when we have a single encoding per m-line in the 
>>>>> SDP and I think it requires that each simulcast set will be in 
>>>>> separate encoding group . Still it will provide less functionality 
>>>>> than the one proposed in the simulcast proposal that will be 
>>>>> discussed in MMUSIC If simulcast in SDP will progress using the 
>>>>> unified plan where we have all encodings in one m-line we will 
>>>>> need to specify that if an MC have max capture encoding >1 will it 
>>>>> mean that it will map to two m-lines or will it use a configuration from an SDP description a=simulcast.
>>>>>
>>>>>>> Duckworth,
>>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings 
>>>>>>>>> to
>>>>>>>>> 1
>>>>>>> against the
>>>>>>>>> MCC.
>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which 
>>>>>>> means
>>>>> "Max
>>>>>>> [Duckworth, Mark] It depends how the consumer configures it.  
>>>>>>> The provider advertisement says it supports simulcast, so the 
>>>>>>> composed case, so let's say MCC3 has the attribute "max number 
>>>>>>> of captures within
>>>>> a
>>>>>> MCC" = 1.
>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for 
>>>>>>> the two encodings.  Then the provider decides when to switch 
>>>>>>> among VC0, VC1, and VC2, and whichever one the provider is 
>>>>>>> sending for
>>>>>>>> The other approach may be to have an attribute for an MC and 
>>>>>>>> MCC that
>>>>>>> will
>>>>>>>> BTW: I think that the implied solution works when the 
>>>>>>>> individual encodings are the same (spatial or different codces) 
>>>>>>>> what if we the provider can send
>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be 
>>>>>>>> four different encodings but not all combinations allowed. How 
>>>>>>>> to represent it in an advertisement? Is it :
>>>>>>> [Duckworth, Mark] I can consider this case after we get the 
>>>>>>> first case above cleared up.
>>>>>>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 21 Nov 2014 06:52:03 -0800

Yes, the people in the room at IETF 91 were clearly in favor of removing the CLUE simulcast feature enabled by "Max Capture Encodings" > 1.  A reason to remove it is to avoid interop issue which could arise by having two different ways to do simulcast that don't interop with each other.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Friday, November 21, 2014 1:21 AM
> To: Christian Groves; [email-masked]
> the generic >simulcast draft.
>
> It was more a timing issue, as we didn't want to delay the CLUE work when it
> was unsure whether the simulcast was going to be adopted.
>
> >I'm wondering why the adoption of that meant part of CLUE was removed
> (at least >as I understand from the notes)?
>
> > The generic simulcast draft was adopted in MMUSIC, and the idea is that it
> will be used also if someone wants to provide simulcast for CLUE.
> >
> > Regards,
> >
> > Christer
> >
> >>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max
> Capture
> >>>>>>> Encodings"?
> >>>>>>> [Duckworth, Mark] Neither.  The MCC3 provides a single
> "conceptual"
> >>>>>>> capture.

---

From: Christian Groves <[email-masked]>
Date: Mon, 24 Nov 2014 11:28:35 +1100

I don't think its a trivial change. I assume if we remove this then a 
consumer must always choose "one" encoding from an encoding group? It 
also changes the semantic of the encoding group to sets of mutually 
exclusive encodings. Then does the "maxgroupbandwidth" also become 
meaningless for CLUE as from a CLUE perspective only one encoding will 
be chosen? If we decide to remove simulcast then we should remove it 
completely and not rely on some functionality in SDP and others in CLUE.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Nov 2014 23:45:33 -0500

> Yes, the people in the room at IETF 91 were clearly in favor of removing the CLUE simulcast feature enabled by "Max Capture Encodings" > 1.  A reason to remove it is to avoid interop issue which co…

I think I was the only one in the room arguing for keeping the clue 
mechanism (while of course the other one could also be used.)

IMO both mechanisms have unique advantages over the other.
But I do appreciate the interop argument. And I was the only one on that 
side of the issue.

	Thanks,
	Paul