Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 1 May 2013 13:56:29 -0700

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2013 11:06 PM
> To: Duckworth, Mark
> Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and
> Capture Scene Entries

> >> [CNG] In some respects not having the CS, CSE in an STS mirrors a
> >> configure response in that it only lists captures. However there
> >> appears to be a problem with a configure when having to return CSE
> parameters.
> >> If a consumer can "choose" attribute values what it mean for STSs?
> >> Does the value setting have an effect on what media capture
> >> combination can be supported in a capture?
> > [Duckworth, Mark] I don't understand the question.  What do you mean by
> "what media capture combination can be supported in a capture"?  I'll look
> for the Capture Scene Entry attribute question and respond separately, I
> don't see how it is related to this thread.
> [CNG] For example: We have a CSE attribute of Scene-Switch-Policy which
> allows a provider to select the value. What I was wondering is if this affects
> what media captures are mentioned in the STS? For switching I might be able
> to support a different number captures than say a segment switch. If a
> consumer advertises an STS with a CSE that is effectively "variable" what
> could this mean? We do say that all captures within an CSE must be able to be
> sent together so it may not be a problem.

 [Duckworth, Mark] I don't see a problem.  If a Provider really wants to express a different Simultaneous Transmission Set depending on the type of Scene-Switch-Policy, then the provider can advertise separate Capture Scene Entries with separate Media Captures, where each Capture Scene Entry has a different Scene-Switch-Policy.  And also use multiple Simultaneous Transmission Sets to express the options for what it can send simultaneously.

Mark

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 10:40:16 +0000

Hi,

> This is a follow up to an action item from IETF-86.  I said I would propose text based on the discussion to allow a 
> Media Provider to represent Simultaneous Transmission Sets in terms of Capture Scenes and Capture Scene 
> Entries.  Currently the framework says a Simultaneous Transmission Set is a set of Media Captures of a particular media type.
>
> === begin proposed new paragraph to add near end of section 6.3 ===
> For shorthand convenience, a Provider may describe a Simultaneous Transmission Set in terms of Capture Scene 
> Entries and Capture Scenes.  If a Capture Scene Entry is included in a Simultaneous Transmission Set, then all Media Captures in the Capture Scene Entry are included in the Simultaneous Transmission Set.  If a Capture Scene is included > in a Simultaneous Transmission Set, then all its Capture Scene Entries (of the corresponding media type) are included 
> in the Simultaneous Transmission Set.  The end result reduces to a set of Media Captures in any case.
> === end proposed new paragraph to add near end of section 6.3 ===
>
> I suggest we do not make this change, and instead just describe a Simultaneous Transmission Set as a set of Media Captures.  I think 
> allowing the additional ways to represent the set adds complication without adding value.  A Media Consumer that wants to use 
> simultaneous sets would have more work to do to parse out the contents of the set.
>
> Your thoughts?

I disagree with your suggestion.

We have had long discussions about this, and if I remember correctly the outcome was that we will allow the STS to contain media captures, CSEs and CSs.

With only allowing media captures, the consumer will have to do work in order to figure out which ones have spatial relationship etc, while a CSE provides that information implicitly.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 May 2013 11:09:40 -0400

> With only allowing media captures, the consumer will have to do work in order to figure out which ones have spatial relationship etc, while a CSE provides that information implicitly.

I don't have a strong opinion on this, either way.

But I find it silly to base the decision on whether more work must be 
done by the provider or the consumer. From a computation perspective it 
is insignificant. From a programming perspective for the developer it is 
a few minutes work, either in the provider code or the consumer code. 
And most implementations will be both provider and consumer, so they 
have to write the code anyway.

One might argue that having this ability will make advertisements 
smaller. In indeed might, but again the difference is going to be 
insignificant in any practical case.

IMO that leaves a few criteria to use to decide:

PRO: make examples and use cases easier to read and write
CON: minimize the complexity of the data model schema

	Thanks,
	Paul (as individual)

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 10:05:46 +0000

Hi,

>>> This is a follow up to an action item from IETF-86.  I said I would 
>>> propose text based on the discussion to allow a Media Provider to 
>>> represent Simultaneous Transmission Sets in terms of Capture Scenes and Capture Scene Entries.  Currently the 
>>> framework says a Simultaneous Transmission Set is a set of Media Captures of a particular media type.
>>>
>>> For shorthand convenience, a Provider may describe a Simultaneous 
>>> Transmission Set in terms of Capture Scene Entries and Capture 
>>> Scenes.  If a Capture Scene Entry is included in a Simultaneous Transmission Set, then all Media Captures in the 
>>> Capture Scene Entry are included in the Simultaneous Transmission Set.  If a Capture Scene is included 
>>> in a Simultaneous Transmission Set, then all its Capture Scene Entries (of the corresponding media type) are included 
>>> I suggest we do not make this change, and instead just describe a 
>>> Simultaneous Transmission Set as a set of Media Captures.  I think 
>>> allowing the additional ways to represent the set adds complication without adding value.  A Media Consumer that wants to use simultaneous sets would have more work to do to parse out the contents of the set.
>>>
>>> Your thoughts?
>>
> But I find it silly to base the decision on whether more work must be done by the provider or the consumer. From a computation perspective it is 
> insignificant. From a programming perspective for the developer it is a few minutes work, either in the provider code or the consumer code. 
> And most implementations will be both provider and consumer, so they have to write the code anyway.
>
> One might argue that having this ability will make advertisements smaller. In indeed might, but again the difference is going to be insignificant in any practical case.

It is not about the code.

But, in many systems the provided, and the consumed, CSE will always be the same - especially when more "low end" devices are used. So, instead of having to always compute the same stuff, simply signal the CSE.

The important thing, as we discussed in Orlando, is to make sure that we get the semantics correct, ie to make sure it is clear what it means when e.g. a media capture is advertised individually, and part of a CSE. Etc.

So, unless there is a technical problem why it won't work, I don't think we shall go back on agreements that we have managed to reach.

Regards,

Christer