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

From: "Duckworth, Mark" <[email-masked]>
Date: Sun, 23 Nov 2014 20:26:18 -0800

Hi Christian,
I don't  follow you. The original point of encoding groups, which still holds true, is that multiple media captures can use the same encoding group.  So there is still a use for an encoding group, which can have multiple individual encodings, each of which can be configured to encode a different capture.
So maybe I'm not understanding your concern?
Mark

-------- Original message --------
From: Christian Groves <[email-masked]>
Date:11/23/2014 7:28 PM (GMT-05:00)
To: "Duckworth, Mark" <[email-masked]>, Christer Holmberg <[email-masked]>, [email-masked]
Subject: Re: [clue] CLUE and Simulcast - ticket #47

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

On 22/11/2014 1:52 AM, Duckworth, Mark wrote:
> 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
>
>> -----Original Message-----
>> From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
>> Sent: Friday, November 21, 2014 1:21 AM
>> To: Christian Groves; [email-masked]
>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>
>> 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:
>>> 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:
>>>> 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
>>>>
>>>> On 11/12/14 1:29 PM, Roni Even wrote:
>>>>> 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
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Robert Hansen (rohanse2) [mailto:[email-masked]]
>>>>>> Sent: 12 November, 2014 11:03 PM
>>>>>> To: Duckworth, Mark; Roni Even
>>>>>> Cc: [email-masked]
>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>>>>>
>>>>>> 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,
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Roni Even [mailto:[email-masked]]
>>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM
>>>>>>> To: Duckworth, Mark
>>>>>>> Cc: [email-masked]
>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> 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
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> 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]
>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of Roni
>>>>>>>>>> Even
>>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM
>>>>>>>>>> To: 'Christian Groves'; [email-masked]
>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: clue [mailto:[email-masked]] On Behalf Of
>>>>>>>>>>> Christian Groves
>>>>>>>>>>> Sent: 28 October, 2014 2:56 AM
>>>>>>>>>>> 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.
>>>>>>>>>> [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
>>>>>>>>> [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".
>>>>>>>>>
>>>>>>>>>>     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
>>>>>>>>>
>>>>>>>>> [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.
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>> [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 :
>>>>>>>>> [Duckworth, Mark] I can consider this case after we get the
>>>>>>>>> first case above cleared up.
>>>>>>>>>
>>>>>>>>>> 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)?
>>>>>>>>>>
>>>>>>>>>     ... snip ...
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>
>>> _______________________________________________
>>> 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: Mon, 24 Nov 2014 18:17:46 +1100

Hello Mark,

You're right, I wasn't thinking about didn't captures using the encoding 
group. I was trying to see what the impact of this change was. My 
comment comes out of the text in clause 9.3 of the framework,

"Any of the Captures that use a particular Encoding Group can be encoded
    according to any of the Individual Encodings in the group.  If
    there are multiple Individual Encodings in the group, then the
    Consumer can configure the Provider, via a Configure message, to
    encode a single Media Capture into multiple different Capture
    Encodings at the same time, subject to the Max Capture Encodings
    constraint, with each capture encoding following the constraints of
    a different Individual Encoding."

If the encoding group was used for simulcast the maxgroupbandwidth could 
be used to apply to the simulcast streams. If we now move this out 
mechanism out, is there an equivalent for the simulcast cast SDP? b= ?

With respect to multiple captures using one encoding group, I didn't see 
in the draft where it says that a media consumer can only choose one 
individual encoding (i.e. as identified by a=label) for one of the 
captures referencing the encoding group (i.e. an individual encoding 
can't be used more than once). Does it make sense for two captures 
(outside a MCC) to share an individual encoding?

Regards, Christian

On 24/11/2014 3:26 PM, Duckworth, Mark wrote:
> Hi Christian,
> I don't  follow you. The original point of encoding groups, which 
> still holds true, is that multiple media captures can use the same 
> encoding group.  So there is still a use for an encoding group, which 
> can have multiple individual encodings, each of which can be 
> configured to encode a different capture.
> To: "Duckworth, Mark" <[email-masked]>, Christer Holmberg 
> <[email-masked]>, [email-masked]
> > 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: "Roni Even" <[email-masked]>
Date: Mon, 24 Nov 2014 19:24:43 +0200

Hi Christian,
The issues were that there is no single defined semantics when having
multiple individual encoding to a media capture. If we are talking about
simulcast it will mean that each of the multiple multicast encoding will
have its own m-line in the SDP and this is not the direction that MMUSIC is
taking. The MMUSIC direction is based on the "unified" plan where all
encodings from the same source should be in the same m-line.

Roni

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: 24 November, 2014 9:18 AM
> To: Duckworth, Mark; [email-masked]
group. I
> was trying to see what the impact of this change was. My comment comes out
> of the text in clause 9.3 of the framework,
> 
be
> used to apply to the simulcast streams. If we now move this out mechanism
> out, is there an equivalent for the simulcast cast SDP? b= ?
> 
in the
> draft where it says that a media consumer can only choose one individual
> encoding (i.e. as identified by a=label) for one of the captures
referencing the
> encoding group (i.e. an individual encoding can't be used more than once).
> Does it make sense for two captures (outside a MCC) to share an individual
> encoding?
> 
> Regards, Christian
> 
> > >> As far as I remember, yes. Nobody could come up with a reason why
> > >> it should be kept.
> > >>
> > >> Regards,
> > >>
> > >> Christer
> > >>
> > >>
> > >>>> 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.
> > >>>>
> > >>>>> 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
> > >>>>>
> > >>>>>> Yes, I'd have thought ideally multiple simulcast qualities,
> > >>>>>> repair streams
> > >>>>> etc
> > >>>>>> encoding from CLUE's perspective. That matches the unified plan
> > >>>>>> and the proposal in
> > >>>>> draft-
> > >>>>>> would mean that negotiating simulcast qualities, repair flows
> > >>>>>> etc would be purely an
> > >>>>> SDP
> > >>>>>> Duckworth, Mark
> > >>>>>> 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.
> > >>>>>>
> > >>>>>> are they similar enough that it is really the same issue?  Do
> > >>>>>> SVC layered
> > >>>>> codec
> > >>>>>> Sounds like we do need some more discussion about this.  My
> > >>>>>> first thought
> > >>>>> is
> > >>>>>>> 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
> > >>>>>>> We will need to see how it works with retransmission if we
> > >>>>>>> specify a retransmission RTP stream as an individual encoding.
> > >>>>>>>
> > >>>>>>> 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
> > >>>>>>>>>>>> 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
> > >>>>>>>>>>>> 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
> > >>>>>>>>>>> If you want a pure switched MCC just set
> > >>>>>>>>>>> maxCaptureEncodings to
> > >>>>>>>>>>> 1
> > >>>>>>>>> against the
> > >>>>>>>>>>> MCC.
> > >>>>>>>>>> [Roni Even] The thing is that I am not sure how to
> > >>>>>>>>>> advertise this
> > >>>>>>> example.
> > >>>>>>>>>>     1. Scene view with VC0, VC1, VC2 each with two
> > >>>>>>>>>> simulcast streams
> > >>>>> 2.
> > >>>>>>>>> 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)
> > >>>>>>>>> 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?
> > >>>>>>>>>
> > >>>>>>>>> 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
> > >>>>>>>>> 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.
> > >>>>>>>>>> The other approach may be to have an attribute for an MC
> > >>>>>>>>>> and MCC that
> > >>>>>>>>> will
> > >>>>>>>>> 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.
> > >>>>>>>>>> individual encodings are the same (spatial or different
> > >>>>>>>>>> codces) what if we the provider can send
> > >>>>>>>>>> four different encodings but not all combinations allowed.
> > >>>>>>>>>> How to represent it in an advertisement? Is it :

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 24 Nov 2014 12:34:52 -0800

Hi Christian,

The encoding group maxgroupbandwidth should stay the same as before.  But you raise an interesting point about how it relates to the bandwidth allowed for an SDP m-line when there are multiple RTP flows for a single m-line.  I don't think the issue is just for simulcast, but also for layered coding, FEC, and maybe other reasons.  At first glance it seems to me the sum of all packets associated with an m-line (which is a CLUE encoding) is what counts toward the CLUE encoding group maxgroupbandwidth.  If we need to describe this better, I think the signaling document is the place to do it, because that is where we make the connection between CLUE and SDP.

With respect to multiple captures using one encoding group, the framework section 9.1 says "An Individual Encoding can be assigned to at most one Capture Encoding at any given time."

Regards,
Mark

> Sent: Monday, November 24, 2014 12:25 PM
> To: 'Christian Groves'; Duckworth, Mark; [email-masked]
> > > >>>>>>>>>>> If you want a simultcast MCC just set
> maxCaptureEncodings
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>> =2
> > > >>>>>>>>> against the
> > > >>>>>>>>>>> MCC.

---

From: Christian Groves <[email-masked]>
Date: Tue, 25 Nov 2014 10:45:27 +1100

Hello Mark,

Thanks for the reference to 9.1 I missed the sentence.

With regards to the encoding group maxgroupbandwidth I think it would be 
good to have some sort of guidance for it. If an endpoint uses an 
encoding group with a single encoding that uses 
draft-westerlund-avtcore-rtp-simulcast should it uses maxgroupbandwidth 
or an SDP based mechanism? To me for this case an SDP specific mechanism 
should be used. Maxgroupbandwidth would only come into play when there 
is >1 encoding in the group.

Regards, Christian