Subject: [clue] redefining scene-switch-policy?

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 11 Oct 2013 08:28:30 -0700

Christian, Roni, Weiwei,

draft-groves-clue-multi-content-00 section 3.3.3 has a proposal for renaming the scene-switch-policy attribute, and also proposal to rewrite the description of what this attribute means.  I think this proposal overall is good, in that it gives a more precise description without changing the intent.

But I have a few questions about the proposal (listed below).  Also I wonder if alternatively we could just remove the scene-switch-policy (and proposed capture source synchronization attribute) altogether, if we decide to move forward with the multiple content capture (MCC) with sync-id attribute.  It seems to me that by using MCC with sync-id it can accomplish the same thing in more general way without needing scene-switch-policy.  What do others think?

Questions on section 3.3.3 (these questions are moot if we decide to remove this attribute altogether):

1.       I think it would be useful to add a reference back to the use case document, saying the motivation for this is to enable the use cases related to site-switch and segment-switch as described in the use case document.  Would that help readers understand what this is all about?

2.       I don't understand the statement "However it is assumed that each capture within the CSE will contain the same number and set of sources."  Is this talking about an MCC and the other MCs that could contribute to it?  Why would each capture in a CSE have to contain the same number and set of sources?

3.       I don't understand the two paragraphs about the "Switched" attribute and "Composed" attribute.  It sounds like a proposal to subtly change the meaning of these attributes if the advertiser also uses the Capture Source Synchronization attribute.  I don't get the intent of this, can you explain further?

Mark

---

From: Christian Groves <[email-masked]>
Date: Mon, 14 Oct 2013 14:05:14 +1100

Hello Mark,

Please see my comments below.

Regards, Christian

On 12/10/2013 2:28 AM, Duckworth, Mark wrote:
>
> Christian, Roni, Weiwei,
>
> draft-groves-clue-multi-content-00 section 3.3.3 has a proposal for 
> renaming the scene-switch-policy attribute, and also proposal to 
> rewrite the description of what this attribute means. I think this 
> proposal overall is good, in that it gives a more precise description 
> without changing the intent.
>
[CNG] It wasn't planned to change the intent. Only to clarify.
>
> But I have a few questions about the proposal (listed below). Also I 
> wonder if alternatively we could just remove the scene-switch-policy 
> (and proposed capture source synchronization attribute) altogether, if 
> we decide to move forward with the multiple content capture (MCC) with 
> sync-id attribute. It seems to me that by using MCC with sync-id it 
> can accomplish the same thing in more general way without needing 
> scene-switch-policy. What do others think?
>
[CNG] The intention was that if we accept the MCC concept that we 
wouldn't need the "Scene-switch-policy" attribute and thus it could be 
deleted. So I agree.
> 1.I think it would be useful to add a reference back to the use case 
> document, saying the motivation for this is to enable the use cases 
> related to site-switch and segment-switch as described in the use case 
> document. Would that help readers understand what this is all about?
>
[CNG] OK by me.
>
> 2.I don’t understand the statement “However it is assumed that each 
> capture within the CSE will contain the same number and set of 
> sources.” Is this talking about an MCC and the other MCs that could 
> contribute to it? Why would each capture in a CSE have to contain the 
> same number and set of sources?
>
[CNG] No this isn't considering an MCC. Its considering what the 
consumer can expect to receive. Given the example in sect 3.3.3 
CSE1(VC1,VC2,VC3). It means that the consumer should always expect to 
receive 3 media streams. Not one or two as the CSE indicates that 3 VCs 
make up a scene. e.g. if EP(1) only had 1VC, EP(2) had 2VCs and EP(3) 
had 3VCs then in the synchronous switching case only when you switched 
to EP(3) would the encodings associated with VC1,VC2,VC3 have media.
We could specify other behaviour for this, I took the simplest behaviour 
when proposing the update.

> 3.I don’t understand the two paragraphs about the “Switched” attribute 
> and “Composed” attribute. It sounds like a proposal to subtly change 
> the meaning of these attributes if the advertiser also uses the 
> Capture Source Synchronization attribute. I don’t get the intent of 
> this, can you explain further?
>
[CNG] The intent of those paragraphs is to explain the interaction 
between the "Capture Source Synchronisation" and "switched" and 
"composed" attributes. I.e. what does it mean when they are set 
together? This aspect was missing from the framework. Those paragraphs 
are an attempt to document it.
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 18:09:24 +0000

Hi,

I appologize for suddenly leaving the design team meeting today.

My mobile ran out of battery, and as I was driving I wasn't able to charge it.

Regards,

Christer