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

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 3 Jul 2011 14:31:40 -0700

Folks,

A first draft for the framework has just been posted.

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 03, 2011 2:30 PM
To: Allyn Romanow (allyn)
Cc: [email-masked]; Allyn Romanow (allyn); Andrew Pepperell (apeppere); [email-masked]; [email-masked]
Subject: New Version Notification for draft-romanow-clue-framework-00.txt

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

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

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

The IETF Secretariat

---

From: Roni Even <[email-masked]>
Date: Wed, 27 Jul 2011 07:04:55 +0300

Hi,
Found some time to review the draft, it is a good start but I think it needs
more work. Some comments ( the one from 5 to 8 may look similar but they are
all about the relation between sender and receiver and captures sets as
appear in the draft)

1. This is the major one. I saw "VC0- (the left camera stream), encoding
group:EG0, attributes:purpose=main;auto-switched:no" and "VC5- (the zoomed
out view of all people in the room ), encoding group:EG1, attributes:
purpose=main;auto-switched:no". How do you encode in the messge (the left
camera stream) or (the zoomed out view of all people in the room). How do
you define such information. Without this definition the rest of the syntax
is not enough to understand the offers.

2. in the introduction section it says that this is the basic approach and
mechanism and that next versions will address more use cases. What is next
version, are we going to publish only basic mechanism according to this
draft and have the other in a different draft or is this going to be in new
version of the current draft-romanow-clue-framework

3. In the definition section there is no definition to media stream that is
used in it.

4. The capture set definition "includes Media Captures that all represent
some aspect of the same Capture Scene.  The items (rows) in a Capture Set
represent different alternatives for representing the same  Capture Scene.".
Reading the description I assume that a capture set includes the layout from
the sender perspective and it provide information about the layout or
geometry as well as the content of each capture device. Is this true

5. If 4 is correct than in section 6.3  "A media receiver could choose one
row of each media type (e.g., audio and video) from a capture set.  For
example a three stream receiver  could choose the first video row plus the
audio row, while a single  stream receiver could choose the second or third
video row plus the audio row." I was wondering how can a receiver select
just one capture stream from the capture set if not specified by itself,
like just the left camera or from the example in section 7.1 "{VC0, VC1,
VC2}" just VC0.

6. The text in section 6.3 "An MCU receiver might choose to receive multiple
rows". I thought that rows are physical simultaneity so cannot be sent at
the same time.

7. My understanding from section 4 and 5 "The protocol resulting from the
framework will be declarative rather than negotiative." is that the sender
sends the list of capture set and may send anything from it. I do  not see
how the receiver selects the capture set it wants to receive now or a subset
from it (my question 5). Yet section 6.3 says that the receiver can chose a
capture set from all the offered ones. So is this a negotiation? Defiantly
if it can ask for a capture set that will have only a subset of the captures
in a row.

8.   More on this, in section 7.1 "{VC0, VC3, VC2}" is says "both VC0 and
VC2 are redundant if VC3 is included". What does redundant mean, that VC and
VC2 are not sent or that the receiver can say it wants to receive {VC3} or
{VC0, VC3)

9. In A.5 how is this parameter used?

Regards
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allyn Romanow (allyn)
> Sent: Monday, July 04, 2011 12:32 AM
> To: [email-masked]
> Subject: [clue] FW: New Version Notification for draft-romanow-clue-
> framework-00.txt
> 
> Folks,
> 
> Cc: [email-masked]; Allyn Romanow (allyn); Andrew Pepperell
> (apeppere); [email-masked]; [email-masked]
> A new version of I-D, draft-romanow-clue-framework-00.txt has been
> successfully submitted by Allyn Romanow and posted to the IETF
> repository.
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 27 Jul 2011 08:05:49 -0700

Some answers inline...

> From: Roni Even > 
> Sent: Wednesday, July 27, 2011 12:05 AM
> 
> Hi,

Those notes "(the left camera stream)" and "(the zoomed out view of all people in the room)" are just explanatory notes, not necessarily explicitly encoded.  The left/center/right information is conveyed in Capture Set #1 by the order of VC0, VC1, VC2 in the first row.  The "zoomed out view" could be implied by the video scale attribute and absence of the switched attribute, but that is not shown in this example.  The intent is to provide enough information so the Media Consumer can make a good choice, but not necessarily all possible detail that isn't really required.
 
> version of the current draft-romanow-clue-framework

future versions of current draft.

> 3. In the definition section there is no definition to media stream
> that is used in it.

Stream is defined as "RTP stream as in RFC3550", which itself is not a precise definition.  Do you have a suggestion for a better definition?

> geometry as well as the content of each capture device. Is this true

It includes the spatial relationship of the media captures, which is the ordering from left to right in which they should be rendered.  And the "composed" attribute gives a hint about video layout within a video capture.  We didn't see that more detail about layout or geometry was necessary.

> like just the left camera or from the example in section 7.1 "{VC0, VC1,

Yes, the intent is to allow a receiver to select a subset of media captures from a particular row, it doesn't have to ask for the entire row.  The framework doesn't go into detail about how to do this selection, but I think it is basically just a list of media captures.
 
> rows". I thought that rows are physical simultaneity so cannot be sent
> at the same time.

No, the simultaneous transmission sets are separate from the capture sets.  The simultaneous information may or may not permit multiple capture set rows to be used simultaneously.

> capture set from all the offered ones. So is this a negotiation?
> Defiantly if it can ask for a capture set that will have only a subset of the
> captures in a row.

Maybe the framework isn't clear on how the receiver selects the media captures.  I think it should simply be just a list of media captures, selected from the Media Producer's capture sets, that the Media Consumer sends to the Media Producer.

I'm not sure what is the importance of calling this "declarative" or "negotiative", it doesn't matter to me.

> VC2 are not sent or that the receiver can say it wants to receive {VC3} or

This example should be improved by adding the capture set (remember this is different than the simultaneous transmission set), which would show VC3 by itself in a capture set row.  So since VC3 is all by itself in a row, it represents the entire capture scene, so other VCs for the same scene would be somewhat redundant, but not necessarily disallowed.

> 9. In A.5 how is this parameter used?

One example for usage of the video scale parameter is for a sender to indicate by this attribute that the image in the video is 1 meter wide.  If the receiver has a display that is 2 meters wide, maybe the receiver would like to scale down the video during rendering in order to display it at the correct size for the application.

Regards,
Mark Duckworth

> >    This memo offers a framework for a protocol that enables devices
> in
> > a