Subject: [clue] contradiction in framework about simultaneous captures in a CSE

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 21 Feb 2014 07:06:06 -0800

When we added MCC to the framework, we introduced a contradiction about the provider's ability to encode and send all captures in a CSE simultaneously.

>From section 7.3
"The Provider MUST be capable of encoding and sending all Captures in a single Capture Scene Entry simultaneously."

>From section 9.3
"Each Media Capture MAY be associated with at least one Encoding Group"

The statement from 7.3 is not correct anymore.  Our intent is to allow the advertisement to include captures without an encoding group, but still include those captures in a CSE, as in example 12.3.1 Table 13.  So having a set of captures in a CSE doesn't necessarily mean the provider can encode and send them.

The point of the 7.3 statement is to ensure that encoding limitations and simultaneous set limitations do not prevent a provider from sending all captures in a CSE simultaneously, because that would defeat the purpose of a CSE.  But since we now allow captures without encoding groups, it makes sense to allow CSEs for scenes which the provider has no intention of sending directly at all.

Here is a proposal for changing the sentence in 7.3:
"If all the Captures in a single Capture Scene Entry have an Encoding Group, then the Provider MUST be capable of encoding and sending all those Captures simultaneously."

Is that a good change?

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Feb 2014 11:54:57 -0500

On 2/21/14 10:06 AM, Duckworth, Mark wrote:

> “If all the Captures in a single Capture Scene Entry have an Encoding
> Group, then the Provider MUST be capable of encoding and sending all
> those Captures simultaneously.”
>
> Is that a good change?

The above implies that if some but not all captures in a CSE have 
encoding groups, then there is no requirement for the provider to be 
able to send them simultaneously.

Does it make sense to define a CSE containing captures without encoding 
groups?

Is there any reason to do so?

ISTM that we could instead say that a CSE MUST NOT reference a capture 
that has no encoding group. Then 7.3 would be ok as it is.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 21 Feb 2014 09:20:36 -0800

Hi Paul,

I thought of that possibility also.  But I think our intent was for the provider to be able to advertise the complete scene information for original sources, including CSEs, even if the provider didn't include encoding groups for those captures.  I think it is useful to include the CSEs for captures without encoding groups, because the consumer can use this information for choosing captures, or choosing subsets within MCCs.

Another possibility is to say either all captures in a CSE must include an encoding group, or none of the captures in a CSE can include an encoding group.  I can't think of a case that makes sense to include a mixture.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, February 21, 2014 11:55 AM
> To: [email-masked]
> Subject: Re: [clue] contradiction in framework about simultaneous captures
> in a CSE
> 
> > "If all the Captures in a single Capture Scene Entry have an Encoding
> > those Captures simultaneously."
> >
> > Is that a good change?
> 
> The above implies that if some but not all captures in a CSE have encoding
> groups, then there is no requirement for the provider to be able to send
> them simultaneously.
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Feb 2014 12:39:34 -0500

> Another possibility is to say either all captures in a CSE must include an encoding group, or none of the captures in a CSE can include an encoding group.  I can't think of a case that makes sense…

We can just say that the provider must be capable of simultaneously 
delivering all those captures in a CSE *that have an encoding group*.

That would allow an CSE that has some captures with encoding groups and 
some without. I can't think of any reason to do that, but it seems 
easier than adding more arbitrary rules.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 21 Feb 2014 09:41:47 -0800

That works for me.
Mark

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, February 21, 2014 12:40 PM
> To: Duckworth, Mark; [email-masked]
> > I thought of that possibility also.  But I think our intent was for the provider
> to be able to advertise the complete scene information for original sources,
> including CSEs, even if the provider didn't include encoding groups for those
> captures.  I think it is useful to include the CSEs for captures without encoding
> groups, because the consumer can use this information for choosing
> captures, or choosing subsets within MCCs.
> >
> > Another possibility is to say either all captures in a CSE must include an
> encoding group, or none of the captures in a CSE can include an encoding
> group.  I can't think of a case that makes sense to include a mixture.
> 
> some without. I can't think of any reason to do that, but it seems easier than
> adding more arbitrary rules.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> Subject: Re: [clue] contradiction in framework about simultaneous
> >> captures in a CSE
> >>
> >>> "If all the Captures in a single Capture Scene Entry have an
> >>> Encoding Group, then the Provider MUST be capable of encoding and
> >>> sending all those Captures simultaneously."
> >>>
> >>> Is that a good change?
> >>
> >> Does it make sense to define a CSE containing captures without
> >> encoding groups?
> >>
> >> ISTM that we could instead say that a CSE MUST NOT reference a
> >> capture that has no encoding group. Then 7.3 would be ok as it is.
> >>
> >> 	Thanks,
> >> 	Paul
> >>

---

From: Christian Groves <[email-masked]>
Date: Mon, 24 Feb 2014 12:39:03 +1100

WFM.
Christian