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

["Roni Even" <[e-mail]>]

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

 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)?






> >
> > 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.
> >
> > As for the data model draft, the example
> > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#secti
> > on-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:[e-mail]]
> >> Sent: 27 October, 2014 1:37 AM
> >> To: Roni Even; [e-mail]
> >> 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:[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-simul
> >>>>>>>>> ca
> >>>>>>>>> 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-simul
> >>>>>>>>>> ca
> >>>>>>>>>> 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
> >>>>>>> [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