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

[Christian Groves <[e-mail]>]

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

On 25/11/2014 7:34 AM, Duckworth, Mark wrote:
> 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
>
>> -----Original Message-----
>> From: Roni Even [mailto:[e-mail]]
>> Sent: Monday, November 24, 2014 12:25 PM
>> To: 'Christian Groves'; Duckworth, Mark; [e-mail]
>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>
>> 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
>>
>>> -----Original Message-----
>>> From: clue [mailto:[e-mail]] On Behalf Of Christian Groves
>>> Sent: 24 November, 2014 9:18 AM
>>> To: Duckworth, Mark; [e-mail]
>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>
>>> 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.
>>>> So maybe I'm not understanding your concern?
>>>> Mark
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: Christian Groves <[e-mail]>
>>>> Date:11/23/2014 7:28 PM (GMT-05:00)
>>>> To: "Duckworth, Mark" <[e-mail]>, Christer
>>> Holmberg
>>>> <[e-mail]>, [e-mail]
>>>> 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:[e-mail]] On Behalf Of Christer
>>>> Holmberg
>>>>>> Sent: Friday, November 21, 2014 1:21 AM
>>>>>> To: Christian Groves; [e-mail]
>>>>>> 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:[e-mail]] On Behalf Of Christian
>>>>>>> Groves
>>>>>>> Sent: 21 November 2014 05:25
>>>>>>> To: [e-mail]
>>>>>>> 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:[e-mail]]
>>>>>>>>>> Sent: 12 November, 2014 11:03 PM
>>>>>>>>>> To: Duckworth, Mark; Roni Even
>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>> 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:[e-mail]] On Behalf Of
>>>>>>>>>> Duckworth, Mark
>>>>>>>>>> Sent: 12 November 2014 10:54
>>>>>>>>>> To: Roni Even
>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM
>>>>>>>>>>> To: Duckworth, Mark
>>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>> Sent: 06 November, 2014 9:45 PM
>>>>>>>>>>>> To: Roni Even
>>>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>>>> 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:[e-mail]] On Behalf Of
>>>>>>>>>>>>> Duckworth,
>>>>>>>>>>> Mark
>>>>>>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM
>>>>>>>>>>>>> To: Roni Even; 'Christian Groves'; [e-mail]
>>>>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: clue [mailto:[e-mail]] On Behalf Of
>> Roni
>>>>>>>>>>>>>> Even
>>>>>>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM
>>>>>>>>>>>>>> To: 'Christian Groves'; [e-mail]
>>>>>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: clue [mailto:[e-mail]] On Behalf Of
>>>>>>>>>>>>>>> Christian Groves
>>>>>>>>>>>>>>> Sent: 28 October, 2014 2:56 AM
>>>>>>>>>>>>>>> To: [e-mail]
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>> _______________________________________________
>>>>>>>>>> clue mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>> _______________________________________________
>>>>>>>>> clue mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> clue mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> clue mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>
>>>>>> _______________________________________________
>>>>>> clue mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>> _______________________________________________
>>> clue mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/clue
>