Subject: Re: [clue] Christer's initial comments on framework-09

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2013 10:22:04 +0000

Hi,

> For Q1 I think the definition of CSE indicates that its an entire scene.

Yes, the definition is probably ok. I am referring to text elsewhere in the draft.

> With respect to Q2, I agree that's why we made the sending of the simultaneous set optional. If the provider doesn't send the STS the consumer assumes that all captures in the CSE can be provided simultaneously.

EVEN if the provider sends STS, I think a provider MUST be able to provide a CSE.

In my opinion, the only use of STS is when one wants to simultaneously provide captures belonging to different CSE/CS. But, as I indicated earlier, in my opinion is would be better to indicate Simultaneous CSE Set.

Regards,

Christer

On 28/02/2013 11:24 PM, Christer Holmberg wrote:
>
> Hi,
>
> A couple of initial comments:
>
> -------------------
>
> Q1: Capture Scene and Capture Scene Entry editorial
>
> In a few places, there is text saying that "a Capture Scene includes 
> one or more Capture Scene Entries". I think that is a little 
> misleading, because it sounds like one uses one or more CSEs in order 
> to describe a CS.
>
> But, as each single CSE describes the whole scene, I think the text 
> should talk about CSEs providing alternatives for providing the CS.
>
> -------------------
>
> Q2: Simultaneous Transmission Set
>
> We had a long discussion about this some time ago, and we never came 
> to a conclusion. I know there is another thread about STSs also, and I 
> will reply to that.
>
> But, I think that an endpoint shall always be able to simultaneously 
> provide all captures within a given CSE. So, there is no need to 
> explicitly advertise that the captures associated with a given CSE can 
> be provided simultaneously.
>
> -------------------
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Mar 2013 19:15:34 +0800

> EVEN if the provider sends STS, I think a provider MUST be able to provide a CSE.

I think this makes sense, but what to do if the simultaneous set conflicts?

> In my opinion, the only use of STS is when one wants to simultaneously provide captures belonging to different CSE/CS. But, as I indicated earlier, in my opinion is would be better to indicate Simu…

I disagree, because it may be feasible to provide *some* simultaneity 
but not be able to provide two complete CSEs simultaneously.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 5 Mar 2013 08:07:22 -0800

I agree with Christian and Paul about Q1, and think the framework is okay as is.  Section 6.2 says " The Capture Scene Entries in a Capture Scene are different alternatives the provider is suggesting for representing the Capture Scene."

I agree with Christian and Paul about Q2, and think the framework is okay as is regarding the optional Simultaneous Transmission Set.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, March 01, 2013 6:16 AM
> To: [email-masked]
> Subject: Re: [clue] Christer's initial comments on framework-09
> 
> >> With respect to Q2, I agree that's why we made the sending of the
> simultaneous set optional. If the provider doesn't send the STS the consumer
> assumes that all captures in the CSE can be provided simultaneously.
> >
> > In my opinion, the only use of STS is when one wants to simultaneously
> provide captures belonging to different CSE/CS. But, as I indicated earlier, in
> my opinion is would be better to indicate Simultaneous CSE Set.
> 
> I disagree, because it may be feasible to provide *some* simultaneity but
> not be able to provide two complete CSEs simultaneously.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >> to a conclusion. I know there is another thread about STSs also, and
> >> I will reply to that.
> >>
> >> explicitly advertise that the captures associated with a given CSE
> >> can be provided simultaneously.
> >>
> >> -------------------
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Mar 2013 09:41:46 +0000

Hi,

>I agree with Christian and Paul about Q2, and think the framework is okay as is regarding the optional Simultaneous Transmission Set.

I am ok with providing both CSEs and individual captures. 

But, we need to make it clear that, if a provider in the same set entry provides both a CSE and a capture, and the capture is also part of the CSE, it provides two "instances" (we can come up with better wording) of the same capture.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> > Yes, the definition is probably ok. I am referring to text elsewhere 
> > in the
> draft.
> >
> simultaneous set optional. If the provider doesn't send the STS the 
> consumer assumes that all captures in the CSE can be provided simultaneously.
> >
> > EVEN if the provider sends STS, I think a provider MUST be able to 
> > provide
> a CSE.
> 
> provide captures belonging to different CSE/CS. But, as I indicated 
> earlier, in my opinion is would be better to indicate Simultaneous CSE Set.
> 
> >> In a few places, there is text saying that "a Capture Scene 
> >> includes one or more Capture Scene Entries". I think that is a 
> >> little misleading, because it sounds like one uses one or more CSEs 
> >> in order to describe a CS.
> >>
> >> We had a long discussion about this some time ago, and we never 
> >> came to a conclusion. I know there is another thread about STSs 
> >> also, and I will reply to that.
> >>
> >> But, I think that an endpoint shall always be able to 
> >> simultaneously provide all captures within a given CSE. So, there 
> >> is no need to explicitly advertise that the captures associated 
> >> with a given CSE can be provided simultaneously.
> >>
> >> -------------------
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 22:28:42 +0800

> But, we need to make it clear that, if a provider in the same set entry provides both a CSE and a capture, and the capture is also part of the CSE, it provides two "instances" (we can come up with…

Why? I don't think that this necessarily should mean that.
Providing the same capture multiple times is simulcast, and I thought we 
were handling that separately via the MaxCaptureEncodings element of the 
data model.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Mar 2013 14:46:50 +0000

Hi,

> Providing the same capture multiple times is simulcast, and I thought we were handling that separately via the MaxCaptureEncodings element of the data model.

So what does it mean? "Unspecified"?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 23:21:07 +0800

> So what does it mean? "Unspecified"?

"it"? IMO, as Mark said, multiple instances of the same capture in the 
same simultaneous set mean the same as one instance.

And the MaxCaptureEncodings for that, together with the number of 
available encodings in the encoding group associated with that capture, 
determine how many encodings of it you can receive.

Consider a case where a receiver wants to receive two full CSEs that 
happen to have a capture in common. It is quite likely that the receiver 
will only want to receive a single copy of that. Certainly that is 
likely to be the case for an MCU.

	Thanks,
	Paul