Subject: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 2 Oct 2011 20:31:36 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, October 02, 2011 8:28 PM

A new version of I-D, draft-romanow-clue-framework-01.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-framework
Revision:	 01
Title:		 Framework for Telepresence Multi-Streams
Creation date:	 2011-10-03
WG ID:		 Individual Submission
Number of pages: 32

Abstract:
   This memo offers a framework for a protocol that enables devices in a
   telepresence conference to interoperate by specifying the
   relationships between multiple RTP streams.

The IETF Secretariat

---

From: Christian Groves <[email-masked]>
Date: Tue, 04 Oct 2011 14:05:05 +1100

Hello Allyn, all,

Thanks for posting the updated version. Glad to see the inclusion of 
spatial information attributes. A few questions/comments:

5.2.1 Presentation (Nit) - I guess rather than talk about "stream" 
should it say "media capture"?

5.2.2 Audio Mixed / Video Composed - I wondering if it necessary to 
distinguish between these attributes particularly as they are both 
boolean. You know what type the media capture is, i.e. audio or video. 
The key point of the attribute is to indicate whether or not the media 
capture is made up from multiple sources. Could we simply have a 
"mixed/composed" attribute instead of two? i.e. auto switched applies to 
both ACs and VCs.

5.2.4 and 5.2.5, not explicitly stated in the text, I assume that both 
the area and point of capture must both have a common x,y,z origin?

5.2.4 and 5.2.5 also related to the origin and numbering, what is the 
assumption here? Area of Capture only stipulates that the numbers go 
from lower to higher this could mean positive (e.g. 
area_of_capture={xBegin=0, xEnd=100}) and/or negative numbers (e.g. 
area_of_capture={xBegin=-50, xEnd=50}) can be supported??

5.2.4 - Do we need to consider the range start and end when determining 
the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) where:
    o  VC0- (the left camera stream), area_of_capture={xBegin=0, xEnd=33}
    o  VC1- (the center camera stream), area_of_capture={xBegin=33, xEnd=66}
    o  VC2- (the right camera stream), area_of_capture={xBegin=66, xEnd=99}
This example is clear each capture relates to 1/3 of the overall capture 
scene.

Now if instead the capture scene (VC1) was sent. How does the renderer 
put this in context? VC1 is the center capture (thus only 1/3 of the 
providers overall capability). The renderer will receieve xBegin=33 and 
xEnd=66 only and thus conclude its 100% of the capture scene. Do we need 
a means to indicate that the total area is 0 to 99 but the current 
capture only relates to a subset?

5.2.6 Just to clarify if "area scale millimeters" = FALSE, then numbers 
used are relational only? The text doesn't make this explicit.

6.1 : Is it intended that this same message flow be used for 
"re-negotiation" when media captures come and go as per the requirements 
document? Section 7.1 hints at this i.e. "the MCU might re-advertise the 
available media". It would be good if there could be some explicit text 
regarding re-negotiation.

6.1.x - Perhaps the section can be re-ordered to align with the message 
flow?

6.1.2 Consumer Capability Message - Is the intention to provide detailed 
information regarding the attribute values or simply a boolean to say 
which parameters are supported?

7.2.2 Nit : seems to be a superflous "v" above the list.

Regards, Christian

On 3/10/2011 2:31 PM, Allyn Romanow (allyn) wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 4 Oct 2011 08:41:50 -0700

Hello Christian,
Thanks for the comments.
My comments are inline.
Mark Duckworth

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Monday, October 03, 2011 11:05 PM
> To: Allyn Romanow (allyn)
> Cc: [email-masked]
> Subject: Re: [clue] FW: New Version Notification for draft-romanow-
> clue-framework-01.txt
> 
> Hello Allyn, all,
> 

[Duckworth, Mark] agreed
 
> "mixed/composed" attribute instead of two? i.e. auto switched applies

[Duckworth, Mark] I had the same thought.  Audio Mixed and Video Composed are really the same concept, and it can be generalized to any media type.
 
> the area and point of capture must both have a common x,y,z origin?

[Duckworth, Mark] Yes, I think that should be clarified.

> area_of_capture={xBegin=-50, xEnd=50}) can be supported??

[Duckworth, Mark] I agree this needs to be clarified.  I'm not sure what the best answer is.  At first, I was thinking we should restrict the numbers to positive integers, but I'm not sure.

> capture only relates to a subset?

[Duckworth, Mark] I don't think the renderer will reach that conclusion.  The immediate consumer will know about the whole range 0 to 99 from the capture set.  If the immediate consumer is also the renderer, then the renderer knows.  If the immediate consumer is a middlebox, then that middlebox becomes the provider for the next consumer (renderer).  The middlebox constructs its own media captures and capture set with its own area of capture attributes.  These attributes may or may not be the same as from the original providers.  The middlebox advertises captures and a capture set with attributes that make sense for whatever behavior the middlebox is trying to provide.  So the ultimate consumer (the renderer) will know about attributes that make sense in this context from the middlebox.  This consumer doesn't know about any of the attributes from the original producer, it only knows the attributes from the middle box.

> used are relational only? The text doesn't make this explicit.

[Duckworth, Mark] I think so.  The text says "there is no physical scale".  Does that imply the same thing?

> regarding re-negotiation.

[Duckworth, Mark] Yes, this is mentioned in section 5.1, paragraph 2.  Maybe that text from 5.1 really belongs in 6.1, with a bit more clarification.
 
> 6.1.x - Perhaps the section can be re-ordered to align with the message

[Duckworth, Mark] I agree some re-ordering of sections might help.

> which parameters are supported?

[Duckworth, Mark] We're not sure of the details yet.  Needs more thought.
 
> 7.2.2 Nit : seems to be a superflous "v" above the list.

[Duckworth, Mark] I noticed too.

Regards,
Mark Duckworth

---

From: Christian Groves <[email-masked]>
Date: Wed, 05 Oct 2011 14:34:12 +1100

Hello Mark,

Thanks for your reply please see my comments below marked [CNG].

Regards, Christian

..snip..

> [Duckworth, Mark] I agree this needs to be clarified.  I'm not sure what the best answer is.  At first, I was thinking we should restrict the numbers to positive integers, but I'm not sure.
[CNG] I think this is also related to the point below about can the 
start of a range be assumed? i.e. if we only support 0 and up, the 
renderer could assume that the start of a range is always 0.

> [Duckworth, Mark] I don't think the renderer will reach that conclusion.  The immediate consumer will know about the whole range 0 to 99 from the capture set.  If the immediate consumer is also the…
[CNG] I think I wasn't clear in my example. What happens if the received 
capture set only contains VC1 and the consumer didn't previously get a 
capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know 
that "area_of_capture={xBegin=33,xEnd=66}" represents the centre region 
of a range (0..99).

I agree these parameters may be altered along the signalling path.

> [Duckworth, Mark] I think so.  The text says "there is no physical scale".  Does that imply the same thing?
[CNG] I guess it a style things and being bitten before. If there's two 
values (even boolean) I prefer to say what TRUE and FALSE mean rather 
than deriving a meaning of a value from the other.

> [Duckworth, Mark] Yes, this is mentioned in section 5.1, paragraph 2.  Maybe that text from 5.1 really belongs in 6.1, with a bit more clarification.
[CNG] That would be good.

> [Duckworth, Mark] We're not sure of the details yet.  Needs more thought.
[CNG] OK

..snip..

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 5 Oct 2011 13:16:16 -0700

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 11:34 PM
> To: Duckworth, Mark
> Cc: [email-masked]
..snip..
> >> This example is clear each capture relates to 1/3 of the overall
> >> capture scene.
> >>
> > [Duckworth, Mark] I don't think the renderer will reach that
> conclusion.  The immediate consumer will know about the whole range 0
> to 99 from the capture set.  If the immediate consumer is also the
> renderer, then the renderer knows.  If the immediate consumer is a
> middlebox, then that middlebox becomes the provider for the next
> consumer (renderer).  The middlebox constructs its own media captures
> and capture set with its own area of capture attributes.  These
> attributes may or may not be the same as from the original providers.
> The middlebox advertises captures and a capture set with attributes
> that make sense for whatever behavior the middlebox is trying to
> provide.  So the ultimate consumer (the renderer) will know about
> attributes that make sense in this context from the middlebox.  This
> consumer doesn't know about any of the attributes from the original
> producer, it only knows the attributes from the middle box.

[Duckworth, Mark] I still don't understand the case you are asking about.  Are you saying a media producer advertises a capture set with only VC1 with an area of capture from 33 to 66? No other video captures?  If a media producer wants to do this, send only one stream, for some reason, then what does it matter what the area of capture is?  There is nothing else to relate it to, so it doesn't matter.

Regards,
Mark

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Thu, 6 Oct 2011 09:28:18 +0200

Inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: 5. oktober 2011 22:16
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification for
draft-romanow-clue-framework-01.txt

..snip..
> >> the area of capture? Consider the example Capture
Scene(VC0,VC1,VC2)
> >> where:

[Duckworth, Mark] I still don't understand the case you are asking
about.  Are you saying a media producer advertises a capture set with
only VC1 with an area of capture from 33 to 66? No other video captures?
If a media producer wants to do this, send only one stream, for some
reason, then what does it matter what the area of capture is?  There is
nothing else to relate it to, so it doesn't matter.

[Espen]I think its useful that the model support the use case where only
a single camera in a row is announced, e.g. when there are only people
in the central positions in a triple camera system. CLUE does not need
to hide the fact that there is other available cameras that are not
active. 

Regards,
Mark

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Oct 2011 13:45:26 +1100

Hello Mark,

Paul Kyzivat's latest email highlights the situation I was thinking 
about. Whilst the producer only produces one stream it would be 
advantageous to know how this stream fits into the producers overall 
system. If the producer sent
VC0- (the left camera stream), area_of_capture={xBegin=0, xEnd=33}, a 3 
display consumer may assume that 0-33 represents the entire field of 
view and place the stream in the centre position when instead it would 
be more appropriate on the left screen.

I think it would be good if the producer could send the capture range 
for the capture set rather than trying to deduce the range from the 
individual captures.

Currently we only have individual capture attributes, perhaps we need to 
introduce attributes associated with the capture set? capture area range 
could be one. Range format (depending on what is decided): i.e. metric, 
degrees, relational could be another one.

Regards, Christian

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 7 Oct 2011 17:17:02 +0200

Some question related to the framework-1 document. 

5.2. Media capture attributes 

I think we should avoid boolean attributes specifying policies like
video-compose and auto-switched. A sender can choose to forward a single
video stream from a room with different policies for selecting the video
stream. Multiple policies is not easy to express in a Boolean. 

5. Capture scene 
As I read the framework a capture set is always inside a capture scene,
which holds the logical scene information (e.g. name) 

Maybe write out information about capture scene attributes, e.g. to name
scenes like 'Speaker', 'Audience', 'Whiteboard' and so on. I used the
names from the lecture use cases, where the video capture sources are
independent and should be named to be properly indentified on the
receive side. 

6.3.2 
*	How to handle different aspect ratios? If you only specify width
and height, you do not really know if the cameras are able to deliver
4:3 or 16:9? 

6.3.3 
*	Can the encoder groups be shared by media captures? E.g.
examples might be endpoints with multiple sources, but only one can be
encoded at the time.  

6.3.4 
* I assume that the Configure Request can be used to specify attributes
for a stream and concrete encoder that is below what is specified in the
announce? 

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Allyn Romanow (allyn)
Sent: 3. oktober 2011 05:32
To: [email-masked]
Subject: [clue] FW: New Version Notification
fordraft-romanow-clue-framework-01.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, October 02, 2011 8:28 PM

A new version of I-D, draft-romanow-clue-framework-01.txt has been
successfully submitted by Allyn Romanow and posted to the IETF
repository.

Abstract:

The IETF Secretariat

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 7 Oct 2011 11:42:34 -0400

in-line

On Fri, Oct 7, 2011 at 11:17 AM, Espen Berger (espeberg) <[email-masked]
> wrote:

> and height, you do not really know if the cameras are able to deliver
[sb]The capture aspect ratio is width:height, so in fact you do know if the
capture is 4:3 or 16:9.  The pixel aspect ratio can be computed from that,
although with H.264 it is generally signaled in the VUI message as well.

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Fri, 7 Oct 2011 09:54:05 -0700

Forgot to reply directly to Paul but I'd agree that his use case is one
where it'd be advantageous to have an up-front description of the entire
'range'.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Groves
Sent: Thursday, October 06, 2011 7:45 PM
To: Duckworth, Mark
Cc: [email-masked]
Subject: Re: [clue] FW: New Version Notification
fordraft-romanow-clue-framework-01.txt

Hello Mark,

Regards, Christian

Scene(VC0,VC1,VC2)