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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]]
>> Sent: 26 October, 2014 11:34 PM
>> To: Roni Even; [e-mail]
>> 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:[e-mail]] On Behalf Of Paul Kyzivat
>>>> Sent: 24 October, 2014 7:57 PM
>>>> To: [e-mail]
>>>> 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:[e-mail]] On Behalf Of Roni Even
>>>>>> Sent: Friday, October 24, 2014 8:19 AM
>>>>>> To: 'Christian Groves'; [e-mail]
>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>>>>
>>>>>> Hi Christian,
>>>>>> Inline
>>>>>> Roni
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: clue [mailto:[e-mail]] On Behalf Of Christian
>>>>>>> Groves
>>>>>>> Sent: 24 October, 2014 4:59 AM
>>>>>>> To: [e-mail]
>>>>>>> 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-simulcast
>>>>>>> -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-simulcast
>>>>>>>> -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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>>
>
>