From Christian.Groves@nteczone.com Thu Sep 1 00:02:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9621F87C9 for ; Thu, 1 Sep 2011 00:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6giR15wLe83 for ; Thu, 1 Sep 2011 00:02:02 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA721F880C for ; Thu, 1 Sep 2011 00:02:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAD4rX0520VLN/2dsb2JhbAAMLQmrDAEBAQECAQEBATUbGwQGARALGAkWCAcJAwIBAgEVHxEGDQEFAgEBh24EuCuDNoMlBKRB Received: from ppp118-209-82-205.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.82.205]) by ipmail06.adl2.internode.on.net with ESMTP; 01 Sep 2011 16:33:32 +0930 Message-ID: <4E5F2E24.9050209@nteczone.com> Date: Thu, 01 Sep 2011 17:03:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Marshall Eubanks References: <4E5E0C00.6050208@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 07:02:03 -0000 Hello Marshall, I think your suggested method is worth exploring. Some comments, questions and thinking out loud below marked CNG. Regards, Christian On 31/08/2011 10:07 PM, Marshall Eubanks wrote: > > > On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves > > > wrote: > > Hello, > > Whilst reviewing the use case document use case 4.1 point to point > meeting talks about the possibility for separate monophonic audio > streams. Now this presumably this allows for a microphone to be > placed in front of each participant. > > Now consider a three position (left to right) two row telepresence > system. Each of these has a microphone i.e. 6 audio captures, > Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. > > The current framework document considers video and audio captures > to be left to right. > So its easy to describe the first row AC0, AC1, AC2. How would I > describe using the current framework the audio captures for the > second row microphones? > > Even if we disregard the row (depth) element, how would I then say > AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / > centre / right position? > > > My own personal opinion is that > > - it is dangerous and limiting to attempt to capture equipment spatial > placement in a simple ordered list, especially when that equipment (or > its capture zone) can move and change with time and that > > - we are likely to be sending kilobytes of information about codec > formats and the like , so I don't see why we can't afford a few bytes to > describe a mapping between equipment ids (numbering) and what and > where they are capturing. [CNG] I would agree it seems bytes are cheap these days... > > If you want a specific proposal to deal with this, here is one. > > There are three possible rankings of spatial equipment capture, > transverse, depth and vertical. Call them T, D and V. > > Each can be declared to be relevant, with the assumption that at least > one will be. Ones not declared relevant are ignored. > > Each can be declared to be fixed or variable width. In the case of > fixed width, the width is also declared. > > Units are degrees (T AND V) and meters (D). > > Everything is referenced to the axis of symmetry of the unit, oriented > from the point of view of an observer standing on the axis at the > capture equipment facing the participants (i.e., the point of view of > an outside observer). Order is right to left (T), front to back (D) > and bottom to top (V) . A "starting" value is given (so that we don't > have to deal with negative numbers in the list) and a "unit" value > (the smallest addressable chunk of degrees or meters). [CNG] Just to be 100% sure when you say axis of symmetry of "the unit" do you mean each media capture device or the telepresence system (TPS)? I guess when we start to take into geometries into consideration the description (and implementation) does become more complex. It might get interesting to consider a presentation related capture. Did the framework draft authors consider such an approach when drafting the draft text? > > All spatially equipment is given an ID (could just be numbered, it > doesn't really matter). > > So, assuming the above AC0-AC5, this situation could be dealt with as > something like > > Declare T UNIT 30 STARTING -60 > Declare D UNIT 2 STARTING 2 [CNG] Are these fixed as described above? If so is the width declared? > > Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, > 2,3), (AC5, 3,3), > > where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) > and D zone 2 (2 to 4 meters into the depth of field), etc. [CNG] I'm a bit confused with this example given the declares. Do you mean (ACO, 1,2)? or should AC0 be changed in the ordered list? Given a triplet (AC0,t,d) t=1, d=1 AC0 is the identity t is a multiplier of the unit T in this case 30deg added to the start -60, i.e. (t * 30) + (-60) = -30 d is a multiplier of the unit D in this case 2m added to the start 2, i.e. (d * 2) + (2) = 4 In words how would you describe? (AC4,2,3) e.g. t=2, d=3 > > If there was a camera that covered all 120 degrees, and 3 others that > covered 30 degrees each, that could be > > Declare T VARIABLE UNIT 30 STARTING -60 > > Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1), > > where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 > degree slices), unit VC1 covers -60 to -30 degrees (1 slice), etc. [CNG] How would you handle overlapping regions? [CNG] Would you see it being problematic if rather than specifying this in terms of units and multipliers that the start and end for each of the variables be explicitly used? e.g. Based on T,D,V For video (VC0,[-60:60]),(VC1,[-60:-30])? or in the audio capture case? (AC0,[-60:-30],[2:4]),(AC4,[-30:0],[4:6]) > > I don't see this as really much more complicated or byte consuming and > it really would avoid a bunch of problems I see as coming from > overlaying a potentially variable 3-D spatial order onto a simple list. [CNG] Perhaps another approach is? to treat each capture set as having "a spatial relationship" between media captures however there is no significance of the position of the media capture in the capture set definition itself (i.e. remove all spatial order from the list). The spatial details related to the capture are given as attributes of each media capture, e.g. T, D, V or other as appropriate. > > Regards > Marshall > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From stephen.botzko@gmail.com Thu Sep 1 05:08:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22121F9069 for ; Thu, 1 Sep 2011 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXQYwA49Suqe for ; Thu, 1 Sep 2011 05:08:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC02621F9045 for ; Thu, 1 Sep 2011 05:08:26 -0700 (PDT) Received: by vws12 with SMTP id 12so1680304vws.31 for ; Thu, 01 Sep 2011 05:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=adAtT55REEe6PsLvBxL5xzmh8MgYOrq4oJrgYqP1EMc=; b=Ab2v/y5T8R52U4RtH4y3d1QDhMMGwkqXSz3Xr809lLkTfBj14HJkhZ56/04ue69/Vu ++v2M9yChHGEkTstuKuyUOAV2afm76NZodrMOMZUO2C6KapKYWPQ2s1+P0Al/ns0HVLh FCfDm5xyoKKnppHX/m7SMjGr6EoeU0Ph81+6o= MIME-Version: 1.0 Received: by 10.52.67.38 with SMTP id k6mr117055vdt.510.1314878997556; Thu, 01 Sep 2011 05:09:57 -0700 (PDT) Received: by 10.52.183.100 with HTTP; Thu, 1 Sep 2011 05:09:57 -0700 (PDT) In-Reply-To: References: <4E5E0C00.6050208@nteczone.com> Date: Thu, 1 Sep 2011 08:09:57 -0400 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf307abe6d926ec804abe01f21 Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 12:08:28 -0000 --20cf307abe6d926ec804abe01f21 Content-Type: text/plain; charset=ISO-8859-1 I guess in the limit the safe path is to include a dimensioned engineering drawing of the room in the signaling, showing placement of every sensor, rendering device, and the furniture, and providing real-time coordinate updates for each movable device. Part of the challenge here is to identify the core information that is actually useful to receivers and senders in establishing a good experience between unlike systems, and also to consider what information is actually known by real systems (which often are installed by third party integrators, or are modified after installation, have no means to precisely determine where a handheld camera is aimed, etc). In my view there is a considered trade-off that will have to be made between completeness, complexity, and deployment constraints. This is not to say that we shouldn't review alternatives, or that the submitted framework draft has everything needed. I am just saying that when I work through the use cases with different room designs, I am finding that a lot of the detailed information we could potentially provide is not very useful in creating an interoperable experience. I am also finding that it is very important to structure the information so that it is easy to extract the core parameters you actually need. So I would encourage folks who want to improve the framework (or develop their own alternatives) to attempt to apply their proposals to the use cases - a lot of things that initially seemed important to me didn't turn out to be helpful when I did that. Stephen Botzko On Wed, Aug 31, 2011 at 8:07 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > > > On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves < > Christian.Groves@nteczone.com> wrote: > >> Hello, >> >> Whilst reviewing the use case document use case 4.1 point to point meeting >> talks about the possibility for separate monophonic audio streams. Now this >> presumably this allows for a microphone to be placed in front of each >> participant. >> >> Now consider a three position (left to right) two row telepresence system. >> Each of these has a microphone i.e. 6 audio captures, Front row AC0, AC1, >> AC2, Back row AC3, AC4, AC5. >> >> The current framework document considers video and audio captures to be >> left to right. >> So its easy to describe the first row AC0, AC1, AC2. How would I describe >> using the current framework the audio captures for the second row >> microphones? >> >> Even if we disregard the row (depth) element, how would I then say AC0 & >> AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / centre / right >> position? >> >> > My own personal opinion is that > > - it is dangerous and limiting to attempt to capture equipment spatial > placement in a simple ordered list, especially when that equipment (or its > capture zone) can move and change with time and that > > - we are likely to be sending kilobytes of information about codec formats > and the like , so I don't see why we can't afford a few bytes to > describe a mapping between equipment ids (numbering) and what and where > they are capturing. > > If you want a specific proposal to deal with this, here is one. > > There are three possible rankings of spatial equipment capture, transverse, > depth and vertical. Call them T, D and V. > > Each can be declared to be relevant, with the assumption that at least one > will be. Ones not declared relevant are ignored. > > Each can be declared to be fixed or variable width. In the case of fixed > width, the width is also declared. > > Units are degrees (T AND V) and meters (D). > > Everything is referenced to the axis of symmetry of the unit, oriented from > the point of view of an observer standing on the axis at the capture > equipment facing the participants (i.e., the point of view of an outside > observer). Order is right to left (T), front to back (D) and bottom to top > (V) . A "starting" value is given (so that we don't have to deal with > negative numbers in the list) and a "unit" value (the smallest addressable > chunk of degrees or meters). > > All spatially equipment is given an ID (could just be numbered, it doesn't > really matter). > > So, assuming the above AC0-AC5, this situation could be dealt with as > something like > > Declare T UNIT 30 STARTING -60 > Declare D UNIT 2 STARTING 2 > > Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, 2,3), (AC5, > 3,3), > > where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and D > zone 2 (2 to 4 meters into the depth of field), etc. > > If there was a camera that covered all 120 degrees, and 3 others that > covered 30 degrees each, that could be > > Declare T VARIABLE UNIT 30 STARTING -60 > > Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1), > > where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 > degree slices), unit VC1 covers -60 to -30 degrees (1 slice), etc. > > I don't see this as really much more complicated or byte consuming and it > really would avoid a bunch of problems I see as coming from overlaying a > potentially variable 3-D spatial order onto a simple list. > > Regards > Marshall > > > >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307abe6d926ec804abe01f21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess in the limit the safe path is to include a dimensioned engineering = drawing of the room in the signaling, showing placement of every sensor, re= ndering device, and the furniture, and providing real-time coordinate updat= es for each movable device.

Part of the challenge here is to identify the core information that is = actually useful to receivers and senders in establishing a good experience = between unlike systems, and also to consider what information is actually k= nown by real systems (which often are installed by third party integrators,= or are modified after installation, have no means to precisely determine w= here a handheld camera is aimed, etc). In my view there is a considered tra= de-off that will have to be made between completeness, complexity, and depl= oyment constraints.=A0

This is not to say that we shouldn't review alternatives, or that t= he submitted framework draft has everything needed.=A0 I am just saying tha= t when I work through the use cases with different room designs, I am findi= ng that a lot of the detailed information we could potentially provide is n= ot very useful in creating an interoperable experience.=A0 I am also findin= g that it is very important to structure the information so that it is easy= to extract the core parameters you actually need.=A0

So I would encourage folks who want to improve the framework (or develo= p their own alternatives) to attempt to apply their proposals to the use ca= ses - a lot of things that initially seemed important to me didn't turn= out to be helpful when I did that.

Stephen Botzko

On Wed, Aug 31, 2011 a= t 8:07 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:


On Wed, Aug 31, 2011 a= t 6:25 AM, Christian Groves <Christian.Groves@nteczone.com= > wrote:
Hello,

Whilst reviewing the use case document use case 4.1 point to point meeting = talks about the possibility for separate monophonic audio streams. Now this= presumably this allows for a microphone to be placed in front of each part= icipant.

Now consider a three position (left to right) two row telepresence system. = Each of these has a microphone i.e. 6 audio captures, Front row AC0, AC1, A= C2, Back row AC3, AC4, AC5.

The current framework document considers video and audio captures to be lef= t to right.
So its easy to describe the first row AC0, AC1, AC2. How would I describe u= sing the current framework the audio captures for the second row microphone= s?

Even if we disregard the row (depth) element, how would I then say AC0 &= ; AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / centre / r= ight position?


My own personal opinion is that<= /div>

- it is dangerous and limiting to attempt to captu= re equipment spatial placement in a simple ordered list, especially when th= at equipment (or its capture zone) can move and change with time and that

- we are likely to be sending kilobytes of information = about codec formats and the like , so I don't see why we can't affo= rd a few bytes to
describe a mapping between equipment ids (numbe= ring) and what and where they are capturing.=A0

If you want a specific proposal to deal with this, here= is one.

There are three possible rankings of spat= ial equipment capture, transverse, depth and vertical. Call them T, D and V= .

Each can be declared to be relevant, with the assumptio= n that at least one will be. Ones not declared relevant are ignored.=A0

Each can be declared to be fixed or variable width. I= n the case of fixed width, the width is also declared.

Units are degrees (T AND V) and meters (D).=A0

Everything is referenced to the axis of symmetry of the un= it, oriented from the point of view of an observer standing on the axis at = the capture equipment facing the participants (i.e., the point of view of a= n outside observer). Order is right to left (T), front to back (D) and bott= om to top (V) . A "starting" value is given (so that we don't= have to deal with negative numbers in the list) and a "unit" val= ue (the smallest addressable chunk of degrees or meters).=A0

All spatially equipment is given an ID (could just be n= umbered, it doesn't really matter).=A0

So, ass= uming the above AC0-AC5, this situation could be dealt with as something li= ke

Declare T UNIT 30 STARTING -60
Declare D UNIT= 2 STARTING 2

Order (ACO, 1,2), (AC1, 2, 2),=A0(AC= 2, 3,2),=A0(AC3, 1,3),=A0(AC4, 2,3),=A0(AC5, 3,3),

where=A0(ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and= D zone 2 (2 to 4 meters into the depth of field), etc.

If there was a camera that covered all 120 degrees, and= 3 others that covered 30 degrees each, that could be

<= div>Declare T VARIABLE UNIT 30 STARTING -60

Order = (VC0, 1, 4),=A0(VC1, 1, 1),=A0(VC1, 1, 1),=A0(VC2, 2, 1),=A0(VC3, 3, 1),

where=A0(VC0, 1, 4) means unit VC0 covers from -60 to += 60 degrees (4 30 degree slices), unit VC1 covers -60 to -30 degrees (1 slic= e), etc.=A0

I don't see this as really much mo= re complicated or byte consuming and it really would avoid a bunch of probl= ems I see as coming from overlaying a potentially variable 3-D spatial orde= r onto a simple list.=A0

Regards
Marshall
=
=A0
Regards, Christian

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf307abe6d926ec804abe01f21-- From stephen.botzko@gmail.com Thu Sep 1 07:51:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5E621F8B56 for ; Thu, 1 Sep 2011 07:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia6zFJ1Sa6Z3 for ; Thu, 1 Sep 2011 07:51:47 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5781521F925F for ; Thu, 1 Sep 2011 07:51:30 -0700 (PDT) Received: by qyk35 with SMTP id 35so1165575qyk.10 for ; Thu, 01 Sep 2011 07:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XlDflAH2R5hD3786I5zRitoJiFsgfaD4+owtFuJIN/c=; b=gOGsd2LwgbAD+Wanvm2Tb7o1SOWYVQnXTmQWq95g+k5Vil2hxAgZRpP0IXFpAUp+5i S/XrUs69ciIW/ojeo/aJOt4Q2vtvnk5bceu3mpJita6GNNka6FWpPVKFH1nK32oL+F1/ clC0jsEaRrYMiuJDMgcbvf0zeX7xqvXHJtiOQ= MIME-Version: 1.0 Received: by 10.52.33.134 with SMTP id r6mr304620vdi.309.1314888783302; Thu, 01 Sep 2011 07:53:03 -0700 (PDT) Received: by 10.52.183.100 with HTTP; Thu, 1 Sep 2011 07:53:03 -0700 (PDT) In-Reply-To: <4E5F07ED.7010809@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F07ED.7010809@nteczone.com> Date: Thu, 1 Sep 2011 10:53:03 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=20cf307812bad90e3404abe266fe Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 14:51:48 -0000 --20cf307812bad90e3404abe266fe Content-Type: text/plain; charset=ISO-8859-1 in-line On Thu, Sep 1, 2011 at 12:19 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Stephen, > > Please see my responses below. > > Regards, > Christian > > > > On 31/08/2011 9:47 PM, Stephen Botzko wrote: > >> The current framework draft allows multiple captures to signal the same >> linear index. So it is fine for AC0,AC3 and the the other pairs to all >> signal the same index. This covers the case where the two rows are captured >> in the same video captures (that is, the left camera VC0 captures the left >> side of both rows). If the video capture set is VC0, VC1, VC2, it is >> possible to associate both AC3 and AC0 with VC0. >> > [CNG] OK, linear index is used to indicate the position of an audio capture > rather than the left/right behaviour? [SCB]Yes. That makes it easy to match the sound stage to the displays, and also deals nicely with the situation where the captures are not evenly placed in the room. > > > >> There is a related case, which is when there are also independent cameras >> (AC3 has a corresponding VC3). The framework also allows multiple capture >> sets, so you can signal VC3, VC4, VC5, AC3, AC4, AC5 as its own independent >> capture set. >> > [CNG] However in this case you would need some "depth" parameter/s? > [SCB] That certainly is one option. For many meeting situations receivers > don't really need to know that VC0 is row 1, and VC3 is row 2; but I suspect > there are cases (perhaps educational) where you might want to know this. > > >> There's been quite a bit of discussion on how two "separate monophonic >> streams" relate to a "stereo audio stream" amongst the authors of the >> framework. At this point I believe the conclusion is that the key >> distinction between them is RTP transport. A second possible distinction is >> that some audio codecs allow a stereo audio stream to be jointly encoded, >> providing somewhat better compression. >> > [CNG] I had assumed that the monophonic audio streams were separate RTP > streams. However my question was more looking at the limitation of the > framework model rather than opening how audio is encoded and carried. [SCB] Understood. > > > >> BTW, though it is convenient to think about audio captures as independent >> microphones, it is important to keep in mind that there are other ways to >> generate them. For instance, a microphone array can use beam-forming >> techniques to construct multiple captures from the microphone array. This >> can in principle be done with video, particularly if you also have depth >> information. The framework does not describe how many sensors are used to >> create a capture. >> > [CNG] I agree. My questions came as a result of the use cases which talk > about monophonic stream and microphones. In the beam-forming would the > aspect of "depth" in addition to "linear index" also be useful? > [SCB] Though I don't think you are suggesting this, I'd like to say that I > don't think we need to send all the information needed for receivers to form > the beam, it is much more practical to have senders form it. > I think sorting out how precisely/completely we need to describe the useful > pickup pattern of an audio or video camera needs more discussion. For audio > particularly, sound pickup depends on the sensor array, the room design, and > who/what is in the room at the moment. I don't think its helpful [and often > not even possible] to describe it too exactly, but it is true that we might > need more than a single linear position. One helpful way to sort out what is > needed is to think about the rendering constraints. > > For instance, in almost all non-mobile cases the audio is being rendering > through a linear array of front speakers. If rear speakers are used, they > are generally for sound reinforcement - meaning that they are adjusted so > that the Haas effect ensures that the sound is always perceived as coming > from the front of the room. In that common situation, the one dimensional > linear index (a panning position) is all you really need. Adding more > parameters will not improve the spatial rendering much. Even if you are not > rendering with a simple linear array, creating spatial audio with depth in > telepresence rooms means placing the far-end sound *behind* the monitors - > and adding rear speakers to the room doesn't help you do that. I don't know > any good way to render room audio so it sounds like it is coming from an > arbitrary depth behind a wall-mounted monitor or projector screen. > > However, if a middle box is selecting a subset of the audio captures in a > room, then it conceivably might be necessary to provide more information > about the pickup region. So far I haven't come up with good use case that > shows that though. > > >> Stephen Botzko >> >> >> >> >> On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello, >> >> Whilst reviewing the use case document use case 4.1 point to point >> meeting talks about the possibility for separate monophonic audio >> streams. Now this presumably this allows for a microphone to be >> placed in front of each participant. >> >> Now consider a three position (left to right) two row telepresence >> system. Each of these has a microphone i.e. 6 audio captures, >> Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. >> >> The current framework document considers video and audio captures >> to be left to right. >> So its easy to describe the first row AC0, AC1, AC2. How would I >> describe using the current framework the audio captures for the >> second row microphones? >> >> Even if we disregard the row (depth) element, how would I then say >> AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / >> centre / right position? >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> --20cf307812bad90e3404abe266fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Thu, Sep 1, 2011 at 12:19 AM, = Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Stephen,

Please see my responses below.

Regards,
Christian



On 31/08/2011 9:47 PM, Stephen Botzko wrote:
The current framework draft allows multiple captures to signal the same lin= ear index. =A0So it is fine for AC0,AC3 and the the other pairs to all sign= al the same index. =A0This covers the case where the two rows are captured = in the same video captures (that is, the left camera VC0 captures the left = side of both rows). If the video capture set is VC0, VC1, VC2, =A0it is pos= sible to associate both AC3 and AC0 with VC0.
[CNG] OK, linear index is used to indicate the position of an audio capture= rather than the left/right behaviour?
[SCB]Yes.=A0 That m= akes it easy to match the sound stage to the displays, and also deals nicel= y with the situation where the captures are not evenly placed in the room.<= br>



There is a related case, which is when there are also independent cameras (= AC3 has a corresponding VC3). =A0The framework also allows multiple capture= sets, so you can signal VC3, VC4, VC5, AC3, AC4, AC5 as its own independen= t capture set.
[CNG] However in this case you would need some "depth" parameter/= s?
[SCB]=A0 That certainly is one option.=A0 For many meet= ing situations receivers don't really need to know that VC0 is row 1, a= nd VC3 is row 2; but I suspect there are cases (perhaps educational) where = you might want to know this.


There's been quite a bit of discussion on how two "separate monoph= onic streams" relate to a "stereo audio stream" amongst the = authors of the framework. =A0At this point I believe the conclusion is that= the key distinction between them is RTP transport. =A0A second possible di= stinction is that some audio codecs allow a stereo audio stream to be joint= ly encoded, providing somewhat better compression.
[CNG] I had assumed that the monophonic audio streams were separate RTP str= eams. However my question was more looking at the limitation of the framewo= rk model rather than opening how audio is encoded and carried.
[SCB] Understood.



BTW, though it is convenient to think about audio captures as independent m= icrophones, it is important to keep in mind that there are other ways to ge= nerate them. =A0For instance, a microphone array can use beam-forming techn= iques to construct multiple captures from the microphone array. =A0This can= in principle be done with video, particularly if you also have depth infor= mation. The framework does not describe how many sensors are used to create= a capture.
[CNG] I agree. My questions came as a result of the use cases which talk ab= out monophonic stream and microphones. In the beam-forming would the aspect= of "depth" in addition to "linear index" also be usefu= l?
=A0
[SC= B] Though I don't think you are suggesting this, I'd like to say th= at I don't think we need to send all the information needed for receive= rs to form the beam, it is much more practical to have senders form it.=A0 =
=A0
I t= hink sorting out how precisely/completely we need to describe the useful pi= ckup pattern of an audio or video camera needs more discussion.=A0 For audi= o particularly, sound pickup depends on the sensor array, the room design, = and who/what is in the room at the moment.=A0 I don't think its helpful= [and often not even possible] to describe it too exactly, but it is true t= hat we might need more than a single linear position. One helpful way to so= rt out what is needed is to think about the rendering constraints.
=A0
For instance, in almost all non-mobile cases the audio is being r= endering through a linear array of front speakers.=A0 If rear speakers are = used, they are generally for sound reinforcement - meaning that they are ad= justed so that the Haas effect ensures that the sound is always perceived a= s coming from the front of the room. =A0 In that common situation, the one = dimensional linear index (a panning position) is all you really need.=A0 Ad= ding more parameters will not improve the spatial rendering much.=A0 Even i= f you are not rendering with a simple linear array, creating spatial audio = with depth in telepresence rooms means placing the far-end sound behind<= /u> the monitors - and adding rear speakers to the room doesn't help yo= u do that. I don't know any good way to render room audio so it sounds = like it is coming from an arbitrary depth behind a wall-mounted monitor or = projector screen.=A0
=A0
However, if a middle box is selecting a subset of the audio captu= res in a room, then it conceivably might be necessary to provide more infor= mation about the pickup region.=A0 So far I haven't come up with good u= se case that shows that though.

=A0

Stephen Botzko




On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0Hello,

=A0 =A0Whilst reviewing the use case document use case 4.1 point to point<= br> =A0 =A0meeting talks about the possibility for separate monophonic audio =A0 =A0streams. Now this presumably this allows for a microphone to be
=A0 =A0placed in front of each participant.

=A0 =A0Now consider a three position (left to right) two row telepresence<= br> =A0 =A0system. Each of these has a microphone i.e. 6 audio captures,
=A0 =A0Front row AC0, AC1, AC2, Back row AC3, AC4, AC5.

=A0 =A0The current framework document considers video and audio captures =A0 =A0to be left to right.
=A0 =A0So its easy to describe the first row AC0, AC1, AC2. How would I =A0 =A0describe using the current framework the audio captures for the
=A0 =A0second row microphones?

=A0 =A0Even if we disregard the row (depth) element, how would I then say<= br> =A0 =A0AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same l= eft /
=A0 =A0centre / right position?

=A0 =A0Regards, Christian

=A0 =A0_______________________________________________
=A0 =A0clue mailing list
=A0 =A0clue@ietf.org <mailto:clue@ietf.o= rg>

=A0 =A0https://www.ietf.org/mailman/listinfo/clue



--20cf307812bad90e3404abe266fe-- From marshall.eubanks@gmail.com Thu Sep 1 09:27:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F3821F9633 for ; Thu, 1 Sep 2011 09:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.858 X-Spam-Level: X-Spam-Status: No, score=-100.858 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP7zIw661xnK for ; Thu, 1 Sep 2011 09:27:50 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D127321F9632 for ; Thu, 1 Sep 2011 09:27:49 -0700 (PDT) Received: by gwb20 with SMTP id 20so1259708gwb.31 for ; Thu, 01 Sep 2011 09:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zzbM2UX1EgYlUuZtikyGW1UC317WEiqAPA491P81794=; b=ZFY9+sJ7p0wE319/I5ymGqzVNIscLc14Xao5BmxbHGTmg6Ipw3dPqvre3N3Kq3i7PG q8YvkRM0jJ2XGjLFIZYfeLESyrkZAv44bQX26BurO3+2Nu/OHLM509EstH9eJdJGWvNl Q/TNF0RwDhYoLzMiPqUrk8MiJ4V3DMe8mopY8= MIME-Version: 1.0 Received: by 10.151.51.7 with SMTP id d7mr208990ybk.426.1314894563034; Thu, 01 Sep 2011 09:29:23 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Thu, 1 Sep 2011 09:29:22 -0700 (PDT) In-Reply-To: <4E5F2E24.9050209@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> Date: Thu, 1 Sep 2011 12:29:22 -0400 Message-ID: From: Marshall Eubanks To: Christian Groves Content-Type: multipart/alternative; boundary=0015174c0e8858c8df04abe3bfba Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 16:27:51 -0000 --0015174c0e8858c8df04abe3bfba Content-Type: text/plain; charset=ISO-8859-1 Dear Christian; On Thu, Sep 1, 2011 at 3:03 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Marshall, > > I think your suggested method is worth exploring. Some comments, questions > and thinking out loud below marked CNG. > > Regards, Christian > > On 31/08/2011 10:07 PM, Marshall Eubanks wrote: > > >> >> On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello, >> >> Whilst reviewing the use case document use case 4.1 point to point >> meeting talks about the possibility for separate monophonic audio >> streams. Now this presumably this allows for a microphone to be >> placed in front of each participant. >> >> Now consider a three position (left to right) two row telepresence >> system. Each of these has a microphone i.e. 6 audio captures, >> Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. >> >> The current framework document considers video and audio captures >> to be left to right. >> So its easy to describe the first row AC0, AC1, AC2. How would I >> describe using the current framework the audio captures for the >> second row microphones? >> >> Even if we disregard the row (depth) element, how would I then say >> AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / >> centre / right position? >> >> >> My own personal opinion is that >> >> - it is dangerous and limiting to attempt to capture equipment spatial >> placement in a simple ordered list, especially when that equipment (or its >> capture zone) can move and change with time and that >> >> - we are likely to be sending kilobytes of information about codec formats >> and the like , so I don't see why we can't afford a few bytes to >> describe a mapping between equipment ids (numbering) and what and where >> they are capturing. >> > [CNG] I would agree it seems bytes are cheap these days... > > >> If you want a specific proposal to deal with this, here is one. >> >> There are three possible rankings of spatial equipment capture, >> transverse, depth and vertical. Call them T, D and V. >> >> Each can be declared to be relevant, with the assumption that at least one >> will be. Ones not declared relevant are ignored. >> >> Each can be declared to be fixed or variable width. In the case of fixed >> width, the width is also declared. >> >> Units are degrees (T AND V) and meters (D). >> >> Everything is referenced to the axis of symmetry of the unit, oriented >> from the point of view of an observer standing on the axis at the capture >> equipment facing the participants (i.e., the point of view of an outside >> observer). Order is right to left (T), front to back (D) and bottom to top >> (V) . A "starting" value is given (so that we don't have to deal with >> negative numbers in the list) and a "unit" value (the smallest addressable >> chunk of degrees or meters). >> > [CNG] Just to be 100% sure when you say axis of symmetry of "the unit" do > you mean each media capture device or the telepresence system (TPS)? I guess > when we start to take into geometries into consideration the description > (and implementation) does become more complex. It might get interesting to > consider a presentation related capture. > In many physics problems, determining the appropriate frame of reference is half of the battle, and I suspect that this will be the case here as well. I find it useful to use the imagery and nomenclature of stagecraft in videoconferencing and telepresence. There is, of course, a rather longer history of running code in the theater and related arts. In the theater, as in videoconferencing and telepresence, there is a local audience. There are also performers (in theater) or remote participants (in telepresence). Think about the most basic things in that situation - There is a spatial division between the audience and the performers. The audience is here, the performers are over there. - The audience sits and looks in some direction. They may look left or right, up or down, but they almost never have to turn around and look behind them. The performers occupy in the forward directions they can look at comfortably. - There is almost always a default direction (what the audience looks at if they look straight ahead) which is an axis of symmetry for the entire room. (That is true even for theater in the round.) This basic setup is seen across cultures, in theater, music, teachers in schools, religious ceremonies, judges in courtrooms, etc. It was familiar to the ancient Greeks, not to mention the Chinese, Japanese, etc. It is also the basic setup for all of the telepresence solutions I know of. There is so much running code here that if we can accommodate it, we are probably "future-proof" for some time to come. That is what I think we should aim for, and that is what I was trying to do. So, I use the axis of symmetry as the basic reference point. Think of it as, where the audience is looking. If someone can come up with a better reference point, I am not wed to it, but I would want to accommodate all of the above cases. > > Did the framework draft authors consider such an approach when drafting the > draft text? > > I have urged this verbally but hadn't previously put in writing. > > >> All spatially equipment is given an ID (could just be numbered, it doesn't >> really matter). >> >> So, assuming the above AC0-AC5, this situation could be dealt with as >> something like >> >> Declare T UNIT 30 STARTING -60 >> Declare D UNIT 2 STARTING 2 >> > [CNG] Are these fixed as described above? If so is the width declared? > > The width is UNIT. I like WIDTH better. so 1,$s/UNIT/UNIT_WIDTH/ > >> Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, 2,3), (AC5, >> 3,3), >> >> where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and D >> zone 2 (2 to 4 meters into the depth of field), etc. >> > [CNG] I'm a bit confused with this example given the declares. Do you mean > (ACO, 1,2)? or should AC0 be changed in the ordered list? > Given a triplet (AC0,t,d) t=1, d=1 > AC0 is the identity > t is a multiplier of the unit T in this case 30deg added to the start > -60, > i.e. (t * 30) + (-60) = -30 > d is a multiplier of the unit D in this case 2m added to the start 2, > i.e. (d * 2) + (2) = 4 > > In words how would you describe? (AC4,2,3) e.g. t=2, d=3 > > > >> If there was a camera that covered all 120 degrees, and 3 others that >> covered 30 degrees each, that could be >> >> Declare T VARIABLE UNIT 30 STARTING -60 >> >> Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1), >> >> Note that there is a typo here - VC > where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 >> degree slices), unit VC1 covers -60 to -30 degrees (1 slice), etc. >> > [CNG] How would you handle overlapping regions? > > > [CNG] Would you see it being problematic if rather than specifying this in > terms of units and multipliers that the start and end for each of the > variables be explicitly used? > e.g. Based on T,D,V > For video > (VC0,[-60:60]),(VC1,[-60:-30])**? > or in the audio capture case? > (AC0,[-60:-30],[2:4]),(AC4,[-**30:0],[4:6]) > > > >> I don't see this as really much more complicated or byte consuming and it >> really would avoid a bunch of problems I see as coming from overlaying a >> potentially variable 3-D spatial order onto a simple list. >> > [CNG] Perhaps another approach is? to treat each capture set as having "a > spatial relationship" between media captures however there is no > significance of the position of the media capture in the capture set > definition itself (i.e. remove all spatial order from the list). The spatial > details related to the capture are given as attributes of each media > capture, e.g. T, D, V or other as appropriate. > > > > > >> Regards >> Marshall >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> --0015174c0e8858c8df04abe3bfba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Christian;


On Thu, Sep 1, 2011 = at 3:03 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Marshall,

I think your suggested method is worth exploring. Some comments, questions = and thinking out loud below marked CNG.

Regards, Christian

On 31/08/2011 10:07 PM, Marshall Eubanks wrote:



On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0Hello,

=A0 =A0Whilst reviewing the use case document use case 4.1 point to point<= br> =A0 =A0meeting talks about the possibility for separate monophonic audio =A0 =A0streams. Now this presumably this allows for a microphone to be
=A0 =A0placed in front of each participant.

=A0 =A0Now consider a three position (left to right) two row telepresence<= br> =A0 =A0system. Each of these has a microphone i.e. 6 audio captures,
=A0 =A0Front row AC0, AC1, AC2, Back row AC3, AC4, AC5.

=A0 =A0The current framework document considers video and audio captures =A0 =A0to be left to right.
=A0 =A0So its easy to describe the first row AC0, AC1, AC2. How would I =A0 =A0describe using the current framework the audio captures for the
=A0 =A0second row microphones?

=A0 =A0Even if we disregard the row (depth) element, how would I then say<= br> =A0 =A0AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same l= eft /
=A0 =A0centre / right position?


My own personal opinion is that

- it is dangerous and limiting to attempt to capture equipment spatial plac= ement in a simple ordered list, especially when that equipment (or its capt= ure zone) can move and change with time and that

- we are likely to be sending kilobytes of information about codec formats = and the like , so I don't see why we can't afford a few bytes to describe a mapping between equipment ids (numbering) and what and where the= y are capturing.
[CNG] I would agree it seems bytes are cheap these days...


If you want a specific proposal to deal with this, here is one.

There are three possible rankings of spatial equipment capture, transverse,= depth and vertical. Call them T, D and V.

Each can be declared to be relevant, with the assumption that at least one = will be. Ones not declared relevant are ignored.

Each can be declared to be fixed or variable width. In the case of fixed wi= dth, the width is also declared.

Units are degrees (T AND V) and meters (D).

Everything is referenced to the axis of symmetry of the unit, oriented from= the point of view of an observer standing on the axis at the capture equip= ment facing the participants (i.e., the point of view of an outside observe= r). Order is right to left (T), front to back (D) and bottom to top (V) . A= "starting" value is given (so that we don't have to deal wit= h negative numbers in the list) and a "unit" value (the smallest = addressable chunk of degrees or meters).
[CNG] Just to be 100% sure when you say axis of symmetry of "the unit&= quot; do you mean each media capture device or the telepresence system (TPS= )? I guess when we start to take into geometries into consideration the des= cription (and implementation) does become more complex. It might get intere= sting to consider a presentation related capture.


In many physics problems, d= etermining the appropriate frame of reference is half of the battle, and I = suspect that this will be the case here as well.

I find it useful to use the imagery and nomenclature of stagecraft in video= conferencing and telepresence. There is, of course, a rather longer history= of running code in the theater and related arts. In the theater, as in vid= eoconferencing and telepresence, there is a local audience. There are also = performers (in theater) or remote participants (in telepresence). Think abo= ut the most basic things in that situation

- There is a spatial division between the audience and = the performers. The audience is here, the performers are over there.=A0

- The audience sits and looks in some direction. They= may look left or right, up or down, but they almost never have to turn aro= und and look behind them. The performers occupy in the forward directions t= hey can look at comfortably.=A0

- There is almost =A0always a default direction (what t= he audience looks at if they look straight ahead) which is an axis of symme= try for the entire room. (That is true even for theater in the round.)=A0

This basic setup is seen across cultures, in theater, m= usic, teachers in schools, religious ceremonies, judges in courtrooms, etc.= It was familiar to the ancient Greeks, not to mention the Chinese, Japanes= e, etc. It is also the basic setup for all of the telepresence solutions I = know of. There is so much running code here that if we can accommodate it, = we are probably "future-proof" for some time to come. That is wha= t I think we should aim for, and that is what I was trying to do.

So, I use the axis of symmetry as the basic reference p= oint. Think of it as, where the audience is looking. If someone can come up= with a better reference point, I am not wed to it, but I would want to acc= ommodate all of the above cases.=A0
=A0

Did the framework draft authors consider such an approach when drafting the= draft text?


I have urged th= is verbally but hadn't previously put in writing.
=A0


All spatially equipment is given an ID (could just be numbered, it doesn= 9;t really matter).

So, assuming the above AC0-AC5, this situation could be dealt with as somet= hing like

Declare T UNIT 30 STARTING -60
Declare D UNIT 2 STARTING 2
[CNG] Are these fixed as described above? If so is the width declared?
=

The width is UNIT. I like WIDTH = better.

so

1,$s/UNIT/UNIT= _WIDTH/
=A0



Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, 2,3), (AC5, 3,= 3),

where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and D = zone 2 (2 to 4 meters into the depth of field), etc.
[CNG] I'm a bit confused with this example given the declares. Do you m= ean (ACO, 1,2)? or should AC0 be changed in the ordered list?
=A0 =A0 =A0Given a triplet (AC0,t,d) =A0t=3D1, d=3D1
=A0 =A0 =A0AC0 is the identity
=A0 =A0 =A0t is a multiplier of the unit T in this case 30deg added to the= start -60,
=A0 =A0 =A0 =A0 =A0 i.e. (t * 30) + (-60) =3D -30
=A0 =A0 =A0d is a multiplier of the unit D in this case 2m added to the st= art 2,
=A0 =A0 =A0 =A0 =A0 i.e. (d * 2) + (2) =3D 4

In words how would you describe? (AC4,2,3) =A0e.g. t=3D2, d=3D3



If there was a camera that covered all 120 degrees, and 3 others that cover= ed 30 degrees each, that could be

Declare T VARIABLE UNIT 30 STARTING -60

Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1),


Note that there is = a typo here - VC
=A0
where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 degre= e slices), unit VC1 covers -60 to -30 degrees (1 slice), etc.
[CNG] How would you handle overlapping regions?


[CNG] Would you see it being problematic if rather than specifying this in = terms of units and multipliers that the start and end for each of the varia= bles be explicitly used?
e.g. Based on T,D,V
For video
=A0 =A0 (VC0,[-60:60]),(VC1,[-60:-30])?
or in the audio capture case?
=A0 =A0 (AC0,[-60:-30],[2:4]),(AC4,[-30:0],[4:6])



I don't see this as really much more complicated or byte consuming and = it really would avoid a bunch of problems I see as coming from overlaying a= potentially variable 3-D spatial order onto a simple list.
[CNG] Perhaps another approach is? to treat each capture set as having &quo= t;a spatial relationship" between media captures however there is no s= ignificance of the position of the media capture in the capture set definit= ion itself (i.e. remove all spatial order from the list). The spatial detai= ls related to the capture are given as attributes of each media capture, e.= g. T, D, V or other as appropriate.





Regards
Marshall

=A0 =A0Regards, Christian

=A0 =A0_______________________________________________
=A0 =A0clue mailing list
=A0 =A0clue@ietf.org <mailto:clue@ietf.o= rg>

--0015174c0e8858c8df04abe3bfba-- From marshall.eubanks@gmail.com Thu Sep 1 09:56:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED121F97D3 for ; Thu, 1 Sep 2011 09:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OOldgn4nYJd for ; Thu, 1 Sep 2011 09:56:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E150E21F97D0 for ; Thu, 1 Sep 2011 09:56:11 -0700 (PDT) Received: by gyf3 with SMTP id 3so1892234gyf.31 for ; Thu, 01 Sep 2011 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ltL0wr0vETMuKRIFbaFtmWxXOvmt8vvGebL7VRUedyg=; b=PTOuVaoT6Yfpbhx0mF7P5lsyiOi47zmv/iK8CKGL7D6t2RniUOEFvwfrtIkUtJJ3Kx VDCfXHerd8uldUZefRJ5rsavezBCW4KLzoJB7pvufxkc5qW70kc/GUX5MvD4VS8Xz2DT BjzV1o73rftv0nsNUubp/9Kj/DF93hKIs19a8= MIME-Version: 1.0 Received: by 10.150.150.41 with SMTP id x41mr260741ybd.255.1314896265145; Thu, 01 Sep 2011 09:57:45 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Thu, 1 Sep 2011 09:57:44 -0700 (PDT) In-Reply-To: <4E5F2E24.9050209@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> Date: Thu, 1 Sep 2011 12:57:44 -0400 Message-ID: From: Marshall Eubanks To: Christian Groves Content-Type: multipart/alternative; boundary=000e0cd70c92cceefb04abe42435 Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 16:56:13 -0000 --000e0cd70c92cceefb04abe42435 Content-Type: text/plain; charset=ISO-8859-1 Dear Christian; On Thu, Sep 1, 2011 at 3:03 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Marshall, > > I think your suggested method is worth exploring. Some comments, questions > and thinking out loud below marked CNG. > > Regards, Christian > > On 31/08/2011 10:07 PM, Marshall Eubanks wrote: > > >> >> On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello, >> >> Whilst reviewing the use case document use case 4.1 point to point >> meeting talks about the possibility for separate monophonic audio >> streams. Now this presumably this allows for a microphone to be >> placed in front of each participant. >> >> Now consider a three position (left to right) two row telepresence >> system. Each of these has a microphone i.e. 6 audio captures, >> Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. >> >> The current framework document considers video and audio captures >> to be left to right. >> So its easy to describe the first row AC0, AC1, AC2. How would I >> describe using the current framework the audio captures for the >> second row microphones? >> >> Even if we disregard the row (depth) element, how would I then say >> AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / >> centre / right position? >> >> >> My own personal opinion is that >> >> - it is dangerous and limiting to attempt to capture equipment spatial >> placement in a simple ordered list, especially when that equipment (or its >> capture zone) can move and change with time and that >> >> - we are likely to be sending kilobytes of information about codec formats >> and the like , so I don't see why we can't afford a few bytes to >> describe a mapping between equipment ids (numbering) and what and where >> they are capturing. >> > [CNG] I would agree it seems bytes are cheap these days... > > >> If you want a specific proposal to deal with this, here is one. >> >> There are three possible rankings of spatial equipment capture, >> transverse, depth and vertical. Call them T, D and V. >> >> Each can be declared to be relevant, with the assumption that at least one >> will be. Ones not declared relevant are ignored. >> >> Each can be declared to be fixed or variable width. In the case of fixed >> width, the width is also declared. >> >> Units are degrees (T AND V) and meters (D). >> >> Everything is referenced to the axis of symmetry of the unit, oriented >> from the point of view of an observer standing on the axis at the capture >> equipment facing the participants (i.e., the point of view of an outside >> observer). Order is right to left (T), front to back (D) and bottom to top >> (V) . A "starting" value is given (so that we don't have to deal with >> negative numbers in the list) and a "unit" value (the smallest addressable >> chunk of degrees or meters). >> > [CNG] Just to be 100% sure when you say axis of symmetry of "the unit" do > you mean each media capture device or the telepresence system (TPS)? I guess > when we start to take into geometries into consideration the description > (and implementation) does become more complex. It might get interesting to > consider a presentation related capture. > In many physics problems, determining the appropriate frame of reference is half of the battle, and I suspect that this will be the case here as well. I find it useful to use the imagery and nomenclature of stagecraft in videoconferencing and telepresence. There is, of course, a rather longer history of running code in the theater and related arts. In the theater, as in videoconferencing and telepresence, there is a local audience. There are also performers (in theater) or remote participants (in telepresence). Think about the most basic things in that situation - There is a spatial division between the audience and the performers. The audience is here, the performers are over there. - The audience sits and looks in some direction. They may look left or right, up or down, but they almost never have to turn around and look behind them. The performers occupy in the forward directions they can look at comfortably. - There is almost always a default direction (what the audience looks at if they look straight ahead) which is an axis of symmetry for the entire room. (That is true even for theater in the round.) This basic setup is seen across cultures, in theater, music, teachers in schools, religious ceremonies, judges in courtrooms, etc. It was familiar to the ancient Greeks, not to mention the Chinese, Japanese, etc. It is also the basic setup for all of the telepresence solutions I know of. There is so much running code here that if we can accommodate it, we are probably "future-proof" for some time to come. That is what I think we should aim for, and that is what I was trying to do. So, I use the axis of symmetry as the basic reference point. Think of it as, where the audience is looking. If someone can come up with a better reference point, I am not wed to it, but I would want to accommodate all of the above cases. > > Did the framework draft authors consider such an approach when drafting the > draft text? > > I have urged this verbally but hadn't previously put in writing. > > >> All spatially equipment is given an ID (could just be numbered, it doesn't >> really matter). >> >> So, assuming the above AC0-AC5, this situation could be dealt with as >> something like >> >> Declare T UNIT 30 STARTING -60 >> Declare D UNIT 2 STARTING 2 >> > [CNG] Are these fixed as described above? If so is the width declared? > > The width is UNIT. I like WIDTH better. so 1,$s/UNIT/UNIT_WIDTH/ > >> Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, 2,3), (AC5, >> 3,3), >> >> where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and D >> zone 2 (2 to 4 meters into the depth of field), etc. >> > [CNG] I'm a bit confused with this example given the declares. Do you mean > (ACO, 1,2)? or should AC0 be changed in the ordered list? > Given a triplet (AC0,t,d) t=1, d=1 > AC0 is the identity > t is a multiplier of the unit T in this case 30deg added to the start > -60, > i.e. (t * 30) + (-60) = -30 > d is a multiplier of the unit D in this case 2m added to the start 2, > i.e. (d * 2) + (2) = 4 > > In words how would you describe? (AC4,2,3) e.g. t=2, d=3 > > > >> If there was a camera that covered all 120 degrees, and 3 others that >> covered 30 degrees each, that could be >> >> Declare T VARIABLE UNIT 30 STARTING -60 >> >> Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1), >> >> Note that there is a typo here - VC1 is repeated. > where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 >> degree slices), unit VC1 covers -60 to -30 degrees (1 slice), etc. >> > [CNG] How would you handle overlapping regions? > > Just do it. The above is overlapping - VC0 overlaps VC1, 2 and 3. Or, if you mean, how should the consumer handle overlapping regions - I don't see that as our job. We set up the infrastructure to describe what's going on. Maybe the consumer only has one screen for this remote site, so they use VC0. Maybe they have lots of bandwidth, but only one screen, so instead they monitor VC0 and use it to pick between VC1, 2 or 3. Maybe they crop overlaps. Whatever. IMO we shouldn't be specifying that. > > [CNG] Would you see it being problematic if rather than specifying this in > terms of units and multipliers that the start and end for each of the > variables be explicitly used? > e.g. Based on T,D,V > For video > (VC0,[-60:60]),(VC1,[-60:-30])**? > or in the audio capture case? > (AC0,[-60:-30],[2:4]),(AC4,[-**30:0],[4:6]) > > Sure. I do not have a good understanding as to what the vendors are comfortable with here - whether they want very simple commands or the full granularity. They should drive that aspect here IMO. I said before that some relation (T or V or D) should be assumed to be present, but it came to me that a one camera mono sound unit doesn't need this, so that could be assumed if the ordering was absent. > >> I don't see this as really much more complicated or byte consuming and it >> really would avoid a bunch of problems I see as coming from overlaying a >> potentially variable 3-D spatial order onto a simple list. >> > [CNG] Perhaps another approach is? to treat each capture set as having "a > spatial relationship" between media captures however there is no > significance of the position of the media capture in the capture set > definition itself (i.e. remove all spatial order from the list). The spatial > details related to the capture are given as attributes of each media > capture, e.g. T, D, V or other as appropriate. > > > I am not sure I am parsing that correctly. Could you provide an example ? Regards Marshall > > > >> Regards >> Marshall >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> --000e0cd70c92cceefb04abe42435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Christian;


On Thu, Sep 1, 2011 = at 3:03 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Marshall,

I think your suggested method is worth exploring. Some comments, questions = and thinking out loud below marked CNG.

Regards, Christian

On 31/08/2011 10:07 PM, Marshall Eubanks wrote:



On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0Hello,

=A0 =A0Whilst reviewing the use case document use case 4.1 point to point<= br> =A0 =A0meeting talks about the possibility for separate monophonic audio =A0 =A0streams. Now this presumably this allows for a microphone to be
=A0 =A0placed in front of each participant.

=A0 =A0Now consider a three position (left to right) two row telepresence<= br> =A0 =A0system. Each of these has a microphone i.e. 6 audio captures,
=A0 =A0Front row AC0, AC1, AC2, Back row AC3, AC4, AC5.

=A0 =A0The current framework document considers video and audio captures =A0 =A0to be left to right.
=A0 =A0So its easy to describe the first row AC0, AC1, AC2. How would I =A0 =A0describe using the current framework the audio captures for the
=A0 =A0second row microphones?

=A0 =A0Even if we disregard the row (depth) element, how would I then say<= br> =A0 =A0AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same l= eft /
=A0 =A0centre / right position?


My own personal opinion is that

- it is dangerous and limiting to attempt to capture equipment spatial plac= ement in a simple ordered list, especially when that equipment (or its capt= ure zone) can move and change with time and that

- we are likely to be sending kilobytes of information about codec formats = and the like , so I don't see why we can't afford a few bytes to describe a mapping between equipment ids (numbering) and what and where the= y are capturing.
[CNG] I would agree it seems bytes are cheap these days...


If you want a specific proposal to deal with this, here is one.

There are three possible rankings of spatial equipment capture, transverse,= depth and vertical. Call them T, D and V.

Each can be declared to be relevant, with the assumption that at least one = will be. Ones not declared relevant are ignored.

Each can be declared to be fixed or variable width. In the case of fixed wi= dth, the width is also declared.

Units are degrees (T AND V) and meters (D).

Everything is referenced to the axis of symmetry of the unit, oriented from= the point of view of an observer standing on the axis at the capture equip= ment facing the participants (i.e., the point of view of an outside observe= r). Order is right to left (T), front to back (D) and bottom to top (V) . A= "starting" value is given (so that we don't have to deal wit= h negative numbers in the list) and a "unit" value (the smallest = addressable chunk of degrees or meters).
[CNG] Just to be 100% sure when you say axis of symmetry of "the unit&= quot; do you mean each media capture device or the telepresence system (TPS= )? I guess when we start to take into geometries into consideration the des= cription (and implementation) does become more complex. It might get intere= sting to consider a presentation related capture.


In many physics problems, d= etermining the appropriate frame of reference is half of the battle, and I = suspect that this will be the case here as well.

I find it useful to use the imagery and nomenclature of stagecraft in video= conferencing and telepresence. There is, of course, a rather longer history= of running code in the theater and related arts. In the theater, as in vid= eoconferencing and telepresence, there is a local audience. There are also = performers (in theater) or remote participants (in telepresence). Think abo= ut the most basic things in that situation

- There is a spatial division between the audience and = the performers. The audience is here, the performers are over there.=A0

- The audience sits and looks in some direction. They= may look left or right, up or down, but they almost never have to turn aro= und and look behind them. The performers occupy in the forward directions t= hey can look at comfortably.=A0

- There is almost =A0always a default direction (what t= he audience looks at if they look straight ahead) which is an axis of symme= try for the entire room. (That is true even for theater in the round.)=A0

This basic setup is seen across cultures, in theater, m= usic, teachers in schools, religious ceremonies, judges in courtrooms, etc.= It was familiar to the ancient Greeks, not to mention the Chinese, Japanes= e, etc. It is also the basic setup for all of the telepresence solutions I = know of. There is so much running code here that if we can accommodate it, = we are probably "future-proof" for some time to come. That is wha= t I think we should aim for, and that is what I was trying to do.

So, I use the axis of symmetry as the basic reference p= oint. Think of it as, where the audience is looking. If someone can come up= with a better reference point, I am not wed to it, but I would want to acc= ommodate all of the above cases.=A0
=A0

Did the framework draft authors consider such an approach when drafting the= draft text?


I have urged th= is verbally but hadn't previously put in writing.
=A0


All spatially equipment is given an ID (could just be numbered, it doesn= 9;t really matter).

So, assuming the above AC0-AC5, this situation could be dealt with as somet= hing like

Declare T UNIT 30 STARTING -60
Declare D UNIT 2 STARTING 2
[CNG] Are these fixed as described above? If so is the width declared?
=

The width is UNIT. I like WIDTH = better.

so

1,$s/UNIT/UNIT= _WIDTH/
=A0



Order (ACO, 1,2), (AC1, 2, 2), (AC2, 3,2), (AC3, 1,3), (AC4, 2,3), (AC5, 3,= 3),

where (ACO, 1,1) means unit ACO covers T zone 1 (-60 to -30 degrees) and D = zone 2 (2 to 4 meters into the depth of field), etc.
[CNG] I'm a bit confused with this example given the declares. Do you m= ean (ACO, 1,2)? or should AC0 be changed in the ordered list?
=A0 =A0 =A0Given a triplet (AC0,t,d) =A0t=3D1, d=3D1
=A0 =A0 =A0AC0 is the identity
=A0 =A0 =A0t is a multiplier of the unit T in this case 30deg added to the= start -60,
=A0 =A0 =A0 =A0 =A0 i.e. (t * 30) + (-60) =3D -30
=A0 =A0 =A0d is a multiplier of the unit D in this case 2m added to the st= art 2,
=A0 =A0 =A0 =A0 =A0 i.e. (d * 2) + (2) =3D 4

In words how would you describe? (AC4,2,3) =A0e.g. t=3D2, d=3D3



If there was a camera that covered all 120 degrees, and 3 others that cover= ed 30 degrees each, that could be

Declare T VARIABLE UNIT 30 STARTING -60

Order (VC0, 1, 4), (VC1, 1, 1), (VC1, 1, 1), (VC2, 2, 1), (VC3, 3, 1),


Note that there is = a typo here - VC1 is repeated.
=A0
where (VC0, 1, 4) means unit VC0 covers from -60 to +60 degrees (4 30 degre= e slices), unit VC1 covers -60 to -30 degrees (1 slice), etc.
[CNG] How would you handle overlapping regions?


Just do it. The above is overlapping -= VC0 overlaps VC1, 2 and 3.

Or, if you mean, how s= hould the consumer handle overlapping regions - I don't see that as our= job. We set up the infrastructure to describe what's going on. Maybe t= he consumer only has one screen for this remote site, so they use VC0. Mayb= e they have lots of bandwidth, but only one screen, so instead they monitor= VC0 and use it to pick between VC1, 2 or 3. Maybe they crop overlaps. What= ever. IMO we shouldn't be specifying that.=A0
=A0

[CNG] Would you see it being problematic if rather than specifying this in = terms of units and multipliers that the start and end for each of the varia= bles be explicitly used?
e.g. Based on T,D,V
For video
=A0 =A0 (VC0,[-60:60]),(VC1,[-60:-30])?
or in the audio capture case?
=A0 =A0 (AC0,[-60:-30],[2:4]),(AC4,[-30:0],[4:6])


Sure. I do not have a good understanding as t= o what the vendors are comfortable with here - whether they want very simpl= e commands or the full granularity. They should drive that aspect here IMO.= =A0
=A0
I said before that some relation (T or V or D) should be= assumed to be present, but it came to me that a one camera mono sound unit= doesn't need this, so=A0that could be assumed if the ordering was abse= nt.



I don't see this as really much more complicated or byte consuming and = it really would avoid a bunch of problems I see as coming from overlaying a= potentially variable 3-D spatial order onto a simple list.
[CNG] Perhaps another approach is? to treat each capture set as having &quo= t;a spatial relationship" between media captures however there is no s= ignificance of the position of the media capture in the capture set definit= ion itself (i.e. remove all spatial order from the list). The spatial detai= ls related to the capture are given as attributes of each media capture, e.= g. T, D, V or other as appropriate.



I am not sure I am parsing that correc= tly. Could you provide an example ?

Regards
<= div>Marshall
=A0



Regards
Marshall

=A0 =A0Regards, Christian

=A0 =A0_______________________________________________
=A0 =A0clue mailing list
=A0 =A0clue@ietf.org <mailto:clue@ietf.o= rg>

--000e0cd70c92cceefb04abe42435-- From Christian.Groves@nteczone.com Thu Sep 1 17:41:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6209921F95F4 for ; Thu, 1 Sep 2011 17:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIWvISwKAr69 for ; Thu, 1 Sep 2011 17:41:55 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 69BB921F95E2 for ; Thu, 1 Sep 2011 17:41:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAAmYE520VLN/2dsb2JhbAAMNqsKAQEBAQIBAQEBJBEbGwYEAQULCxgJFggHCQMCAQIBFR8RBg0BBQIBAYduBLpohl8EpEU Received: from ppp118-209-82-205.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.82.205]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Sep 2011 10:13:22 +0930 Message-ID: <4E602689.6030507@nteczone.com> Date: Fri, 02 Sep 2011 10:42:49 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Stephen Botzko References: <4E5E0C00.6050208@nteczone.com> <4E5F07ED.7010809@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 00:41:56 -0000 Hello Stephen, In-line below Regards, Christian On 2/09/2011 12:53 AM, Stephen Botzko wrote: > in-line > > On Thu, Sep 1, 2011 at 12:19 AM, Christian Groves > > > wrote: > > Hello Stephen, > > Please see my responses below. > > Regards, > Christian > > > > On 31/08/2011 9:47 PM, Stephen Botzko wrote: > > The current framework draft allows multiple captures to signal > the same linear index. So it is fine for AC0,AC3 and the the > other pairs to all signal the same index. This covers the > case where the two rows are captured in the same video > captures (that is, the left camera VC0 captures the left side > of both rows). If the video capture set is VC0, VC1, VC2, it > is possible to associate both AC3 and AC0 with VC0. > > [CNG] OK, linear index is used to indicate the position of an > audio capture rather than the left/right behaviour? > > [SCB]Yes. That makes it easy to match the sound stage to the > displays, and also deals nicely with the situation where the captures > are not evenly placed in the room. [CNG] Rather than having to capture set left->right convention and the linear index could we just have the linear index? i.e. the convention is removed. If we have both then don't we run into potential inconsistency problems. e.g. (AC0[lin_ind=30],AC1[lin_ind=90],AC2[lin_ind=60])? ..snip.. > > > > > > BTW, though it is convenient to think about audio captures as > independent microphones, it is important to keep in mind that > there are other ways to generate them. For instance, a > microphone array can use beam-forming techniques to construct > multiple captures from the microphone array. This can in > principle be done with video, particularly if you also have > depth information. The framework does not describe how many > sensors are used to create a capture. > > [CNG] I agree. My questions came as a result of the use cases > which talk about monophonic stream and microphones. In the > beam-forming would the aspect of "depth" in addition to "linear > index" also be useful? > > [SCB] Though I don't think you are suggesting this, I'd like to > say that I don't think we need to send all the information needed > for receivers to form the beam, it is much more practical to have > senders form it. > > I think sorting out how precisely/completely we need to describe > the useful pickup pattern of an audio or video camera needs more > discussion. For audio particularly, sound pickup depends on the > sensor array, the room design, and who/what is in the room at the > moment. I don't think its helpful [and often not even possible] > to describe it too exactly, but it is true that we might need more > than a single linear position. > [CNG] I agree. I think the challenge is to keep the common cases simple whilst allowing the more complex cases. It my mean we need different but complementary ways of describing this. > One helpful way to sort out what is needed is to think about the > rendering constraints. > > For instance, in almost all non-mobile cases the audio is being > rendering through a linear array of front speakers. If rear > speakers are used, they are generally for sound reinforcement - > meaning that they are adjusted so that the Haas effect ensures > that the sound is always perceived as coming from the front of the > room. In that common situation, the one dimensional linear index > (a panning position) is all you really need. Adding more > parameters will not improve the spatial rendering much. Even if > you are not rendering with a simple linear array, creating spatial > audio with depth in telepresence rooms means placing the far-end > sound _behind_ the monitors - and adding rear speakers to the room > doesn't help you do that. I don't know any good way to render room > audio so it sounds like it is coming from an arbitrary depth > behind a wall-mounted monitor or projector screen. > > However, if a middle box is selecting a subset of the audio > captures in a room, then it conceivably might be necessary to > provide more information about the pickup region. So far I > haven't come up with good use case that shows that though. > [CNG] Whilst any indication to a user can be considered as "rendering", do you see that information about the pickup region could be used to generate some sort of local "service" indication i.e. for example highlighting part of a video region based on an voice activity of a certain audio capture. > > > > Stephen Botzko > > > > > On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves > > >> wrote: > > Hello, > > Whilst reviewing the use case document use case 4.1 point > to point > meeting talks about the possibility for separate monophonic > audio > streams. Now this presumably this allows for a microphone to be > placed in front of each participant. > > Now consider a three position (left to right) two row > telepresence > system. Each of these has a microphone i.e. 6 audio captures, > Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. > > The current framework document considers video and audio > captures > to be left to right. > So its easy to describe the first row AC0, AC1, AC2. How > would I > describe using the current framework the audio captures for the > second row microphones? > > Even if we disregard the row (depth) element, how would I > then say > AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / > centre / right position? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > From Christian.Groves@nteczone.com Thu Sep 1 18:01:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E321F8B0C for ; Thu, 1 Sep 2011 18:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBFfLgjhtfRL for ; Thu, 1 Sep 2011 18:01:35 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2702721F86EC for ; Thu, 1 Sep 2011 18:01:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIwpYE520VLN/2dsb2JhbAAMLQmrCgEBAQECAQEBATUbGwQCBAEQCxgJFggHCQMCAQIBFR8RBg0BBQIBAREGh1cEumqDOoMlBKRF Received: from ppp118-209-82-205.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.82.205]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Sep 2011 10:32:49 +0930 Message-ID: <4E602B17.4020402@nteczone.com> Date: Fri, 02 Sep 2011 11:02:15 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Marshall Eubanks References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 01:01:36 -0000 Hello Marshall Please see my replies below. Regards, Christian On 2/09/2011 2:57 AM, Marshall Eubanks wrote: > Dear Christian; > > > On Thu, Sep 1, 2011 at 3:03 AM, Christian Groves > > > wrote: > > Hello Marshall, > > I think your suggested method is worth exploring. Some comments, > questions and thinking out loud below marked CNG. > > Regards, Christian > > On 31/08/2011 10:07 PM, Marshall Eubanks wrote: > > > > On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves > > >> wrote: > > Hello, > > Whilst reviewing the use case document use case 4.1 point > to point > meeting talks about the possibility for separate monophonic > audio > streams. Now this presumably this allows for a microphone to be > placed in front of each participant. > > Now consider a three position (left to right) two row > telepresence > system. Each of these has a microphone i.e. 6 audio captures, > Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. > > The current framework document considers video and audio > captures > to be left to right. > So its easy to describe the first row AC0, AC1, AC2. How > would I > describe using the current framework the audio captures for the > second row microphones? > > Even if we disregard the row (depth) element, how would I > then say > AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / > centre / right position? > > > My own personal opinion is that > > - it is dangerous and limiting to attempt to capture equipment > spatial placement in a simple ordered list, especially when > that equipment (or its capture zone) can move and change with > time and that > > - we are likely to be sending kilobytes of information about > codec formats and the like , so I don't see why we can't > afford a few bytes to > describe a mapping between equipment ids (numbering) and what > and where they are capturing. > > [CNG] I would agree it seems bytes are cheap these days... > > > If you want a specific proposal to deal with this, here is one. > > There are three possible rankings of spatial equipment > capture, transverse, depth and vertical. Call them T, D and V. > > Each can be declared to be relevant, with the assumption that > at least one will be. Ones not declared relevant are ignored. > > Each can be declared to be fixed or variable width. In the > case of fixed width, the width is also declared. > > Units are degrees (T AND V) and meters (D). > > Everything is referenced to the axis of symmetry of the unit, > oriented from the point of view of an observer standing on the > axis at the capture equipment facing the participants (i.e., > the point of view of an outside observer). Order is right to > left (T), front to back (D) and bottom to top (V) . A > "starting" value is given (so that we don't have to deal with > negative numbers in the list) and a "unit" value (the smallest > addressable chunk of degrees or meters). > > [CNG] Just to be 100% sure when you say axis of symmetry of "the > unit" do you mean each media capture device or the telepresence > system (TPS)? I guess when we start to take into geometries into > consideration the description (and implementation) does become > more complex. It might get interesting to consider a presentation > related capture. > > > > In many physics problems, determining the appropriate frame of > reference is half of the battle, and I suspect that this will be the > case here as well. > > I find it useful to use the imagery and nomenclature of stagecraft in > videoconferencing and telepresence. There is, of course, a rather > longer history of running code in the theater and related arts. In the > theater, as in videoconferencing and telepresence, there is a local > audience. There are also performers (in theater) or remote > participants (in telepresence). Think about the most basic things in > that situation > > - There is a spatial division between the audience and the performers. > The audience is here, the performers are over there. > > - The audience sits and looks in some direction. They may look left or > right, up or down, but they almost never have to turn around and look > behind them. The performers occupy in the forward directions they can > look at comfortably. > > - There is almost always a default direction (what the audience looks > at if they look straight ahead) which is an axis of symmetry for the > entire room. (That is true even for theater in the round.) > > This basic setup is seen across cultures, in theater, music, teachers > in schools, religious ceremonies, judges in courtrooms, etc. It was > familiar to the ancient Greeks, not to mention the Chinese, Japanese, > etc. It is also the basic setup for all of the telepresence solutions > I know of. There is so much running code here that if we can > accommodate it, we are probably "future-proof" for some time to come. > That is what I think we should aim for, and that is what I was trying > to do. > > So, I use the axis of symmetry as the basic reference point. Think of > it as, where the audience is looking. If someone can come up with a > better reference point, I am not wed to it, but I would want to > accommodate all of the above cases. [CNG] OK so the intention was that the axis of symmetry is not really related to a device but related to the "scene" > ... > > > > I don't see this as really much more complicated or byte > consuming and it really would avoid a bunch of problems I see > as coming from overlaying a potentially variable 3-D spatial > order onto a simple list. > > [CNG] Perhaps another approach is? to treat each capture set as > having "a spatial relationship" between media captures however > there is no significance of the position of the media capture in > the capture set definition itself (i.e. remove all spatial order > from the list). The spatial details related to the capture are > given as attributes of each media capture, e.g. T, D, V or other > as appropriate. > > > > I am not sure I am parsing that correctly. Could you provide an example ? [CNG] Something like: "MediaCaptures" IDENTITY = STRING Attributes = STRING IDENTITY:Attributes[";" *Attributes] "CaptureSets" "(" IDENTITY [";" *IDENTITY] e.g. MediaCaptures VC0:purpose=main;t=[-90:-30] VC1:purpose=main;t=[-30:30] VC2:purpose=main;t=[30:60] CaptureSets (VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3) It doesn't matter what the order of the identities are all that the capture set indicates is that they are related. The actual spatial information is defined in the definition of the capture. > > Regards > Marshall > > > > > Regards > Marshall > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > From marshall.eubanks@gmail.com Thu Sep 1 18:21:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711F121F9378 for ; Thu, 1 Sep 2011 18:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9JO307E9qSE for ; Thu, 1 Sep 2011 18:21:47 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94CE821F90B1 for ; Thu, 1 Sep 2011 18:21:33 -0700 (PDT) Received: by yie12 with SMTP id 12so2308272yie.31 for ; Thu, 01 Sep 2011 18:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5f5+MZGGxKPnS8y1Xnxi7KjCMs4aSE745r3iqhB/l4U=; b=YVbfQyH7NS9pHEc1Xj+TW0leHfOgcNZPJFBV0XWiBQGpI44trv9PiMs4k4bCYgh+k3 CkJale94yRjCd0gIkvJ8Ig1p667RQsboUmEQPFRQ69+ZQvypB8nkU4fv3Dj76AvQTgi8 83o7JyxPCUoGKAaxLuRuDmWvFwhDkjJegF42w= MIME-Version: 1.0 Received: by 10.150.72.3 with SMTP id u3mr684645yba.84.1314926585962; Thu, 01 Sep 2011 18:23:05 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Thu, 1 Sep 2011 18:23:05 -0700 (PDT) In-Reply-To: <4E602B17.4020402@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> <4E602B17.4020402@nteczone.com> Date: Thu, 1 Sep 2011 21:23:05 -0400 Message-ID: From: Marshall Eubanks To: Christian Groves Content-Type: multipart/alternative; boundary=000e0cd591320fe1a404abeb341c Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 01:21:48 -0000 --000e0cd591320fe1a404abeb341c Content-Type: text/plain; charset=ISO-8859-1 Dear Christian; On Thu, Sep 1, 2011 at 9:02 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Marshall > > Please see my replies below. > > Regards, Christian > > > On 2/09/2011 2:57 AM, Marshall Eubanks wrote: > >> >> >> So, I use the axis of symmetry as the basic reference point. Think of it >> as, where the audience is looking. If someone can come up with a better >> reference point, I am not wed to it, but I would want to accommodate all of >> the above cases. >> > > [CNG] OK so the intention was that the axis of symmetry is not really > related to a device but related to the "scene" > > If by "device" you mean "camera or microphone or ...", then, yes. If by "device" you mean "telepresence unit, then I would argue that the axis of symmetry is inherent in the telepresence unit. Note that the axis of symmetry just establishes the local angular reference (i.e., what "60 degrees to the right" means). You also need a central point for distances. As Stephan indicates, I think we should have a coordinate system for both capture and display. > ... >> >> >> >> >> I don't see this as really much more complicated or byte >> consuming and it really would avoid a bunch of problems I see >> as coming from overlaying a potentially variable 3-D spatial >> order onto a simple list. >> >> [CNG] Perhaps another approach is? to treat each capture set as >> having "a spatial relationship" between media captures however >> there is no significance of the position of the media capture in >> the capture set definition itself (i.e. remove all spatial order >> from the list). The spatial details related to the capture are >> given as attributes of each media capture, e.g. T, D, V or other >> as appropriate. >> >> >> >> I am not sure I am parsing that correctly. Could you provide an example ? >> > > [CNG] Something like: > > "MediaCaptures" > IDENTITY = STRING > Attributes = STRING > IDENTITY:Attributes[";" *Attributes] > "CaptureSets" > "(" IDENTITY [";" *IDENTITY] > > e.g. > MediaCaptures > VC0:purpose=main;t=[-90:-30] > VC1:purpose=main;t=[-30:30] > VC2:purpose=main;t=[30:60] > CaptureSets > (VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3) > > It doesn't matter what the order of the identities are that I think should be the case. > all that the capture set indicates is that they are related. The actual > spatial information is defined in the definition of the capture. > > > So, VC0 captures far right to middle right (60 deg), V1 the center (30 deg). VC2 the left (30 deg), all non-overlapping ? That seems fine to me (the format, if not the cameras). We should have something flexible enough to represent people at podiums and the like, which I think this does with no effort. Regards Marshall > > >> Regards >> Marshall >> >> >> >> >> Regards >> Marshall >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org > >> > >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> --000e0cd591320fe1a404abeb341c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Christian;

On Thu, Sep 1, 2011 at 9:= 02 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:
=
Hello Marshall

Please see my replies below.

Regards, Christian


On 2/09/2011 2:57 AM, Marshall Eubanks wrote:
<snip>
So, I use the axis of symmetry as the basic reference point. Think of it as= , where the audience is looking. If someone can come up with a better refer= ence point, I am not wed to it, but I would want to accommodate all of the = above cases.

[CNG] OK so the intention was that the axis of symmetry is not really relat= ed to a device but related to the "scene"


If by "device" you mean &quo= t;camera or microphone or ...", then, yes.

If= by "device" you mean "telepresence unit, then I would argue= that the axis of symmetry is inherent =A0in the telepresence unit.

Note that the axis of symmetry just establishes the loc= al angular reference (i.e., what "60 degrees to the right" means)= . You also need a central=A0
point for distances. =A0As Stephan i= ndicates, I think we should have a coordinate system for both capture and d= isplay.=A0
=A0
...




=A0 =A0 =A0 =A0I don't see this as really much more complicated or byt= e
=A0 =A0 =A0 =A0consuming and it really would avoid a bunch of problems I s= ee
=A0 =A0 =A0 =A0as coming from overlaying a potentially variable 3-D spatia= l
=A0 =A0 =A0 =A0order onto a simple list.

=A0 =A0[CNG] Perhaps another approach is? to treat each capture set as
=A0 =A0having "a spatial relationship" between media captures ho= wever
=A0 =A0there is no significance of the position of the media capture in =A0 =A0the capture set definition itself (i.e. remove all spatial order =A0 =A0from the list). The spatial details related to the capture are
=A0 =A0given as attributes of each media capture, e.g. T, D, V or other =A0 =A0as appropriate.



I am not sure I am parsing that correctly. Could you provide an example ?

[CNG] Something like:

"MediaCaptures"
IDENTITY =3D STRING
Attributes =3D STRING
IDENTITY:Attributes[";" *Attributes]
"CaptureSets"
"(" IDENTITY [";" *IDENTITY]

e.g.
MediaCaptures
VC0:purpose=3Dmain;t=3D[-90:-30]
VC1:purpose=3Dmain;t=3D[-30:30]
VC2:purpose=3Dmain;t=3D[30:60]
CaptureSets
(VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3)

It doesn't matter what the order of the identities are

that I think should be the case.=A0
=A0
all that the capture set indicates is that they are related. The actual sp= atial information is defined in the definition of the capture.



So, VC0 captures far right to middle r= ight (60 deg), V1 the center (30 deg). VC2 the left (30 deg), all non-overl= apping ?=A0

That seems fine to me (the format, if = not the cameras).=A0

We should have something flexible enough to represent p= eople at podiums and the like, which I think this does with no effort.=A0

Regards
Marshall=A0

<= div>
=A0


Regards
Marshall




=A0 =A0 =A0 =A0Regards
=A0 =A0 =A0 =A0Marshall

=A0 =A0 =A0 =A0 =A0 Regards, Christian

=A0 =A0 =A0 =A0 =A0 _______________________________________________=
=A0 =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org

=A0 =A0 =A0 =A0<mailto:clue@ietf.org>>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue




--000e0cd591320fe1a404abeb341c-- From stephen.botzko@gmail.com Thu Sep 1 18:23:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BCB21F959A for ; Thu, 1 Sep 2011 18:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHCZAka4pEfJ for ; Thu, 1 Sep 2011 18:23:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96321F94D0 for ; Thu, 1 Sep 2011 18:23:27 -0700 (PDT) Received: by vws12 with SMTP id 12so2334807vws.31 for ; Thu, 01 Sep 2011 18:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rR81HAsQMPOpaQMpL9TESCyyyJ3WS8NpeYMyx6j7khA=; b=jAB9wvJIpAMf11MyUodAZZx45g0rk0C35QL+1aJyI5qIBcL66z0OAgzRPUGfMH9mqt taU4GCGilBlG1OzHzyFkDFiUN3mvnSKcuqnS34Lq9BQ3PgWveUHXzbXDFg0F1yGtEzOZ PDboQZX52+nbhkcVF3rclQWOqw/ybWxFTwhOo= MIME-Version: 1.0 Received: by 10.52.67.38 with SMTP id k6mr462367vdt.510.1314926699669; Thu, 01 Sep 2011 18:24:59 -0700 (PDT) Received: by 10.52.183.100 with HTTP; Thu, 1 Sep 2011 18:24:59 -0700 (PDT) In-Reply-To: <4E602689.6030507@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F07ED.7010809@nteczone.com> <4E602689.6030507@nteczone.com> Date: Thu, 1 Sep 2011 21:24:59 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=20cf307abe6dd6ea2b04abeb3af1 Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 01:23:29 -0000 --20cf307abe6dd6ea2b04abeb3af1 Content-Type: text/plain; charset=ISO-8859-1 Hi Christian- In-line On Thu, Sep 1, 2011 at 8:42 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Stephen, > > In-line below > > Regards, Christian > > > On 2/09/2011 12:53 AM, Stephen Botzko wrote: > >> in-line >> >> >> On Thu, Sep 1, 2011 at 12:19 AM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello Stephen, >> >> Please see my responses below. >> >> Regards, >> Christian >> >> >> >> On 31/08/2011 9:47 PM, Stephen Botzko wrote: >> >> The current framework draft allows multiple captures to signal >> the same linear index. So it is fine for AC0,AC3 and the the >> other pairs to all signal the same index. This covers the >> case where the two rows are captured in the same video >> captures (that is, the left camera VC0 captures the left side >> of both rows). If the video capture set is VC0, VC1, VC2, it >> is possible to associate both AC3 and AC0 with VC0. >> >> [CNG] OK, linear index is used to indicate the position of an >> audio capture rather than the left/right behaviour? >> >> [SCB]Yes. That makes it easy to match the sound stage to the displays, >> and also deals nicely with the situation where the captures are not evenly >> placed in the room. >> > [CNG] Rather than having to capture set left->right convention and the > linear index could we just have the linear index? i.e. the convention is > removed. If we have both then don't we run into potential inconsistency > problems. e.g. (AC0[lin_ind=30],AC1[lin_ind=**90],AC2[lin_ind=60])? > > [SCB] that makes sense to me, though perhaps if you are looking to select a > particular stream (perhaps the one closest to the center) it would be > convenient if they were ordered. > > ..snip.. > > >> >> >> >> >> BTW, though it is convenient to think about audio captures as >> independent microphones, it is important to keep in mind that >> there are other ways to generate them. For instance, a >> microphone array can use beam-forming techniques to construct >> multiple captures from the microphone array. This can in >> principle be done with video, particularly if you also have >> depth information. The framework does not describe how many >> sensors are used to create a capture. >> >> [CNG] I agree. My questions came as a result of the use cases >> which talk about monophonic stream and microphones. In the >> beam-forming would the aspect of "depth" in addition to "linear >> index" also be useful? >> >> [SCB] Though I don't think you are suggesting this, I'd like to >> say that I don't think we need to send all the information needed >> for receivers to form the beam, it is much more practical to have >> senders form it. >> I think sorting out how precisely/completely we need to describe >> the useful pickup pattern of an audio or video camera needs more >> discussion. For audio particularly, sound pickup depends on the >> sensor array, the room design, and who/what is in the room at the >> moment. I don't think its helpful [and often not even possible] >> to describe it too exactly, but it is true that we might need more >> than a single linear position. >> > [CNG] I agree. I think the challenge is to keep the common cases simple > whilst allowing the more complex cases. It my mean we need different but > complementary ways of describing this. [SCB] My guess is that the basic information on the capture areas etc will be the same, though I agree that we should be open to the idea that some of the description is specific to audio or video. Sound behaves differently from light. > > > One helpful way to sort out what is needed is to think about the >> rendering constraints. >> >> For instance, in almost all non-mobile cases the audio is being >> rendering through a linear array of front speakers. If rear >> speakers are used, they are generally for sound reinforcement - >> meaning that they are adjusted so that the Haas effect ensures >> that the sound is always perceived as coming from the front of the >> room. In that common situation, the one dimensional linear index >> (a panning position) is all you really need. Adding more >> parameters will not improve the spatial rendering much. Even if >> you are not rendering with a simple linear array, creating spatial >> audio with depth in telepresence rooms means placing the far-end >> sound _behind_ the monitors - and adding rear speakers to the room >> doesn't help you do that. I don't know any good way to render room >> audio so it sounds like it is coming from an arbitrary depth >> behind a wall-mounted monitor or projector screen. >> >> However, if a middle box is selecting a subset of the audio >> captures in a room, then it conceivably might be necessary to >> provide more information about the pickup region. So far I >> haven't come up with good use case that shows that though. >> >> [CNG] Whilst any indication to a user can be considered as "rendering", > do you see that information about the pickup region could be used to > generate some sort of local "service" indication i.e. for example > highlighting part of a video region based on an voice activity of a certain > audio capture. > [SCB]If you detect voice activity in an audio capture, you absolutely want to find the video capture[s] that carry the talker's image. So I would agree that the capture areas need to provide enough information to do that. > >> >> >> Stephen Botzko >> >> >> >> >> On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves >> > >> > >> >> >>> >> wrote: >> >> Hello, >> >> Whilst reviewing the use case document use case 4.1 point >> to point >> meeting talks about the possibility for separate monophonic >> audio >> streams. Now this presumably this allows for a microphone to be >> placed in front of each participant. >> >> Now consider a three position (left to right) two row >> telepresence >> system. Each of these has a microphone i.e. 6 audio captures, >> Front row AC0, AC1, AC2, Back row AC3, AC4, AC5. >> >> The current framework document considers video and audio >> captures >> to be left to right. >> So its easy to describe the first row AC0, AC1, AC2. How >> would I >> describe using the current framework the audio captures for the >> second row microphones? >> >> Even if we disregard the row (depth) element, how would I >> then say >> AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate to the same left / >> centre / right position? >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org > >> > >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> --20cf307abe6dd6ea2b04abeb3af1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian-
In-line

On Thu, Sep 1, 2= 011 at 8:42 PM, Christian Groves <Christian.Groves@nteczone.co= m> wrote:
Hello Stephen,

In-line below

Regards, Christian


On 2/09/2011 12:53 AM, Stephen Botzko wrote:
in-line


On Thu, Sep 1, 2011 at 12:19 AM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0Hello Stephen,

=A0 =A0Please see my responses below.

=A0 =A0Regards,
=A0 =A0Christian



=A0 =A0On 31/08/2011 9:47 PM, Stephen Botzko wrote:

=A0 =A0 =A0 =A0The current framework draft allows multiple captures to sig= nal
=A0 =A0 =A0 =A0the same linear index. =A0So it is fine for AC0,AC3 and the= the
=A0 =A0 =A0 =A0other pairs to all signal the same index. =A0This covers th= e
=A0 =A0 =A0 =A0case where the two rows are captured in the same video
=A0 =A0 =A0 =A0captures (that is, the left camera VC0 captures the left si= de
=A0 =A0 =A0 =A0of both rows). If the video capture set is VC0, VC1, VC2, = =A0it
=A0 =A0 =A0 =A0is possible to associate both AC3 and AC0 with VC0.

=A0 =A0[CNG] OK, linear index is used to indicate the position of an
=A0 =A0audio capture rather than the left/right behaviour?

[SCB]Yes. =A0That makes it easy to match the sound stage to the displays, a= nd also deals nicely with the situation where the captures are not evenly p= laced in the room.
[CNG] Rather than having to capture set left->right convention and the l= inear index could we just have the linear index? i.e. the convention is rem= oved. If we have both then don't we run into potential inconsistency pr= oblems. e.g. (AC0[lin_ind=3D30],AC1[lin_ind=3D90],AC2[lin_ind=3D60])= ?
=A0
[SCB] that makes sense to me, though perhaps if you are looking to select a= particular stream (perhaps the one closest to the center) it would be conv= enient if they were ordered.=A0
=A0
..snip..






=A0 =A0 =A0 =A0BTW, though it is convenient to think about audio captures = as
=A0 =A0 =A0 =A0independent microphones, it is important to keep in mind th= at
=A0 =A0 =A0 =A0there are other ways to generate them. =A0For instance, a =A0 =A0 =A0 =A0microphone array can use beam-forming techniques to constru= ct
=A0 =A0 =A0 =A0multiple captures from the microphone array. =A0This can in=
=A0 =A0 =A0 =A0principle be done with video, particularly if you also have=
=A0 =A0 =A0 =A0depth information. The framework does not describe how many=
=A0 =A0 =A0 =A0sensors are used to create a capture.

=A0 =A0[CNG] I agree. My questions came as a result of the use cases
=A0 =A0which talk about monophonic stream and microphones. In the
=A0 =A0beam-forming would the aspect of "depth" in addition to &= quot;linear
=A0 =A0index" also be useful?

=A0 =A0[SCB] Though I don't think you are suggesting this, I'd lik= e to
=A0 =A0say that I don't think we need to send all the information need= ed
=A0 =A0for receivers to form the beam, it is much more practical to have =A0 =A0senders form it.
=A0 =A0I think sorting out how precisely/completely we need to describe =A0 =A0the useful pickup pattern of an audio or video camera needs more =A0 =A0discussion. =A0For audio particularly, sound pickup depends on the<= br> =A0 =A0sensor array, the room design, and who/what is in the room at the =A0 =A0moment. =A0I don't think its helpful [and often not even possib= le]
=A0 =A0to describe it too exactly, but it is true that we might need more<= br> =A0 =A0than a single linear position.
[CNG] I agree. I think the challenge is to keep the common cases simple whi= lst allowing the more complex cases. It my mean we need different but compl= ementary ways of describing this.
[SCB] My guess is that t= he basic information on the capture areas etc will be the same, though I ag= ree that we should be open to the idea that some of the description is spec= ific to audio or video. Sound behaves differently from light.


=A0 =A0One helpful way to sort out what is needed is to think about the =A0 =A0rendering constraints.

=A0 =A0For instance, in almost all non-mobile cases the audio is being
=A0 =A0rendering through a linear array of front speakers. =A0If rear
=A0 =A0speakers are used, they are generally for sound reinforcement -
=A0 =A0meaning that they are adjusted so that the Haas effect ensures
=A0 =A0that the sound is always perceived as coming from the front of the<= br> =A0 =A0room. =A0 In that common situation, the one dimensional linear inde= x
=A0 =A0(a panning position) is all you really need. =A0Adding more
=A0 =A0parameters will not improve the spatial rendering much. =A0Even if<= br> =A0 =A0you are not rendering with a simple linear array, creating spatial<= br> =A0 =A0audio with depth in telepresence rooms means placing the far-end =A0 =A0sound _behind_ the monitors - and adding rear speakers to the room<= br> =A0 =A0doesn't help you do that. I don't know any good way to rend= er room
=A0 =A0audio so it sounds like it is coming from an arbitrary depth
=A0 =A0behind a wall-mounted monitor or projector screen.

=A0 =A0However, if a middle box is selecting a subset of the audio
=A0 =A0captures in a room, then it conceivably might be necessary to
=A0 =A0provide more information about the pickup region. =A0So far I
=A0 =A0haven't come up with good use case that shows that though.

[CNG] Whilst any indication to a user can be considered as "rendering&= quot;, do you see that information about the pickup region could be used to= generate some sort of local "service" indication i.e. for exampl= e highlighting part of a video region based on an voice activity of a certa= in audio capture.
=A0
[SCB]If you detect voice activity in an aud= io capture, you absolutely want to find the video capture[s] that carry the= talker's image.=A0 So I would agree that the capture areas need to pro= vide enough information to do that.



=A0 =A0 =A0 =A0Stephen Botzko




=A0 =A0 =A0 =A0On Wed, Aug 31, 2011 at 6:25 AM, Christian Groves
=A0 =A0 =A0 =A0<Christian.Groves@nteczone.com
=A0 =A0 =A0 =A0<mailto:Christian.Groves@nteczone.com>
=A0 =A0 =A0 =A0<mailto:Christian.Groves@nteczone.com
=A0 =A0 =A0 =A0<mailto:Christian.Groves@nteczone.com>>> wro= te:

=A0 =A0 =A0 =A0 =A0 Hello,

=A0 =A0 =A0 =A0 =A0 Whilst reviewing the use case document use case 4.1 po= int
=A0 =A0 =A0 =A0to point
=A0 =A0 =A0 =A0 =A0 meeting talks about the possibility for separate monop= honic
=A0 =A0 =A0 =A0audio
=A0 =A0 =A0 =A0 =A0 streams. Now this presumably this allows for a microph= one to be
=A0 =A0 =A0 =A0 =A0 placed in front of each participant.

=A0 =A0 =A0 =A0 =A0 Now consider a three position (left to right) two row<= br> =A0 =A0 =A0 =A0telepresence
=A0 =A0 =A0 =A0 =A0 system. Each of these has a microphone i.e. 6 audio ca= ptures,
=A0 =A0 =A0 =A0 =A0 Front row AC0, AC1, AC2, Back row AC3, AC4, AC5.

=A0 =A0 =A0 =A0 =A0 The current framework document considers video and aud= io
=A0 =A0 =A0 =A0captures
=A0 =A0 =A0 =A0 =A0 to be left to right.
=A0 =A0 =A0 =A0 =A0 So its easy to describe the first row AC0, AC1, AC2. H= ow
=A0 =A0 =A0 =A0would I
=A0 =A0 =A0 =A0 =A0 describe using the current framework the audio capture= s for the
=A0 =A0 =A0 =A0 =A0 second row microphones?

=A0 =A0 =A0 =A0 =A0 Even if we disregard the row (depth) element, how woul= d I
=A0 =A0 =A0 =A0then say
=A0 =A0 =A0 =A0 =A0 AC0 & AC3, AC1 & AC4 and AC3 & AC5 relate = to the same left /
=A0 =A0 =A0 =A0 =A0 centre / right position?

=A0 =A0 =A0 =A0 =A0 Regards, Christian

=A0 =A0 =A0 =A0 =A0 _______________________________________________=
=A0 =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org

=A0 =A0 =A0 =A0<mailto:clue@ietf.org>>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue




--20cf307abe6dd6ea2b04abeb3af1-- From Christian.Groves@nteczone.com Thu Sep 1 19:18:14 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6895121F91D1 for ; Thu, 1 Sep 2011 19:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFoi3kT5JnvU for ; Thu, 1 Sep 2011 19:18:13 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3221F919A for ; Thu, 1 Sep 2011 19:18:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABI7YE520VLN/2dsb2JhbAAMLQmrCgEBAQECAQEBATUbGwQCBAEQCxgJFggHCQMCAQIBFR8RBg0BBQIBAYduBLoegzqDJQSkRQ Received: from ppp118-209-82-205.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.82.205]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Sep 2011 11:49:46 +0930 Message-ID: <4E603D20.7030207@nteczone.com> Date: Fri, 02 Sep 2011 12:19:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Marshall Eubanks References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> <4E602B17.4020402@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 02:18:14 -0000 Hello Marshall, On 2/09/2011 11:23 AM, Marshall Eubanks wrote: > Dear Christian; > > On Thu, Sep 1, 2011 at 9:02 PM, Christian Groves > > > wrote: > > Hello Marshall > > Please see my replies below. > > Regards, Christian > > > On 2/09/2011 2:57 AM, Marshall Eubanks wrote: > > > > So, I use the axis of symmetry as the basic reference point. > Think of it as, where the audience is looking. If someone can > come up with a better reference point, I am not wed to it, but > I would want to accommodate all of the above cases. > > > [CNG] OK so the intention was that the axis of symmetry is not > really related to a device but related to the "scene" > > > If by "device" you mean "camera or microphone or ...", then, yes. > > If by "device" you mean "telepresence unit, then I would argue that > the axis of symmetry is inherent in the telepresence unit. > > Note that the axis of symmetry just establishes the local angular > reference (i.e., what "60 degrees to the right" means). You also need > a central > point for distances. As Stephan indicates, I think we should have a > coordinate system for both capture and display. > > ... > > > > > I don't see this as really much more complicated or byte > consuming and it really would avoid a bunch of problems > I see > as coming from overlaying a potentially variable 3-D > spatial > order onto a simple list. > > [CNG] Perhaps another approach is? to treat each capture set as > having "a spatial relationship" between media captures however > there is no significance of the position of the media > capture in > the capture set definition itself (i.e. remove all spatial > order > from the list). The spatial details related to the capture are > given as attributes of each media capture, e.g. T, D, V or > other > as appropriate. > > > > I am not sure I am parsing that correctly. Could you provide > an example ? > > > [CNG] Something like: > > "MediaCaptures" > IDENTITY = STRING > Attributes = STRING > IDENTITY:Attributes[";" *Attributes] > "CaptureSets" > "(" IDENTITY [";" *IDENTITY] > > e.g. > MediaCaptures > VC0:purpose=main;t=[-90:-30] > VC1:purpose=main;t=[-30:30] > VC2:purpose=main;t=[30:60] > CaptureSets > (VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3) > > It doesn't matter what the order of the identities are > > > that I think should be the case. > > all that the capture set indicates is that they are related. The > actual spatial information is defined in the definition of the > capture. > > > > So, VC0 captures far right to middle right (60 deg), V1 the center (30 > deg). VC2 the left (30 deg), all non-overlapping ? [CNG] Yes that's correct. > > That seems fine to me (the format, if not the cameras). [CNG] At this stage I'm not proposing a particular format more just the principle that the spatial information is an attribute of the individual capture rather the capture set. The T=, was to illustrate a spatial attribute. I don't know whether to satisfy the minimum complexity camp whether we would need to compliment the geometric information with a further "hint". Say something like VC1:purpose=main;t=[-30:30.center] . I read with their structured approach where you can have an adjective and thought perhaps we could do something like this in CLUE for parameters where most cases a generic description will do but in other cases additional information may be beneficial. > > We should have something flexible enough to represent people at > podiums and the like, which I think this does with no effort. > > Regards > Marshall > > > > > Regards > Marshall > > > > > Regards > Marshall > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > > > >> > > https://www.ietf.org/mailman/listinfo/clue > > > > From marshall.eubanks@gmail.com Thu Sep 1 20:28:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E5721F94AC for ; Thu, 1 Sep 2011 20:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx18xQVWPyAD for ; Thu, 1 Sep 2011 20:28:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1035721F934C for ; Thu, 1 Sep 2011 20:28:04 -0700 (PDT) Received: by yie12 with SMTP id 12so2370196yie.31 for ; Thu, 01 Sep 2011 20:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ap6SJ9aXk3UtOX1rn1Ot/bPFcgd6iqvy9uNnjRUDVHE=; b=kuZ4WGEitZmBEiFpF9cFAERr5HNpgvbulwbxtgN0/aZwsRGCXwseR8bZwrrPDEg9Gd VMf+/JcIoNGK9gbia146LxsXBZN8QAwMj0DWrsMZLRv+TGrZ3xB1212GTF6Zem60mWkI 61UB1C0XpLV569arGvhZKRqeh1AcXbN2kvoBg= MIME-Version: 1.0 Received: by 10.150.72.3 with SMTP id u3mr736040yba.84.1314934178643; Thu, 01 Sep 2011 20:29:38 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Thu, 1 Sep 2011 20:29:38 -0700 (PDT) In-Reply-To: <4E603D20.7030207@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> <4E602B17.4020402@nteczone.com> <4E603D20.7030207@nteczone.com> Date: Thu, 1 Sep 2011 23:29:38 -0400 Message-ID: From: Marshall Eubanks To: Christian Groves Content-Type: multipart/alternative; boundary=000e0cd591329efe2304abecf879 Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 03:28:05 -0000 --000e0cd591329efe2304abecf879 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 1, 2011 at 10:19 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Marshall, > > > On 2/09/2011 11:23 AM, Marshall Eubanks wrote: > >> Dear Christian; >> >> >> On Thu, Sep 1, 2011 at 9:02 PM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello Marshall >> >> Please see my replies below. >> >> Regards, Christian >> >> >> On 2/09/2011 2:57 AM, Marshall Eubanks wrote: >> >> >> >> So, I use the axis of symmetry as the basic reference point. >> Think of it as, where the audience is looking. If someone can >> come up with a better reference point, I am not wed to it, but >> I would want to accommodate all of the above cases. >> >> >> [CNG] OK so the intention was that the axis of symmetry is not >> really related to a device but related to the "scene" >> >> >> If by "device" you mean "camera or microphone or ...", then, yes. >> >> If by "device" you mean "telepresence unit, then I would argue that the >> axis of symmetry is inherent in the telepresence unit. >> >> Note that the axis of symmetry just establishes the local angular >> reference (i.e., what "60 degrees to the right" means). You also need a >> central >> point for distances. As Stephan indicates, I think we should have a >> coordinate system for both capture and display. >> >> ... >> >> >> >> >> I don't see this as really much more complicated or byte >> consuming and it really would avoid a bunch of problems >> I see >> as coming from overlaying a potentially variable 3-D >> spatial >> order onto a simple list. >> >> [CNG] Perhaps another approach is? to treat each capture set as >> having "a spatial relationship" between media captures however >> there is no significance of the position of the media >> capture in >> the capture set definition itself (i.e. remove all spatial >> order >> from the list). The spatial details related to the capture are >> given as attributes of each media capture, e.g. T, D, V or >> other >> as appropriate. >> >> >> >> I am not sure I am parsing that correctly. Could you provide >> an example ? >> >> >> [CNG] Something like: >> >> "MediaCaptures" >> IDENTITY = STRING >> Attributes = STRING >> IDENTITY:Attributes[";" *Attributes] >> "CaptureSets" >> "(" IDENTITY [";" *IDENTITY] >> >> e.g. >> MediaCaptures >> VC0:purpose=main;t=[-90:-30] >> VC1:purpose=main;t=[-30:30] >> VC2:purpose=main;t=[30:60] >> CaptureSets >> (VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3) >> >> It doesn't matter what the order of the identities are >> >> >> that I think should be the case. >> >> all that the capture set indicates is that they are related. The >> actual spatial information is defined in the definition of the >> capture. >> >> >> >> So, VC0 captures far right to middle right (60 deg), V1 the center (30 >> deg). VC2 the left (30 deg), all non-overlapping ? >> > [CNG] Yes that's correct. > > > >> That seems fine to me (the format, if not the cameras). >> > [CNG] At this stage I'm not proposing a particular format more just the > principle that the spatial information is an attribute of the individual > capture rather the capture set. > The T=, was to illustrate a spatial attribute. > > I don't know whether to satisfy the minimum complexity camp whether we > would need to compliment the geometric information with a further "hint". > Say something like VC1:purpose=main;t=[-30:30.**center] What is your intent with "purpose=main" ? What are the options with that field ? > . I read with their structured > approach where you can have an adjective and thought perhaps we could do > something like this in CLUE for parameters where most cases a generic > description will do but in other cases additional information may be > beneficial. > > Yes, that would be good. Regards Marshall > > >> We should have something flexible enough to represent people at podiums >> and the like, which I think this does with no effort. >> >> Regards >> Marshall >> >> >> >> >> Regards >> Marshall >> >> >> >> >> Regards >> Marshall >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org > > > >> >> >> >> >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> >> --000e0cd591329efe2304abecf879 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 1, 2011 at 10:19 PM, Christi= an Groves <Christian.Groves@nteczone.com> wrote:
Hello Marshall,


On 2/09/2011 11:23 AM, Marshall Eubanks wrote:
Dear Christian;


On Thu, Sep 1, 2011 at 9:02 PM, Christian Groves <Christian.Groves@nteczone.com<= /a> <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0Hello Marshall

=A0 =A0Please see my replies below.

=A0 =A0Regards, Christian


=A0 =A0On 2/09/2011 2:57 AM, Marshall Eubanks wrote:

=A0 =A0 =A0 =A0<snip>

=A0 =A0 =A0 =A0So, I use the axis of symmetry as the basic reference point= .
=A0 =A0 =A0 =A0Think of it as, where the audience is looking. If someone c= an
=A0 =A0 =A0 =A0come up with a better reference point, I am not wed to it, = but
=A0 =A0 =A0 =A0I would want to accommodate all of the above cases.


=A0 =A0[CNG] OK so the intention was that the axis of symmetry is not
=A0 =A0really related to a device but related to the "scene"


If by "device" you mean "camera or microphone or ...", = then, yes.

If by "device" you mean "telepresence unit, then I would arg= ue that the axis of symmetry is inherent =A0in the telepresence unit.

Note that the axis of symmetry just establishes the local angular reference= (i.e., what "60 degrees to the right" means). You also need a ce= ntral
point for distances. =A0As Stephan indicates, I think we should have a coor= dinate system for both capture and display.

=A0 =A0 =A0 =A0...




=A0 =A0 =A0 =A0 =A0 =A0 =A0 I don't see this as really much more compl= icated or byte
=A0 =A0 =A0 =A0 =A0 =A0 =A0 consuming and it really would avoid a bunch of= problems
=A0 =A0 =A0 =A0I see
=A0 =A0 =A0 =A0 =A0 =A0 =A0 as coming from overlaying a potentially variab= le 3-D
=A0 =A0 =A0 =A0spatial
=A0 =A0 =A0 =A0 =A0 =A0 =A0 order onto a simple list.

=A0 =A0 =A0 =A0 =A0 [CNG] Perhaps another approach is? to treat each captu= re set as
=A0 =A0 =A0 =A0 =A0 having "a spatial relationship" between medi= a captures however
=A0 =A0 =A0 =A0 =A0 there is no significance of the position of the media<= br> =A0 =A0 =A0 =A0capture in
=A0 =A0 =A0 =A0 =A0 the capture set definition itself (i.e. remove all spa= tial
=A0 =A0 =A0 =A0order
=A0 =A0 =A0 =A0 =A0 from the list). The spatial details related to the cap= ture are
=A0 =A0 =A0 =A0 =A0 given as attributes of each media capture, e.g. T, D, = V or
=A0 =A0 =A0 =A0other
=A0 =A0 =A0 =A0 =A0 as appropriate.



=A0 =A0 =A0 =A0I am not sure I am parsing that correctly. Could you provid= e
=A0 =A0 =A0 =A0an example ?


=A0 =A0[CNG] Something like:

=A0 =A0"MediaCaptures"
=A0 =A0IDENTITY =3D STRING
=A0 =A0Attributes =3D STRING
=A0 =A0IDENTITY:Attributes[";" *Attributes]
=A0 =A0"CaptureSets"
=A0 =A0"(" IDENTITY [";" *IDENTITY]

=A0 =A0e.g.
=A0 =A0MediaCaptures
=A0 =A0VC0:purpose=3Dmain;t=3D[-90:-30]
=A0 =A0VC1:purpose=3Dmain;t=3D[-30:30]
=A0 =A0VC2:purpose=3Dmain;t=3D[30:60]
=A0 =A0CaptureSets
=A0 =A0(VC1,VC0,VC2) or (VC0,VC2,VC1) or (VC0,VC1,VC3)

=A0 =A0It doesn't matter what the order of the identities are


that I think should be the case.

=A0 =A0all that the capture set indicates is that they are related. The =A0 =A0actual spatial information is defined in the definition of the
=A0 =A0capture.



So, VC0 captures far right to middle right (60 deg), V1 the center (30 deg)= . VC2 the left (30 deg), all non-overlapping ?
[CNG] Yes that's correct.



That seems fine to me (the format, if not the cameras).
[CNG] At this stage I'm not proposing a particular format more just the= principle that the spatial information is an attribute of the individual c= apture rather the capture set.
The T=3D<start_angle>,<end_angle> was to illustrate a spatial a= ttribute.

I don't know whether to satisfy the minimum complexity camp whether we = would need to compliment the geometric information with a further "hin= t". Say something like VC1:purpose=3Dmain;t=3D[-30:30.center] <= /blockquote>

What is your intent with "purpose=3Dmain" ? W= hat are the options with that field ?=A0
=A0
. I read <draft-polk-mmusic-traffic-class-for-sdp> with their = structured approach where you can have an adjective and thought perhaps we = could do something like this in CLUE for parameters where most cases a gene= ric description will do but in other cases additional information may be be= neficial.


Yes, that would be good.=A0
=
Regards
Marshall
=A0


We should have something flexible enough to represent people at podiums and= the like, which I think this does with no effort.

Regards
Marshall




=A0 =A0 =A0 =A0Regards
=A0 =A0 =A0 =A0Marshall




=A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Marshall

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Regards, Christian

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________________= _______________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0<mailto:clue@ietf.org>> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0<mailto:clue@ietf.org>

=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>


=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue





--000e0cd591329efe2304abecf879-- From Christian.Groves@nteczone.com Fri Sep 2 01:49:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C468F21F90A0 for ; Fri, 2 Sep 2011 01:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF5vTSLdj-rL for ; Fri, 2 Sep 2011 01:49:27 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE321F8C89 for ; Fri, 2 Sep 2011 01:49:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAMWVYE520VLN/2dsb2JhbAAMNqsYAQEBAQMBAQE1GxsGBAEQCyEWCAcJAwIBAgEVHxEGDQEFAgEBh3K3RIZlBKRK Received: from ppp118-209-82-205.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.82.205]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Sep 2011 18:20:59 +0930 Message-ID: <4E6098D1.5080007@nteczone.com> Date: Fri, 02 Sep 2011 18:50:25 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Marshall Eubanks References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> <4E602B17.4020402@nteczone.com> <4E603D20.7030207@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 08:49:27 -0000 Hello Marshall, In-line below. Regards, Christian ..snip.. > > > > > That seems fine to me (the format, if not the cameras). > > [CNG] At this stage I'm not proposing a particular format more > just the principle that the spatial information is an attribute of > the individual capture rather the capture set. > The T=, was to illustrate a spatial attribute. > > I don't know whether to satisfy the minimum complexity camp > whether we would need to compliment the geometric information with > a further "hint". Say something like > VC1:purpose=main;t=[-30:30.center] > > > What is your intent with "purpose=main" ? What are the options with > that field ? [CNG] This was just a copy of an attribute from the existing framework to show that there may be multiple attributes. > . I read with their > structured approach where you can have an adjective and thought > perhaps we could do something like this in CLUE for parameters > where most cases a generic description will do but in other cases > additional information may be beneficial. > > > Yes, that would be good. > > Regards > Marshall > > > > We should have something flexible enough to represent people > at podiums and the like, which I think this does with no effort. > > Regards > Marshall > > > > > Regards > Marshall > > > > > Regards > Marshall > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > > >> > > > > > > >>> > > > https://www.ietf.org/mailman/listinfo/clue > > > > > From marshall.eubanks@gmail.com Fri Sep 2 03:59:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9021F904E for ; Fri, 2 Sep 2011 03:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkyt5HCzYXK1 for ; Fri, 2 Sep 2011 03:59:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0833D21F904D for ; Fri, 2 Sep 2011 03:59:36 -0700 (PDT) Received: by yxj17 with SMTP id 17so1310526yxj.31 for ; Fri, 02 Sep 2011 04:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBoEXHedEotlu75AvYukBQT2jwUpujIw2xlcCj3JdCs=; b=R0Rb1oSvKBXWLBrt5a4Pb2bsRfk811tx2CKYC1szXgLSR+pD+/+p6gmzHtG+dtVZFv bPDMSpYpbxgEHhz1NXlkdRPM604WagdjYz0CsZTfU28s8reXhXbO/ZEFLm0PgfpoeMQ6 tvHMNfOoQuY4FG2P055/lw/7hlGDH8lz9L/c0= MIME-Version: 1.0 Received: by 10.150.177.16 with SMTP id z16mr1002470ybe.27.1314961272430; Fri, 02 Sep 2011 04:01:12 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Fri, 2 Sep 2011 04:01:12 -0700 (PDT) In-Reply-To: <4E6098D1.5080007@nteczone.com> References: <4E5E0C00.6050208@nteczone.com> <4E5F2E24.9050209@nteczone.com> <4E602B17.4020402@nteczone.com> <4E603D20.7030207@nteczone.com> <4E6098D1.5080007@nteczone.com> Date: Fri, 2 Sep 2011 07:01:12 -0400 Message-ID: From: Marshall Eubanks To: Christian Groves Content-Type: multipart/alternative; boundary=000e0cd6a95a8962d504abf347e6 Cc: clue@ietf.org Subject: Re: [clue] Use Case and Framework question X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 10:59:37 -0000 --000e0cd6a95a8962d504abf347e6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 2, 2011 at 4:50 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Marshall, > > > In-line below. > > Regards, Christian > > > ..snip.. > > >> >> >> >> That seems fine to me (the format, if not the cameras). >> >> [CNG] At this stage I'm not proposing a particular format more >> just the principle that the spatial information is an attribute of >> the individual capture rather the capture set. >> The T=, was to illustrate a spatial attribute. >> >> I don't know whether to satisfy the minimum complexity camp >> whether we would need to compliment the geometric information with >> a further "hint". Say something like >> VC1:purpose=main;t=[-30:30.**center] >> >> What is your intent with "purpose=main" ? What are the options with that >> field ? >> > > [CNG] This was just a copy of an attribute from the existing framework to > show that there may be multiple attributes. > > ACK, Marshall > > . I read with their >> structured approach where you can have an adjective and thought >> perhaps we could do something like this in CLUE for parameters >> where most cases a generic description will do but in other cases >> additional information may be beneficial. >> >> >> Yes, that would be good. >> >> Regards >> Marshall >> >> >> >> We should have something flexible enough to represent people >> at podiums and the like, which I think this does with no effort. >> >> Regards >> Marshall >> >> >> >> >> Regards >> Marshall >> >> >> >> >> Regards >> Marshall >> >> Regards, Christian >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org > > > >> >> >> >> > >> >> >> >>> >> >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> >> >> --000e0cd6a95a8962d504abf347e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 2, 2011 at 4:50 AM, Christia= n Groves <Christian.Groves@nteczone.com> wrote:
Hello Marshall,


In-line below.

Regards, Christian


..snip..





=A0 =A0 =A0 =A0That seems fine to me (the format, if not the cameras).

=A0 =A0[CNG] At this stage I'm not proposing a particular format more<= br> =A0 =A0just the principle that the spatial information is an attribute of<= br> =A0 =A0the individual capture rather the capture set.
=A0 =A0The T=3D<start_angle>,<end_angle> was to illustrate a s= patial attribute.

=A0 =A0I don't know whether to satisfy the minimum complexity camp
=A0 =A0whether we would need to compliment the geometric information with<= br> =A0 =A0a further "hint". Say something like
=A0 =A0VC1:purpose=3Dmain;t=3D[-30:30.center]

What is your intent with "purpose=3Dmain" ? What are the options = with that field ?

[CNG] This was just a copy of an attribute from the existing framework to s= how that there may be multiple attributes.


ACK,

Marshall
=A0

=A0 =A0. I read <draft-polk-mmusic-traffic-class-for-sdp> wit= h their
=A0 =A0structured approach where you can have an adjective and thought
=A0 =A0perhaps we could do something like this in CLUE for parameters
=A0 =A0where most cases a generic description will do but in other cases =A0 =A0additional information may be beneficial.


Yes, that would be good.

Regards
Marshall



=A0 =A0 =A0 =A0We should have something flexible enough to represent peopl= e
=A0 =A0 =A0 =A0at podiums and the like, which I think this does with no ef= fort.

=A0 =A0 =A0 =A0Regards
=A0 =A0 =A0 =A0Marshall




=A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Marshall




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Regards
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Marshall

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards, Christian

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __________________________= _____________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0<mailto:clue@ietf.org>> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0<mailto:clue@ietf.org>
=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>
=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>
=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>

=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>
=A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>>


=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue






--000e0cd6a95a8962d504abf347e6-- From allyn@cisco.com Sun Sep 4 15:19:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4821F85C0 for ; Sun, 4 Sep 2011 15:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgtYiBFdJDN4 for ; Sun, 4 Sep 2011 15:19:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D062C21F85C4 for ; Sun, 4 Sep 2011 15:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=53172; q=dns/txt; s=iport; t=1315174878; x=1316384478; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=L1gumQIznQbZeK4OpOxAeqFdxvzHFUrQjvm1F0NXQXk=; b=EAouZ+LFdXR/QsX0EeEnWI5wEL+BVPgLnAgk5PqUC1n85vJGtNcd42nq VPsKggtcbLRZtS9WdpHuu/TJ/qfE3I0/pZsOQDw9y8+FpUNf85vOqqtG5 CESTjD1pRdpd4f0O0NkYxbhK2HmJoIXOt55bpaep5aH6zn7cfVG4PJr2P Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcAAAr5Y06rRDoJ/2dsb2JhbABCDoI/liePdHiBRgEBAQEDAQEBDwEHAgsGAz4GBQwEAgEIEQQBAQsGEAEGAQYBJh8JCAEBBAESCBqHVZkpAZ1uhgpgBIdrkFuLPVg X-IronPort-AV: E=Sophos;i="4.68,330,1312156800"; d="scan'208,217";a="168245" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Sep 2011 22:21:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p84MLHuw030485; Sun, 4 Sep 2011 22:21:17 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 4 Sep 2011 15:21:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6B50.F703008C" x-cr-puzzleid: {4A9AEC13-20B7-4AC4-AE1C-21AD52736C90} x-cr-hashedpuzzle: AvCP DVNE ICR6 IUXe JJ0x L1rW UwcA YRYN Y/pF ZMpB ZhaU cSiH h7YO iHf+ jJub nb1+; 4; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAdgBlAG4ALgByAG8AbgBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AG0AYQByAHMAaABhAGwAbAAuAGUAdQBiAGEAbgBrAHMAQABnAG0AYQBpAGwALgBjAG8AbQA7AHAAawB5AHoAaQB2AGEAdABAAGEAbAB1AG0ALgBtAGkAdAAuAGUAZAB1AA==; Sosha1_v1; 7; {4A9AEC13-20B7-4AC4-AE1C-21AD52736C90}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sun, 04 Sep 2011 22:21:06 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAFEAdQBlAHMAdABpAG8AbgBzACAAbwBuACAAYgBhAHMAaQBjACAAbQBlAHMAcwBhAGcAZQAgAGYAbABvAHcAIABpAG4AIAB0AGgAZQAgAGYAcgBhAG0AZQB3AG8AcgBrAA== Content-class: urn:content-classes:message Date: Sun, 4 Sep 2011 15:21:06 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC057A8A7A@xmb-sjc-221.amer.cisco.com> In-Reply-To: <015d01cc640e$6f4ae200$4de0a600$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Questions on basic message flow in the framework Thread-Index: AcxkBvdjoPFGDASBSJWUzKE9wRkV+wABkemAAdCAZOA= References: <033601cc6261$f8487670$e8d96350$%roni@huawei.com><4E567C6C.9010504@cisco.com><00a901cc6359$484f0880$d8ed1980$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05603802@xmb-sjc-221.amer.cisco.com><00b001cc635f$f029b590$d07d20b0$%roni@huawei.com><4E57AA11.6090704@alum.mit.edu> <015d01cc640e$6f4ae200$4de0a600$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Marshall Eubanks" , "Paul Kyzivat" X-OriginalArrivalTime: 04 Sep 2011 22:21:17.0538 (UTC) FILETIME=[F72D0420:01CC6B50] Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 22:19:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6B50.F703008C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Roni, =20 I agree with Paul's notes on this thread, which say there are many ways to do things, etc. However, I had a question just in terms of the framework as it is currently spec'ed. Your sequence of 4 messages confuses me a bit. The framework suggests a series of 3 messages - consumer->provider->consumer->provider. Maybe your 4 messages are also meant to include the exchange of information in the opposite direction when the roles are reversed?? But that would be another 3 messages. So I'm unclear on the sequence you listed. =20 Thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, August 26, 2011 9:37 AM To: 'Marshall Eubanks'; 'Paul Kyzivat' Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework =20 Hi, It is not a three message flow but four as far as I understand in order to achieve a two way communication. =20 The caller will send his Consumer capability advertisement (as a consumer) and an SDP for non CLUE interoperability. The called party will send Consumer capability advertisement and his Media Capture Advertisement The calling party will send Media Capture Advertisement and can send Consumer config of provider streams ( what it wants to receive) The called party will send Consumer config of provider streams. =20 I think we need all these messages but should be aware of what it means. In the past we thought about having initial communication with partial streams. And get all streams after the full exchange. Maybe we can have it as an option that can be part of the offer/answer. =20 Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Friday, August 26, 2011 6:43 PM To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework =20 =20 On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat wrote: On 8/25/11 3:48 PM, Roni Even wrote: Hi, This will mean two stage, the initial SIP exchange will require a valid SDP for backward interoperability that will open one video, one video and CLUE channels and only afterwards the full telepresence sessions will be added. We can say that systems that support CLUE will wait for the exchange in the CLUE channel to establish media which is a delay. If we use multi body in the SIP message, we will still need to discuss how to have the three message exchange in an offer answer dialog. The way we chose will also affect my third question about using the messages after the initial media channels are running. This is why I was asking about maybe we need mode change messages. =20 There are many ways to accomplish this. Is your concern the call setup delay while more messages are exchanged? Or is it other aspects of user experience, such as establishing one video stream before the others? Delay due to extra message exchange can be hidden so that the user experience isn't diminished (much). E.g. the extra message(s) can be exchanged while "ringing" (on calling side) and before alerting commences (on called side). =20 This needs to be looked at but may be acceptable at call setup, which always seems to take a few seconds. =20 I am also worried about changes _during the call_, where a few seconds delay could be bad. =20 Here is an example (I am going to try and capture the worries I expressed in QC, and at the interim). =20 A session starts, with two endpoints separated by (say) 150 msec one way . There is=20 =20 Consumer capability advertisement |-----------------------------> =20 Media Capture Advertisement <-----------------------------| =20 Consumer config of provider |-----------------------------> streams=20 =20 That takes roughly 450 msec + a little, which seems OK. =20 1.) Won't in practice the provider send a SDP file to the consumer, which in practice the consumer should receive and parse (if only as an error check), so won't that add ANOTHER round trip ? So, won't that take 600 msec plus a little, which is less OK ? And, won't that also mean that, if there is a 1% packet loss, there will be a (1 - (0.99)^4 =3D) 4% chance of a problem with these handshakes ? And won't a drop on any of these 4 messages mean a considerably longer setup delay ?=20 =20 And, then=20 =20 2.) Suppose, at some point in the session, there is a network blip and inbound becomes congested. The provider needs to throttle back. The consumer detects this, says "I need to advertise less bandwidth," sends a corresponding CCA via UDP. The provider receives this, and sends a new MCA. =20 This gets lost in the congestion. Even if three in a row are sent, they might all be lost, as the link is congested. =20 So, then there is a timer set. Tick, tick, tick. The consumer will send more CCAs (presumably) once the timer times out, but nothing comes back. The consumer can talk to the provider, but it doesn't know it, and it isn't allowed to except through this three way, so the situation never gets resolved. Meanwhile, up at Layer 8, the company CEO is getting pissed off. (And, in some parallel universe, IESG ADs are asking questions about congestion control.) Even a 1 second timer would mean that the time to recover from _one_ control packet loss could be 1.5 seconds, which is not good.=20 =20 This says to me that either =20 - providers SHOULD include information about adapting to congestion in the first handshake, so that the consumer can send an appropriate config message as needed =20 or=20 =20 - consumers should be able to send a "squelch" message to the provider, saying "reduce bandwidth to me now," and let the provider puzzle it out. This could take the form of (say) a not to exceed bandwidth in the config message; a subsequent config could be the same except for a lowered NTE bandwidth. Obviously, in a really severe problem, you might want to set that to zero. =20 or both.=20 =20 All of this seems fairly fundamental to me, the sort of thing that needs to be addressed if we are going to use this 3-way handshake.=20 =20 Regards Marshall =20 =20 For instance, there could be multiple O/A exchanges, with preconditions used to delay the alerting. There could then also be exchanges over a "clue" stream between the first o/a and the last one resolving the preconditions. =09 I don't think its necessary to decide on this mechanism yet. =09 Thanks Paul =20 Roni -----Original Message----- From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Thursday, August 25, 2011 10:08 PM To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org Subject: RE: [clue] Questions on basic message flow in the framework =09 One option would be to establish CLUE through SIP, and then these messages are CLUE messages, not SIP messages. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 25, 2011 12:01 PM To: Andrew Pepperell (apeppere); clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework =09 Hi, During the initial discussion on this work one of the issues was if we are talking about one or two stage signaling. As far as I remember we talked about one stage signaling, is this still the case or do we still keep it open. This was way I asked about the mapping to SIP and why I think we need to consider it early to verify if the proposed message flow works with one stage signaling. Regards Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: Thursday, August 25, 2011 7:47 PM To: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework =09 Thanks Charles! To follow up: =09 >>[Roni] >> I was looking at the use cases of 3 to 3 and 3 to 1 and tried to understand what will be conveyed in the three messages and how will we use the information. >> The first question I had was how this relates to SIP. At which stage of the SIP call will the consumer advertize its capabilities? >[Charles] >I think it is best to focus on the framework a bit more before mapping to SIP. =09 Yes, that's been our approach so far... =09 >>[Roni] >> The third question I had was if these three messages can be repeated at any time or do we see a different message to request a mode change. >[Charles] >My understanding, based on the presentation in the virtual meeting, is that these messages, though shown as an ordered exchange, could theoretically come in any order at any time. =09 While for the purposes of of producing robust implementations messages would need to be handled "in any order at any time", within the model as proposed there are some constraints - specifically, a media stream provider must not send a media capture advertisement until it's seen at least one consumer capability advertisement, and a consumer would not be able to send a stream configuration message until it's seen at least one media capture advertisement from the provider. =09 Andy =09 =09 On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote: Hi Roni, =09 Please see inline. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, August 24, 2011 6:30 AM To: clue@ietf.org Subject: [clue] Questions on basic message flow in the framework =09 Hi, =09 In the interim meeting I mentioned that I that I support the model but think that there are parameters that I would like to add. At the meeting it was clear to me that there will be a new revision soon that will support parameters at the capture scene level. Trying to see which parameters I would like to see supported I looked at the message flow and I have some questions. Andy presented the basic message flow with three messages: =09 =09 =09 1. Consumer capability advertisement =09 2. Provider - media capture advertisement =09 3. Consumer configuration of provider streams. =09 =09 =09 I was looking at the use cases of 3 to 3 and 3 to 1 and tried to understand what will be conveyed in the three messages and how will we use the information. =09 The first question I had was how this relates to SIP. At which stage of the SIP call will the consumer advertize its capabilities? I think it is best to focus on the framework a bit more before mapping to SIP. In the second part, I was then looking at a telepresence system that has 3 65" screens where the distance between the screens including the frames is 6". The system has three cameras, each mounted on the center of a screen. The system is facing a room with three rows each row sits 6 people and each camera is capable of capturing a third of the room but the default views of each camera does not overlap with the others. The cameras support zoom and pan (local from the application). The system can decode up to four video streams where one is presentation (H.239 like). The system can support an internal 4-way multipoint call, means that it can receive the three main video streams from one, two or three endpoints. =09 I think that this is a very standard system, nothing special. =09 The telepresence application is willing to provide all this information as part of the consumer capability advertisement and according to Andy's slides the message include physical factors , user preferences and software limitations. =09 I am now trying to understand what the purpose of the consumer capability advertisement is in order to see what information is important to convey. =09 Is the reason for the consumer capability advertisement to allow the provider to propose a better media capability advertisement, or is it to allow the provider to optimize the content of the media streams he is sending based on the information provided. This will help with looking at which parameters can be used. The slides show that the information is used for the capability advertisements. I viewed it as being primarily for the former, but using it for the latter may make sense as well and should not be excluded. The extent to which the provider actually uses the information is implementation dependent. =09 =09 The third question I had was if these three messages can be repeated at any time or do we see a different message to request a mode change. My understanding, based on the presentation in the virtual meeting, is that these messages, though shown as an ordered exchange, could theoretically come in any order at any time. =09 Cheers, Charles Thanks =09 Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC6B50.F703008C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

I agree with Paul’s notes on this thread, which say = there are many ways to do things, etc.

However, I had a question just in terms of the framework = as it is currently spec’ed. Your sequence of 4 messages confuses me a = bit. The framework suggests a series of 3 messages – consumer->provider->consumer->provider.  Maybe your 4 = messages are also meant to include the exchange of information in the opposite = direction when the roles are reversed?? But that would be another 3 messages. So I’m unclear on the sequence you listed.

 

Thanks,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Friday, August 26, 2011 9:37 AM
To: 'Marshall Eubanks'; 'Paul Kyzivat'
Cc: clue@ietf.org
Subject: Re: [clue] Questions on basic message flow in the = framework

 

Hi,

It is not a three message flow but four as far as I = understand in order to achieve a two way communication.

 

The caller will send his Consumer capability advertisement (as a consumer) and an SDP for non CLUE = interoperability.

The called party will send Consumer capability = advertisement and his Media Capture Advertisement

The calling party will send Media Capture = Advertisement  and can send Consumer config of provider  streams ( what it = wants to receive)

The called party will send Consumer config of = provider  streams.

 

I think we need all these messages but should be = aware of what it means.

In the past we thought about having initial = communication with partial streams. And get all streams after the full exchange. Maybe = we can have it as an option that can be part of the = offer/answer.

 

Roni

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Marshall Eubanks
Sent: Friday, August 26, 2011 6:43 PM
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: [clue] Questions on basic message flow in the = framework

 

 

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat = <pkyzivat@alum.mit.edu> = wrote:

On 8/25/11 3:48 PM, Roni Even wrote:

Hi,
This will mean two stage, the initial SIP exchange will require a valid = SDP
for backward interoperability that will open one video, one video and = CLUE
channels and only afterwards the full telepresence sessions will be = added.
We can say that systems that support CLUE will wait for the exchange in = the
CLUE channel to establish media which is a delay.
If we use multi body in the SIP message, we will still need to discuss = how
to have the three message exchange in an offer answer dialog.

The way we chose will also affect my third question about using the = messages
after the initial media channels are running. This is why I was asking = about
maybe we need mode change messages.

 

There are many ways = to accomplish this.

Is your concern the call setup delay while more messages are exchanged? = Or is it other aspects of user experience, such as establishing one video = stream before the others?

Delay due to extra message exchange can be hidden so that the user = experience isn't diminished (much). E.g. the extra message(s) can be exchanged = while "ringing" (on calling side) and before alerting commences (on = called side).

 

This needs to be looked at but may be acceptable at = call setup, which always seems to take a few seconds.

 

I am also worried about changes _during the call_, = where a few seconds delay could be bad.

 

Here is an example (I am going to try and capture = the worries I expressed in QC, and at the interim).

 

A session starts, with two endpoints separated by = (say) 150 msec one way . There is 

 

Consumer capability advertisement |----------------------------->

 

Media Capture Advertisement       <-----------------------------|

 

Consumer config of provider       |----------------------------->

streams 

 

That takes roughly 450 msec + a little, which seems = OK.

 

1.) Won't in practice the provider send a SDP file = to the consumer, which in practice the consumer should receive and parse (if = only as an error check), so won't that add ANOTHER round trip ? So, won't that = take 600 msec plus a little, which is less OK ? And, won't that also mean = that,

if there is a 1% packet loss, there will be a (1 - = (0.99)^4 =3D)  4% chance of a problem with these handshakes ? And won't a = drop on any of these 4 messages mean a considerably longer setup delay = ? 

 

And, then 

 

2.) Suppose, at some point in the session, there is = a network blip and inbound becomes congested. The provider needs to = throttle back. The consumer detects this, says "I need to advertise less bandwidth," sends a corresponding CCA via UDP. The provider = receives this, and sends a new MCA.

 

This gets lost in the congestion. Even if three in = a row are sent, they might all be lost, as the link is congested.

 

So, then there is a timer set. Tick, tick, tick. = The consumer will send more CCAs (presumably) once the timer times out, but = nothing comes back. The consumer can talk to the provider, but it doesn't know = it, and it isn't allowed to except through

this three way, so the situation never gets = resolved. Meanwhile, up at Layer 8, the company CEO is getting pissed off. (And, in some = parallel universe, IESG ADs are asking questions about congestion control.) Even = a 1 second timer would mean that the time to recover from _one_ control = packet loss could be 1.5 seconds, which is not good. 

 

This says to me that either

 

- providers SHOULD include information about = adapting to congestion in the first handshake, so that the consumer can send an = appropriate

config message as needed

 

or 

 

- consumers  should be able to send a "squelch" message to the provider, saying "reduce = bandwidth to me now," and let the provider puzzle it out. This could take the = form of (say) a not to exceed bandwidth in the config message; a subsequent = config could be the same except for a lowered  NTE bandwidth. Obviously, = in a really severe problem, you might want to set that to = zero.

 

or both. 

 

All of this seems fairly fundamental to me, the = sort of thing that needs to be addressed if we are going to use this 3-way handshake. 

 

Regards

Marshall

 

 

=

For instance, there could be multiple O/A = exchanges, with preconditions used to delay the alerting. There could then also be = exchanges over a "clue" stream between the first o/a and the last one = resolving the preconditions.

I don't think its necessary to decide on this mechanism yet.

       Thanks
      =  Paul

=

 

Roni

-----Original = Message-----
From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Thursday, August 25, 2011 10:08 PM
To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org
Subject: RE: [clue] Questions on basic message flow in the framework

One option would be to establish CLUE through SIP, and then these
messages are CLUE messages, not SIP messages.

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf

Of

Roni Even
Sent: Thursday, August 25, 2011 12:01 PM
To: Andrew Pepperell (apeppere); clue@ietf.org
Subject: Re: [clue] Questions on basic message flow in the framework

Hi,
During the initial discussion on this work one of the issues was = if

we

are
talking about one or two stage signaling. As far as I remember we
talked
about one stage signaling, is this still the case or do we still = keep
it
open. This was way I asked about the mapping to SIP and why I = think

we

need
to consider it early to verify if the proposed message flow = works

with

one
stage signaling.
Regards
Roni

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On

Behalf

Of

Andy Pepperell
Sent: Thursday, August 25, 2011 7:47 PM
To: clue@ietf.org
Subject: Re: [clue] Questions on basic message flow in = the

framework

=


Thanks Charles! To follow up:

 >>[Roni]
 >>  I was looking at the use cases of 3 to 3 and 3 to 1 = and tried

to

=

understand what will be conveyed in the three = messages and how will

we

use the information.
 >>  The first question I had was how this relates to = SIP. At which
stage
of the SIP call will the consumer advertize its capabilities?
 >[Charles]
 >I think it is best to focus on the framework a bit more = before
mapping
to SIP.

Yes, that's been our approach so far...

 >>[Roni]
 >>  The third question I had was if these three = messages can be
repeated
at any time or do we see a different message to request a = mode

change.

 >[Charles]
 >My understanding, based on the presentation in the = virtual

meeting,

=

is
that these messages, though shown as an ordered exchange, could
theoretically come in any order at any time.

While for the purposes of of producing robust = implementations

messages

would need to be handled "in any order at any time", within the

model

=

as
proposed there are some constraints - specifically, a media stream
provider must not send a media capture advertisement until = it's

seen

at

least one consumer capability advertisement, and a = consumer would

not

=

be
able to send a stream configuration message until it's seen = at

least

=

one
media capture advertisement from the provider.

Andy


On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote:

Hi Roni,

Please see inline.

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On

Behalf

=

Of Roni Even

Sent: Wednesday, August 24, 2011 6:30 AM
To: clue@ietf.org
Subject: [clue] Questions on basic message flow in the framework

Hi,

In the interim meeting I mentioned that I that I support = the

model

=

but

think that there are parameters

that I would like to add. At the meeting it was = clear to me that

there

will be a new revision soon

that will support parameters at the capture scene = level. Trying

to

=

see

which parameters I would like

to see supported I looked at the message flow and I = have some

questions.

Andy presented the basic message flow with three = messages:



1.       Consumer capability advertisement

2.       Provider - media capture advertisement

3.       Consumer configuration of provider streams.



I was looking at the use cases of 3 to 3 and 3 to 1 and tried = to

understand what will be conveyed in

the three messages and how will we use the = information.

The first question I had was how this relates to SIP. At = which

stage

=

of the SIP call will the consumer

advertize its capabilities?

I think it is best to focus on the framework a bit = more before

mapping

to = SIP.

In the second part, I was then looking at a  telepresence system

that

has 3 65" screens where the

distance between the screens including the frames = is 6". The

system

=

has three cameras, each mounted on

the center of a screen. The system is facing a room = with three

rows

=

each row sits 6 people and each

camera is capable of capturing a third of the room = but the

default

=
=

views of each camera does not

overlap with the others. The cameras support zoom = and pan (local

from

the application).

The system can decode up to four video streams = where one is

presentation (H.239 like). The system = can

support an internal 4-way multipoint call, means = that it can

receive

=

the three main video streams from

one, two or three endpoints.

I think that this is a very standard system, nothing special.

The telepresence application is willing to provide all = this

information as part of the consumer

capability advertisement and according to Andy's = slides the

message

=

include physical factors , user

preferences and software limitations.

I am now trying to understand what the purpose of the = consumer

capability advertisement is in order = to

see what information is important to convey.

Is the reason for the consumer capability advertisement to = allow

the

=

provider to propose a better

media capability advertisement, or is it to allow = the provider

to

=
=

optimize the content of the media

streams he is sending based on the information = provided. This

will

=
=

help with looking at which

parameters can be used. The slides show that the = information is

used

=

for the capability

advertisements.

I viewed it as being primarily for the former, but = using it for

the

=
=

latter may make sense as well and should not be = excluded. The

extent

to

which the provider actually uses the information = is

implementation

=
=

dependent.



The third question I had was if these three messages can = be

repeated

=

at any time or do we see a

different message to = request a mode change.

My understanding, based on the presentation in the = virtual

meeting,

=

is

that these messages, = though shown as an ordered exchange, could
theoretically come in any order at any time.

Cheers,
Charles

Thanks

Roni Even

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CC6B50.F703008C-- From Even.roni@huawei.com Sun Sep 4 15:49:18 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554AF21F8876 for ; Sun, 4 Sep 2011 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-3.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTfea26gFxgy for ; Sun, 4 Sep 2011 15:49:11 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC321F86AF for ; Sun, 4 Sep 2011 15:49:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR000AV6SSPPG@szxga03-in.huawei.com> for clue@ietf.org; Mon, 05 Sep 2011 06:50:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR000KGHSSPO1@szxga03-in.huawei.com> for clue@ietf.org; Mon, 05 Sep 2011 06:50:49 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LR00057QSSIO2@szxml12-in.huawei.com>; Mon, 05 Sep 2011 06:50:49 +0800 (CST) Date: Mon, 05 Sep 2011 01:49:35 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC057A8A7A@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" , 'Marshall Eubanks' , 'Paul Kyzivat' Message-id: <01a601cc6b54$ef1ad600$cd508200$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Yy9xr+nzwokmLosHK+xQkg)" Content-language: en-us Thread-index: AcxkBvdjoPFGDASBSJWUzKE9wRkV+wABkemAAdCAZOAAAUO+QA== References: <033601cc6261$f8487670$e8d96350$%roni@huawei.com> <4E567C6C.9010504@cisco.com> <00a901cc6359$484f0880$d8ed1980$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05603802@xmb-sjc-221.amer.cisco.com> <00b001cc635f$f029b590$d07d20b0$%roni@huawei.com> <4E57AA11.6090704@alum.mit.edu> <015d01cc640e$6f4ae200$4de0a600$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC057A8A7A@xmb-sjc-221.amer.cisco.com> Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 22:49:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Yy9xr+nzwokmLosHK+xQkg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Allyn, This is for a two way communication since this is what we are talking about in CLUE (not streaming). I assume that a message can include two information blocks. For example the second message from the called party will include his consumer capability adv and his media capture adv if the first message had the calling party consumer capability adv. If this assumption is not true than we will need more messages to have a two way communication. Roni From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Monday, September 05, 2011 1:21 AM To: Roni Even; Marshall Eubanks; Paul Kyzivat Cc: clue@ietf.org Subject: RE: [clue] Questions on basic message flow in the framework Hi Roni, I agree with Paul's notes on this thread, which say there are many ways to do things, etc. However, I had a question just in terms of the framework as it is currently spec'ed. Your sequence of 4 messages confuses me a bit. The framework suggests a series of 3 messages - consumer->provider->consumer->provider. Maybe your 4 messages are also meant to include the exchange of information in the opposite direction when the roles are reversed?? But that would be another 3 messages. So I'm unclear on the sequence you listed. Thanks, Allyn From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, August 26, 2011 9:37 AM To: 'Marshall Eubanks'; 'Paul Kyzivat' Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework Hi, It is not a three message flow but four as far as I understand in order to achieve a two way communication. The caller will send his Consumer capability advertisement (as a consumer) and an SDP for non CLUE interoperability. The called party will send Consumer capability advertisement and his Media Capture Advertisement The calling party will send Media Capture Advertisement and can send Consumer config of provider streams ( what it wants to receive) The called party will send Consumer config of provider streams. I think we need all these messages but should be aware of what it means. In the past we thought about having initial communication with partial streams. And get all streams after the full exchange. Maybe we can have it as an option that can be part of the offer/answer. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Friday, August 26, 2011 6:43 PM To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat wrote: On 8/25/11 3:48 PM, Roni Even wrote: Hi, This will mean two stage, the initial SIP exchange will require a valid SDP for backward interoperability that will open one video, one video and CLUE channels and only afterwards the full telepresence sessions will be added. We can say that systems that support CLUE will wait for the exchange in the CLUE channel to establish media which is a delay. If we use multi body in the SIP message, we will still need to discuss how to have the three message exchange in an offer answer dialog. The way we chose will also affect my third question about using the messages after the initial media channels are running. This is why I was asking about maybe we need mode change messages. There are many ways to accomplish this. Is your concern the call setup delay while more messages are exchanged? Or is it other aspects of user experience, such as establishing one video stream before the others? Delay due to extra message exchange can be hidden so that the user experience isn't diminished (much). E.g. the extra message(s) can be exchanged while "ringing" (on calling side) and before alerting commences (on called side). This needs to be looked at but may be acceptable at call setup, which always seems to take a few seconds. I am also worried about changes _during the call_, where a few seconds delay could be bad. Here is an example (I am going to try and capture the worries I expressed in QC, and at the interim). A session starts, with two endpoints separated by (say) 150 msec one way . There is Consumer capability advertisement |-----------------------------> Media Capture Advertisement <-----------------------------| Consumer config of provider |-----------------------------> streams That takes roughly 450 msec + a little, which seems OK. 1.) Won't in practice the provider send a SDP file to the consumer, which in practice the consumer should receive and parse (if only as an error check), so won't that add ANOTHER round trip ? So, won't that take 600 msec plus a little, which is less OK ? And, won't that also mean that, if there is a 1% packet loss, there will be a (1 - (0.99)^4 =) 4% chance of a problem with these handshakes ? And won't a drop on any of these 4 messages mean a considerably longer setup delay ? And, then 2.) Suppose, at some point in the session, there is a network blip and inbound becomes congested. The provider needs to throttle back. The consumer detects this, says "I need to advertise less bandwidth," sends a corresponding CCA via UDP. The provider receives this, and sends a new MCA. This gets lost in the congestion. Even if three in a row are sent, they might all be lost, as the link is congested. So, then there is a timer set. Tick, tick, tick. The consumer will send more CCAs (presumably) once the timer times out, but nothing comes back. The consumer can talk to the provider, but it doesn't know it, and it isn't allowed to except through this three way, so the situation never gets resolved. Meanwhile, up at Layer 8, the company CEO is getting pissed off. (And, in some parallel universe, IESG ADs are asking questions about congestion control.) Even a 1 second timer would mean that the time to recover from _one_ control packet loss could be 1.5 seconds, which is not good. This says to me that either - providers SHOULD include information about adapting to congestion in the first handshake, so that the consumer can send an appropriate config message as needed or - consumers should be able to send a "squelch" message to the provider, saying "reduce bandwidth to me now," and let the provider puzzle it out. This could take the form of (say) a not to exceed bandwidth in the config message; a subsequent config could be the same except for a lowered NTE bandwidth. Obviously, in a really severe problem, you might want to set that to zero. or both. All of this seems fairly fundamental to me, the sort of thing that needs to be addressed if we are going to use this 3-way handshake. Regards Marshall For instance, there could be multiple O/A exchanges, with preconditions used to delay the alerting. There could then also be exchanges over a "clue" stream between the first o/a and the last one resolving the preconditions. I don't think its necessary to decide on this mechanism yet. Thanks Paul Roni -----Original Message----- From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Thursday, August 25, 2011 10:08 PM To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org Subject: RE: [clue] Questions on basic message flow in the framework One option would be to establish CLUE through SIP, and then these messages are CLUE messages, not SIP messages. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 25, 2011 12:01 PM To: Andrew Pepperell (apeppere); clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework Hi, During the initial discussion on this work one of the issues was if we are talking about one or two stage signaling. As far as I remember we talked about one stage signaling, is this still the case or do we still keep it open. This was way I asked about the mapping to SIP and why I think we need to consider it early to verify if the proposed message flow works with one stage signaling. Regards Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: Thursday, August 25, 2011 7:47 PM To: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework Thanks Charles! To follow up: >>[Roni] >> I was looking at the use cases of 3 to 3 and 3 to 1 and tried to understand what will be conveyed in the three messages and how will we use the information. >> The first question I had was how this relates to SIP. At which stage of the SIP call will the consumer advertize its capabilities? >[Charles] >I think it is best to focus on the framework a bit more before mapping to SIP. Yes, that's been our approach so far... >>[Roni] >> The third question I had was if these three messages can be repeated at any time or do we see a different message to request a mode change. >[Charles] >My understanding, based on the presentation in the virtual meeting, is that these messages, though shown as an ordered exchange, could theoretically come in any order at any time. While for the purposes of of producing robust implementations messages would need to be handled "in any order at any time", within the model as proposed there are some constraints - specifically, a media stream provider must not send a media capture advertisement until it's seen at least one consumer capability advertisement, and a consumer would not be able to send a stream configuration message until it's seen at least one media capture advertisement from the provider. Andy On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote: Hi Roni, Please see inline. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, August 24, 2011 6:30 AM To: clue@ietf.org Subject: [clue] Questions on basic message flow in the framework Hi, In the interim meeting I mentioned that I that I support the model but think that there are parameters that I would like to add. At the meeting it was clear to me that there will be a new revision soon that will support parameters at the capture scene level. Trying to see which parameters I would like to see supported I looked at the message flow and I have some questions. Andy presented the basic message flow with three messages: 1. Consumer capability advertisement 2. Provider - media capture advertisement 3. Consumer configuration of provider streams. I was looking at the use cases of 3 to 3 and 3 to 1 and tried to understand what will be conveyed in the three messages and how will we use the information. The first question I had was how this relates to SIP. At which stage of the SIP call will the consumer advertize its capabilities? I think it is best to focus on the framework a bit more before mapping to SIP. In the second part, I was then looking at a telepresence system that has 3 65" screens where the distance between the screens including the frames is 6". The system has three cameras, each mounted on the center of a screen. The system is facing a room with three rows each row sits 6 people and each camera is capable of capturing a third of the room but the default views of each camera does not overlap with the others. The cameras support zoom and pan (local from the application). The system can decode up to four video streams where one is presentation (H.239 like). The system can support an internal 4-way multipoint call, means that it can receive the three main video streams from one, two or three endpoints. I think that this is a very standard system, nothing special. The telepresence application is willing to provide all this information as part of the consumer capability advertisement and according to Andy's slides the message include physical factors , user preferences and software limitations. I am now trying to understand what the purpose of the consumer capability advertisement is in order to see what information is important to convey. Is the reason for the consumer capability advertisement to allow the provider to propose a better media capability advertisement, or is it to allow the provider to optimize the content of the media streams he is sending based on the information provided. This will help with looking at which parameters can be used. The slides show that the information is used for the capability advertisements. I viewed it as being primarily for the former, but using it for the latter may make sense as well and should not be excluded. The extent to which the provider actually uses the information is implementation dependent. The third question I had was if these three messages can be repeated at any time or do we see a different message to request a mode change. My understanding, based on the presentation in the virtual meeting, is that these messages, though shown as an ordered exchange, could theoretically come in any order at any time. Cheers, Charles Thanks Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_Yy9xr+nzwokmLosHK+xQkg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Allyn,

This is for a two way communication since this is what we are talking = about in CLUE (not streaming). I assume that a message can include two = information blocks. For example the second message from the called party = will include his consumer capability adv and his media capture adv if = the first message had the calling party consumer capability adv. If this = assumption is not true than we will need more messages to have a two way = communication.

 

Roni

 

From:= = Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Monday, = September 05, 2011 1:21 AM
To: Roni Even; Marshall Eubanks; = Paul Kyzivat
Cc: clue@ietf.org
Subject: RE: [clue] = Questions on basic message flow in the = framework

 

Hi Roni,

 

I agree with Paul’s notes on this thread, which say there are = many ways to do things, etc.

However, I had a question just in terms of the framework as it is = currently spec’ed. Your sequence of 4 messages confuses me a bit. = The framework suggests a series of 3 messages – = consumer->provider->consumer->provider.  Maybe your 4 = messages are also meant to include the exchange of information in the = opposite direction when the roles are reversed?? But that would be = another 3 messages. So I’m unclear on the sequence you = listed.

 

Thanks,

Allyn

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Friday, August 26, 2011 9:37 = AM
To: 'Marshall Eubanks'; 'Paul Kyzivat'
Cc: = clue@ietf.org
Subject: Re: [clue] Questions on basic message = flow in the framework

 

Hi,

It is not a three message flow but four as far as I understand in = order to achieve a two way communication.

 

The caller will send his Consumer capability advertisement (as = a consumer) and an SDP for non CLUE interoperability.

The called party will send Consumer capability = advertisement and his Media Capture Advertisement

The calling party will send Media Capture = Advertisement  and can send Consumer config of provider =  streams ( what it wants to receive)

The called party will send Consumer config of provider =  streams.

 

I think we = need all these messages but should be aware of what it = means.

In the past we thought about = having initial communication with partial streams. And get all streams = after the full exchange. Maybe we can have it as an option that can be = part of the offer/answer.

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Marshall Eubanks
Sent: Friday, August 26, 2011 6:43 = PM
To: Paul Kyzivat
Cc: = clue@ietf.org
Subject: Re: [clue] Questions on basic message = flow in the framework

 

 

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 8/25/11 3:48 PM, Roni = Even wrote:

Hi,
This will mean two = stage, the initial SIP exchange will require a valid SDP
for backward = interoperability that will open one video, one video and = CLUE
channels and only afterwards the full telepresence sessions will = be added.
We can say that systems that support CLUE will wait for the = exchange in the
CLUE channel to establish media which is a = delay.
If we use multi body in the SIP message, we will still need to = discuss how
to have the three message exchange in an offer answer = dialog.

The way we chose will also affect my third question about = using the messages
after the initial media channels are running. This = is why I was asking about
maybe we need mode change = messages.

 

There are many ways to accomplish = this.

Is your concern the call setup delay while more messages = are exchanged? Or is it other aspects of user experience, such as = establishing one video stream before the others?

Delay due to = extra message exchange can be hidden so that the user experience isn't = diminished (much). E.g. the extra message(s) can be exchanged while = "ringing" (on calling side) and before alerting commences (on = called side).

 

This needs to be looked at but may be acceptable at = call setup, which always seems to take a few = seconds.

 

I = am also worried about changes _during the call_, where a few seconds = delay could be bad.

 

Here is an example (I am going to try and capture the = worries I expressed in QC, and at the = interim).

 

A = session starts, with two endpoints separated by (say) 150 msec one way . = There is 

 

Consumer capability advertisement = |----------------------------->

 

Media Capture Advertisement       = <-----------------------------|

 

Consumer config of provider       = |----------------------------->

streams 

 

That takes roughly 450 msec + a little, which seems = OK.

 

1.) Won't in practice the provider send a SDP file to = the consumer, which in practice the consumer should receive and parse = (if only as an error check), so won't that add ANOTHER round trip ? So, = won't that take 600 msec plus a little, which is less OK ? And, won't = that also mean that,

if = there is a 1% packet loss, there will be a (1 - (0.99)^4 =3D)  4% = chance of a problem with these handshakes ? And won't a drop on any of = these 4 messages mean a considerably longer setup delay = ? 

 

And, then 

 

2.) Suppose, at some point in the session, there is a = network blip and inbound becomes congested. The provider needs to = throttle back. The consumer detects this, says "I need to advertise = less bandwidth," sends a corresponding CCA via UDP. The = provider receives this, and sends a new MCA.

 

This gets lost in the congestion. Even if three in a = row are sent, they might all be lost, as the link is = congested.

 

So, then there is a timer set. Tick, tick, tick. The = consumer will send more CCAs (presumably) once the timer times out, but = nothing comes back. The consumer can talk to the provider, but it = doesn't know it, and it isn't allowed to except = through

this three way, so = the situation never gets resolved. Meanwhile, up at Layer 8, the company = CEO is getting pissed off. (And, in some parallel universe, IESG ADs are = asking questions about congestion control.) Even a 1 second timer would = mean that the time to recover from _one_ control packet loss could be = 1.5 seconds, which is not good. 

 

This says to me that = either

 

- = providers SHOULD include information about adapting to congestion in the = first handshake, so that the consumer can send an = appropriate

config message = as needed

 

or 

 

- = consumers  should be able to send a "squelch" message to = the provider, saying "reduce bandwidth to me now," and let the = provider puzzle it out. This could take the form of (say) a not to = exceed bandwidth in the config message; a subsequent config could be the = same except for a lowered  NTE bandwidth. Obviously, in a really = severe problem, you might want to set that to = zero.

 

or both. 

 

All of this seems fairly fundamental to me, the sort = of thing that needs to be addressed if we are going to use this 3-way = handshake. 

 

Regards

Marshall

 

 

For instance, there could be multiple O/A = exchanges, with preconditions used to delay the alerting. There could = then also be exchanges over a "clue" stream between the first = o/a and the last one resolving the preconditions.

I don't think = its necessary to decide on this mechanism yet.

    =    Thanks
    =    Paul

 

Roni

-----Original Message-----
From: Allyn = Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Thursday, August 25, = 2011 10:08 PM
To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org
Subject: RE: [clue] Questions on = basic message flow in the framework

One option would be to = establish CLUE through SIP, and then these
messages are CLUE = messages, not SIP messages.

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf

Of

Roni = Even
Sent: Thursday, August 25, 2011 12:01 PM
To: Andrew Pepperell = (apeppere); clue@ietf.org
Subject: Re: [clue] Questions on = basic message flow in the framework

Hi,
During the initial = discussion on this work one of the issues was if

we

are
talking = about one or two stage signaling. As far as I remember = we
talked
about one stage signaling, is this still the case or do = we still keep
it
open. This was way I asked about the mapping to = SIP and why I think

we

need
to = consider it early to verify if the proposed message flow = works

with

one
stage = signaling.
Regards
Roni

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On

Behalf

Of

Andy = Pepperell
Sent: Thursday, August 25, 2011 7:47 PM
To: clue@ietf.org
Subject: Re: [clue] Questions on = basic message flow in the

framework


Thanks Charles! To follow = up:

 >>[Roni]
 >>  I was looking at = the use cases of 3 to 3 and 3 to 1 and = tried

to

understand what will be conveyed in the three = messages and how will

we

use the = information.
 >>  The first question I had was how = this relates to SIP. At which
stage
of the SIP call will the = consumer advertize its = capabilities?
 >[Charles]
 >I think it is best to = focus on the framework a bit more before
mapping
to = SIP.

Yes, that's been our approach so = far...

 >>[Roni]
 >>  The third = question I had was if these three messages can be
repeated
at any = time or do we see a different message to request a mode

change.

 >[Charles]
 >My understanding, = based on the presentation in the virtual

meeting,

is
that these messages, though shown as an = ordered exchange, could
theoretically come in any order at any = time.

While for the purposes of of producing robust = implementations

messages

would need = to be handled "in any order at any time", within = the

model

as
proposed there are some constraints - = specifically, a media stream
provider must not send a media capture = advertisement until it's

seen

at

least one = consumer capability advertisement, and a consumer would

not

be
able to send a stream configuration = message until it's seen at

least

one
media capture advertisement from the = provider.

Andy


On 24/08/2011 21:09, Charles Eckel = (eckelcu) wrote:

Hi Roni,

Please see = inline.

-----Original = Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On

Behalf

Of Roni Even

Sent: Wednesday, August 24, 2011 6:30 AM
To: clue@ietf.org
Subject: [clue] Questions on = basic message flow in the framework

Hi,

In the interim = meeting I mentioned that I that I support = the

model

but

think = that there are parameters

that I = would like to add. At the meeting it was clear to me = that

there

will be a new revision soon

that will support parameters at the capture scene = level. Trying

to

see

which = parameters I would like

to see = supported I looked at the message flow and I have some

questions.

Andy = presented the basic message flow with three messages:



1. =       Consumer capability advertisement

2.   =     Provider - media capture advertisement

3.   =     Consumer configuration of provider = streams.



I was looking at the use cases of 3 to 3 and 3 = to 1 and tried to

understand what = will be conveyed in

the three = messages and how will we use the information.

The first question = I had was how this relates to SIP. At = which

stage

of the SIP call will the = consumer

advertize its = capabilities?

I think it is best to = focus on the framework a bit more before

mapping

to SIP.

In the second part, I was then looking at a =  telepresence system

that

has 3 65" = screens where the

distance between = the screens including the frames is 6". The

system

has three cameras, each mounted = on

the center of a screen. The system = is facing a room with three

rows

each row sits 6 people and = each

camera is capable of capturing a = third of the room but the

default

views of each camera does = not

overlap with the others. The = cameras support zoom and pan (local

from

the = application).

The system can decode = up to four video streams where one is

presentation (H.239 like). The system = can

support an internal 4-way = multipoint call, means that it can

receive

the three main video streams = from

one, two or three = endpoints.

I think that this is a very standard system, nothing = special.

The telepresence application is willing to provide all = this

information as part of the = consumer

capability advertisement and = according to Andy's slides the

message

include physical factors , = user

preferences and software = limitations.

I am now trying to understand what the purpose of = the consumer

capability advertisement = is in order to

see what information = is important to convey.

Is the reason for the consumer capability = advertisement to allow

the

provider to propose a better

media capability advertisement, or is it to allow the = provider

to

optimize the content of the = media

streams he is sending based on = the information provided. = This

will

help with looking at which

parameters can be used. The slides show that the = information is

used

for the capability

advertisements.

I = viewed it as being primarily for the former, but using it = for

the

latter may make sense as well and should not = be excluded. The

extent

to

which the = provider actually uses the information is

implementation

dependent.



The third question I had was if these three = messages can be

repeated

at any time or do we see a

different message to = request a mode change.

My = understanding, based on the presentation in the = virtual

meeting,

is

that these messages, though shown as an = ordered exchange, could
theoretically come in any order at any = time.

Cheers,
Charles

Thanks

Roni Even

_______________________________________________
clue= mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
= clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
= clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


______________________________________= _________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


_______________________________________________
= clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

= --Boundary_(ID_Yy9xr+nzwokmLosHK+xQkg)-- From marshall.eubanks@gmail.com Sun Sep 4 16:05:11 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D699221F8A4F for ; Sun, 4 Sep 2011 16:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2pmLLA+uU8G for ; Sun, 4 Sep 2011 16:05:09 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2DB21F8A4B for ; Sun, 4 Sep 2011 16:05:09 -0700 (PDT) Received: by yie12 with SMTP id 12so3668981yie.31 for ; Sun, 04 Sep 2011 16:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M++YQ+3YK1KKnuNQxPPXUhcmpq2IUiW5GxTnVU5UEcM=; b=XW/I1yrNug8x2DZMxs1KmxFxTfXooqrPe98MrzACRjzwSo+TP4pjz93pVRbuB2BQmw ANEDGaUlBc7RGYn6tsxbttEFw4uYLPRPGc8Fuu8FxfVilnU+EeNqvK1ZnS6bDAVou05g RDPdi09y4oGEXBFJZkg0Vnr3B8QbQYe8J2OJA= MIME-Version: 1.0 Received: by 10.150.8.15 with SMTP id 15mr2455520ybh.198.1315177609032; Sun, 04 Sep 2011 16:06:49 -0700 (PDT) Received: by 10.150.185.9 with HTTP; Sun, 4 Sep 2011 16:06:48 -0700 (PDT) In-Reply-To: <01a601cc6b54$ef1ad600$cd508200$%roni@huawei.com> References: <033601cc6261$f8487670$e8d96350$%roni@huawei.com> <4E567C6C.9010504@cisco.com> <00a901cc6359$484f0880$d8ed1980$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05603802@xmb-sjc-221.amer.cisco.com> <00b001cc635f$f029b590$d07d20b0$%roni@huawei.com> <4E57AA11.6090704@alum.mit.edu> <015d01cc640e$6f4ae200$4de0a600$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC057A8A7A@xmb-sjc-221.amer.cisco.com> <01a601cc6b54$ef1ad600$cd508200$%roni@huawei.com> Date: Sun, 4 Sep 2011 19:06:48 -0400 Message-ID: From: Marshall Eubanks To: Roni Even Content-Type: multipart/alternative; boundary=000e0cd48d3633f53204ac25a6b7 Cc: clue@ietf.org Subject: Re: [clue] Questions on basic message flow in the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 23:05:12 -0000 --000e0cd48d3633f53204ac25a6b7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Allyn, Roni; On Sun, Sep 4, 2011 at 6:49 PM, Roni Even wrote: > Allyn,**** > > This is for a two way communication since this is what we are talking abo= ut > in CLUE (not streaming). I assume that a message can include two informat= ion > blocks. For example the second message from the called party will include > his consumer capability adv and his media capture adv if the first messag= e > had the calling party consumer capability adv. If this assumption is not > true than we will need more messages to have a two way communication.**** > > ** > I still think that there is likely to be lower level communications (such a= s RTCP or SIP) going on that we may not care too much about in the CLUE protocols, but which will still add to the setup / convergence time, and so we need to be aware of. Regards Marshall > ** > > Roni**** > > ** ** > > *From:* Allyn Romanow (allyn) [mailto:allyn@cisco.com] > *Sent:* Monday, September 05, 2011 1:21 AM > *To:* Roni Even; Marshall Eubanks; Paul Kyzivat > *Cc:* clue@ietf.org > > *Subject:* RE: [clue] Questions on basic message flow in the framework***= * > > ** ** > > Hi Roni,**** > > ** ** > > I agree with Paul=92s notes on this thread, which say there are many ways= to > do things, etc.**** > > However, I had a question just in terms of the framework as it is current= ly > spec=92ed. Your sequence of 4 messages confuses me a bit. The framework > suggests a series of 3 messages =96 consumer->provider->consumer->provide= r. > Maybe your 4 messages are also meant to include the exchange of informati= on > in the opposite direction when the roles are reversed?? But that would be > another 3 messages. So I=92m unclear on the sequence you listed.**** > > ** ** > > Thanks,**** > > Allyn**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Roni Even > *Sent:* Friday, August 26, 2011 9:37 AM > *To:* 'Marshall Eubanks'; 'Paul Kyzivat' > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Questions on basic message flow in the framework***= * > > ** ** > > Hi,**** > > It is not a three message flow but four as far as I understand in order t= o > achieve a two way communication.**** > > ** ** > > The caller will send his Consumer capability advertisement (as a consumer= ) > and an SDP for non CLUE interoperability.**** > > The called party will send Consumer capability advertisement and his Medi= a > Capture Advertisement**** > > The calling party will send Media Capture Advertisement and can send > Consumer config of provider streams ( what it wants to receive)**** > > The called party will send Consumer config of provider streams.**** > > ** ** > > I think we need all these messages but should be aware of what it means.*= * > ** > > In the past we thought about having initial communication with partial > streams. And get all streams after the full exchange. Maybe we can have i= t > as an option that can be part of the offer/answer.**** > > ** ** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Marshall Eubanks > *Sent:* Friday, August 26, 2011 6:43 PM > *To:* Paul Kyzivat > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Questions on basic message flow in the framework***= * > > ** ** > > ** ** > > On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat > wrote:**** > > On 8/25/11 3:48 PM, Roni Even wrote:**** > > Hi, > This will mean two stage, the initial SIP exchange will require a valid S= DP > for backward interoperability that will open one video, one video and CLU= E > channels and only afterwards the full telepresence sessions will be added= . > We can say that systems that support CLUE will wait for the exchange in t= he > CLUE channel to establish media which is a delay. > If we use multi body in the SIP message, we will still need to discuss ho= w > to have the three message exchange in an offer answer dialog. > > The way we chose will also affect my third question about using the > messages > after the initial media channels are running. This is why I was asking > about > maybe we need mode change messages.**** > > ** ** > > There are many ways to accomplish this. > > Is your concern the call setup delay while more messages are exchanged? O= r > is it other aspects of user experience, such as establishing one video > stream before the others? > > Delay due to extra message exchange can be hidden so that the user > experience isn't diminished (much). E.g. the extra message(s) can be > exchanged while "ringing" (on calling side) and before alerting commences > (on called side).**** > > ** ** > > This needs to be looked at but may be acceptable at call setup, which > always seems to take a few seconds.**** > > ** ** > > I am also worried about changes _during the call_, where a few seconds > delay could be bad.**** > > ** ** > > Here is an example (I am going to try and capture the worries I expressed > in QC, and at the interim).**** > > ** ** > > A session starts, with two endpoints separated by (say) 150 msec one way = . > There is **** > > ** ** > > Consumer capability advertisement |----------------------------->**** > > ** ** > > Media Capture Advertisement <-----------------------------|**** > > ** ** > > Consumer config of provider |----------------------------->**** > > streams **** > > ** ** > > That takes roughly 450 msec + a little, which seems OK.**** > > ** ** > > 1.) Won't in practice the provider send a SDP file to the consumer, which > in practice the consumer should receive and parse (if only as an error > check), so won't that add ANOTHER round trip ? So, won't that take 600 ms= ec > plus a little, which is less OK ? And, won't that also mean that,**** > > if there is a 1% packet loss, there will be a (1 - (0.99)^4 =3D) 4% chan= ce > of a problem with these handshakes ? And won't a drop on any of these 4 > messages mean a considerably longer setup delay ? **** > > ** ** > > And, then **** > > ** ** > > 2.) Suppose, at some point in the session, there is a network blip and > inbound becomes congested. The provider needs to throttle back. The consu= mer > detects this, says "I need to advertise less bandwidth," sends a > corresponding CCA via UDP. The provider receives this, and sends a new MC= A. > **** > > ** ** > > This gets lost in the congestion. Even if three in a row are sent, they > might all be lost, as the link is congested.**** > > ** ** > > So, then there is a timer set. Tick, tick, tick. The consumer will send > more CCAs (presumably) once the timer times out, but nothing comes back. = The > consumer can talk to the provider, but it doesn't know it, and it isn't > allowed to except through**** > > this three way, so the situation never gets resolved. Meanwhile, up at > Layer 8, the company CEO is getting pissed off. (And, in some parallel > universe, IESG ADs are asking questions about congestion control.) Even a= 1 > second timer would mean that the time to recover from _one_ control packe= t > loss could be 1.5 seconds, which is not good. **** > > ** ** > > This says to me that either**** > > ** ** > > - providers SHOULD include information about adapting to congestion in th= e > first handshake, so that the consumer can send an appropriate**** > > config message as needed**** > > ** ** > > or **** > > ** ** > > - consumers should be able to send a "squelch" message to the provider, > saying "reduce bandwidth to me now," and let the provider puzzle it out. > This could take the form of (say) a not to exceed bandwidth in the config > message; a subsequent config could be the same except for a lowered NTE > bandwidth. Obviously, in a really severe problem, you might want to set t= hat > to zero.**** > > ** ** > > or both. **** > > ** ** > > All of this seems fairly fundamental to me, the sort of thing that needs = to > be addressed if we are going to use this 3-way handshake. **** > > ** ** > > Regards**** > > Marshall**** > > ** ** > > **** > > For instance, there could be multiple O/A exchanges, with preconditions > used to delay the alerting. There could then also be exchanges over a "cl= ue" > stream between the first o/a and the last one resolving the preconditions= . > > I don't think its necessary to decide on this mechanism yet. > > Thanks > Paul**** > > ** ** > > Roni**** > > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Sent: Thursday, August 25, 2011 10:08 PM > To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org > Subject: RE: [clue] Questions on basic message flow in the framework > > One option would be to establish CLUE through SIP, and then these > messages are CLUE messages, not SIP messages.**** > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf**** > > Of**** > > Roni Even > Sent: Thursday, August 25, 2011 12:01 PM > To: Andrew Pepperell (apeppere); clue@ietf.org > Subject: Re: [clue] Questions on basic message flow in the framework > > Hi, > During the initial discussion on this work one of the issues was if**** > > we**** > > are > talking about one or two stage signaling. As far as I remember we > talked > about one stage signaling, is this still the case or do we still keep > it > open. This was way I asked about the mapping to SIP and why I think**** > > we**** > > need > to consider it early to verify if the proposed message flow works**** > > with**** > > one > stage signaling. > Regards > Roni**** > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On**** > > Behalf**** > > Of**** > > Andy Pepperell > Sent: Thursday, August 25, 2011 7:47 PM > To: clue@ietf.org > Subject: Re: [clue] Questions on basic message flow in the**** > > framework**** > > > Thanks Charles! To follow up: > > >>[Roni] > >> I was looking at the use cases of 3 to 3 and 3 to 1 and tried**** > > to**** > > understand what will be conveyed in the three messages and how will**** > > we**** > > use the information. > >> The first question I had was how this relates to SIP. At which > stage > of the SIP call will the consumer advertize its capabilities? > >[Charles] > >I think it is best to focus on the framework a bit more before > mapping > to SIP. > > Yes, that's been our approach so far... > > >>[Roni] > >> The third question I had was if these three messages can be > repeated > at any time or do we see a different message to request a mode**** > > change.**** > > >[Charles] > >My understanding, based on the presentation in the virtual**** > > meeting,**** > > is > that these messages, though shown as an ordered exchange, could > theoretically come in any order at any time. > > While for the purposes of of producing robust implementations**** > > messages**** > > would need to be handled "in any order at any time", within the**** > > model**** > > as > proposed there are some constraints - specifically, a media stream > provider must not send a media capture advertisement until it's**** > > seen**** > > at**** > > least one consumer capability advertisement, and a consumer would**** > > not**** > > be > able to send a stream configuration message until it's seen at**** > > least**** > > one > media capture advertisement from the provider. > > Andy > > > On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote:**** > > Hi Roni, > > Please see inline.**** > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On**** > > Behalf**** > > Of Roni Even**** > > Sent: Wednesday, August 24, 2011 6:30 AM > To: clue@ietf.org > Subject: [clue] Questions on basic message flow in the framework > > Hi, > > In the interim meeting I mentioned that I that I support the**** > > model**** > > but**** > > think that there are parameters**** > > that I would like to add. At the meeting it was clear to me that**** > > there**** > > will be a new revision soon**** > > that will support parameters at the capture scene level. Trying**** > > to**** > > see**** > > which parameters I would like**** > > to see supported I looked at the message flow and I have some**** > > questions.**** > > Andy presented the basic message flow with three messages: > > > > 1. Consumer capability advertisement > > 2. Provider - media capture advertisement > > 3. Consumer configuration of provider streams. > > > > I was looking at the use cases of 3 to 3 and 3 to 1 and tried to**** > > understand what will be conveyed in**** > > the three messages and how will we use the information. > > The first question I had was how this relates to SIP. At which**** > > stage**** > > of the SIP call will the consumer**** > > advertize its capabilities?**** > > I think it is best to focus on the framework a bit more before**** > > mapping**** > > to SIP.**** > > In the second part, I was then looking at a telepresence system**** > > that**** > > has 3 65" screens where the**** > > distance between the screens including the frames is 6". The**** > > system**** > > has three cameras, each mounted on**** > > the center of a screen. The system is facing a room with three**** > > rows**** > > each row sits 6 people and each**** > > camera is capable of capturing a third of the room but the**** > > default**** > > views of each camera does not**** > > overlap with the others. The cameras support zoom and pan (local**** > > from**** > > the application).**** > > The system can decode up to four video streams where one is**** > > presentation (H.239 like). The system can**** > > support an internal 4-way multipoint call, means that it can**** > > receive**** > > the three main video streams from**** > > one, two or three endpoints. > > I think that this is a very standard system, nothing special. > > The telepresence application is willing to provide all this**** > > information as part of the consumer**** > > capability advertisement and according to Andy's slides the**** > > message**** > > include physical factors , user**** > > preferences and software limitations. > > I am now trying to understand what the purpose of the consumer**** > > capability advertisement is in order to**** > > see what information is important to convey. > > Is the reason for the consumer capability advertisement to allow**** > > the**** > > provider to propose a better**** > > media capability advertisement, or is it to allow the provider**** > > to**** > > optimize the content of the media**** > > streams he is sending based on the information provided. This**** > > will**** > > help with looking at which**** > > parameters can be used. The slides show that the information is**** > > used**** > > for the capability**** > > advertisements.**** > > I viewed it as being primarily for the former, but using it for**** > > the**** > > latter may make sense as well and should not be excluded. The**** > > extent**** > > to**** > > which the provider actually uses the information is**** > > implementation**** > > dependent.**** > > > > The third question I had was if these three messages can be**** > > repeated**** > > at any time or do we see a**** > > different message to request a mode change.**** > > My understanding, based on the presentation in the virtual**** > > meeting,**** > > is**** > > that these messages, though shown as an ordered exchange, could > theoretically come in any order at any time. > > Cheers, > Charles**** > > Thanks > > Roni Even**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --000e0cd48d3633f53204ac25a6b7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Allyn, Roni;

On Sun, Sep 4, 2011 at 6:49 = PM, Roni Even <Even.roni@huawei.com> wrote:

Allyn,

This is for a two way communication since this is what we are talking abo= ut in CLUE (not streaming). I assume that a message can include two informa= tion blocks. For example the second message from the called party will incl= ude his consumer capability adv and his media capture adv if the first mess= age had the calling party consumer capability adv. If this assumption is no= t true than we will need more messages to have a two way communication.<= /u>

=A0


I still think = that there is likely to be lower level communications (such as RTCP or SIP)= going on that we may not care too much about in
the CLUE protocols, but which will still add to the setup / convergenc= e time, and so we need to be aware of.

Regards
Marshall

=A0

Roni=

=A0

From:= Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent:= Monday, September 05, 2011 1:21 AM
To: Roni Even; Marshall Eubanks; Paul Kyzivat
Cc: clue@ietf.org


Subject: RE: [clue] Questions on = basic message flow in the framework

=A0

Hi Roni,

=A0=

I agr= ee with Paul=92s notes on this thread, which say there are many ways to do = things, etc.

However, I had a question just in terms of = the framework as it is currently spec=92ed. Your sequence of 4 messages con= fuses me a bit. The framework suggests a series of 3 messages =96 consumer-= >provider->consumer->provider.=A0 Maybe your 4 messages are also m= eant to include the exchange of information in the opposite direction when = the roles are reversed?? But that would be another 3 messages. So I=92m unc= lear on the sequence you listed.

=A0

Thanks,

Allyn

=A0

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Roni Even
Sent: Friday, August 26, 2011 9:37 AM
To: 'Marshall Eu= banks'; 'Paul Kyzivat'
Cc: clue@ietf.org
Subject: Re: [clue] Qu= estions on basic message flow in the framework

=A0

Hi,=

I= t is not a three message flow but four as far as I understand in order to a= chieve a two way communication.

=A0

The caller will send his Consumer capability adver= tisement (as a consumer) and an SDP for non CLUE interoperability.

The called party will send Consumer capability adver= tisement and his Media Capture Advertisement

The calling party will send Media Capture Advertisement =A0and ca= n send Consumer config of provider =A0streams ( what it wants to receive)

The called party will send Consumer config of provid= er =A0streams.

=A0

I think we need all these messages but should be aw= are of what it means.

In the past we thought about having initial communic= ation with partial streams. And get all streams after the full exchange. Ma= ybe we can have it as an option that can be part of the offer/answer.

=A0

Roni

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Marshall Eubanks
Sent: Friday, August 26, 2011 6:43 PM
To: Paul Kyzivat
= Cc: clue@ietf.org=
Subject: Re: [clue] Questions on basic message flow in the f= ramework

=A0

=A0

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> w= rote:

On 8/25/11 3:48 PM, Roni Even wrote:<= /u>

Hi,
This will mean two stage, the initial = SIP exchange will require a valid SDP
for backward interoperability that= will open one video, one video and CLUE
channels and only afterwards the full telepresence sessions will be added.<= br>We can say that systems that support CLUE will wait for the exchange in = the
CLUE channel to establish media which is a delay.
If we use multi= body in the SIP message, we will still need to discuss how
to have the three message exchange in an offer answer dialog.

The wa= y we chose will also affect my third question about using the messages
a= fter the initial media channels are running. This is why I was asking about=
maybe we need mode change messages.

=A0

There are many ways to accomplish this.

Is your concern the c= all setup delay while more messages are exchanged? Or is it other aspects o= f user experience, such as establishing one video stream before the others?=

Delay due to extra message exchange can be hidden so that the user expe= rience isn't diminished (much). E.g. the extra message(s) can be exchan= ged while "ringing" (on calling side) and before alerting commenc= es (on called side).

=A0

This needs to be looked at but may be acceptable at call setup, whi= ch always seems to take a few seconds.

=A0

I am also worried ab= out changes _during the call_, where a few seconds delay could be bad.

=A0

<= div>

Here is an example (I am going to try and capture th= e worries I expressed in QC, and at the interim).

=A0

A session starts, with two endpoints separated by (say) 150 msec one way . = There is=A0

=A0

Consumer capability adverti= sement |----------------------------->

=A0

Media Capture Advertisement =A0 =A0 =A0 <----------------= -------------|

= =A0

Consumer config of provider =A0 =A0 =A0 |------= ----------------------->

streams=A0

= =A0

That takes roughly 450 msec + a little, w= hich seems OK.

= =A0

1.) Won't in practice t= he provider send a SDP file to the consumer, which in practice the consumer= should receive and parse (if only as an error check), so won't that ad= d ANOTHER round trip ? So, won't that take 600 msec plus a little, whic= h is less OK ? And, won't that also mean that,

if there is a 1% packet loss, there will = be a (1 - (0.99)^4 =3D) =A04% chance of a problem with these handshakes ? A= nd won't a drop on any of these 4 messages mean a considerably longer s= etup delay ?=A0

=A0

And, then=A0

=A0

2.) Suppose, at = some point in the session, there is a network blip and inbound becomes cong= ested. The provider needs to throttle back. The consumer detects this, says= "I need to advertise less bandwidth," sends=A0a corresponding CC= A via UDP. The provider receives this, and sends a new MCA.

=A0

This gets lost in the congestion. Even if three in a row are= sent, they might all be lost, as the link is congested.

<= /div>

=A0

So, then there is a timer set. Tick, tick, tick. The consumer will = send more CCAs (presumably) once the timer times out, but nothing comes bac= k. The consumer can talk to the provider, but it doesn't know it, and i= t isn't allowed to except through

this three way, so the situation never ge= ts resolved. Meanwhile, up at Layer 8, the company CEO is getting pissed of= f. (And, in some parallel universe, IESG ADs are asking questions about con= gestion control.) Even a 1 second timer would mean that the time to recover= from _one_ control packet loss could be 1.5 seconds, which is not good.=A0=

=A0

This says to me that either

=A0

-= providers SHOULD include information about adapting to congestion in the f= irst handshake, so that the consumer can send an appropriate<= /p>

config message as needed

=A0

or=A0

= =A0

- consumers =A0should be able to send a &= quot;squelch" message to the provider, saying "reduce bandwidth t= o me now," and let the provider puzzle it out. This could take the for= m of (say) a not to exceed bandwidth in the config message; a subsequent co= nfig could be the same except for a lowered =A0NTE bandwidth. Obviously, in= a really severe problem, you might want to set that to zero.=

=A0

or both.=A0

=A0

All of this seems= fairly fundamental to me, the sort of thing that needs to be addressed if = we are going to use this 3-way handshake.=A0

=A0

Regards

M= arshall

=A0

=A0

For instance, there could be multiple O/A exchanges, with preconditions use= d to delay the alerting. There could then also be exchanges over a "cl= ue" stream between the first o/a and the last one resolving the precon= ditions.

I don't think its necessary to decide on this mechanism yet.
=A0 =A0 =A0 =A0Thanks
=A0 =A0 =A0 =A0Paul=

=A0

=

Roni

-----Original Messag= e-----
From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Thursday, August 25, 2011 10:08= PM
To: Roni Even; Andrew Pepperell (apeppere); clue@ietf.org
Subject: RE: [clue] Questions on basic message flow in the framework
One option would be to establish CLUE through SIP, and then these
messa= ges are CLUE messages, not SIP messages.

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf<= u>

Of

Roni Even=
Sent: Thursday, August 25, 2011 12:01 PM
To: Andrew Pepperell (apepp= ere); clue@ietf.org<= br>Subject: Re: [clue] Questions on basic message flow in the framework

Hi,
During the initial discussion on this work one of the issues was= if

we

are
talking about one or two stage signaling. As far as I re= member we
talked
about one stage signaling, is this still the case or do we still = keep
it
open. This was way I asked about the mapping to SIP and why I= think

we

need
to consider it early to verify if the proposed message flow works

with

one
stage signaling.
Regards<= br> Roni

-----Original Message-----
= From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On

Behalf

Of=

Andy Pepperell
Sent: Thursday, Aug= ust 25, 2011 7:47 PM
To: clue@ietf.org
Subject: Re: [clue] Questions on basic message flow in the

framework


Thanks Charles! To follow up:

=A0>>= [Roni]
=A0>> =A0I was looking at the use cases of 3 to 3 and 3 to = 1 and tried

to<= u>

understand what will be conveyed in th= e three messages and how will

we

use the information.
=A0>> =A0The first question I had was how= this relates to SIP. At which
stage
of the SIP call will the consume= r advertize its capabilities?
=A0>[Charles]
=A0>I think it is best to focus on the framework a b= it more before
mapping
to SIP.

Yes, that's been our approa= ch so far...

=A0>>[Roni]
=A0>> =A0The third question = I had was if these three messages can be
repeated
at any time or do we see a different message to request a mode<= u>

change.

=A0>[Charles]
=A0>My understanding, based on the pr= esentation in the virtual

meeting,

is
that these messages, though shown as an ordered exchange, could
th= eoretically come in any order at any time.

While for the purposes of= of producing robust implementations

messages

would need to be handled &= quot;in any order at any time", within the

model

as
proposed there are some constraints - specific= ally, a media stream
provider must not send a media capture advertisemen= t until it's

seen<= u>

at

least one= consumer capability advertisement, and a consumer would

<= p class=3D"MsoNormal">not

be
able to send a stream configuration message un= til it's seen at

l= east

one
media capture advertisement from the provider= .

Andy


On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote= :

Hi= Roni,

Please see inline.

-----Origina= l Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On

Behalf

<= p class=3D"MsoNormal"> Of Roni Even

Sent: Wednesday, Augus= t 24, 2011 6:30 AM
To: clue@ietf.org
Subject: [clue] Questions on basic message flow in t= he framework

Hi,

In the interim meeting I mentioned that I that I support the=

model

but

think th= at there are parameters

that I woul= d like to add. At the meeting it was clear to me that

there

will be a new revision soon

that will support parameters at the = capture scene level. Trying

to

see<= /p>

which parameters I would like

to see supported I looked at the message flow and I have = some

questions.

Andy presented the basic message flow with three messages:



1= . =A0 =A0 =A0 Consumer capability advertisement

2. =A0 =A0 =A0 Provi= der - media capture advertisement

3. =A0 =A0 =A0 Consumer configurat= ion of provider streams.



I was looking at the use cases of 3 to 3 and 3 to 1 and tried t= o

understand what will be conveyed = in

the three messages and how will = we use the information.

The first question I had was how this relates to SIP. At which

stage

of the SIP call will the consumer

<= p class=3D"MsoNormal">advertize its capabilities?

I think it is best to focus on the framework a bit more befo= re

mapping

to SIP.

In the second part, I was then looking at a =A0telepresence = system

that

has 3 6= 5" screens where the

distance = between the screens including the frames is 6". The

<= p class=3D"MsoNormal"> system

has three came= ras, each mounted on

the center of a screen. The system is facing a room = with three

rows=

each row sits 6 people and each

camera is capable of capturing a third of the room but = the

default<= /u>

views of each camera does not

overlap with the others. The cameras support zoom and pan= (local

from=

the application).

The system can decode up to four video streams where one is=

presentation (H.239 like). The system can=

support an internal 4-way multipoint call, means tha= t it can

receive

the three main video streams from

<= p class=3D"MsoNormal">one, two or three endpoints.

I think that this= is a very standard system, nothing special.

The telepresence applic= ation is willing to provide all this

information as part of the consumer

capability advertisement and according to Andy'= s slides the

message

include physical factors , user=

preferences and software limitations.

I am no= w trying to understand what the purpose of the consumer

capability advertisement is in order to<= /p>

see what information is important to convey.

= Is the reason for the consumer capability advertisement to allow<= /u>

the

provider to propose a better

media capability advertisement, or is it to allow the prov= ider

to<= /p>

optimize the content of the media

<= p class=3D"MsoNormal">streams he is sending based on the information provid= ed. This

= will

help with looking at which

parameters can be used. The slides show that the information= is

used<= u>

for the capability

advertisements.

I viewed it as bein= g primarily for the former, but using it for

=

the

latter may make sense as well and shou= ld not be excluded. The

extent

to

which the p= rovider actually uses the information is

implementation

dependent.<= /u>



The third question I had was if these= three messages can be

repeated

at any time = or do we see a

different message to = request a mode change.

My understan= ding, based on the presentation in the virtual

meeting,

is

t= hat these messages, though shown as an ordered exchange, could
theoretic= ally come in any order at any time.

Cheers,
Charles=

Thanks

Roni Ev= en

________________________________= _______________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue maili= ng list
clue@ietf.org
https= ://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing listclue@ietf.org
http= s://www.ietf.org/mailman/listinfo/clue


_________________= ______________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mail= man/listinfo/clue


___________________________________= ____________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue<= /a>

=A0

=

--000e0cd48d3633f53204ac25a6b7-- From mary.ietf.barnes@gmail.com Wed Sep 7 08:18:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2621F8A57 for ; Wed, 7 Sep 2011 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qBIIh8hE5KM for ; Wed, 7 Sep 2011 08:18:55 -0700 (PDT) Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 570A821F85CE for ; Wed, 7 Sep 2011 08:18:52 -0700 (PDT) Received: by vws10 with SMTP id 10so9188195vws.16 for ; Wed, 07 Sep 2011 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uHrl4U7DOGgWdFwEOluvE7vIuMWf3YBJR7kxKRWDQx4=; b=LA4LvZwisuPrgRFQ5L42bhWzepuEJradPSZ/JQ8wXkuICCk3olU7qLDKnPnzKANb9E RJqtqUgCVr5OXmF73lxSN4DV89lCrHqWVVtW1KRlohaoiIC3q0WFJ2RZ4QTk3235SxjV 8jXnovAnKraPLizycZFdv+AMgLKqc9F/SAZa4= MIME-Version: 1.0 Received: by 10.52.109.66 with SMTP id hq2mr6688516vdb.157.1315408841662; Wed, 07 Sep 2011 08:20:41 -0700 (PDT) Received: by 10.52.35.2 with HTTP; Wed, 7 Sep 2011 08:20:41 -0700 (PDT) In-Reply-To: References: <1241030509.3022037.1314646459806.JavaMail.doodle@worker2> Date: Wed, 7 Sep 2011 10:20:41 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5485fcabde1bb04ac5b7c5d Subject: Re: [clue] Doodle: Link for poll "CLUE WG F2F Interim" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:19:00 -0000 --bcaec5485fcabde1bb04ac5b7c5d Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We have a quorom for this meeting, so we will have a f2f in Andover, Massachusetts, Tuesday Oct. 11th and 12th. The meeting will last 1.5 days to allow folks to catch a flight on Wednesday afternoon - we'll adjust the stop time based upon when folks must leave. Note, that the logistics in Andover are being worked - the meeting will either be at the Polycom office (100 Minuteman Road) or a nearby hotel. We'll announce the details as soon as they are worked out. We will also post the Webex information for remote participants. The agenda will be something like the following: Day 1: --------- 9:00-9:10 Chair - status, agenda bash 9:10-09:50 Discussion of any remaining open issues for the use cases and framework 09:50-10:00 Short coffee break 10:00-11:30 Proposed framework discussion 11:30-13:00 Lunch 13:30-15:00 Proposed framework discussion 15:00-15:20 Break 15:20-17:00 Proposed framework discussion 17:00-18:00 Summary and identification of key items for discussion on Tuesday Day 2 (note this agenda will be finalized based on the outcome of Tuesday's meeting) -------- 08:30-08:45 Plans for the day 08:45-10:30 Discussion 10:30-10:45 Break 10:45-12:30 Discussion 12:30-13:00 Discussion of way forward and summary of action items We'll publish an agenda with drafts and related reading a week or two before the meeting so that folks can arrive prepared. Regards, Mary On Mon, Aug 29, 2011 at 4:45 PM, Mary Barnes wrote: > Hi folks, > > We are considering holding a face to face for CLUE in order to progress the > framework. In speaking to some of the primary authors, October 11th and 12th > (1.5 days) looks like it might work. The plan is to host the meeting in > Boston (ideally at the Polycom Andover site, but we'll need to work out the > logistics). However, we first need an idea of how many people could attend > a f2f. > http://doodle.com/h3ahqn9ht96m839k > > We would also have a Webex session. If you are not able to attend a f2f > but would participate via Webex, please include a comment indicating such. > > In order to plan, we would like responses no later than Monday, Sept. 5th > at 5pm Pacific. > > We will do a separate doodle poll for a virtual interim if we don't get > enough folks able to attend a f2f. > > Thanks, > Mary > CLUE WG co-chair > > > --bcaec5485fcabde1bb04ac5b7c5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

We have a quorom for this meeting, so we will = have a f2f in Andover, Massachusetts, Tuesday Oct. 11th and 12th. =A0The me= eting will last 1.5 days to allow folks to catch a flight on Wednesday afte= rnoon - we'll adjust the stop time based upon when folks must leave.=A0=

Note, that the logistics in Andover are being worked - = the meeting will either be at the Polycom office (100 Minuteman Road) or a = nearby hotel. =A0We'll announce the details as soon as they are worked = out. =A0We will also post the Webex information for remote participants.=A0=

The agenda will be something like the following:
<= div>
Day 1:
---------
9:00-9:10 Chair - s= tatus, agenda bash
9:10-09:50 Discussion of any remaining open is= sues for the use cases and framework
09:50-10:00 Short coffee break
10:00-11:30 Proposed framewor= k discussion
11:30-13:00 Lunch=A0
13:30-15:00 =A0=A0Pro= posed framework discussion
15:00-15:20 =A0Break
15:20-1= 7:00 =A0Proposed framework discussion
17:00-18:00 =A0Summary and identification of key items for discussion = on Tuesday

Day 2 =A0(note this agenda will be fina= lized based on the outcome of Tuesday's meeting)
--------
08:30-08:45 =A0Plans for the day
08:45-10:30 =A0Discussion
10:30-10:45 =A0Break
10:45-12:30 =A0Discussion
12:30-13:00 =A0Discussion of way forward and summary of action items
=


We'll publish an agenda with drafts and relat= ed reading a week or two before the meeting so that folks can arrive prepar= ed. =A0

Regards,
Mary

On Mon, Aug 29, 2011 at 4:45 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi folks,

We are considering holding a face to face fo= r CLUE in order to progress the framework. In speaking to some of the prima= ry authors, October 11th and 12th (1.5 days) looks like it might work. =A0T= he plan is to host the meeting in Boston (ideally at the Polycom Andover si= te, but we'll need to work out the logistics). =A0However, we first nee= d an idea of how many people could attend a f2f. =A0
http://doodle.com/h3ahqn9ht96m839k

We would also have a Webex session. =A0If you are not able to attend a = f2f but would participate via Webex, please include a comment indicating su= ch.=A0

In order to plan, we would like responses no later than Monday, Sept. 5th = at 5pm Pacific. =A0

We will do = a separate doodle poll for a virtual interim if we don't get enough fol= ks able to attend a f2f.

Thanks,
Mary
CLUE WG co-chair



--bcaec5485fcabde1bb04ac5b7c5d-- From wwwrun@ietfa.amsl.com Mon Sep 12 09:38:44 2011 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 4E96121F8B21; Mon, 12 Sep 2011 09:38:44 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110912163844.4E96121F8B21@ietfa.amsl.com> Date: Mon, 12 Sep 2011 09:38:44 -0700 (PDT) Cc: clue@ietf.org Subject: [clue] CLUE WG Interim meeting, Oct. 11th & 12, 2011 - Andover, Massachusetts, USA X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 16:38:44 -0000 Hi Folks, Based upon WG input and consultation with our area director, a face-to-face interim meeting is being scheduled for the CLUE WG. Date: Oct. 11-12th, 2011 (full day on the 11th, 1/2 day on the 12th) Location: Andover, Massachusetts. Exact meeting location is TBA - either we will meet at the Polycom office (100 Minuteman Road, Andover, Mass) or a nearby hotel. We'll announce the details as soon as they are finalized. We will also post the Webex information for remote participants. The draft agenda is as follows: Day 1: --------- 9:00-9:10 Chair - status, agenda bash 9:10-09:50 Discussion of any remaining open issues for the use cases and framework 09:50-10:00 Short coffee break 10:00-11:30 Proposed framework discussion 11:30-13:00 Lunch 13:30-15:00 Proposed framework discussion 15:00-15:20 Break 15:20-17:00 Proposed framework discussion 17:00-18:00 Summary and identification of key items for discussion on Tuesday Day 2 (note this agenda will be finalized based on the outcome of Tuesday's meeting) -------- 08:30-08:45 Plans for the day 08:45-10:30 Discussion 10:30-10:45 Break 10:45-12:30 Discussion 12:30-13:00 Discussion of way forward and summary of action items Complete details and meeting materials will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary Barnes, Paul Kyzivat CLUE WG chairs From Even.roni@huawei.com Wed Sep 14 05:56:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6603421F8BCB for ; Wed, 14 Sep 2011 05:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.739 X-Spam-Level: X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmCBL8X3fKuO for ; Wed, 14 Sep 2011 05:56:58 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BBE6A21F8B98 for ; Wed, 14 Sep 2011 05:56:58 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI002SGK2ENZ@szxga03-in.huawei.com> for clue@ietf.org; Wed, 14 Sep 2011 20:59:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI00JM4K2DGP@szxga03-in.huawei.com> for clue@ietf.org; Wed, 14 Sep 2011 20:59:02 +0800 (CST) Received: from windows8d787f9 ([59.37.10.82]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LRI00N7RK283S@szxml12-in.huawei.com> for clue@ietf.org; Wed, 14 Sep 2011 20:59:01 +0800 (CST) Date: Wed, 14 Sep 2011 15:57:42 +0300 From: Roni Even To: clue@ietf.org Message-id: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aO6OKQSVhnoGWC56UBwqIQ)" Content-language: en-us Thread-index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPA== Subject: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 12:56:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aO6OKQSVhnoGWC56UBwqIQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation." In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation". Is there going to be a description for the capture scene that will specify what is the capture scene of? As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use? Thanks Roni Even --Boundary_(ID_aO6OKQSVhnoGWC56UBwqIQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation."

In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation".

Is there going to be a description for the capture scene that will specify what is the capture scene of?

As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use?

Thanks

Roni Even

< oNormal> 

--Boundary_(ID_aO6OKQSVhnoGWC56UBwqIQ)-- From bbaldino@cisco.com Wed Sep 14 06:51:18 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF221F8B8C for ; Wed, 14 Sep 2011 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvFYikzkVWpZ for ; Wed, 14 Sep 2011 06:51:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 628D121F8B91 for ; Wed, 14 Sep 2011 06:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=7751; q=dns/txt; s=iport; t=1316008403; x=1317218003; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=GQLn/LxvrsqxYS/7Yub9w3mqL4Wc659hMB0UUTq9t3Y=; b=RbDtGx+OvH9kW3zVBBWAMKLAQ6TMlJWhlUT9ysIJRSducaFjcxZ3DaGJ jrPqS/nrZhhdhJwN48zJmsAWYLSyJgdukRzACZySEnertEJEypYpvSrIR WI++qz0oyLiPj3J1E6czMZSB565z+qt/31kbrKL2Hy0BHY2W2afoOB/bN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AALSwcE6rRDoH/2dsb2JhbABBgk2WH457eIFTAQEBAQMSAQkRA0IXAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqfMQGeNIYOYASHbpB1jCE X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208,217";a="2066115" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 14 Sep 2011 13:53:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8EDrN12011162; Wed, 14 Sep 2011 13:53:23 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 06:53:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC72E5.AAFB4547" Date: Wed, 14 Sep 2011 06:53:18 -0700 Message-ID: In-Reply-To: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Qusetion on Captyre Scene and Capture set thread-index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPAANvnvg References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 14 Sep 2011 13:53:23.0185 (UTC) FILETIME=[AB2D4610:01CC72E5] Subject: Re: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:51:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC72E5.AAFB4547 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A capture has a 'role' attribute that describes it as presentation or participant video, so for the current cases we've seen that as sufficient (instead of putting a similar attribute on the entire capture set). =20 A capture set describes a single capture scene, so you couldn't have multiple capture sets describing the same 'scene', but I'd say how a device decides to split up captures amongst scenes is somewhat up to them. Splitting up presentation and participant captures into two separate scenes seems to make sense as there's no spatial relationship between the two sets of captures. From the receive side, I don't think a receiver would choose only a single capture scene to view, I think it would choose captures from each capture set. =20 -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, September 14, 2011 5:58 AM To: clue@ietf.org Subject: [clue] Qusetion on Captyre Scene and Capture set =20 Hi, In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation." In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation".=20 Is there going to be a description for the capture scene that will specify what is the capture scene of? As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use? Thanks Roni Even < oNormal> ------_=_NextPart_001_01CC72E5.AAFB4547 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A capture has a ‘role’ attribute that describes = it as presentation or participant video, so for the current cases we’ve seen that as sufficient (instead of putting a similar attribute on the entire capture = set).

 

A capture set describes a single capture scene, so you = couldn’t have multiple capture sets describing the same ‘scene’, but = I’d say how a device decides to split up captures amongst scenes is somewhat = up to them.  Splitting up presentation and participant captures into two separate scenes seems to make sense as there’s no spatial = relationship between the two sets of captures.  From the receive side, I = don’t think a receiver would choose only a single capture scene to view, I = think it would choose captures from each capture set.

 

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, September 14, 2011 5:58 AM
To: clue@ietf.org
Subject: [clue] Qusetion on Captyre Scene and Capture = set

 

Hi,

In the last Interim meeting presentation on Capture = sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments = that "There could be multiple capture scenes - For example another scene = for a presentation."

In the next slide I saw "There can be multiple = capture sets, such as one for people and one for a presentation". =

Is there going to be a description for the capture = scene that will specify what is the capture scene of?

As for capture sets do you see the presentation and = people capture set in the same scene or are they in a separate scenes, how do = you decide which one to use?

Thanks

Roni Even

< oNormal>

------_=_NextPart_001_01CC72E5.AAFB4547-- From Even.roni@huawei.com Wed Sep 14 07:39:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549121F8C2A for ; Wed, 14 Sep 2011 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=-2.754, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED9SwNy6xiaW for ; Wed, 14 Sep 2011 07:39:54 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 946BA21F8BE7 for ; Wed, 14 Sep 2011 07:39:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI005I3OTY90@szxga03-in.huawei.com> for clue@ietf.org; Wed, 14 Sep 2011 22:41:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRI007QYOTYKA@szxga03-in.huawei.com> for clue@ietf.org; Wed, 14 Sep 2011 22:41:58 +0800 (CST) Received: from windows8d787f9 ([59.37.10.82]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LRI005G0OTY7I@szxml11-in.huawei.com>; Wed, 14 Sep 2011 22:41:58 +0800 (CST) Date: Wed, 14 Sep 2011 17:40:43 +0300 From: Roni Even In-reply-to: To: "'Brian Baldino (bbaldino)'" , clue@ietf.org Message-id: <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_U2yK2cc+Hk7RDy10iszKFA)" Content-language: en-us Thread-index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPAANvnvgAAEPbWA= References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> Subject: Re: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:39:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_U2yK2cc+Hk7RDy10iszKFA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian, Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple capture sets in slide 2. I think that the relation between the capture scene and capture set is not clear. Looking at section 9 of the framework draft I can see two capture sets (#1 and #2) and it says that the receiver picks a row from each capture set. So is this one capture scene or two. The text talk about sending capture sets but not capture scenes and there is no drawing that include both. As for the presentation, a row in a capture set can include multiple media captures that has implied spatial relation, so if you put the presentation in a row with three other video captures how is it spatially related. Can you put the presentation in any position in the row. I also understand that the presentation cannot be in a separate row in a capture set since the selection is one row from a capture set. This leads me to think that there can be more than one capture set or more than one scene if we define the hierarchal relation between the tw. Regards Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Wednesday, September 14, 2011 4:53 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Qusetion on Captyre Scene and Capture set A capture has a 'role' attribute that describes it as presentation or participant video, so for the current cases we've seen that as sufficient (instead of putting a similar attribute on the entire capture set). A capture set describes a single capture scene, so you couldn't have multiple capture sets describing the same 'scene', but I'd say how a device decides to split up captures amongst scenes is somewhat up to them. Splitting up presentation and participant captures into two separate scenes seems to make sense as there's no spatial relationship between the two sets of captures. From the receive side, I don't think a receiver would choose only a single capture scene to view, I think it would choose captures from each capture set. -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, September 14, 2011 5:58 AM To: clue@ietf.org Subject: [clue] Qusetion on Captyre Scene and Capture set Hi, In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation." In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation". Is there going to be a description for the capture scene that will specify what is the capture scene of? As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use? Thanks Roni Even < oNormal> --Boundary_(ID_U2yK2cc+Hk7RDy10iszKFA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian,

Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple capture sets in slide 2. I think that the relation between the capture scene and capture set is not clear. Looking at section 9 of the framework draft I can see two capture sets (#1 and #2) and it says that the receiver picks a row from each capture set. So is this one capture scene or two. The text talk about sending capture sets but not capture scenes and there is no drawing that include both.

As for the presentation, a row in a capture set can include multiple media captures that has implied spatial relation, so if you put the presentation in a row with three other video captures how is it spatially related.  Can you put the presentation in any position in the row.

I als o unders n cannot be in a separate row in a capture set since the selection is one row from a capture set. This leads me to think that there can be more than one capture set or more than one scene if we define the hierarchal relation between the tw.

 

Regards

Roni

 

From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: Wednesday, September 14, 2011 4:53 PM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p>

 

A capture has a ‘role’ attribute that describes it as presentation or participant video, so for the current cases we’ve seen that as sufficient (instead of putting a similar attribute on the entire capture set).

 

A capture set describes a single capture scene, so you couldn’t have multiple capture sets describing the same ‘scene’, but I’d say how a device decides to split up captures amongst scenes is somewhat up to them.  Splitting up presentation and participant captures into two separate scenes seems to make sense as there’s no spatial relationship between the two sets of receive side, I don’t think a receiver would choose only a single capture scene to view, I think it would choose captures from each capture set.

 

-Brian

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, September 14, 2011 5:58 AM
To: clue@ietf.org
Subject: [clue] Qusetion on Captyre Scene and Cap >

 

Hi,

In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation."

In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation".

Is there going to be a description for the capture scene that will specify what is the capture scene of?

As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use?

Thanks

Roni Even

< oNormal>

X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB5421F8B5F for ; Sun, 18 Sep 2011 16:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL7cGtOeV2Hx for ; Sun, 18 Sep 2011 16:55:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 656FB21F8B59 for ; Sun, 18 Sep 2011 16:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=14374; q=dns/txt; s=iport; t=1316390272; x=1317599872; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Cwuu2wxtgC70dOS3Aghld/nmicPmnSn8/DN0ZTPy+iI=; b=mh3zgztWVRAYcRJ+KeHkN32F54l/1OPXFWfVK748nyxvdJiK17J5e1ra HG1egXHio8rU2qNLAE2oC7u4zALdxfrCSTLDUEQTUm1qrVMbH9Jzi4ydX Xla9+RE1CVZK5xE3jO55uavvPLpZmFfNG6Q1hk0+ApW/h7MwPmCAtB84O E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAKqEdk6rRDoH/2dsb2JhbABCgk2Vbo5/d4FTAQEBBBIBCREDQhcCAQgRBAEBCwYXAQYBRQkIAQEEARIIGp8TAZxshhhgBIdvkQCMJw X-IronPort-AV: E=Sophos;i="4.68,402,1312156800"; d="scan'208,217";a="2862820" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 18 Sep 2011 23:57:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8INvkkY032056; Sun, 18 Sep 2011 23:57:46 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 16:57:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC765E.C317E7A6" Date: Sun, 18 Sep 2011 16:57:41 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> In-Reply-To: <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Qusetion on Captyre Scene and Capture set Thread-Index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPAANvnvgAAEPbWAA3QXGYA== References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Brian Baldino (bbaldino)" , X-OriginalArrivalTime: 18 Sep 2011 23:57:46.0216 (UTC) FILETIME=[C347AE80:01CC765E] Subject: Re: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 23:55:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC765E.C317E7A6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Roni, The text in the draft hasn't been updated yet, so you might find small discrepancies with any slide deck which is more recent than the draft. The more recent document is the one to be considered. We are due to have a new draft before the interim meeting. =20 It is meant for each capture set to be an aggregation of the media captures describing a capture scene. Each capture set describes a scene which is non-overlapping, not redundant, unique, with respect to other capture sets. =20 I'm sorry I couldn't parse your last remark due to some typos. =20 Regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, September 14, 2011 7:41 AM To: Brian Baldino (bbaldino); clue@ietf.org Subject: Re: [clue] Qusetion on Captyre Scene and Capture set =20 Hi Brian, Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple capture sets in slide 2. I think that the relation between the capture scene and capture set is not clear. Looking at section 9 of the framework draft I can see two capture sets (#1 and #2) and it says that the receiver picks a row from each capture set. So is this one capture scene or two. The text talk about sending capture sets but not capture scenes and there is no drawing that include both. As for the presentation, a row in a capture set can include multiple media captures that has implied spatial relation, so if you put the presentation in a row with three other video captures how is it spatially related. Can you put the presentation in any position in the row.=20 I als o unders n cannot be in a separate row in a capture set since the selection is one row from a capture set. This leads me to think that there can be more than one capture set or more than one scene if we define the hierarchal relation between the tw. =20 Regards Roni=20 =20 From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]=20 Sent: Wednesday, September 14, 2011 4:53 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> =20 A capture has a 'role' attribute that describes it as presentation or participant video, so for the current cases we've seen that as sufficient (instead of putting a similar attribute on the entire capture set). =20 A capture set describes a single capture scene, so you couldn't have multiple capture sets describing the same 'scene', but I'd say how a device decides to split up captures amongst scenes is somewhat up to them. Splitting up presentation and participant captures into two separate scenes seems to make sense as there's no spatial relationship between the two sets of receive side, I don't think a receiver would choose only a single capture scene to view, I think it would choose captures from each capture set. =20 -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, September 14, 2011 5:58 AM To: clue@ietf.org Subject: [clue] Qusetion on Captyre Scene and Cap > =20 Hi, In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments that "There could be multiple capture scenes - For example another scene for a presentation." In the next slide I saw "There can be multiple capture sets, such as one for people and one for a presentation".=20 Is there going to be a description for the capture scene that will specify what is the capture scene of? As for capture sets do you see the presentation and people capture set in the same scene or are they in a separate scenes, how do you decide which one to use? Thanks Roni Even < oNormal> ------_=_NextPart_001_01CC765E.C317E7A6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Roni,

The text in the draft = hasn’t been updated yet, so you might find small discrepancies with any slide = deck which is more recent than the draft. The more recent document is the one = to be considered. We are due to have a new draft before the interim = meeting.

 

It is meant for each = capture set to be an aggregation of the media captures describing a capture scene. = Each capture set describes a scene which is non-overlapping, not redundant, = unique, with respect to other capture sets.

 

I’m sorry I = couldn’t parse your last remark due to some typos.

 

Regards,

Allyn

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, September 14, 2011 7:41 AM
To: Brian Baldino (bbaldino); clue@ietf.org
Subject: Re: [clue] Qusetion on Captyre Scene and Capture = set

 

Hi Brian,

Looking at = 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple capture sets in slide 2. I think that the relation between the = capture scene and capture set is not clear. Looking at section 9 of the = framework draft I can see two capture sets (#1 and #2) and it says that the receiver = picks a row from each capture set. So is this one capture scene or two. The text = talk about sending capture sets but not capture scenes and there is no = drawing that include both.

As for the presentation, a row in a capture set can = include multiple media captures that has implied spatial relation, so if you put = the presentation in a row with three other video captures how is it = spatially related.  Can you put the presentation in any position in the row. =

I als o unders n cannot be in a separate row in a = capture set since the selection is one row from a capture set. This leads me to = think that there can be more than one capture set or more than one scene if we = define the hierarchal relation between the tw.

 

Regards

Roni

 

From:= Brian = Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: Wednesday, September 14, 2011 4:53 PM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu = /p>

 

A capture has a ‘role’ attribute that describes = it as presentation or participant video, so for the current cases we’ve = seen that as sufficient (instead of putting a similar attribute on the entire capture set).

 

A capture set describes a single capture scene, so you couldn’t have multiple capture sets describing the same ‘scene’, but I’d say how a device decides to split up captures amongst scenes is somewhat up to them.  Splitting up = presentation and participant captures into two separate scenes seems to make sense as there’s no spatial relationship between the two sets of receive = side, I don’t think a receiver would choose only a single capture scene to = view, I think it would choose captures from each capture = set.

 

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, September 14, 2011 5:58 AM
To: clue@ietf.org
Subject: [clue] Qusetion on Captyre Scene and Cap = >

 

Hi,

In the last Interim meeting presentation on Capture = sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments = that "There could be multiple capture scenes - For example another scene = for a presentation."

In the next slide I saw "There can be multiple = capture sets, such as one for people and one for a presentation". =

Is there going to be a description for the capture = scene that will specify what is the capture scene of?

As for capture sets do you see the presentation and = people capture set in the same scene or are they in a separate scenes, how do = you decide which one to use?

Thanks

Roni Even

< oNormal>

------_=_NextPart_001_01CC765E.C317E7A6-- From Even.roni@huawei.com Sun Sep 18 23:02:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5C621F8B34 for ; Sun, 18 Sep 2011 23:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.244 X-Spam-Level: X-Spam-Status: No, score=-106.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8QxQXmM4c9E for ; Sun, 18 Sep 2011 23:02:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4047A21F8B5E for ; Sun, 18 Sep 2011 23:02:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR00ANJA81OX@szxga03-in.huawei.com> for clue@ietf.org; Mon, 19 Sep 2011 14:04:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR00MGGA81HD@szxga03-in.huawei.com> for clue@ietf.org; Mon, 19 Sep 2011 14:04:49 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LRR009C9A7WWB@szxml12-in.huawei.com>; Mon, 19 Sep 2011 14:04:49 +0800 (CST) Date: Mon, 19 Sep 2011 09:03:24 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" , "'Brian Baldino (bbaldino)'" , clue@ietf.org Message-id: <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPAANvnvgAAEPbWAA3QXGYAAMcSNw References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 06:02:31 -0000 Hi Allyn, First the last two sentences from my email, I am not sure why they got = like that, I am using outlook and the email is in HTML format, I am sending = it now as plain text. As for the presentation, a row in a capture set can include multiple = media captures that has implied spatial relation, so if you put the = presentation in a row with three other video captures from a camera how is it = spatially related. =A0Can you put the presentation in any position in the row.=20 I also understand that the presentation cannot be in a separate row in a capture set since the selection is one row of each media type from a = capture set. This leads me to think that there can be more than one capture set = or more than one scene if we define the hierarchal relation between the = two. As for media scene and capture set I do not understand what is a scene = and what is the hierarchal order between both , so far my assumption was = that the scene is the local meeting room with all it functionality and there = is one capture scene in an offer. There can be a capture set for the = people view and a capture set for the presentations. We need to have some = hierarchy in the framework.=20 I think that each layer (Scene, Capture sets, media captures,=85) should = have attributes that describe the layer. Regards Roni=20 From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Sent: Monday, September 19, 2011 2:58 AM To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org Subject: RE: [clue] Qusetion on Captyre Scene and Capture set Hi Roni, The text in the draft hasn=92t been updated yet, so you might find small discrepancies with any slide deck which is more recent than the draft. = The more recent document is the one to be considered. We are due to have a = new draft before the interim meeting. It is meant for each capture set to be an aggregation of the media = captures describing a capture scene. Each capture set describes a scene which is non-overlapping, not redundant, unique, with respect to other capture = sets. I=92m sorry I couldn=92t parse your last remark due to some typos. Regards, Allyn From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even Sent: Wednesday, September 14, 2011 7:41 AM To: Brian Baldino (bbaldino); clue@ietf.org Subject: Re: [clue] Qusetion on Captyre Scene and Capture set Hi Brian, Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple = capture sets in slide 2. I think that the relation between the capture scene and capture set is not clear. Looking at section 9 of the framework draft I = can see two capture sets (#1 and #2) and it says that the receiver picks a = row from each capture set. So is this one capture scene or two. The text = talk about sending capture sets but not capture scenes and there is no = drawing that include both. As for the presentation, a row in a capture set can include multiple = media captures that has implied spatial relation, so if you put the = presentation in a row with three other video captures how is it spatially related. = =A0Can you put the presentation in any position in the row.=20 I als o unders n cannot be in a separate row in a capture set since the selection is one row from a capture set. This leads me to think that = there can be more than one capture set or more than one scene if we define the hierarchal relation between the tw. Regards Roni=20 From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]=20 Sent: Wednesday, September 14, 2011 4:53 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> A capture has a =91role=92 attribute that describes it as presentation = or participant video, so for the current cases we=92ve seen that as = sufficient (instead of putting a similar attribute on the entire capture set). A capture set describes a single capture scene, so you couldn=92t have multiple capture sets describing the same =91scene=92, but I=92d say how = a device decides to split up captures amongst scenes is somewhat up to them.=A0 Splitting up presentation and participant captures into two separate = scenes seems to make sense as there=92s no spatial relationship between the two = sets of receive side, I don=92t think a receiver would choose only a single = capture scene to view, I think it would choose captures from each capture set. -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even Sent: Wednesday, September 14, 2011 5:58 AM To: clue@ietf.org Subject: [clue] Qusetion on Captyre Scene and Cap > Hi, In the last Interim meeting presentation on Capture sets (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments = that "There could be multiple capture scenes - For example another scene for = a presentation." In the next slide I saw "There can be multiple capture sets, such as one = for people and one for a presentation".=20 Is there going to be a description for the capture scene that will = specify what is the capture scene of? As for capture sets do you see the presentation and people capture set = in the same scene or are they in a separate scenes, how do you decide which = one to use? Thanks Roni Even < oNormal> From allyn@cisco.com Fri Sep 23 14:19:19 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817C221F8C1F for ; Fri, 23 Sep 2011 14:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVt0tOwjJqP2 for ; Fri, 23 Sep 2011 14:19:18 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0321F8C07 for ; Fri, 23 Sep 2011 14:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6815; q=dns/txt; s=iport; t=1316812914; x=1318022514; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dPljoZ4lwYA3Rz0ScI2ELkiIsFN3JHNuFMbc2Lrlg20=; b=dWiPja7t8947yXjgzowBDA6EHBkMv2U7JNUZuJO0nIzse5kCOMrV46xF Kwenv+I6Lh90n8047TrViq/Yrcf1BdmABa5N1a8BaS5VQ04RYe4hPFH3i 4aZ9lo4Ami6muB0rEQqSia3iPkjlDyxG2c6lUXSmQqC/AfLnl89Mr6GYQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMAAD33fE6rRDoI/2dsb2JhbABCmSCOfHiBUwEBAQQSAR1CEwQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGqBOAZ4nhiFgBIdCMJEJjCg X-IronPort-AV: E=Sophos;i="4.68,432,1312156800"; d="scan'208";a="3971670" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 23 Sep 2011 21:21:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8NLLraG025328; Fri, 23 Sep 2011 21:21:53 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 14:21:53 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2011 14:21:50 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> In-Reply-To: <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Qusetion on Capture Scene and Capture set Thread-Index: AcxyrpJy+WQR1nBFRoqesmaRXMfgPAANvnvgAAEPbWAA3QXGYAAMcSNwAOmSPJA= References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Brian Baldino (bbaldino)" , X-OriginalArrivalTime: 23 Sep 2011 21:21:53.0772 (UTC) FILETIME=[D0DABAC0:01CC7A36] Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:19:19 -0000 Hi Roni, Please see below- Regards, Allyn > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Sunday, September 18, 2011 11:03 PM > To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org > Subject: RE: [clue] Qusetion on Capture Scene and Capture set >=20 > Hi Allyn, > First the last two sentences from my email, I am not sure why they got > like > that, I am using outlook and the email is in HTML format, I am sending > it > now as plain text. >=20 > As for the presentation, a row in a capture set can include multiple > media > captures that has implied spatial relation, so if you put the > presentation > in a row with three other video captures from a camera how is it > spatially > related. I don't seen this happening. The scene for the main video and audio is = different than the scene for each presentation. I will agree with you that we need to specify scene more explicitly in = the next draft. So we would have a capture set for each scene. There are likely multiple = scenes in the endpoint. For example one scene for which there are main = audio and video captures, which are aggregated into Capture Set 1; then = one scene for a presentation audio and video captures, which are = aggregated into Capture Set 2; then just for fun we can imagine a second = presentation which be another capture scene maybe also with audio and = video presentation captures in capture set 3. So that endpoint would be = sending 3 capture sets describing the streams being generated at that = endpoint. I hope this clarifies some-- Best, Allyn =A0Can you put the presentation in any position in the row. > I also understand that the presentation cannot be in a separate row in > a > capture set since the selection is one row of each media type from a > capture > set. This leads me to think that there can be more than one capture = set > or > more than one scene if we define the hierarchal relation between the > two. >=20 > As for media scene and capture set I do not understand what is a scene > and > what is the hierarchal order between both , so far my assumption was > that > the scene is the local meeting room with all it functionality and = there > is > one capture scene in an offer. There can be a capture set for the > people > view and a capture set for the presentations. We need to have some > hierarchy > in the framework. > I think that each layer (Scene, Capture sets, media captures,...) = should > have > attributes that describe the layer. >=20 > Regards > Roni >=20 >=20 > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Sent: Monday, September 19, 2011 2:58 AM > To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org > Subject: RE: [clue] Qusetion on Captyre Scene and Capture set >=20 > Hi Roni, > The text in the draft hasn't been updated yet, so you might find small > discrepancies with any slide deck which is more recent than the draft. > The > more recent document is the one to be considered. We are due to have a > new > draft before the interim meeting. >=20 > It is meant for each capture set to be an aggregation of the media > captures > describing a capture scene. Each capture set describes a scene which = is > non-overlapping, not redundant, unique, with respect to other capture > sets. >=20 > I'm sorry I couldn't parse your last remark due to some typos. >=20 > Regards, > Allyn >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni > Even > Sent: Wednesday, September 14, 2011 7:41 AM > To: Brian Baldino (bbaldino); clue@ietf.org > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set >=20 > Hi Brian, > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture > sets in slide 2. I think that the relation between the capture scene > and > capture set is not clear. Looking at section 9 of the framework draft = I > can > see two capture sets (#1 and #2) and it says that the receiver picks a > row > from each capture set. So is this one capture scene or two. The text > talk > about sending capture sets but not capture scenes and there is no > drawing > that include both. > As for the presentation, a row in a capture set can include multiple > media > captures that has implied spatial relation, so if you put the > presentation > in a row with three other video captures how is it spatially related. > =A0Can > you put the presentation in any position in the row. > I als o unders n cannot be in a separate row in a capture set since = the > selection is one row from a capture set. This leads me to think that > there > can be more than one capture set or more than one scene if we define > the > hierarchal relation between the tw. >=20 >=20 > Regards > Roni >=20 > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > Sent: Wednesday, September 14, 2011 4:53 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> >=20 > A capture has a 'role' attribute that describes it as presentation or > participant video, so for the current cases we've seen that as > sufficient > (instead of putting a similar attribute on the entire capture set). >=20 > A capture set describes a single capture scene, so you couldn't have > multiple capture sets describing the same 'scene', but I'd say how a > device > decides to split up captures amongst scenes is somewhat up to them. > Splitting up presentation and participant captures into two separate > scenes > seems to make sense as there's no spatial relationship between the two > sets > of receive side, I don't think a receiver would choose only a single > capture > scene to view, I think it would choose captures from each capture set. >=20 > -Brian >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni > Even > Sent: Wednesday, September 14, 2011 5:58 AM > To: clue@ietf.org > Subject: [clue] Qusetion on Captyre Scene and Cap > >=20 > Hi, > In the last Interim meeting presentation on Capture sets > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments > that > "There could be multiple capture scenes - For example another scene = for > a > presentation." > In the next slide I saw "There can be multiple capture sets, such as > one for > people and one for a presentation". > Is there going to be a description for the capture scene that will > specify > what is the capture scene of? > As for capture sets do you see the presentation and people capture set > in > the same scene or are they in a separate scenes, how do you decide > which one > to use? > Thanks > Roni Even > < oNormal> From Even.roni@huawei.com Sat Sep 24 00:24:33 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1021F8AB0 for ; Sat, 24 Sep 2011 00:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.263 X-Spam-Level: X-Spam-Status: No, score=-106.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKSh02LMUEe6 for ; Sat, 24 Sep 2011 00:24:32 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5314B21F8AAF for ; Sat, 24 Sep 2011 00:24:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000JJKNC4MA@szxga04-in.huawei.com> for clue@ietf.org; Sat, 24 Sep 2011 15:26:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000DKCNC4A8@szxga04-in.huawei.com> for clue@ietf.org; Sat, 24 Sep 2011 15:26:28 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LS00021HNC0ZV@szxml11-in.huawei.com> for clue@ietf.org; Sat, 24 Sep 2011 15:26:28 +0800 (CST) Date: Sat, 24 Sep 2011 10:24:48 +0300 From: Roni Even To: clue@ietf.org Message-id: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gOe0Yn27D3+8fF9rxSYF1g)" Content-language: en-us Thread-index: Acx6iwnmrXteHDWGRVGsfY/w7YGmbg== Subject: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 07:24:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gOe0Yn27D3+8fF9rxSYF1g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, During the last Interim meeting I mentioned this requirement and will now try to explain the use case for it. In a conference room when there are three camera and three monitors and when there is an object that spans between two monitors (for example a person standing so that his image is divided between two cameras) it will be good if the image will look continuous even though part of it is missing due to the gap between the monitors. It is possible to calibrate the local room capture so that the local image will look continuous. In order to have a similar experience on the remote side when rendering the local system can convey the distance between the local monitors (including the monitor frame) in pixels (This can be calculated based on the local monitor size and resolution) allowing the remote side to have similar compensation. This will require the local system to send this information, which is an attribute on the conference room level or the capture scene level. I think that it will also be good to add this feature to the use case document Regards Roni Even --Boundary_(ID_gOe0Yn27D3+8fF9rxSYF1g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

During the last Interim meeting I mentioned this requirement and will now try to explain the use case for it.

In a conference room when there are three camera and three monitors and when there is an object that spans between two monitors (for example a person standing so that his image is divided between two cameras) it will be good if the image will look continuous even though part of it is missing due to the gap between the monitors.

It is possible to calibrate the local room capture so that the  local image will look continuous. In order to have a similar experience on the remote side when rendering the local system can convey the distance between the local monitors (including the monitor frame) in pixels (This can be calculated based on the lo cal moni allowing the remote side to have similar compensation.

This will require the local system to send this information, which is an attribute on the conference room level or the capture scene level.

 

I think that it will also be good to add this feature to the use case document

 

Regards

Roni Even

 

--Boundary_(ID_gOe0Yn27D3+8fF9rxSYF1g)-- From stephen.botzko@gmail.com Sat Sep 24 04:36:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E0F21F8B37 for ; Sat, 24 Sep 2011 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXNtjjmXlPQQ for ; Sat, 24 Sep 2011 04:36:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBF21F8B3B for ; Sat, 24 Sep 2011 04:36:26 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2364562vcb.31 for ; Sat, 24 Sep 2011 04:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7puMlsIFZVLzEKBdGjkO0b8KXYyWsP+JWYhcj9bllSw=; b=fX4YZcds/lIy/FxZefFSCZGAvZx+DQnymStwfWyppXxKaIwMcqOTOwYDNQQCqerDsG mC2X8ku3H5bSffAKDZFdQw17ztk3k4X3iMyzAltJM0sBN6uTPLfOlcotS5YhvCyfE3Bv 4q2JPKpJVRpAr7BzNyuw18XmdhyMffOKQ98Go= MIME-Version: 1.0 Received: by 10.52.178.164 with SMTP id cz4mr4193536vdc.467.1316864342196; Sat, 24 Sep 2011 04:39:02 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Sat, 24 Sep 2011 04:39:02 -0700 (PDT) In-Reply-To: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> Date: Sat, 24 Sep 2011 07:39:02 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=bcaec5186a5c5580de04adae5f44 Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 11:36:27 -0000 --bcaec5186a5c5580de04adae5f44 Content-Type: text/plain; charset=ISO-8859-1 There is a similar overlap case when projectors are in use. Some projector walls overlap the pictures slightly, gradually fading each picture in the overlap region to keep the overall brightness even. This makes it much harder to see any mismatch in the various projectors. In either case (gaps or overlap) the compensation can be done in either the receiver or the sender. -The receiving system can crop the original capture (to create the gap) and stretch the slightly smaller picture to fill the screen. Creating overlap is a bit harder, as you need to grab some pixels from the adjacent capture(s). Though projector walls that use overlap are already doing this. -A sending system would most likely use the identical methods. In principle, PTZ motors could also be used to shift the capture. But pan-tilt-zoom motors are generally not accurate enough to maintain precise alignment, esp. when you are adjusting multiple cameras. Every time you move the camera, the positional error builds, which requires fairly frequent manual re-alignment. Since a capture can be received by more than one receiver, it is generally much better if such compensation is done in each receiver. The bezels in new displays keep shrinking, so even system models from the same manufacturer are likely to have different gaps (depending on their deployment date). So I am thinking that signaling display arrangements (and hoping that the sender will compensate) is not a good idea. It is more robust to use receiver compensation. I am ok with senders being able to signal that their *captures* (not their displays) either have small gaps or small overlaps between them. Though for the reasons above, I suspect most vendors will go with precisely adjacent captures. Regards, Stephen Botzko On Sat, Sep 24, 2011 at 3:24 AM, Roni Even wrote: > Hi,**** > > During the last Interim meeting I mentioned this requirement and will now > try to explain the use case for it. **** > > In a conference room when there are three camera and three monitors and > when there is an object that spans between two monitors (for example a > person standing so that his image is divided between two cameras) it will be > good if the image will look continuous even though part of it is missing due > to the gap between the monitors.**** > > It is possible to calibrate the local room capture so that the local image > will look continuous. In order to have a similar experience on the remote > side when rendering the local system can convey the distance between the > local monitors (including the monitor frame) in pixels (This can be > calculated based on the lo cal moni allowing the remote side to have similar > compensation.**** > > This will require the local system to send this information, which is an > attribute on the conference room level or the capture scene level.**** > > ** ** > > I think that it will also be good to add this feature to the use case > document**** > > ** ** > > Regards**** > > Roni Even**** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec5186a5c5580de04adae5f44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is a similar overlap case when projectors are in use.=A0 Some project= or walls overlap the pictures slightly, gradually fading each picture in th= e overlap region to keep the overall brightness even. This makes it much ha= rder to see any mismatch in the various projectors.

In either case (gaps or overlap) the compensation can be done in either= the receiver or the sender.

-The receiving system can crop the orig= inal capture (to create the gap) and stretch the slightly smaller picture t= o fill the screen.=A0 Creating overlap is a bit harder, as you need to grab= some pixels from the adjacent capture(s).=A0 Though projector walls that u= se overlap are already doing this.

-A sending system would most likely use the identical methods.=A0 In pr= inciple, PTZ motors could also be used to shift the capture.=A0 But pan-til= t-zoom motors are generally not accurate enough to maintain precise alignme= nt, esp. when you are adjusting multiple cameras. Every time you move the c= amera, the positional error builds, which requires fairly frequent manual r= e-alignment.

Since a capture can be received by more than one receiver, it is genera= lly much better if such compensation is done in each receiver.=A0 The bezel= s in new displays keep shrinking, so even system models from the same manuf= acturer are likely to have different gaps (depending on their deployment da= te).=A0 So I am thinking that signaling display arrangements (and hoping th= at the sender will compensate) is not a good idea. It is more robust to use= receiver compensation.

I am ok with senders being able to signal that their captures (n= ot their displays) either have small gaps or small overlaps between them.= =A0 Though for the reasons above, I suspect most vendors will go with preci= sely adjacent captures.

Regards,
Stephen Botzko

On Sat, Se= p 24, 2011 at 3:24 AM, Roni Even <Even.roni@huawei.com> wrote:

Hi,

During the last Interim mee= ting I mentioned this requirement and will now try to explain the use case = for it.

In a conference room when there are three camera and= three monitors and when there is an object that spans between two monitors= (for example a person standing so that his image is divided between two ca= meras) it will be good if the image will look continuous even though part o= f it is missing due to the gap between the monitors.

It is possible to calibrate the local room capture s= o that the=A0 local image will look continuous. In order to have a similar = experience on the remote side when rendering the local system can convey th= e distance between the local monitors (including the monitor frame) in pixe= ls (This can be calculated based on the lo cal moni allowing the remote side to have similar compensation.

This will require the local system to send this informa= tion, which is an attribute on the conference room level or the capture sce= ne level.

=A0

I think = that it will also be good to add this feature to the use case document

=A0

Regards

Roni Even

=A0


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--bcaec5186a5c5580de04adae5f44-- From stephen.botzko@gmail.com Sat Sep 24 05:16:54 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6436F21F8548 for ; Sat, 24 Sep 2011 05:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb0qNEdBFtZa for ; Sat, 24 Sep 2011 05:16:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E083D21F84A5 for ; Sat, 24 Sep 2011 05:16:52 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2382134vcb.31 for ; Sat, 24 Sep 2011 05:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FOOb4Qia7EgSF6ME8GdBCSD0KXM7M//ZL88tb/MwTes=; b=EUnwNy53ZlXUBxKi0slnJ793H2Z1cUlK9ZHktTHttfGdTG3bliMi+pnjQsWTjz5O18 k4sSpb6wpMha3JYiNYYzTlqVWnaL2iZmknyviTkOMaZBF1equH/E6X7hNWBiaqIeB3Tk 94zpCPj5OG2fPq1OqDoDg28mmSk28yRR8TWmw= MIME-Version: 1.0 Received: by 10.52.27.239 with SMTP id w15mr3959920vdg.333.1316866766437; Sat, 24 Sep 2011 05:19:26 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Sat, 24 Sep 2011 05:19:26 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> Date: Sat, 24 Sep 2011 08:19:26 -0400 Message-ID: From: Stephen Botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf307c9bc0d47cdf04adaeefef Cc: clue@ietf.org Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 12:16:54 -0000 --20cf307c9bc0d47cdf04adaeefef Content-Type: text/plain; charset=ISO-8859-1 Presentation display in today's systems is extremely diverse. Some vendors place small displays at every seating position, others place large displays somewhere in the room. In the latter case, there is no de-facto "standard" placement. I don't see this converging to a common design anytime soon. In the most common use case (showing a computer screen) there is no actual capture of a scene within the room. One can attempt to substitute the position of the locally-rendered presentation instead, but this will (in general) not enable gaze awareness. That is, it will often not be possible to ensure that I will perceive someone at another site as looking at the presentation. I think in practice it will be ok if we treat the presentation as a scene which is spatially unrelated to other scenes. If there is a way to describe how scenes relate to each other, then of course people could apply that signaling to their sourced presentations. Though in most practical cases the receiving systems will basically ignore that information - they will display the presentation on their presentation monitors, wherever they happen to be. Stephen Botzko On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) wrote: > Hi Roni, > Please see below- > Regards, > Allyn > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Sunday, September 18, 2011 11:03 PM > > To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org > > Subject: RE: [clue] Qusetion on Capture Scene and Capture set > > > > Hi Allyn, > > First the last two sentences from my email, I am not sure why they got > > like > > that, I am using outlook and the email is in HTML format, I am sending > > it > > now as plain text. > > > > As for the presentation, a row in a capture set can include multiple > > media > > captures that has implied spatial relation, so if you put the > > presentation > > in a row with three other video captures from a camera how is it > > spatially > > related. > I don't seen this happening. The scene for the main video and audio is > different than the scene for each presentation. > I will agree with you that we need to specify scene more explicitly in the > next draft. > So we would have a capture set for each scene. There are likely multiple > scenes in the endpoint. For example one scene for which there are main audio > and video captures, which are aggregated into Capture Set 1; then one scene > for a presentation audio and video captures, which are aggregated into > Capture Set 2; then just for fun we can imagine a second presentation which > be another capture scene maybe also with audio and video presentation > captures in capture set 3. So that endpoint would be sending 3 capture sets > describing the streams being generated at that endpoint. > > I hope this clarifies some-- > > Best, > Allyn > > Can you put the presentation in any position in the row. > > I also understand that the presentation cannot be in a separate row in > > a > > capture set since the selection is one row of each media type from a > > capture > > set. This leads me to think that there can be more than one capture set > > or > > more than one scene if we define the hierarchal relation between the > > two. > > > > As for media scene and capture set I do not understand what is a scene > > and > > what is the hierarchal order between both , so far my assumption was > > that > > the scene is the local meeting room with all it functionality and there > > is > > one capture scene in an offer. There can be a capture set for the > > people > > view and a capture set for the presentations. We need to have some > > hierarchy > > in the framework. > > I think that each layer (Scene, Capture sets, media captures,...) should > > have > > attributes that describe the layer. > > > > Regards > > Roni > > > > > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: Monday, September 19, 2011 2:58 AM > > To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org > > Subject: RE: [clue] Qusetion on Captyre Scene and Capture set > > > > Hi Roni, > > The text in the draft hasn't been updated yet, so you might find small > > discrepancies with any slide deck which is more recent than the draft. > > The > > more recent document is the one to be considered. We are due to have a > > new > > draft before the interim meeting. > > > > It is meant for each capture set to be an aggregation of the media > > captures > > describing a capture scene. Each capture set describes a scene which is > > non-overlapping, not redundant, unique, with respect to other capture > > sets. > > > > I'm sorry I couldn't parse your last remark due to some typos. > > > > Regards, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Roni > > Even > > Sent: Wednesday, September 14, 2011 7:41 AM > > To: Brian Baldino (bbaldino); clue@ietf.org > > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set > > > > Hi Brian, > > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > > capture > > sets in slide 2. I think that the relation between the capture scene > > and > > capture set is not clear. Looking at section 9 of the framework draft I > > can > > see two capture sets (#1 and #2) and it says that the receiver picks a > > row > > from each capture set. So is this one capture scene or two. The text > > talk > > about sending capture sets but not capture scenes and there is no > > drawing > > that include both. > > As for the presentation, a row in a capture set can include multiple > > media > > captures that has implied spatial relation, so if you put the > > presentation > > in a row with three other video captures how is it spatially related. > > Can > > you put the presentation in any position in the row. > > I als o unders n cannot be in a separate row in a capture set since the > > selection is one row from a capture set. This leads me to think that > > there > > can be more than one capture set or more than one scene if we define > > the > > hierarchal relation between the tw. > > > > > > Regards > > Roni > > > > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > > Sent: Wednesday, September 14, 2011 4:53 PM > > To: Roni Even; clue@ietf.org > > Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> > > > > A capture has a 'role' attribute that describes it as presentation or > > participant video, so for the current cases we've seen that as > > sufficient > > (instead of putting a similar attribute on the entire capture set). > > > > A capture set describes a single capture scene, so you couldn't have > > multiple capture sets describing the same 'scene', but I'd say how a > > device > > decides to split up captures amongst scenes is somewhat up to them. > > Splitting up presentation and participant captures into two separate > > scenes > > seems to make sense as there's no spatial relationship between the two > > sets > > of receive side, I don't think a receiver would choose only a single > > capture > > scene to view, I think it would choose captures from each capture set. > > > > -Brian > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Roni > > Even > > Sent: Wednesday, September 14, 2011 5:58 AM > > To: clue@ietf.org > > Subject: [clue] Qusetion on Captyre Scene and Cap > > > > > Hi, > > In the last Interim meeting presentation on Capture sets > > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments > > that > > "There could be multiple capture scenes - For example another scene for > > a > > presentation." > > In the next slide I saw "There can be multiple capture sets, such as > > one for > > people and one for a presentation". > > Is there going to be a description for the capture scene that will > > specify > > what is the capture scene of? > > As for capture sets do you see the presentation and people capture set > > in > > the same scene or are they in a separate scenes, how do you decide > > which one > > to use? > > Thanks > > Roni Even > > < oNormal> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307c9bc0d47cdf04adaeefef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Presentation display in today's systems is extremely diverse.=A0 Some v= endors place small displays at every seating position, others place large d= isplays somewhere in the room.=A0 In the latter case, there is no de-facto = "standard" placement.=A0 I don't see this converging to a com= mon design anytime soon.

In the most common use case (showing a computer screen) there is no act= ual capture of a scene within the room. One can attempt to substitute the p= osition of the locally-rendered presentation instead, but this will (in gen= eral) not enable gaze awareness.=A0 That is, it will often not be possible = to ensure that I will perceive someone at another site as looking at the pr= esentation.

I think in practice it will be ok if we treat the presentation as a sce= ne which is spatially unrelated to other scenes. If there is a way to descr= ibe how scenes relate to each other, then of course people could apply that= signaling to their sourced presentations.=A0 Though in most practical case= s the receiving systems will basically ignore that information - they will = display the presentation on their presentation monitors, wherever they happ= en to be.

Stephen Botzko


On Fri, Sep 23, 20= 11 at 5:21 PM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:
Hi Roni,
Please see below-
Regards,
Allyn

> -----Original Message-----
> From: Roni Even [mailto:Even.r= oni@huawei.com]
> Sent: Sunday, September 18, 2011 11:03 PM
> To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Capture Scene and Capture set
>
> Hi Allyn,
> First the last two sentences from my email, I am not sure why they got=
> like
> that, I am using outlook and the email is in HTML format, I am sending=
> it
> now as plain text.
>
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures from a camera how is it
> spatially
> related.
I don't seen this happening. The scene for the main video and aud= io is different than the scene for each presentation.
I will agree with you that we need to specify scene more explicitly in the = next draft.
So we would have a capture set for each scene. There are likely multiple sc= enes in the endpoint. For example one scene for which there are main audio = and video captures, which are aggregated into Capture Set 1; then one scene= for a presentation audio and video captures, which are aggregated into Cap= ture Set 2; then just for fun we can imagine a second presentation which be= another capture scene maybe also with audio and video presentation capture= s in capture set 3. So that endpoint would be sending 3 capture sets descri= bing the streams being generated at that endpoint.

I hope this clarifies some--

Best,
Allyn

=A0=A0Can you put the presentation in any position in the row.
> I also understand that the presentation cannot be in a separate row in=
> a
> capture set since the selection is one row of each media type from a > capture
> set. This leads me to think that there can be more than one capture se= t
> or
> more than one scene if we define the hierarchal relation between the > two.
>
> As for media scene and capture set I do not understand what is a scene=
> and
> what is the hierarchal order between both , so far my assumption was > that
> the scene is the local meeting room with all it functionality and ther= e
> is
> one capture scene in an offer. =A0There can be a capture set for the > people
> view and a capture set for the presentations. We need to have some
> hierarchy
> in the framework.
> I think that each layer (Scene, Capture sets, media captures,...) shou= ld
> have
> attributes that describe the layer.
>
> Regards
> Roni
>
>
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: Monday, September 19, 2011 2:58 AM
> To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Roni,
> The text in the draft hasn't been updated yet, so you might find s= mall
> discrepancies with any slide deck which is more recent than the draft.=
> The
> more recent document is the one to be considered. We are due to have a=
> new
> draft before the interim meeting.
>
> It is meant for each capture set to be an aggregation of the media
> captures
> describing a capture scene. Each capture set describes a scene which i= s
> non-overlapping, not redundant, unique, with respect to other capture<= br> > sets.
>
> I'm sorry I couldn't parse your last remark due to some typos.=
>
> Regards,
> Allyn
>
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 7:41 AM
> To: Brian Baldino (bbaldino); clue@ie= tf.org
> Subject: Re: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Brian,
> Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture
> sets in slide 2. I think that the relation between the capture scene > and
> capture set is not clear. Looking at section 9 of the framework draft = I
> can
> see two capture sets (#1 and #2) and it says that the receiver picks a=
> row
> from each capture set. So is this one capture scene or two. The text > talk
> about sending capture sets but not capture scenes and there is no
> drawing
> that include both.
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures how is it spatially related.<= br> > =A0Can
> you put the presentation in any position in the row.
> I als o unders n cannot be in a separate row in a capture set since th= e
> selection is one row from a capture set. This leads me to think that > there
> can be more than one capture set or more than one scene if we define > the
> hierarchal relation between the tw.
>
>
> Regards
> Roni
>
> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
> Sent: Wednesday, September 14, 2011 4:53 PM
> To: Roni Even; clue@ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p>
>
> A capture has a 'role' attribute that describes it as presenta= tion or
> participant video, so for the current cases we've seen that as
> sufficient
> (instead of putting a similar attribute on the entire capture set). >
> A capture set describes a single capture scene, so you couldn't ha= ve
> multiple capture sets describing the same 'scene', but I'd= say how a
> device
> decides to split up captures amongst scenes is somewhat up to them. > Splitting up presentation and participant captures into two separate > scenes
> seems to make sense as there's no spatial relationship between the= two
> sets
> of receive side, I don't think a receiver would choose only a sing= le
> capture
> scene to view, I think it would choose captures from each capture set.=
>
> -Brian
>
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 5:58 AM
> To: clue@ietf.org
> Subject: [clue] Qusetion on Captyre Scene and Cap >
>
> Hi,
> In the last Interim meeting presentation on Capture sets
> (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments=
> that
> "There could be multiple capture scenes - For example another sce= ne for
> a
> presentation."
> In the next slide I saw "There can be multiple capture sets, such= as
> one for
> people and one for a presentation".
> Is there going to be a description for the capture scene that will
> specify
> what is the capture scene of?
> As for capture sets do you see the presentation and people capture set=
> in
> the same scene or are they in a separate scenes, how do you decide
> which one
> to use?
> Thanks
> Roni Even
> < oNormal>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307c9bc0d47cdf04adaeefef-- From marshall.eubanks@gmail.com Sat Sep 24 06:35:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC1521F8A69 for ; Sat, 24 Sep 2011 06:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOnBXSvGY6pT for ; Sat, 24 Sep 2011 06:34:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7921F87C9 for ; Sat, 24 Sep 2011 06:34:59 -0700 (PDT) Received: by gyd12 with SMTP id 12so3935129gyd.31 for ; Sat, 24 Sep 2011 06:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vyPubQLetwvsE5NzA5mxhItQalikRbTnMxzz8PWBowQ=; b=tLCXPaI5hjJpPeXarL7nuWvKgZAoF0d8xpjcqWyx3mfuAWM/1jlQPQNKFNUjZZb+uX l8gtK0bSMCoOHTCLLoFLIKbglkSCNPGRQX/pRPfrk5fswZEc/TYkJt6xS6z+5YephwZa Dvaoy6koeOPLp6KhRREmWzqRkl9n7AXAgI0lY= MIME-Version: 1.0 Received: by 10.150.56.12 with SMTP id e12mr4728123yba.254.1316871456064; Sat, 24 Sep 2011 06:37:36 -0700 (PDT) Received: by 10.151.150.3 with HTTP; Sat, 24 Sep 2011 06:37:36 -0700 (PDT) In-Reply-To: References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> Date: Sat, 24 Sep 2011 09:37:36 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: multipart/alternative; boundary=000e0cd709c65a86ab04adb007d0 Cc: clue@ietf.org Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 13:35:00 -0000 --000e0cd709c65a86ab04adb007d0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 24, 2011 at 8:19 AM, Stephen Botzko wrote: > Presentation display in today's systems is extremely diverse. Some vendors > place small displays at every seating position, others place large displays > somewhere in the room. In the latter case, there is no de-facto "standard" > placement. I don't see this converging to a common design anytime soon. > > In the most common use case (showing a computer screen) there is no actual > capture of a scene within the room. One can attempt to substitute the > position of the locally-rendered presentation instead, but this will (in > general) not enable gaze awareness. That is, it will often not be possible > to ensure that I will perceive someone at another site as looking at the > presentation. > > I think in practice it will be ok if we treat the presentation as a scene > which is spatially unrelated to other scenes. If there is a way to describe > how scenes relate to each other, then of course people could apply that > signaling to their sourced presentations. Though in most practical cases > the receiving systems will basically ignore that information - they will > display the presentation on their presentation monitors, wherever they > happen to be. > When there are multiple independent presentation screens, it is natural to refer to them spatially (the left screen, the upper screen, etc.) I think that being able to refer to multiple screens that way is probably more important than gaze awareness. (In other words, if I say "on the left screen you will see a graph of...", you may look down, or up, or even right, and none of that would bother me much as long as you are looking at the correct screen.) This is clearly a "it would be nice," and, yet, well it would be nice... BTW, at least the medical telepresence systems we installed at Barrow had multiple presentation screens, and I see as a natural evolution for all systems. Regards Marshall > > Stephen Botzko > > > > On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) wrote: > >> Hi Roni, >> Please see below- >> Regards, >> Allyn >> >> > -----Original Message----- >> > From: Roni Even [mailto:Even.roni@huawei.com] >> > Sent: Sunday, September 18, 2011 11:03 PM >> > To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org >> > Subject: RE: [clue] Qusetion on Capture Scene and Capture set >> > >> > Hi Allyn, >> > First the last two sentences from my email, I am not sure why they got >> > like >> > that, I am using outlook and the email is in HTML format, I am sending >> > it >> > now as plain text. >> > >> > As for the presentation, a row in a capture set can include multiple >> > media >> > captures that has implied spatial relation, so if you put the >> > presentation >> > in a row with three other video captures from a camera how is it >> > spatially >> > related. >> I don't seen this happening. The scene for the main video and audio is >> different than the scene for each presentation. >> I will agree with you that we need to specify scene more explicitly in the >> next draft. >> So we would have a capture set for each scene. There are likely multiple >> scenes in the endpoint. For example one scene for which there are main audio >> and video captures, which are aggregated into Capture Set 1; then one scene >> for a presentation audio and video captures, which are aggregated into >> Capture Set 2; then just for fun we can imagine a second presentation which >> be another capture scene maybe also with audio and video presentation >> captures in capture set 3. So that endpoint would be sending 3 capture sets >> describing the streams being generated at that endpoint. >> >> I hope this clarifies some-- >> >> Best, >> Allyn >> >> Can you put the presentation in any position in the row. >> > I also understand that the presentation cannot be in a separate row in >> > a >> > capture set since the selection is one row of each media type from a >> > capture >> > set. This leads me to think that there can be more than one capture set >> > or >> > more than one scene if we define the hierarchal relation between the >> > two. >> > >> > As for media scene and capture set I do not understand what is a scene >> > and >> > what is the hierarchal order between both , so far my assumption was >> > that >> > the scene is the local meeting room with all it functionality and there >> > is >> > one capture scene in an offer. There can be a capture set for the >> > people >> > view and a capture set for the presentations. We need to have some >> > hierarchy >> > in the framework. >> > I think that each layer (Scene, Capture sets, media captures,...) should >> > have >> > attributes that describe the layer. >> > >> > Regards >> > Roni >> > >> > >> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> > Sent: Monday, September 19, 2011 2:58 AM >> > To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org >> > Subject: RE: [clue] Qusetion on Captyre Scene and Capture set >> > >> > Hi Roni, >> > The text in the draft hasn't been updated yet, so you might find small >> > discrepancies with any slide deck which is more recent than the draft. >> > The >> > more recent document is the one to be considered. We are due to have a >> > new >> > draft before the interim meeting. >> > >> > It is meant for each capture set to be an aggregation of the media >> > captures >> > describing a capture scene. Each capture set describes a scene which is >> > non-overlapping, not redundant, unique, with respect to other capture >> > sets. >> > >> > I'm sorry I couldn't parse your last remark due to some typos. >> > >> > Regards, >> > Allyn >> > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> > Roni >> > Even >> > Sent: Wednesday, September 14, 2011 7:41 AM >> > To: Brian Baldino (bbaldino); clue@ietf.org >> > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set >> > >> > Hi Brian, >> > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple >> > capture >> > sets in slide 2. I think that the relation between the capture scene >> > and >> > capture set is not clear. Looking at section 9 of the framework draft I >> > can >> > see two capture sets (#1 and #2) and it says that the receiver picks a >> > row >> > from each capture set. So is this one capture scene or two. The text >> > talk >> > about sending capture sets but not capture scenes and there is no >> > drawing >> > that include both. >> > As for the presentation, a row in a capture set can include multiple >> > media >> > captures that has implied spatial relation, so if you put the >> > presentation >> > in a row with three other video captures how is it spatially related. >> > Can >> > you put the presentation in any position in the row. >> > I als o unders n cannot be in a separate row in a capture set since the >> > selection is one row from a capture set. This leads me to think that >> > there >> > can be more than one capture set or more than one scene if we define >> > the >> > hierarchal relation between the tw. >> > >> > >> > Regards >> > Roni >> > >> > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] >> > Sent: Wednesday, September 14, 2011 4:53 PM >> > To: Roni Even; clue@ietf.org >> > Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> >> > >> > A capture has a 'role' attribute that describes it as presentation or >> > participant video, so for the current cases we've seen that as >> > sufficient >> > (instead of putting a similar attribute on the entire capture set). >> > >> > A capture set describes a single capture scene, so you couldn't have >> > multiple capture sets describing the same 'scene', but I'd say how a >> > device >> > decides to split up captures amongst scenes is somewhat up to them. >> > Splitting up presentation and participant captures into two separate >> > scenes >> > seems to make sense as there's no spatial relationship between the two >> > sets >> > of receive side, I don't think a receiver would choose only a single >> > capture >> > scene to view, I think it would choose captures from each capture set. >> > >> > -Brian >> > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> > Roni >> > Even >> > Sent: Wednesday, September 14, 2011 5:58 AM >> > To: clue@ietf.org >> > Subject: [clue] Qusetion on Captyre Scene and Cap > >> > >> > Hi, >> > In the last Interim meeting presentation on Capture sets >> > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments >> > that >> > "There could be multiple capture scenes - For example another scene for >> > a >> > presentation." >> > In the next slide I saw "There can be multiple capture sets, such as >> > one for >> > people and one for a presentation". >> > Is there going to be a description for the capture scene that will >> > specify >> > what is the capture scene of? >> > As for capture sets do you see the presentation and people capture set >> > in >> > the same scene or are they in a separate scenes, how do you decide >> > which one >> > to use? >> > Thanks >> > Roni Even >> > < oNormal> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --000e0cd709c65a86ab04adb007d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Sep 24, 2011 at 8:19 AM, Stephen= Botzko <s= tephen.botzko@gmail.com> wrote:
Presentation display in today's systems is extremely diverse.=A0 Some v= endors place small displays at every seating position, others place large d= isplays somewhere in the room.=A0 In the latter case, there is no de-facto = "standard" placement.=A0 I don't see this converging to a com= mon design anytime soon.

In the most common use case (showing a computer screen) there is no act= ual capture of a scene within the room. One can attempt to substitute the p= osition of the locally-rendered presentation instead, but this will (in gen= eral) not enable gaze awareness.=A0 That is, it will often not be possible = to ensure that I will perceive someone at another site as looking at the pr= esentation.

I think in practice it will be ok if we treat the presentation as a sce= ne which is spatially unrelated to other scenes. If there is a way to descr= ibe how scenes relate to each other, then of course people could apply that= signaling to their sourced presentations.=A0 Though in most practical case= s the receiving systems will basically ignore that information - they will = display the presentation on their presentation monitors, wherever they happ= en to be.

When there are multiple independent =A0pre= sentation screens, it is natural to refer to them spatially (the left scree= n, the upper screen, etc.)=A0
I think that being able to refer to= multiple screens that way is probably more important than gaze awareness. = (In other words, if I say "on the left screen you will see a graph of.= ..", you may look down, or up, or even right, and none of that would b= other me much as long as you are looking at the correct screen.)=A0

This is clearly a "it would be nice," and, ye= t, well it would be nice...

BTW, at least the medi= cal telepresence systems we installed at Barrow had multiple presentation s= creens, and I see as a natural evolution for all systems.

Regards
Marshall
=A0

Stephen Botzko



On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (ally= n) <allyn@cisco.com> wrote:
Hi Roni,
Please see below-
Regards,
Allyn

> -----Original Message-----
> From: Roni Even [mailto:Even.roni@huawei.com]
> Sent: Sunday, September 18, 2011 11:03 PM
> To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Capture Scene and Capture set
>
> Hi Allyn,
> First the last two sentences from my email, I am not sure why they got=
> like
> that, I am using outlook and the email is in HTML format, I am sending=
> it
> now as plain text.
>
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures from a camera how is it
> spatially
> related.
I don't seen this happening. The scene for the main video and aud= io is different than the scene for each presentation.
I will agree with you that we need to specify scene more explicitly in the = next draft.
So we would have a capture set for each scene. There are likely multiple sc= enes in the endpoint. For example one scene for which there are main audio = and video captures, which are aggregated into Capture Set 1; then one scene= for a presentation audio and video captures, which are aggregated into Cap= ture Set 2; then just for fun we can imagine a second presentation which be= another capture scene maybe also with audio and video presentation capture= s in capture set 3. So that endpoint would be sending 3 capture sets descri= bing the streams being generated at that endpoint.

I hope this clarifies some--

Best,
Allyn

=A0=A0Can you put the presentation in any position in the row.
> I also understand that the presentation cannot be in a separate row in=
> a
> capture set since the selection is one row of each media type from a > capture
> set. This leads me to think that there can be more than one capture se= t
> or
> more than one scene if we define the hierarchal relation between the > two.
>
> As for media scene and capture set I do not understand what is a scene=
> and
> what is the hierarchal order between both , so far my assumption was > that
> the scene is the local meeting room with all it functionality and ther= e
> is
> one capture scene in an offer. =A0There can be a capture set for the > people
> view and a capture set for the presentations. We need to have some
> hierarchy
> in the framework.
> I think that each layer (Scene, Capture sets, media captures,...) shou= ld
> have
> attributes that describe the layer.
>
> Regards
> Roni
>
>
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: Monday, September 19, 2011 2:58 AM
> To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Roni,
> The text in the draft hasn't been updated yet, so you might find s= mall
> discrepancies with any slide deck which is more recent than the draft.=
> The
> more recent document is the one to be considered. We are due to have a=
> new
> draft before the interim meeting.
>
> It is meant for each capture set to be an aggregation of the media
> captures
> describing a capture scene. Each capture set describes a scene which i= s
> non-overlapping, not redundant, unique, with respect to other capture<= br> > sets.
>
> I'm sorry I couldn't parse your last remark due to some typos.=
>
> Regards,
> Allyn
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 7:41 AM
> To: Brian Baldino (bbaldino); clue@ietf.org
> Subject: Re: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Brian,
> Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture
> sets in slide 2. I think that the relation between the capture scene > and
> capture set is not clear. Looking at section 9 of the framework draft = I
> can
> see two capture sets (#1 and #2) and it says that the receiver picks a=
> row
> from each capture set. So is this one capture scene or two. The text > talk
> about sending capture sets but not capture scenes and there is no
> drawing
> that include both.
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures how is it spatially related.<= br> > =A0Can
> you put the presentation in any position in the row.
> I als o unders n cannot be in a separate row in a capture set since th= e
> selection is one row from a capture set. This leads me to think that > there
> can be more than one capture set or more than one scene if we define > the
> hierarchal relation between the tw.
>
>
> Regards
> Roni
>
> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
> Sent: Wednesday, September 14, 2011 4:53 PM
> To: Roni Even; clue= @ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p>
>
> A capture has a 'role' attribute that describes it as presenta= tion or
> participant video, so for the current cases we've seen that as
> sufficient
> (instead of putting a similar attribute on the entire capture set). >
> A capture set describes a single capture scene, so you couldn't ha= ve
> multiple capture sets describing the same 'scene', but I'd= say how a
> device
> decides to split up captures amongst scenes is somewhat up to them. > Splitting up presentation and participant captures into two separate > scenes
> seems to make sense as there's no spatial relationship between the= two
> sets
> of receive side, I don't think a receiver would choose only a sing= le
> capture
> scene to view, I think it would choose captures from each capture set.=
>
> -Brian
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 5:58 AM
> To: clue@ietf.org
> Subject: [clue] Qusetion on Captyre Scene and Cap >
>
> Hi,
> In the last Interim meeting presentation on Capture sets
> (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments=
> that
> "There could be multiple capture scenes - For example another sce= ne for
> a
> presentation."
> In the next slide I saw "There can be multiple capture sets, such= as
> one for
> people and one for a presentation".
> Is there going to be a description for the capture scene that will
> specify
> what is the capture scene of?
> As for capture sets do you see the presentation and people capture set=
> in
> the same scene or are they in a separate scenes, how do you decide
> which one
> to use?
> Thanks
> Roni Even
> < oNormal>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--000e0cd709c65a86ab04adb007d0-- From stephen.botzko@gmail.com Sat Sep 24 08:01:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35C21F8AB8 for ; Sat, 24 Sep 2011 08:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTxvxtKS+TR7 for ; Sat, 24 Sep 2011 08:01:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E421F8922 for ; Sat, 24 Sep 2011 08:01:04 -0700 (PDT) Received: by vws5 with SMTP id 5so5386213vws.31 for ; Sat, 24 Sep 2011 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gh1bzaEzdJrPCg1oeNUA28SoRgbcR3MJLhZbKveLHnM=; b=BSLjXlG3BUGVXgGOZVlhJtD7nXspHrNgkl0E24/VEW88ZYF6Y6m3tWpvLGX7+/Vfd/ IXbb6gm27wiPr/rd/Wt9UivTah6IWscRaZoZLXj6arYsxF6Ls64+NTDH2+dl6fjUcwfm kB17RbAFE6QZfpNBBaGMR3Gc9EmQlnz/cDG9c= MIME-Version: 1.0 Received: by 10.52.178.164 with SMTP id cz4mr4358370vdc.467.1316876621493; Sat, 24 Sep 2011 08:03:41 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Sat, 24 Sep 2011 08:03:41 -0700 (PDT) In-Reply-To: References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> Date: Sat, 24 Sep 2011 11:03:41 -0400 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=bcaec5186a5c3cb6a104adb13bc7 Cc: clue@ietf.org Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 15:01:06 -0000 --bcaec5186a5c3cb6a104adb13bc7 Content-Type: text/plain; charset=ISO-8859-1 I think we agree. There are two multiple-screen cases- One is where the same content is mirrored on multiple displays in the same room. The scenarios I was describing are various instances of that. The second is where a presentation comprises multiple screens (showing different stuff on each screen). I think that is the case you are talking about. I agree that it would be good to signal the spatial relationships in that case. That was why I suggested treating the presentation as a scene, and not assume it is a single "capture". BTW, presentations is one situation where using an angular measure for height/width doesn't work very well. Stephen B. On Sat, Sep 24, 2011 at 9:37 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > > > On Sat, Sep 24, 2011 at 8:19 AM, Stephen Botzko wrote: > >> Presentation display in today's systems is extremely diverse. Some >> vendors place small displays at every seating position, others place large >> displays somewhere in the room. In the latter case, there is no de-facto >> "standard" placement. I don't see this converging to a common design >> anytime soon. >> >> In the most common use case (showing a computer screen) there is no actual >> capture of a scene within the room. One can attempt to substitute the >> position of the locally-rendered presentation instead, but this will (in >> general) not enable gaze awareness. That is, it will often not be possible >> to ensure that I will perceive someone at another site as looking at the >> presentation. >> >> I think in practice it will be ok if we treat the presentation as a scene >> which is spatially unrelated to other scenes. If there is a way to describe >> how scenes relate to each other, then of course people could apply that >> signaling to their sourced presentations. Though in most practical cases >> the receiving systems will basically ignore that information - they will >> display the presentation on their presentation monitors, wherever they >> happen to be. >> > > When there are multiple independent presentation screens, it is natural to > refer to them spatially (the left screen, the upper screen, etc.) > I think that being able to refer to multiple screens that way is probably > more important than gaze awareness. (In other words, if I say "on the left > screen you will see a graph of...", you may look down, or up, or even right, > and none of that would bother me much as long as you are looking at the > correct screen.) > > This is clearly a "it would be nice," and, yet, well it would be nice... > > BTW, at least the medical telepresence systems we installed at Barrow had > multiple presentation screens, and I see as a natural evolution for all > systems. > > Regards > Marshall > > >> >> Stephen Botzko >> >> >> >> On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) wrote: >> >>> Hi Roni, >>> Please see below- >>> Regards, >>> Allyn >>> >>> > -----Original Message----- >>> > From: Roni Even [mailto:Even.roni@huawei.com] >>> > Sent: Sunday, September 18, 2011 11:03 PM >>> > To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org >>> > Subject: RE: [clue] Qusetion on Capture Scene and Capture set >>> > >>> > Hi Allyn, >>> > First the last two sentences from my email, I am not sure why they got >>> > like >>> > that, I am using outlook and the email is in HTML format, I am sending >>> > it >>> > now as plain text. >>> > >>> > As for the presentation, a row in a capture set can include multiple >>> > media >>> > captures that has implied spatial relation, so if you put the >>> > presentation >>> > in a row with three other video captures from a camera how is it >>> > spatially >>> > related. >>> I don't seen this happening. The scene for the main video and audio is >>> different than the scene for each presentation. >>> I will agree with you that we need to specify scene more explicitly in >>> the next draft. >>> So we would have a capture set for each scene. There are likely multiple >>> scenes in the endpoint. For example one scene for which there are main audio >>> and video captures, which are aggregated into Capture Set 1; then one scene >>> for a presentation audio and video captures, which are aggregated into >>> Capture Set 2; then just for fun we can imagine a second presentation which >>> be another capture scene maybe also with audio and video presentation >>> captures in capture set 3. So that endpoint would be sending 3 capture sets >>> describing the streams being generated at that endpoint. >>> >>> I hope this clarifies some-- >>> >>> Best, >>> Allyn >>> >>> Can you put the presentation in any position in the row. >>> > I also understand that the presentation cannot be in a separate row in >>> > a >>> > capture set since the selection is one row of each media type from a >>> > capture >>> > set. This leads me to think that there can be more than one capture set >>> > or >>> > more than one scene if we define the hierarchal relation between the >>> > two. >>> > >>> > As for media scene and capture set I do not understand what is a scene >>> > and >>> > what is the hierarchal order between both , so far my assumption was >>> > that >>> > the scene is the local meeting room with all it functionality and there >>> > is >>> > one capture scene in an offer. There can be a capture set for the >>> > people >>> > view and a capture set for the presentations. We need to have some >>> > hierarchy >>> > in the framework. >>> > I think that each layer (Scene, Capture sets, media captures,...) >>> should >>> > have >>> > attributes that describe the layer. >>> > >>> > Regards >>> > Roni >>> > >>> > >>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>> > Sent: Monday, September 19, 2011 2:58 AM >>> > To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org >>> > Subject: RE: [clue] Qusetion on Captyre Scene and Capture set >>> > >>> > Hi Roni, >>> > The text in the draft hasn't been updated yet, so you might find small >>> > discrepancies with any slide deck which is more recent than the draft. >>> > The >>> > more recent document is the one to be considered. We are due to have a >>> > new >>> > draft before the interim meeting. >>> > >>> > It is meant for each capture set to be an aggregation of the media >>> > captures >>> > describing a capture scene. Each capture set describes a scene which is >>> > non-overlapping, not redundant, unique, with respect to other capture >>> > sets. >>> > >>> > I'm sorry I couldn't parse your last remark due to some typos. >>> > >>> > Regards, >>> > Allyn >>> > >>> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>> > Roni >>> > Even >>> > Sent: Wednesday, September 14, 2011 7:41 AM >>> > To: Brian Baldino (bbaldino); clue@ietf.org >>> > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set >>> > >>> > Hi Brian, >>> > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple >>> > capture >>> > sets in slide 2. I think that the relation between the capture scene >>> > and >>> > capture set is not clear. Looking at section 9 of the framework draft I >>> > can >>> > see two capture sets (#1 and #2) and it says that the receiver picks a >>> > row >>> > from each capture set. So is this one capture scene or two. The text >>> > talk >>> > about sending capture sets but not capture scenes and there is no >>> > drawing >>> > that include both. >>> > As for the presentation, a row in a capture set can include multiple >>> > media >>> > captures that has implied spatial relation, so if you put the >>> > presentation >>> > in a row with three other video captures how is it spatially related. >>> > Can >>> > you put the presentation in any position in the row. >>> > I als o unders n cannot be in a separate row in a capture set since the >>> > selection is one row from a capture set. This leads me to think that >>> > there >>> > can be more than one capture set or more than one scene if we define >>> > the >>> > hierarchal relation between the tw. >>> > >>> > >>> > Regards >>> > Roni >>> > >>> > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] >>> > Sent: Wednesday, September 14, 2011 4:53 PM >>> > To: Roni Even; clue@ietf.org >>> > Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> >>> > >>> > A capture has a 'role' attribute that describes it as presentation or >>> > participant video, so for the current cases we've seen that as >>> > sufficient >>> > (instead of putting a similar attribute on the entire capture set). >>> > >>> > A capture set describes a single capture scene, so you couldn't have >>> > multiple capture sets describing the same 'scene', but I'd say how a >>> > device >>> > decides to split up captures amongst scenes is somewhat up to them. >>> > Splitting up presentation and participant captures into two separate >>> > scenes >>> > seems to make sense as there's no spatial relationship between the two >>> > sets >>> > of receive side, I don't think a receiver would choose only a single >>> > capture >>> > scene to view, I think it would choose captures from each capture set. >>> > >>> > -Brian >>> > >>> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>> > Roni >>> > Even >>> > Sent: Wednesday, September 14, 2011 5:58 AM >>> > To: clue@ietf.org >>> > Subject: [clue] Qusetion on Captyre Scene and Cap > >>> > >>> > Hi, >>> > In the last Interim meeting presentation on Capture sets >>> > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments >>> > that >>> > "There could be multiple capture scenes - For example another scene for >>> > a >>> > presentation." >>> > In the next slide I saw "There can be multiple capture sets, such as >>> > one for >>> > people and one for a presentation". >>> > Is there going to be a description for the capture scene that will >>> > specify >>> > what is the capture scene of? >>> > As for capture sets do you see the presentation and people capture set >>> > in >>> > the same scene or are they in a separate scenes, how do you decide >>> > which one >>> > to use? >>> > Thanks >>> > Roni Even >>> > < oNormal> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --bcaec5186a5c3cb6a104adb13bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we agree.

There are two multiple-screen cases-

One is= where the same content is mirrored on multiple displays in the same room.= =A0 The scenarios I was describing are various instances of that.

Th= e second is where a presentation comprises multiple screens (showing differ= ent stuff on each screen).=A0 I think that is the case you are talking abou= t.=A0 I agree that it would be good to signal the spatial relationships in = that case.=A0 That was why I suggested treating the presentation as a scene= , and not assume it is a single "capture".=A0

BTW, presentations is one situation where using an angular measure for = height/width doesn't work very well.

Stephen B.

On Sat, Sep 24, 2011 at 9:37 AM, Marshall Eubanks <marshall.euban= ks@gmail.com> wrote:


On Sat, Sep 24, 2011 at 8:19 AM, Stephen Botzko <stephen.= botzko@gmail.com> wrote:
Presentation display in today's systems is extremely diverse.=A0 Some v= endors place small displays at every seating position, others place large d= isplays somewhere in the room.=A0 In the latter case, there is no de-facto = "standard" placement.=A0 I don't see this converging to a com= mon design anytime soon.

In the most common use case (showing a computer screen) there is no act= ual capture of a scene within the room. One can attempt to substitute the p= osition of the locally-rendered presentation instead, but this will (in gen= eral) not enable gaze awareness.=A0 That is, it will often not be possible = to ensure that I will perceive someone at another site as looking at the pr= esentation.

I think in practice it will be ok if we treat the presentation as a sce= ne which is spatially unrelated to other scenes. If there is a way to descr= ibe how scenes relate to each other, then of course people could apply that= signaling to their sourced presentations.=A0 Though in most practical case= s the receiving systems will basically ignore that information - they will = display the presentation on their presentation monitors, wherever they happ= en to be.

When there are multiple independent = =A0presentation screens, it is natural to refer to them spatially (the left= screen, the upper screen, etc.)=A0
I think that being able to re= fer to multiple screens that way is probably more important than gaze aware= ness. (In other words, if I say "on the left screen you will see a gra= ph of...", you may look down, or up, or even right, and none of that w= ould bother me much as long as you are looking at the correct screen.)=A0

This is clearly a "it would be nice," and, ye= t, well it would be nice...

BTW, at least the medi= cal telepresence systems we installed at Barrow had multiple presentation s= creens, and I see as a natural evolution for all systems.

Regards
Marshall
=A0

Stephen Botzko



On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) <allyn@cis= co.com> wrote:
Hi Roni,
Please see below-
Regards,
Allyn

> -----Original Message-----
> From: Roni Even [mailto:Even.roni@huawei.com]
> Sent: Sunday, September 18, 2011 11:03 PM
> To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Capture Scene and Capture set
>
> Hi Allyn,
> First the last two sentences from my email, I am not sure why they got=
> like
> that, I am using outlook and the email is in HTML format, I am sending=
> it
> now as plain text.
>
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures from a camera how is it
> spatially
> related.
I don't seen this happening. The scene for the main video and aud= io is different than the scene for each presentation.
I will agree with you that we need to specify scene more explicitly in the = next draft.
So we would have a capture set for each scene. There are likely multiple sc= enes in the endpoint. For example one scene for which there are main audio = and video captures, which are aggregated into Capture Set 1; then one scene= for a presentation audio and video captures, which are aggregated into Cap= ture Set 2; then just for fun we can imagine a second presentation which be= another capture scene maybe also with audio and video presentation capture= s in capture set 3. So that endpoint would be sending 3 capture sets descri= bing the streams being generated at that endpoint.

I hope this clarifies some--

Best,
Allyn

=A0=A0Can you put the presentation in any position in the row.
> I also understand that the presentation cannot be in a separate row in=
> a
> capture set since the selection is one row of each media type from a > capture
> set. This leads me to think that there can be more than one capture se= t
> or
> more than one scene if we define the hierarchal relation between the > two.
>
> As for media scene and capture set I do not understand what is a scene=
> and
> what is the hierarchal order between both , so far my assumption was > that
> the scene is the local meeting room with all it functionality and ther= e
> is
> one capture scene in an offer. =A0There can be a capture set for the > people
> view and a capture set for the presentations. We need to have some
> hierarchy
> in the framework.
> I think that each layer (Scene, Capture sets, media captures,...) shou= ld
> have
> attributes that describe the layer.
>
> Regards
> Roni
>
>
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: Monday, September 19, 2011 2:58 AM
> To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Roni,
> The text in the draft hasn't been updated yet, so you might find s= mall
> discrepancies with any slide deck which is more recent than the draft.=
> The
> more recent document is the one to be considered. We are due to have a=
> new
> draft before the interim meeting.
>
> It is meant for each capture set to be an aggregation of the media
> captures
> describing a capture scene. Each capture set describes a scene which i= s
> non-overlapping, not redundant, unique, with respect to other capture<= br> > sets.
>
> I'm sorry I couldn't parse your last remark due to some typos.=
>
> Regards,
> Allyn
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 7:41 AM
> To: Brian Baldino (bbaldino); clue@ietf.org
> Subject: Re: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Brian,
> Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture
> sets in slide 2. I think that the relation between the capture scene > and
> capture set is not clear. Looking at section 9 of the framework draft = I
> can
> see two capture sets (#1 and #2) and it says that the receiver picks a=
> row
> from each capture set. So is this one capture scene or two. The text > talk
> about sending capture sets but not capture scenes and there is no
> drawing
> that include both.
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures how is it spatially related.<= br> > =A0Can
> you put the presentation in any position in the row.
> I als o unders n cannot be in a separate row in a capture set since th= e
> selection is one row from a capture set. This leads me to think that > there
> can be more than one capture set or more than one scene if we define > the
> hierarchal relation between the tw.
>
>
> Regards
> Roni
>
> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
> Sent: Wednesday, September 14, 2011 4:53 PM
> To: Roni Even; clue= @ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p>
>
> A capture has a 'role' attribute that describes it as presenta= tion or
> participant video, so for the current cases we've seen that as
> sufficient
> (instead of putting a similar attribute on the entire capture set). >
> A capture set describes a single capture scene, so you couldn't ha= ve
> multiple capture sets describing the same 'scene', but I'd= say how a
> device
> decides to split up captures amongst scenes is somewhat up to them. > Splitting up presentation and participant captures into two separate > scenes
> seems to make sense as there's no spatial relationship between the= two
> sets
> of receive side, I don't think a receiver would choose only a sing= le
> capture
> scene to view, I think it would choose captures from each capture set.=
>
> -Brian
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 5:58 AM
> To: clue@ietf.org
> Subject: [clue] Qusetion on Captyre Scene and Cap >
>
> Hi,
> In the last Interim meeting presentation on Capture sets
> (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments=
> that
> "There could be multiple capture scenes - For example another sce= ne for
> a
> presentation."
> In the next slide I saw "There can be multiple capture sets, such= as
> one for
> people and one for a presentation".
> Is there going to be a description for the capture scene that will
> specify
> what is the capture scene of?
> As for capture sets do you see the presentation and people capture set=
> in
> the same scene or are they in a separate scenes, how do you decide
> which one
> to use?
> Thanks
> Roni Even
> < oNormal>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



--bcaec5186a5c3cb6a104adb13bc7-- From marshall.eubanks@gmail.com Sat Sep 24 09:24:58 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C421F85FF for ; Sat, 24 Sep 2011 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDgHxdbhUk8r for ; Sat, 24 Sep 2011 09:24:57 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D139821F8569 for ; Sat, 24 Sep 2011 09:24:56 -0700 (PDT) Received: by yic13 with SMTP id 13so3844573yic.31 for ; Sat, 24 Sep 2011 09:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B1u3isXy8zLM9+KI5nP+ynkvkyHcGZY+PKeKwF8rVic=; b=SfdDMbYzDUl0ssUVo9nIS2GFujk/YAvnwfrp3mC9+1c4LGkYNaEhuayO+4PH/OEvZX hITNEoEMrcB9FuUmg919zFO/1tbbjNl76dZ5wX979NQMd6gKHQumHKDSK+/Q5CwW1ntf 0GHU+kpPX6cs1dQy3T6YOyoDabZmPzlR513Jg= MIME-Version: 1.0 Received: by 10.151.14.12 with SMTP id r12mr4527150ybi.368.1316881654017; Sat, 24 Sep 2011 09:27:34 -0700 (PDT) Received: by 10.151.150.3 with HTTP; Sat, 24 Sep 2011 09:27:33 -0700 (PDT) In-Reply-To: References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <008b01cc7691$db0e1350$912a39f0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05AB1E74@xmb-sjc-221.amer.cisco.com> Date: Sat, 24 Sep 2011 12:27:33 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: multipart/alternative; boundary=000e0cd47dca32f45504adb267e5 Cc: clue@ietf.org Subject: Re: [clue] Qusetion on Capture Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 16:24:58 -0000 --000e0cd47dca32f45504adb267e5 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 24, 2011 at 11:03 AM, Stephen Botzko wrote: > I think we agree. > > There are two multiple-screen cases- > > One is where the same content is mirrored on multiple displays in the same > room. The scenarios I was describing are various instances of that. > > Yes, and there are of course many examples of this. > The second is where a presentation comprises multiple screens (showing > different stuff on each screen). I think that is the case you are talking > about. Yep > I agree that it would be good to signal the spatial relationships in that > case. That was why I suggested treating the presentation as a scene, and > not assume it is a single "capture". > > BTW, presentations is one situation where using an angular measure for > height/width doesn't work very well. > > Yep. Marshall > Stephen B. > > > On Sat, Sep 24, 2011 at 9:37 AM, Marshall Eubanks < > marshall.eubanks@gmail.com> wrote: > >> >> >> On Sat, Sep 24, 2011 at 8:19 AM, Stephen Botzko > > wrote: >> >>> Presentation display in today's systems is extremely diverse. Some >>> vendors place small displays at every seating position, others place large >>> displays somewhere in the room. In the latter case, there is no de-facto >>> "standard" placement. I don't see this converging to a common design >>> anytime soon. >>> >>> In the most common use case (showing a computer screen) there is no >>> actual capture of a scene within the room. One can attempt to substitute the >>> position of the locally-rendered presentation instead, but this will (in >>> general) not enable gaze awareness. That is, it will often not be possible >>> to ensure that I will perceive someone at another site as looking at the >>> presentation. >>> >>> I think in practice it will be ok if we treat the presentation as a scene >>> which is spatially unrelated to other scenes. If there is a way to describe >>> how scenes relate to each other, then of course people could apply that >>> signaling to their sourced presentations. Though in most practical cases >>> the receiving systems will basically ignore that information - they will >>> display the presentation on their presentation monitors, wherever they >>> happen to be. >>> >> >> When there are multiple independent presentation screens, it is natural >> to refer to them spatially (the left screen, the upper screen, etc.) >> I think that being able to refer to multiple screens that way is probably >> more important than gaze awareness. (In other words, if I say "on the left >> screen you will see a graph of...", you may look down, or up, or even right, >> and none of that would bother me much as long as you are looking at the >> correct screen.) >> >> This is clearly a "it would be nice," and, yet, well it would be nice... >> >> BTW, at least the medical telepresence systems we installed at Barrow had >> multiple presentation screens, and I see as a natural evolution for all >> systems. >> >> Regards >> Marshall >> >> >>> >>> Stephen Botzko >>> >>> >>> >>> On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) wrote: >>> >>>> Hi Roni, >>>> Please see below- >>>> Regards, >>>> Allyn >>>> >>>> > -----Original Message----- >>>> > From: Roni Even [mailto:Even.roni@huawei.com] >>>> > Sent: Sunday, September 18, 2011 11:03 PM >>>> > To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org >>>> > Subject: RE: [clue] Qusetion on Capture Scene and Capture set >>>> > >>>> > Hi Allyn, >>>> > First the last two sentences from my email, I am not sure why they got >>>> > like >>>> > that, I am using outlook and the email is in HTML format, I am sending >>>> > it >>>> > now as plain text. >>>> > >>>> > As for the presentation, a row in a capture set can include multiple >>>> > media >>>> > captures that has implied spatial relation, so if you put the >>>> > presentation >>>> > in a row with three other video captures from a camera how is it >>>> > spatially >>>> > related. >>>> I don't seen this happening. The scene for the main video and audio is >>>> different than the scene for each presentation. >>>> I will agree with you that we need to specify scene more explicitly in >>>> the next draft. >>>> So we would have a capture set for each scene. There are likely multiple >>>> scenes in the endpoint. For example one scene for which there are main audio >>>> and video captures, which are aggregated into Capture Set 1; then one scene >>>> for a presentation audio and video captures, which are aggregated into >>>> Capture Set 2; then just for fun we can imagine a second presentation which >>>> be another capture scene maybe also with audio and video presentation >>>> captures in capture set 3. So that endpoint would be sending 3 capture sets >>>> describing the streams being generated at that endpoint. >>>> >>>> I hope this clarifies some-- >>>> >>>> Best, >>>> Allyn >>>> >>>> Can you put the presentation in any position in the row. >>>> > I also understand that the presentation cannot be in a separate row in >>>> > a >>>> > capture set since the selection is one row of each media type from a >>>> > capture >>>> > set. This leads me to think that there can be more than one capture >>>> set >>>> > or >>>> > more than one scene if we define the hierarchal relation between the >>>> > two. >>>> > >>>> > As for media scene and capture set I do not understand what is a scene >>>> > and >>>> > what is the hierarchal order between both , so far my assumption was >>>> > that >>>> > the scene is the local meeting room with all it functionality and >>>> there >>>> > is >>>> > one capture scene in an offer. There can be a capture set for the >>>> > people >>>> > view and a capture set for the presentations. We need to have some >>>> > hierarchy >>>> > in the framework. >>>> > I think that each layer (Scene, Capture sets, media captures,...) >>>> should >>>> > have >>>> > attributes that describe the layer. >>>> > >>>> > Regards >>>> > Roni >>>> > >>>> > >>>> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] >>>> > Sent: Monday, September 19, 2011 2:58 AM >>>> > To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org >>>> > Subject: RE: [clue] Qusetion on Captyre Scene and Capture set >>>> > >>>> > Hi Roni, >>>> > The text in the draft hasn't been updated yet, so you might find small >>>> > discrepancies with any slide deck which is more recent than the draft. >>>> > The >>>> > more recent document is the one to be considered. We are due to have a >>>> > new >>>> > draft before the interim meeting. >>>> > >>>> > It is meant for each capture set to be an aggregation of the media >>>> > captures >>>> > describing a capture scene. Each capture set describes a scene which >>>> is >>>> > non-overlapping, not redundant, unique, with respect to other capture >>>> > sets. >>>> > >>>> > I'm sorry I couldn't parse your last remark due to some typos. >>>> > >>>> > Regards, >>>> > Allyn >>>> > >>>> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>> > Roni >>>> > Even >>>> > Sent: Wednesday, September 14, 2011 7:41 AM >>>> > To: Brian Baldino (bbaldino); clue@ietf.org >>>> > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set >>>> > >>>> > Hi Brian, >>>> > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple >>>> > capture >>>> > sets in slide 2. I think that the relation between the capture scene >>>> > and >>>> > capture set is not clear. Looking at section 9 of the framework draft >>>> I >>>> > can >>>> > see two capture sets (#1 and #2) and it says that the receiver picks a >>>> > row >>>> > from each capture set. So is this one capture scene or two. The text >>>> > talk >>>> > about sending capture sets but not capture scenes and there is no >>>> > drawing >>>> > that include both. >>>> > As for the presentation, a row in a capture set can include multiple >>>> > media >>>> > captures that has implied spatial relation, so if you put the >>>> > presentation >>>> > in a row with three other video captures how is it spatially related. >>>> > Can >>>> > you put the presentation in any position in the row. >>>> > I als o unders n cannot be in a separate row in a capture set since >>>> the >>>> > selection is one row from a capture set. This leads me to think that >>>> > there >>>> > can be more than one capture set or more than one scene if we define >>>> > the >>>> > hierarchal relation between the tw. >>>> > >>>> > >>>> > Regards >>>> > Roni >>>> > >>>> > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] >>>> > Sent: Wednesday, September 14, 2011 4:53 PM >>>> > To: Roni Even; clue@ietf.org >>>> > Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p> >>>> > >>>> > A capture has a 'role' attribute that describes it as presentation or >>>> > participant video, so for the current cases we've seen that as >>>> > sufficient >>>> > (instead of putting a similar attribute on the entire capture set). >>>> > >>>> > A capture set describes a single capture scene, so you couldn't have >>>> > multiple capture sets describing the same 'scene', but I'd say how a >>>> > device >>>> > decides to split up captures amongst scenes is somewhat up to them. >>>> > Splitting up presentation and participant captures into two separate >>>> > scenes >>>> > seems to make sense as there's no spatial relationship between the two >>>> > sets >>>> > of receive side, I don't think a receiver would choose only a single >>>> > capture >>>> > scene to view, I think it would choose captures from each capture set. >>>> > >>>> > -Brian >>>> > >>>> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>> > Roni >>>> > Even >>>> > Sent: Wednesday, September 14, 2011 5:58 AM >>>> > To: clue@ietf.org >>>> > Subject: [clue] Qusetion on Captyre Scene and Cap > >>>> > >>>> > Hi, >>>> > In the last Interim meeting presentation on Capture sets >>>> > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments >>>> > that >>>> > "There could be multiple capture scenes - For example another scene >>>> for >>>> > a >>>> > presentation." >>>> > In the next slide I saw "There can be multiple capture sets, such as >>>> > one for >>>> > people and one for a presentation". >>>> > Is there going to be a description for the capture scene that will >>>> > specify >>>> > what is the capture scene of? >>>> > As for capture sets do you see the presentation and people capture set >>>> > in >>>> > the same scene or are they in a separate scenes, how do you decide >>>> > which one >>>> > to use? >>>> > Thanks >>>> > Roni Even >>>> > < oNormal> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> > --000e0cd47dca32f45504adb267e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Sep 24, 2011 at 11:03 AM, Stephe= n Botzko <= stephen.botzko@gmail.com> wrote:
I think we agree.

There are two multiple-screen cases-

One is= where the same content is mirrored on multiple displays in the same room.= =A0 The scenarios I was describing are various instances of that.


Yes, and there are of course many examples of this.=A0<= /div>
=A0
The second is where a pr= esentation comprises multiple screens (showing different stuff on each scre= en).=A0 I think that is the case you are talking about.

Yep
=A0
= =A0 I agree that it would be good to signal the spatial relationships in th= at case.=A0 That was why I suggested treating the presentation as a scene, = and not assume it is a single "capture".=A0

BTW, presentations is one situation where using an angular measure for = height/width doesn't work very well.


Yep.

Marshall
=A0
Stephen B.


On Sat, Sep 24, 2011 at 9:37 AM, Marshall Eubanks <= ;marshall.e= ubanks@gmail.com> wrote:


On S= at, Sep 24, 2011 at 8:19 AM, Stephen Botzko <stephen.botzko@gmail= .com> wrote:
Presentation display in today's systems is extremely diverse.=A0 Some v= endors place small displays at every seating position, others place large d= isplays somewhere in the room.=A0 In the latter case, there is no de-facto = "standard" placement.=A0 I don't see this converging to a com= mon design anytime soon.

In the most common use case (showing a computer screen) there is no act= ual capture of a scene within the room. One can attempt to substitute the p= osition of the locally-rendered presentation instead, but this will (in gen= eral) not enable gaze awareness.=A0 That is, it will often not be possible = to ensure that I will perceive someone at another site as looking at the pr= esentation.

I think in practice it will be ok if we treat the presentation as a sce= ne which is spatially unrelated to other scenes. If there is a way to descr= ibe how scenes relate to each other, then of course people could apply that= signaling to their sourced presentations.=A0 Though in most practical case= s the receiving systems will basically ignore that information - they will = display the presentation on their presentation monitors, wherever they happ= en to be.

When there are multiple independent = =A0presentation screens, it is natural to refer to them spatially (the left= screen, the upper screen, etc.)=A0
I think that being able to re= fer to multiple screens that way is probably more important than gaze aware= ness. (In other words, if I say "on the left screen you will see a gra= ph of...", you may look down, or up, or even right, and none of that w= ould bother me much as long as you are looking at the correct screen.)=A0

This is clearly a "it would be nice," and, ye= t, well it would be nice...

BTW, at least the medi= cal telepresence systems we installed at Barrow had multiple presentation s= creens, and I see as a natural evolution for all systems.

Regards
Marshall
=A0

Stephen Botzko



On Fri, Sep 23, 2011 at 5:21 PM, Allyn Romanow (allyn) <allyn@cis= co.com> wrote:
Hi Roni,
Please see below-
Regards,
Allyn

> -----Original Message-----
> From: Roni Even [mailto:Even.roni@huawei.com]
> Sent: Sunday, September 18, 2011 11:03 PM
> To: Allyn Romanow (allyn); Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Capture Scene and Capture set
>
> Hi Allyn,
> First the last two sentences from my email, I am not sure why they got=
> like
> that, I am using outlook and the email is in HTML format, I am sending=
> it
> now as plain text.
>
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures from a camera how is it
> spatially
> related.
I don't seen this happening. The scene for the main video and aud= io is different than the scene for each presentation.
I will agree with you that we need to specify scene more explicitly in the = next draft.
So we would have a capture set for each scene. There are likely multiple sc= enes in the endpoint. For example one scene for which there are main audio = and video captures, which are aggregated into Capture Set 1; then one scene= for a presentation audio and video captures, which are aggregated into Cap= ture Set 2; then just for fun we can imagine a second presentation which be= another capture scene maybe also with audio and video presentation capture= s in capture set 3. So that endpoint would be sending 3 capture sets descri= bing the streams being generated at that endpoint.

I hope this clarifies some--

Best,
Allyn

=A0=A0Can you put the presentation in any position in the row.
> I also understand that the presentation cannot be in a separate row in=
> a
> capture set since the selection is one row of each media type from a > capture
> set. This leads me to think that there can be more than one capture se= t
> or
> more than one scene if we define the hierarchal relation between the > two.
>
> As for media scene and capture set I do not understand what is a scene=
> and
> what is the hierarchal order between both , so far my assumption was > that
> the scene is the local meeting room with all it functionality and ther= e
> is
> one capture scene in an offer. =A0There can be a capture set for the > people
> view and a capture set for the presentations. We need to have some
> hierarchy
> in the framework.
> I think that each layer (Scene, Capture sets, media captures,...) shou= ld
> have
> attributes that describe the layer.
>
> Regards
> Roni
>
>
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: Monday, September 19, 2011 2:58 AM
> To: Roni Even; Brian Baldino (bbaldino); clue@ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Roni,
> The text in the draft hasn't been updated yet, so you might find s= mall
> discrepancies with any slide deck which is more recent than the draft.=
> The
> more recent document is the one to be considered. We are due to have a=
> new
> draft before the interim meeting.
>
> It is meant for each capture set to be an aggregation of the media
> captures
> describing a capture scene. Each capture set describes a scene which i= s
> non-overlapping, not redundant, unique, with respect to other capture<= br> > sets.
>
> I'm sorry I couldn't parse your last remark due to some typos.=
>
> Regards,
> Allyn
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 7:41 AM
> To: Brian Baldino (bbaldino); clue@ietf.org
> Subject: Re: [clue] Qusetion on Captyre Scene and Capture set
>
> Hi Brian,
> Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture
> sets in slide 2. I think that the relation between the capture scene > and
> capture set is not clear. Looking at section 9 of the framework draft = I
> can
> see two capture sets (#1 and #2) and it says that the receiver picks a=
> row
> from each capture set. So is this one capture scene or two. The text > talk
> about sending capture sets but not capture scenes and there is no
> drawing
> that include both.
> As for the presentation, a row in a capture set can include multiple > media
> captures that has implied spatial relation, so if you put the
> presentation
> in a row with three other video captures how is it spatially related.<= br> > =A0Can
> you put the presentation in any position in the row.
> I als o unders n cannot be in a separate row in a capture set since th= e
> selection is one row from a capture set. This leads me to think that > there
> can be more than one capture set or more than one scene if we define > the
> hierarchal relation between the tw.
>
>
> Regards
> Roni
>
> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
> Sent: Wednesday, September 14, 2011 4:53 PM
> To: Roni Even; clue= @ietf.org
> Subject: RE: [clue] Qusetion on Captyre Scene a nd Captu /p>
>
> A capture has a 'role' attribute that describes it as presenta= tion or
> participant video, so for the current cases we've seen that as
> sufficient
> (instead of putting a similar attribute on the entire capture set). >
> A capture set describes a single capture scene, so you couldn't ha= ve
> multiple capture sets describing the same 'scene', but I'd= say how a
> device
> decides to split up captures amongst scenes is somewhat up to them. > Splitting up presentation and participant captures into two separate > scenes
> seems to make sense as there's no spatial relationship between the= two
> sets
> of receive side, I don't think a receiver would choose only a sing= le
> capture
> scene to view, I think it would choose captures from each capture set.=
>
> -Brian
>
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni
> Even
> Sent: Wednesday, September 14, 2011 5:58 AM
> To: clue@ietf.org
> Subject: [clue] Qusetion on Captyre Scene and Cap >
>
> Hi,
> In the last Interim meeting presentation on Capture sets
> (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments=
> that
> "There could be multiple capture scenes - For example another sce= ne for
> a
> presentation."
> In the next slide I saw "There can be multiple capture sets, such= as
> one for
> people and one for a presentation".
> Is there going to be a description for the capture scene that will
> specify
> what is the capture scene of?
> As for capture sets do you see the presentation and people capture set=
> in
> the same scene or are they in a separate scenes, how do you decide
> which one
> to use?
> Thanks
> Roni Even
> < oNormal>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue




--000e0cd47dca32f45504adb267e5-- From Mark.Duckworth@polycom.com Sat Sep 24 11:20:11 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379BC21F8B4A for ; Sat, 24 Sep 2011 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4c-XyPp4ups for ; Sat, 24 Sep 2011 11:20:10 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF021F8AF5 for ; Sat, 24 Sep 2011 11:20:08 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([::1]) with mapi; Sat, 24 Sep 2011 11:22:46 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sat, 24 Sep 2011 11:22:41 -0700 Thread-Topic: [clue] Support for information about the spacing between monitors. Thread-Index: Acx6iwnmrXteHDWGRVGsfY/w7YGmbgAWzceQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> In-Reply-To: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61CDD2A53ACRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 18:20:11 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61CDD2A53ACRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Let me see if I understand. Is this what you mean? The side that receives video can send some information about its physical d= isplay placement (size of gap between displays). The side that sends video might be able to use this information to automati= cally adjust its cameras (pan and zoom) or video cropping and scaling param= eters such that the image rendered on the receiving side looks continuous, = taking into account the gap between displays. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Saturday, September 24, 2011 3:25 AM To: clue@ietf.org Subject: [clue] Support for information about the spacing between monitors. Hi, During the last Interim meeting I mentioned this requirement and will now t= ry to explain the use case for it. In a conference room when there are three camera and three monitors and whe= n there is an object that spans between two monitors (for example a person = standing so that his image is divided between two cameras) it will be good = if the image will look continuous even though part of it is missing due to = the gap between the monitors. It is possible to calibrate the local room capture so that the local image= will look continuous. In order to have a similar experience on the remote = side when rendering the local system can convey the distance between the lo= cal monitors (including the monitor frame) in pixels (This can be calculate= d based on the lo cal moni allowing the remote side to have similar compens= ation. This will require the local system to send this information, which is an at= tribute on the conference room level or the capture scene level. I think that it will also be good to add this feature to the use case docum= ent Regards Roni Even --_000_44C6B6B2D0CF424AA90B6055548D7A61CDD2A53ACRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Let me see if I understand.  Is this what you = mean?

The side that receives video can send some information about its physica= l display placement (size of gap between displays).

The side that sends video = might be able to use this information to automatically adjust its cameras (= pan and zoom) or video cropping and scaling parameters such that the image = rendered on the receiving side looks continuous, taking into account the ga= p between displays.

 

Mark Duckworth

 

From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even
Sent: Saturday, Septe= mber 24, 2011 3:25 AM
To: clue@ietf.org
Subject: [clue]= Support for information about the spacing between monitors.

 

Hi,

During the last Interim meeti= ng I mentioned this requirement and will now try to explain the use case fo= r it.

In a conference room when there a= re three camera and three monitors and when there is an object that spans b= etween two monitors (for example a person standing so that his image is div= ided between two cameras) it will be good if the image will look continuous= even though part of it is missing due to the gap between the monitors.

It is possible to calibrate the local room = capture so that the  local image will look continuous. In order to hav= e a similar experience on the remote side when rendering the local system c= an convey the distance between the local monitors (including the monitor fr= ame) in pixels (This can be calculated based on the lo cal moni allowing th= e remote side to have similar compensation.

This will require the local system to send this information, which is a= n attribute on the conference room level or the capture scene level.

 

I th= ink that it will also be good to add this feature to the use case document<= o:p>

 

Regards

Roni Even

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A61CDD2A53ACRPMBOXPRD01pol_-- From marshall.eubanks@gmail.com Sat Sep 24 11:57:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7DF21F8BB0 for ; Sat, 24 Sep 2011 11:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGJLXVnWdcdF for ; Sat, 24 Sep 2011 11:57:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 282E221F86A1 for ; Sat, 24 Sep 2011 11:57:47 -0700 (PDT) Received: by yxt33 with SMTP id 33so4237028yxt.31 for ; Sat, 24 Sep 2011 12:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xMV5JBAjxtbrPgqphzYs1cOMySU/oKGV4QHkfqsvXrE=; b=Fyc2FHDaVx1aynWlf5sYDKEH9FSjXOb1RV3IZYa0zI7zKDiBJVruaIUS7mZCOBdwHN 5ofOnEJaOKE4SGU36pn/GIgoL7S/TTZADeN3QGO36gaVvXIIAZMrocGyOhJl/8Hdqxiq Jp2BZ4s3xLbFW/a71tATec6PVC7tLNZyiMivQ= MIME-Version: 1.0 Received: by 10.150.73.31 with SMTP id v31mr4767232yba.26.1316890824797; Sat, 24 Sep 2011 12:00:24 -0700 (PDT) Received: by 10.151.150.3 with HTTP; Sat, 24 Sep 2011 12:00:24 -0700 (PDT) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> Date: Sat, 24 Sep 2011 15:00:24 -0400 Message-ID: From: Marshall Eubanks To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=000e0cd59156d1ee0804adb48924 Cc: "clue@ietf.org" Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 18:57:48 -0000 --000e0cd59156d1ee0804adb48924 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 24, 2011 at 2:22 PM, Duckworth, Mark wrote: > Hi Roni,**** > > ** ** > > Let me see if I understand. Is this what you mean?**** > > The side that receives video can send some information about its physical > display placement (size of gap between displays). > There is really both a physical gap, and an angular gap. I would argue that the appropriate metaphor here is a window frame (to be specific, picture a double hung casement window with vertical sight blockage between the two sashes - http://en.wikipedia.org/wiki/File:Gordijnen_aan_venster.JPG ). If I look out the window right now where I am, I see people crossing behind the join between the sashes. I will call this a vertical obstruction, again just to be specific. There are several things I would want if I was going to replace this view with a telepresence view, with one screen per sash. 1.) That there be no glitch in time or space as someone passes from one screen to the next. Even if the monitors are perfectly synced, if the vertical obstruction is wider or narrower in the remote room than it is in the video capture side, that will come across as a glitch in time (i.e., your mind will predict that the face or whatever should appear before or after it actually does). It produces a stutter in what should be a smooth motion. This is highly noticeable. Similar things could be said about differences in scale or orientation, but is less common that different screen formats abut each other. 2.) That someone who is standing behind the vertical obstruction appears normal (for example, that we never see more than the usual number of eyes, and that the face appears to be the right width). This will be tough in some units (it was a weakness in the old projected Telepresence units). Now, here is a further complication : There also can be barrel distortions in the vertical obstruction (in other words, the actual gap or overlap may not be a vertical line, but a curve). Typically, this would be smallest mid-level, and would increase going up and down. Notice that this means that you could have both a gap and an overlap, depending on where you are vertically. These complications are, of course, why typical units try really hard to keep people from sitting behind a gap. > **** > > The side that sends video might be able to use this information to > automatically adjust its cameras (pan and zoom) or video cropping and > scaling parameters such that the image rendered on the receiving side looks > continuous, taking into account the gap between displays.**** > > ** > This is a case where adjustment might be done on both sides. Suppose my unit has a continuous capture, with no vertical obstruction. If the receive side knows this, and it has a vertical obstruction, it might usefully crop the received video to impose the right gap. Regards Marshall > ** > > Mark Duckworth**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *Roni Even > *Sent:* Saturday, September 24, 2011 3:25 AM > *To:* clue@ietf.org > *Subject:* [clue] Support for information about the spacing between > monitors.**** > > ** ** > > Hi,**** > > During the last Interim meeting I mentioned this requirement and will now > try to explain the use case for it. **** > > In a conference room when there are three camera and three monitors and > when there is an object that spans between two monitors (for example a > person standing so that his image is divided between two cameras) it will be > good if the image will look continuous even though part of it is missing due > to the gap between the monitors.**** > > It is possible to calibrate the local room capture so that the local image > will look continuous. In order to have a similar experience on the remote > side when rendering the local system can convey the distance between the > local monitors (including the monitor frame) in pixels (This can be > calculated based on the lo cal moni allowing the remote side to have similar > compensation.**** > > This will require the local system to send this information, which is an > attribute on the conference room level or the capture scene level.**** > > ** ** > > I think that it will also be good to add this feature to the use case > document**** > > ** ** > > Regards**** > > Roni Even**** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --000e0cd59156d1ee0804adb48924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Sep 24, 2011 at 2:22 PM, Duckwor= th, Mark <Mark.Duckworth@polycom.com> wrote:

Hi Roni,

=A0

Let me see if I understand.=A0 Is this what y= ou mean?

The side that receives video can send some information about its= physical display placement (size of gap between displays).


There is really both a physica= l gap, and an angular gap.

I would argue that the= appropriate metaphor here is a window frame (to be specific, picture a dou= ble hung casement window with vertical sight blockage between the two sashe= s - http://en.wikipedia.org/wiki/File:Gordijnen_aan_venster.JPG ). If I lo= ok out the window right now where I am, I see people crossing behind the jo= in between the sashes. I will call this a vertical obstruction, again just = to be specific.=A0

There are several things I would want if I was going to= replace this view with a telepresence view, with one screen per sash.=A0

1.) That there be no glitch in time or space as som= eone passes from one screen to the next. =A0Even if the monitors are perfec= tly synced, if the vertical obstruction is wider or narrower in the remote = room than it is in the video capture side, that will come across as a glitc= h in time (i.e., your mind will predict that the face or whatever should ap= pear before or after it actually does). It produces a stutter in what shoul= d be a smooth motion.=A0

This is highly noticeable.

Sim= ilar things could be said about differences in scale or orientation, but is= less common that different screen formats abut each other.

2.) That someone who is standing behind the vertical obstruction= appears normal (for example, that we never see more than the usual number = of eyes, and that the face appears to be the right width). This will be tou= gh in some units (it was a weakness in the old projected Telepresence units= ).

Now, here is a further complication :
=A0
There also can be barrel distortions in the vertical=A0obstruction= =A0(in other words, the actual gap or overlap may not be a vertical line, b= ut a curve). Typically, this would be smallest mid-level, and would increas= e going up and down. =A0Notice that this means that you could have both a g= ap and an overlap, depending on where you are vertically.=A0

These complications are, of course, why typical units t= ry really hard to keep people from sitting behind a gap.=A0

<= /div>
=A0

The side that sends video might be abl= e to use this information to automatically adjust its cameras (pan and zoom= ) or video cropping and scaling parameters such that the image rendered on = the receiving side looks continuous, taking into account the gap between di= splays.

=A0

<= /div>

This is a case where adjustment= might be done on both sides. Suppose my unit has a continuous capture, wit= h no vertical obstruction. If the receive side knows this, and it has a ver= tical obstruction, it might usefully crop the received video to impose the = right gap.=A0

Regards
Marshall
=A0
<= div>

Mark Duckworth

=A0

Fr= om: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Saturday, September 24, 2011 3:25 AM
To: clue@ietf.org
Subject: [clue] Support for information about the spacing between monitors.=

=A0

Hi,

During the last Interim meeting I mentioned this requirement and wil= l now try to explain the use case for it.

In a conference room when there are three camera and= three monitors and when there is an object that spans between two monitors= (for example a person standing so that his image is divided between two ca= meras) it will be good if the image will look continuous even though part o= f it is missing due to the gap between the monitors.

It is possible to calibrate the local room capture s= o that the=A0 local image will look continuous. In order to have a similar = experience on the remote side when rendering the local system can convey th= e distance between the local monitors (including the monitor frame) in pixe= ls (This can be calculated based on the lo cal moni allowing the remote sid= e to have similar compensation.

This will require the local system to send this info= rmation, which is an attribute on the conference room level or the capture = scene level.

=A0

<= p class=3D"MsoNormal"> I think that it will also be good to add this feature to the use case docum= ent

=A0

Regards

Roni Even=

=A0

<= br>_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--000e0cd59156d1ee0804adb48924-- From Even.roni@huawei.com Sat Sep 24 12:45:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0921F8B1C for ; Sat, 24 Sep 2011 12:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6rZlReRXAqI for ; Sat, 24 Sep 2011 12:45:51 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53E21F8B10 for ; Sat, 24 Sep 2011 12:45:51 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS1000LELORI0@szxga04-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 03:48:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS1000WWLORGN@szxga04-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 03:48:27 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LS100DW0LOM61@szxml11-in.huawei.com>; Sun, 25 Sep 2011 03:48:27 +0800 (CST) Date: Sat, 24 Sep 2011 22:46:43 +0300 From: Roni Even In-reply-to: <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> To: "'Duckworth, Mark'" , clue@ietf.org Message-id: <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZTnSM2raFTf9lAdPzxfphQ)" Content-language: en-us Thread-index: Acx6iwnmrXteHDWGRVGsfY/w7YGmbgAWzceQAALmA4A= References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 19:45:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZTnSM2raFTf9lAdPzxfphQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mark, It is the other way. The side that send the video calibrated the local capture, so it provides the information about what is the gap in the capture. This allow multiple receiver to get the same capture and crop or scale to adjust for their gap. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Saturday, September 24, 2011 9:23 PM To: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. Hi Roni, Let me see if I understand. Is this what you mean? The side that receives video can send some information about its physical display placement (size of gap between displays). The side that sends video might be able to use this information to automatically adjust its cameras (pan and zoom) or video cropping and scaling parameters such that the image rendered on the receiving side looks continuous, taking into account the gap between displays. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Saturday, September 24, 2011 3:25 AM To: clue@ietf.org Subject: [clue] Support for information about the spacing between monitors. Hi, During the last Interim meeting I mentioned this requirement and will now try to explain the use case for it. In a conference room when there are three camera and three monitors and when there is an object that spans between two monitors (for example a person standing so that his image is divided between two cameras) it will be good if the image will look continuous even though part of it is missing due to the gap between the monitors. It is possible to calibrate the local room capture so that the local image will look continuous. In order to have a similar experience on the remote side when rendering the local system can convey the distance between the local monitors (including the monitor frame) in pixels (This can be calculated based on the lo cal moni allowing the remote side to have similar compensation. This will require the local system to send this information, which is an attribute on the conference room level or the capture scene level. I think that it will also be good to add this feature to the use case document Regards Roni Even --Boundary_(ID_ZTnSM2raFTf9lAdPzxfphQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Mark,

It is the other way. The = side that send the video calibrated the local capture, so it provides = the information about what is the gap in the = capture.

This allow multiple receiver to get the same = capture and crop or scale to adjust for their = gap.

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Saturday, September 24, 2011 9:23 = PM
To: clue@ietf.org
Subject: Re: [clue] Support for = information about the spacing between = monitors.

 

Hi Roni,

 

Let me see if I = understand.  Is this what you mean?

The side that receives = video can send some information about its physical display placement = (size of gap between displays).

The side that sends = video might be able to use this information to automatically adjust its = cameras (pan and zoom) or video cropping and scaling parameters such = that the image rendered on the receiving side looks continuous, taking = into account the gap between displays.

 

Mark = Duckworth

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Saturday, September 24, 2011 3:25 = AM
To: clue@ietf.org
Subject: [clue] Support for = information about the spacing between = monitors.

 

Hi,

During the last = Interim meeting I mentioned this requirement and will now try to explain = the use case for it.

In a conference = room when there are three camera and three monitors and when there is an = object that spans between two monitors (for example a person standing so = that his image is divided between two cameras) it will be good if the = image will look continuous even though part of it is missing due to the = gap between the monitors.

It is = possible to calibrate the local room capture so that the  local = image will look continuous. In order to have a similar experience on the = remote side when rendering the local system can convey the distance = between the local monitors (including the monitor frame) in pixels (This = can be calculated based on the lo cal moni allowing the remote side to = have similar compensation.

This will = require the local system to send this information, which is an attribute = on the conference room level or the capture scene = level.

 

I think that it will also be good to add this feature = to the use case document

 

Regards

Roni = Even

 

= --Boundary_(ID_ZTnSM2raFTf9lAdPzxfphQ)-- From stephen.botzko@gmail.com Sat Sep 24 13:32:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65721F8510 for ; Sat, 24 Sep 2011 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnSAOQya7Ib0 for ; Sat, 24 Sep 2011 13:32:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79A8D21F850B for ; Sat, 24 Sep 2011 13:32:08 -0700 (PDT) Received: by vws5 with SMTP id 5so5536994vws.31 for ; Sat, 24 Sep 2011 13:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=epPIAWP0vYXpIdZtjFzKSWlVVbst8fbIZWVy2le9Ux0=; b=Et5FdpXAo0upnouDl5/bZjikD3ELhVbVrRnH8SBDg0dsFE+Nyqj7sao535ficaaRpM p7spQrZmNGMpMpzz76smWMC0QM9uDHVSc3nPfDfagmTpKWNA5olBl0Mo/Rpw2zT5/99Q EsQq7bTDcj5cujkVJ4LKaGDcJQMwcxzd4/HpU= MIME-Version: 1.0 Received: by 10.52.77.35 with SMTP id p3mr4732824vdw.199.1316896486222; Sat, 24 Sep 2011 13:34:46 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Sat, 24 Sep 2011 13:34:46 -0700 (PDT) In-Reply-To: <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> Date: Sat, 24 Sep 2011 16:34:46 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=20cf307f34a4446b5604adb5dbc2 Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 20:32:09 -0000 --20cf307f34a4446b5604adb5dbc2 Content-Type: text/plain; charset=ISO-8859-1 Ok. So you are suggesting that we should support signaling gaps between captures, not that we should be signaling gaps between monitors??? Regards Stephen Botzko On Sat, Sep 24, 2011 at 3:46 PM, Roni Even wrote: > Hi Mark,**** > > It is the other way. The side that send the video calibrated the local > capture, so it provides the information about what is the gap in the > capture.**** > > This allow multiple receiver to get the same capture and crop or scale to > adjust for their gap.**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *Duckworth, Mark > *Sent:* Saturday, September 24, 2011 9:23 PM > *To:* clue@ietf.org > *Subject:* Re: [clue] Support for information about the spacing between > monitors.**** > > ** ** > > Hi Roni,**** > > ** ** > > Let me see if I understand. Is this what you mean?**** > > The side that receives video can send some information about its physical > display placement (size of gap between displays).**** > > The side that sends video might be able to use this information to > automatically adjust its cameras (pan and zoom) or video cropping and > scaling parameters such that the image rendered on the receiving side looks > continuous, taking into account the gap between displays.**** > > ** ** > > Mark Duckworth**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *Roni Even > *Sent:* Saturday, September 24, 2011 3:25 AM > *To:* clue@ietf.org > *Subject:* [clue] Support for information about the spacing between > monitors.**** > > ** ** > > Hi,**** > > During the last Interim meeting I mentioned this requirement and will now > try to explain the use case for it. **** > > In a conference room when there are three camera and three monitors and > when there is an object that spans between two monitors (for example a > person standing so that his image is divided between two cameras) it will be > good if the image will look continuous even though part of it is missing due > to the gap between the monitors.**** > > It is possible to calibrate the local room capture so that the local image > will look continuous. In order to have a similar experience on the remote > side when rendering the local system can convey the distance between the > local monitors (including the monitor frame) in pixels (This can be > calculated based on the lo cal moni allowing the remote side to have similar > compensation.**** > > This will require the local system to send this information, which is an > attribute on the conference room level or the capture scene level.**** > > ** ** > > I think that it will also be good to add this feature to the use case > document**** > > ** ** > > Regards**** > > Roni Even**** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307f34a4446b5604adb5dbc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok.=A0 So you are suggesting that we should support signaling gaps between = captures, not that we should be signaling gaps between monitors???

R= egards
Stephen Botzko

On Sat, Sep 24, = 2011 at 3:46 PM, Roni Even <Even.roni@huawei.com> wrote:

Hi Mark,<= u>

It is the other way. T= he side that send the video calibrated the local capture, so it provides th= e information about what is the gap in the capture.

This allow multiple re= ceiver to get the same capture and crop or scale to adjust for their gap.

Roni

=A0

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Duckworth, Mark
Sent: Saturday, September 24, 2011 9:23 PM
To: clue@ietf.org
Subject: Re: [clue] Support for information about the spacing between monitors.=

=A0

Hi Roni= ,

=A0

Let me see if I unders= tand.=A0 Is this what you mean?

The side that receives video can send som= e information about its physical display placement (size of gap between dis= plays).

The side that sends vi= deo might be able to use this information to automatically adjust its camer= as (pan and zoom) or video cropping and scaling parameters such that the im= age rendered on the receiving side looks continuous, taking into account th= e gap between displays.

=A0

Mark Duckworth

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Roni Even
Sent: Saturday, September 24, 2011 3:25 AM
To: clue@ietf.org
Subject: [clue] Support for information about the spacing between monitors.=

=A0

Hi,

During the last Interim mee= ting I mentioned this requirement and will now try to explain the use case = for it.

In a conference room when there are three camera and= three monitors and when there is an object that spans between two monitors= (for example a person standing so that his image is divided between two ca= meras) it will be good if the image will look continuous even though part o= f it is missing due to the gap between the monitors.

It is possible to calibrate the local room capture s= o that the=A0 local image will look continuous. In order to have a similar = experience on the remote side when rendering the local system can convey th= e distance between the local monitors (including the monitor frame) in pixe= ls (This can be calculated based on the lo cal moni allowing the remote sid= e to have similar compensation.

This will require the local system to send this info= rmation, which is an attribute on the conference room level or the capture = scene level.

=A0

<= p class=3D"MsoNormal"> I think that it will also be good to add this feature to the use case docum= ent

=A0

Regards

Roni Even=

=A0

<= /div>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf307f34a4446b5604adb5dbc2-- From Even.roni@huawei.com Sat Sep 24 14:29:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174CC21F8A6F for ; Sat, 24 Sep 2011 14:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qLRagWInnR3 for ; Sat, 24 Sep 2011 14:29:23 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B54A521F86C1 for ; Sat, 24 Sep 2011 14:29:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS1000Z1QHAHV@szxga05-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 05:31:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS100FIYQH9J9@szxga05-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 05:31:58 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LS1007YPQGCOB@szxml12-in.huawei.com>; Sun, 25 Sep 2011 05:31:57 +0800 (CST) Date: Sun, 25 Sep 2011 00:29:47 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' Message-id: <06ee01cc7b01$29567f20$7c037d60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vvzw4jt1A/Z0EQHgyqf1cw)" Content-language: en-us Thread-index: Acx6+Wn0xBzxCSURSRKv5sH2pbXzxgABuKwQ References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 21:29:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_vvzw4jt1A/Z0EQHgyqf1cw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Steve, I suggest gap between monitors but on the sender size. The sender calibrates the local view based on the local gap. By providing this gap in pixels the receiver side can crop or scale. Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Saturday, September 24, 2011 11:35 PM To: Roni Even Cc: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. Ok. So you are suggesting that we should support signaling gaps between captures, not that we should be signaling gaps between monitors??? Regards Stephen Botzko On Sat, Sep 24, 2011 at 3:46 PM, Roni Even wrote: Hi Mark, It is the other way. The side that send the video calibrated the local capture, so it provides the information about what is the gap in the capture. This allow multiple receiver to get the same capture and crop or scale to adjust for their gap. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Saturday, September 24, 2011 9:23 PM To: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. Hi Roni, Let me see if I understand. Is this what you mean? The side that receives video can send some information about its physical display placement (size of gap between displays). The side that sends video might be able to use this information to automatically adjust its cameras (pan and zoom) or video cropping and scaling parameters such that the image rendered on the receiving side looks continuous, taking into account the gap between displays. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Saturday, September 24, 2011 3:25 AM To: clue@ietf.org Subject: [clue] Support for information about the spacing between monitors. Hi, During the last Interim meeting I mentioned this requirement and will now try to explain the use case for it. In a conference room when there are three camera and three monitors and when there is an object that spans between two monitors (for example a person standing so that his image is divided between two cameras) it will be good if the image will look continuous even though part of it is missing due to the gap between the monitors. It is possible to calibrate the local room capture so that the local image will look continuous. In order to have a similar experience on the remote side when rendering the local system can convey the distance between the local monitors (including the monitor frame) in pixels (This can be calculated based on the lo cal moni allowing the remote side to have similar compensation. This will require the local system to send this information, which is an attribute on the conference room level or the capture scene level. I think that it will also be good to add this feature to the use case document Regards Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_vvzw4jt1A/Z0EQHgyqf1cw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Steve,

I suggest gap between monitors but on the sender size. The sender = calibrates the local view based on the local gap. By providing this gap = in pixels the receiver side can crop or scale.

 

Roni

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Saturday, September 24, 2011 11:35 PM
To: Roni = Even
Cc: Duckworth, Mark; clue@ietf.org
Subject: Re: = [clue] Support for information about the spacing between = monitors.

 

Ok.  So you are suggesting that we = should support signaling gaps between captures, not that we should be = signaling gaps between monitors???

Regards
Stephen = Botzko

On Sat, Sep 24, 2011 at = 3:46 PM, Roni Even <Even.roni@huawei.com> = wrote:

Hi Mark,

It is the other way. The side that send the = video calibrated the local capture, so it provides the information about = what is the gap in the capture.

This allow multiple receiver to get the same = capture and crop or scale to adjust for their = gap.

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Saturday, September 24, 2011 9:23 = PM
To: clue@ietf.org
Subject: Re: [clue] = Support for information about the spacing between = monitors.

 <= /o:p>

Hi Roni,

 

Let me see if I understand.  Is this what = you mean?

The side that receives video can send some = information about its physical display placement (size of gap between = displays).

The side that sends video might be able to use = this information to automatically adjust its cameras (pan and zoom) or = video cropping and scaling parameters such that the image rendered on = the receiving side looks continuous, taking into account the gap between = displays.

 

Mark Duckworth

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni = Even
Sent: Saturday, September 24, 2011 3:25 AM
To: = clue@ietf.org
Subject: [clue] Support = for information about the spacing between = monitors.

 <= /o:p>

Hi,

During the = last Interim meeting I mentioned this requirement and will now try to = explain the use case for it.

In a = conference room when there are three camera and three monitors and when = there is an object that spans between two monitors (for example a person = standing so that his image is divided between two cameras) it will be = good if the image will look continuous even though part of it is missing = due to the gap between the monitors.

It is = possible to calibrate the local room capture so that the  local = image will look continuous. In order to have a similar experience on the = remote side when rendering the local system can convey the distance = between the local monitors (including the monitor frame) in pixels (This = can be calculated based on the lo cal moni allowing the remote side to = have similar compensation.

This will = require the local system to send this information, which is an attribute = on the conference room level or the capture scene = level.

 <= /o:p>

I think = that it will also be good to add this feature to the use case = document

 <= /o:p>

Regards=

Roni = Even

 <= /o:p>


______________________________________= _________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

= --Boundary_(ID_vvzw4jt1A/Z0EQHgyqf1cw)-- From stephen.botzko@gmail.com Sat Sep 24 18:18:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA421F8BF3 for ; Sat, 24 Sep 2011 18:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wX0Qm+IQbe5 for ; Sat, 24 Sep 2011 18:18:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8634F21F8BEB for ; Sat, 24 Sep 2011 18:18:23 -0700 (PDT) Received: by vws5 with SMTP id 5so5649873vws.31 for ; Sat, 24 Sep 2011 18:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yyPLKIXD1zawMjSdzoa05knjyTfucqq4Sx/lel9RmLg=; b=KlLtY5rMAQ847pU+qID3GR7BC9RZJOLjgDQEnhK+DXRXpQYvh2Rhq2RiYM9/lR5Kn9 XOA44cz6NPX/pZUgUbZEN2tzrKMeuYa2ROTNVVxP5tIhzj4t/n8oTGTVEFJ1To1gHLiw tfTZ1ZN3XeZ6uD2NM3bv8MZmJoAZc+jyvomxc= MIME-Version: 1.0 Received: by 10.52.93.1 with SMTP id cq1mr4599468vdb.400.1316913653586; Sat, 24 Sep 2011 18:20:53 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Sat, 24 Sep 2011 18:20:53 -0700 (PDT) In-Reply-To: <06ee01cc7b01$29567f20$7c037d60$%roni@huawei.com> References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> <06ee01cc7b01$29567f20$7c037d60$%roni@huawei.com> Date: Sat, 24 Sep 2011 21:20:53 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=20cf307cfbbc859a2104adb9dae4 Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 01:18:24 -0000 --20cf307cfbbc859a2104adb9dae4 Content-Type: text/plain; charset=ISO-8859-1 I don't think I understand what you mean by "calibrate the local view based on the local gap". Steve On Sat, Sep 24, 2011 at 5:29 PM, Roni Even wrote: > Hi Steve,**** > > I suggest gap between monitors but on the sender size. The sender > calibrates the local view based on the local gap. By providing this gap in > pixels the receiver side can crop or scale.**** > > ** ** > > Roni**** > > ** ** > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Saturday, September 24, 2011 11:35 PM > *To:* Roni Even > *Cc:* Duckworth, Mark; clue@ietf.org > > *Subject:* Re: [clue] Support for information about the spacing between > monitors.**** > > ** ** > > Ok. So you are suggesting that we should support signaling gaps between > captures, not that we should be signaling gaps between monitors??? > > Regards > Stephen Botzko**** > > On Sat, Sep 24, 2011 at 3:46 PM, Roni Even wrote:** > ** > > Hi Mark,**** > > It is the other way. The side that send the video calibrated the local > capture, so it provides the information about what is the gap in the > capture.**** > > This allow multiple receiver to get the same capture and crop or scale to > adjust for their gap.**** > > Roni**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *Duckworth, Mark > *Sent:* Saturday, September 24, 2011 9:23 PM > *To:* clue@ietf.org > *Subject:* Re: [clue] Support for information about the spacing between > monitors.**** > > **** > > Hi Roni,**** > > **** > > Let me see if I understand. Is this what you mean?**** > > The side that receives video can send some information about its physical > display placement (size of gap between displays).**** > > The side that sends video might be able to use this information to > automatically adjust its cameras (pan and zoom) or video cropping and > scaling parameters such that the image rendered on the receiving side looks > continuous, taking into account the gap between displays.**** > > **** > > Mark Duckworth**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *Roni Even > *Sent:* Saturday, September 24, 2011 3:25 AM > *To:* clue@ietf.org > *Subject:* [clue] Support for information about the spacing between > monitors.**** > > **** > > Hi,**** > > During the last Interim meeting I mentioned this requirement and will now > try to explain the use case for it. **** > > In a conference room when there are three camera and three monitors and > when there is an object that spans between two monitors (for example a > person standing so that his image is divided between two cameras) it will be > good if the image will look continuous even though part of it is missing due > to the gap between the monitors.**** > > It is possible to calibrate the local room capture so that the local image > will look continuous. In order to have a similar experience on the remote > side when rendering the local system can convey the distance between the > local monitors (including the monitor frame) in pixels (This can be > calculated based on the lo cal moni allowing the remote side to have similar > compensation.**** > > This will require the local system to send this information, which is an > attribute on the conference room level or the capture scene level.**** > > **** > > I think that it will also be good to add this feature to the use case > document**** > > **** > > Regards**** > > Roni Even**** > > **** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf307cfbbc859a2104adb9dae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think I understand what you mean by "calibrate the local v= iew based on the local gap".

Steve

On Sat, Sep 24, 2011 at 5:29 PM, Roni Even <Even.roni@huawei.com> wr= ote:

Hi Steve,

I sug= gest gap between monitors but on the sender size. The sender calibrates the= local view based on the local gap. By providing this gap in pixels the rec= eiver side can crop or scale.

=A0

Roni

=A0

From: Stephen Botzko [mail= to:stephen.bo= tzko@gmail.com]
Sent: Saturday, September 24, 2011 11:35 PM
To: Roni Even<= br>Cc: Duckworth, Mark; clue@ietf.org


Subject: Re: [clue] Support for information about the spacing between = monitors.

=A0

Ok.=A0 So you are suggesting that we should support signaling gaps b= etween captures, not that we should be signaling gaps between monitors???
Regards
Stephen Botzko

= On Sat, Sep 24, 2011 at 3:46 PM, Roni Even <Even.roni@huawei.com> wrote:=

Hi Mark,

I= t is the other way. The side that send the video calibrated the local captu= re, so it provides the information about what is the gap in the capture.

This allow multiple re= ceiver to get the same capture and crop or scale to adjust for their gap.

Roni

=A0

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Duckworth, Mark
Sent: Saturday, September 24, 2011 9:23 PM
To: clue@ietf.org
Subject: Re: [clue] Support for information about the spacing between monitors.

=A0

Hi Roni,<= /p>

=A0

Let me see if I understand.=A0 Is this what y= ou mean?

The side that receives video can send some information about its= physical display placement (size of gap between displays).

The side that sends vi= deo might be able to use this information to automatically adjust its camer= as (pan and zoom) or video cropping and scaling parameters such that the im= age rendered on the receiving side looks continuous, taking into account th= e gap between displays.

=A0

Mark Duckworth

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Roni Even
Sent: Saturday, September 24, 2011 3:25 AM
To: clue@ietf.org
Subject: [clue] Support for information about the spacing between monitors.=

=A0

Hi,

During the last Interim mee= ting I mentioned this requirement and will now try to explain the use case = for it.

In a conference room when there are three camera and= three monitors and when there is an object that spans between two monitors= (for example a person standing so that his image is divided between two ca= meras) it will be good if the image will look continuous even though part o= f it is missing due to the gap between the monitors.

It is possible to calibrate the local room capture s= o that the=A0 local image will look continuous. In order to have a similar = experience on the remote side when rendering the local system can convey th= e distance between the local monitors (including the monitor frame) in pixe= ls (This can be calculated based on the lo cal moni allowing the remote sid= e to have similar compensation.

This will require the local system to send this info= rmation, which is an attribute on the conference room level or the capture = scene level.

=A0

<= p class=3D"MsoNormal"> I think that it will also be good to add this feature to the use case docum= ent

=A0

Regards

Roni Even=

=A0

<= /div>


____________= ___________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

=A0


--20cf307cfbbc859a2104adb9dae4-- From Even.roni@huawei.com Sun Sep 25 05:40:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E3821F8B4F for ; Sun, 25 Sep 2011 05:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.301 X-Spam-Level: X-Spam-Status: No, score=-106.301 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvipfkUo3PqC for ; Sun, 25 Sep 2011 05:40:45 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBF121F8B4B for ; Sun, 25 Sep 2011 05:40:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS200LKJWOA87@szxga04-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 20:43:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS200IXIWOAEN@szxga04-in.huawei.com> for clue@ietf.org; Sun, 25 Sep 2011 20:43:22 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LS2005TDWO37P@szxml11-in.huawei.com>; Sun, 25 Sep 2011 20:43:21 +0800 (CST) Date: Sun, 25 Sep 2011 15:41:37 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' Message-id: <072001cc7b80$7adf0bd0$709d2370$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bxO89JXekxrMMj/Aq7jT9g)" Content-language: en-us Thread-index: Acx7IWSrtpzfewCkQV25r596aW6K5AAXjziQ References: <067701cc7a8b$0ddde330$2999a990$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDD2A53A@CRPMBOXPRD01.polycom.com> <06d901cc7af2$b4399a50$1caccef0$%roni@huawei.com> <06ee01cc7b01$29567f20$7c037d60$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 12:40:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bxO89JXekxrMMj/Aq7jT9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, What I mean is that the local capture is fixed based on the gap between the local monitors such that a person that stands between two cameras will look correct on the local two displays, There will be a missing part that is proportional to the gap. This is based on the gaps between the local monitors. Now if the remote monitors will have the same gap (In pixels) the rendering on the receiver will look the same as the local display, otherwise the renderer will need to adjust. Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Sunday, September 25, 2011 4:21 AM To: Roni Even Cc: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. I don't think I understand what you mean by "calibrate the local view based on the local gap". Steve On Sat, Sep 24, 2011 at 5:29 PM, Roni Even wrote: Hi Steve, I suggest gap between monitors but on the sender size. The sender calibrates the local view based on the local gap. By providing this gap in pixels the receiver side can crop or scale. Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Saturday, September 24, 2011 11:35 PM To: Roni Even Cc: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. Ok. So you are suggesting that we should support signaling gaps between captures, not that we should be signaling gaps between monitors??? Regards Stephen Botzko On Sat, Sep 24, 2011 at 3:46 PM, Roni Even wrote: Hi Mark, It is the other way. The side that send the video calibrated the local capture, so it provides the information about what is the gap in the capture. This allow multiple receiver to get the same capture and crop or scale to adjust for their gap. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Saturday, September 24, 2011 9:23 PM To: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. Hi Roni, Let me see if I understand. Is this what you mean? The side that receives video can send some information about its physical display placement (size of gap between displays). The side that sends video might be able to use this information to automatically adjust its cameras (pan and zoom) or video cropping and scaling parameters such that the image rendered on the receiving side looks continuous, taking into account the gap between displays. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Saturday, September 24, 2011 3:25 AM To: clue@ietf.org Subject: [clue] Support for information about the spacing between monitors. Hi, During the last Interim meeting I mentioned this requirement and will now try to explain the use case for it. In a conference room when there are three camera and three monitors and when there is an object that spans between two monitors (for example a person standing so that his image is divided between two cameras) it will be good if the image will look continuous even though part of it is missing due to the gap between the monitors. It is possible to calibrate the local room capture so that the local image will look continuous. In order to have a similar experience on the remote side when rendering the local system can convey the distance between the local monitors (including the monitor frame) in pixels (This can be calculated based on the lo cal moni allowing the remote side to have similar compensation. This will require the local system to send this information, which is an attribute on the conference room level or the capture scene level. I think that it will also be good to add this feature to the use case document Regards Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_bxO89JXekxrMMj/Aq7jT9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

What I mean is that the local capture is fixed based on the gap = between the local monitors such that a person that stands between two = cameras will look correct on the local two displays, There will be a = missing part that is proportional  to the gap. This is based on the = gaps between the local monitors.

Now if the remote monitors will have the same gap (In pixels) the = rendering on the receiver will look the same as the local display, = otherwise the renderer will need to adjust.

 

Roni

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Sunday, September 25, 2011 4:21 AM
To: Roni Even
Cc: = Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Support for = information about the spacing between = monitors.

 

I don't think I understand what you mean = by "calibrate the local view based on the local gap". =

Steve

On Sat, Sep 24, = 2011 at 5:29 PM, Roni Even <Even.roni@huawei.com> = wrote:

Hi = Steve,

I suggest gap between monitors = but on the sender size. The sender calibrates the local view based on = the local gap. By providing this gap in pixels the receiver side can = crop or scale.

 

Roni

 

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: = Saturday, September 24, 2011 11:35 PM
To: Roni = Even
Cc: Duckworth, Mark; clue@ietf.org


Subject: Re: [clue] Support for information = about the spacing between = monitors.

 <= /o:p>

Ok.  So you = are suggesting that we should support signaling gaps between captures, = not that we should be signaling gaps between = monitors???

Regards
Stephen Botzko

On Sat, Sep = 24, 2011 at 3:46 PM, Roni Even <Even.roni@huawei.com> = wrote:

Hi Mark,

It is the other way. The side that send the = video calibrated the local capture, so it provides the information about = what is the gap in the capture.

This allow multiple receiver to get the same = capture and crop or scale to adjust for their = gap.

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Saturday, September 24, 2011 9:23 = PM
To: clue@ietf.org
Subject: Re: [clue] = Support for information about the spacing between = monitors.

 <= /o:p>

Hi Roni,

 

Let me see if I understand.  Is this what = you mean?

The side that receives video can send some = information about its physical display placement (size of gap between = displays).

The side that sends video might be able to use = this information to automatically adjust its cameras (pan and zoom) or = video cropping and scaling parameters such that the image rendered on = the receiving side looks continuous, taking into account the gap between = displays.

 

Mark Duckworth

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni = Even
Sent: Saturday, September 24, 2011 3:25 AM
To: = clue@ietf.org
Subject: [clue] Support = for information about the spacing between = monitors.

 <= /o:p>

Hi,

During the = last Interim meeting I mentioned this requirement and will now try to = explain the use case for it.

In a = conference room when there are three camera and three monitors and when = there is an object that spans between two monitors (for example a person = standing so that his image is divided between two cameras) it will be = good if the image will look continuous even though part of it is missing = due to the gap between the monitors.

It is = possible to calibrate the local room capture so that the  local = image will look continuous. In order to have a similar experience on the = remote side when rendering the local system can convey the distance = between the local monitors (including the monitor frame) in pixels (This = can be calculated based on the lo cal moni allowing the remote side to = have similar compensation.

This will = require the local system to send this information, which is an attribute = on the conference room level or the capture scene = level.

 <= /o:p>

I think = that it will also be good to add this feature to the use case = document

 <= /o:p>

Regards=

Roni = Even

 <= /o:p>


______________= _________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 <= /o:p>

 

= --Boundary_(ID_bxO89JXekxrMMj/Aq7jT9g)-- From stephen.botzko@gmail.com Sun Sep 25 07:17:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853A021F8C16 for ; Sun, 25 Sep 2011 07:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1O+l0qGm1uM for ; Sun, 25 Sep 2011 07:17:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E79BE21F8B4B for ; Sun, 25 Sep 2011 07:17:04 -0700 (PDT) Received: by ywa6 with SMTP id 6so4640486ywa.31 for ; Sun, 25 Sep 2011 07:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:mime-version:content-class:from:subject:date:importance :x-priority:to:cc:content-transfer-encoding:content-type; bh=939FJL1uw2aZ8xBmrsOYvIRc4UunicOGjuyJX4iMd4s=; b=q+5Y3DxoDZzJcc4JI61cfG9ksKD4rwRHp7e8m6MFA0XjsBGz88ZFSTW+xhY7FwbpN0 eSDO7iQUJQjPjrBVE+MbK9CU8qTckaIBUqU3Dyfz7TAxFtdtoiDyrxkLK0AQTw6cGz4T tDvw5njixIj3opqT6mGOh4bHwLyH7tdAyz2iE= Received: by 10.150.8.16 with SMTP id 16mr5033214ybh.286.1316960384719; Sun, 25 Sep 2011 07:19:44 -0700 (PDT) Received: from Inbox ([32.164.239.231]) by mx.google.com with ESMTPS id a35sm42937011ana.10.2011.09.25.07.19.40 (version=SSLv3 cipher=OTHER); Sun, 25 Sep 2011 07:19:43 -0700 (PDT) Message-ID: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> MIME-Version: 1.0 content-class: From: Stephen Botzko Date: Sun, 25 Sep 2011 10:20:02 -0400 Importance: normal X-Priority: 3 To: Roni Even Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 14:17:05 -0000 Ok. So the signaling that is needed is the gap between captures, not the g= ap between monitors.=20 I don't think pixels is the right measure, since the relationship of pixels= to distance depends on resolution. Steve -----Original Message----- From: Roni Even Sent: Sunday, September 25, 2011 8:41 AM To: 'Stephen Botzko' Cc: 'Duckworth, Mark' ; clue@ietf.org Subject: RE: [clue] Support for information about the spacing between monit= ors. Hi, What I mean is that the local capture is fixed based on the gap between the local monitors such that a person that stands between two cameras will look correct on the local two displays, There will be a missing part that is proportional to the gap. This is based on the gaps between the local monitors. Now if the remote monitors will have the same gap (In pixels) the rendering on the receiver will look the same as the local display, otherwise the renderer will need to adjust. =20 Roni =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Sunday, September 25, 2011 4:21 AM [The entire original message is not included]= From Even.roni@huawei.com Sun Sep 25 09:43:22 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C726F21F8B04 for ; Sun, 25 Sep 2011 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.313 X-Spam-Level: X-Spam-Status: No, score=-106.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imDa6eYpcx5N for ; Sun, 25 Sep 2011 09:43:22 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CC21F8AFC for ; Sun, 25 Sep 2011 09:43:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS300LIN7WP6M@szxga04-in.huawei.com> for clue@ietf.org; Mon, 26 Sep 2011 00:46:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS3009QF7WPGL@szxga04-in.huawei.com> for clue@ietf.org; Mon, 26 Sep 2011 00:46:01 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LS300CSL7WLOY@szxml11-in.huawei.com>; Mon, 26 Sep 2011 00:46:01 +0800 (CST) Date: Sun, 25 Sep 2011 19:44:18 +0300 From: Roni Even In-reply-to: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> To: 'Stephen Botzko' Message-id: <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acx7jjFTstguQ+o1T/WXj+Mt2xcCtwAE9wQg References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 16:43:22 -0000 Steve, It is east to measure based on the local monitors using pixels since I think that you can calibrate the captures using the local monitors. Roni > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Sunday, September 25, 2011 5:20 PM > To: Roni Even > Cc: 'Duckworth, Mark'; clue@ietf.org > Subject: RE: [clue] Support for information about the spacing between > monitors. > > Ok. So the signaling that is needed is the gap between captures, not > the gap between monitors. > > I don't think pixels is the right measure, since the relationship of > pixels to distance depends on resolution. > > Steve > > -----Original Message----- > From: Roni Even > Sent: Sunday, September 25, 2011 8:41 AM > To: 'Stephen Botzko' > Cc: 'Duckworth, Mark' ; clue@ietf.org > Subject: RE: [clue] Support for information about the spacing between > monitors. > > Hi, > > What I mean is that the local capture is fixed based on the gap between > the > local monitors such that a person that stands between two cameras will > look > correct on the local two displays, There will be a missing part that is > proportional to the gap. This is based on the gaps between the local > monitors. > > Now if the remote monitors will have the same gap (In pixels) the > rendering > on the receiver will look the same as the local display, otherwise the > renderer will need to adjust. > > > > Roni > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Sunday, September 25, 2011 4:21 AM > > > [The entire original message is not included] From keith.drage@alcatel-lucent.com Mon Sep 26 03:52:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C021F85A8 for ; Mon, 26 Sep 2011 03:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLw8fPibiOzt for ; Mon, 26 Sep 2011 03:52:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9B21F85AA for ; Mon, 26 Sep 2011 03:52:50 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8QAtSRO019871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Sep 2011 12:55:28 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 26 Sep 2011 12:55:28 +0200 From: "DRAGE, Keith (Keith)" To: Roni Even , "'Stephen Botzko'" Date: Mon, 26 Sep 2011 12:55:27 +0200 Thread-Topic: [clue] Support for information about the spacing between monitors. Thread-Index: Acx7jjFTstguQ+o1T/WXj+Mt2xcCtwAE9wQgACYDsCA= Message-ID: References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> In-Reply-To: <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "clue@ietf.org" Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 10:52:51 -0000 I guess there is something I'm not getting here. If the idea of the receiving side is to present a single continuous image o= f what is sent why is it not asking for a single view that happens to have = an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the recei= ver how that is then divided between 2 screens, if indeed it is.=20 Surely how I choose to break up a single view between multiple monitors is = up to the local side, the same as if I choose to make one big screen out of= a 4x4 matrix of smaller screens? Or are you implying that the source actually needs to be 2 cameras to suppo= rt this? Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: 25 September 2011 17:44 > To: 'Stephen Botzko' > Cc: clue@ietf.org > Subject: Re: [clue] Support for information about the spacing between > monitors. >=20 > Steve, > It is east to measure based on the local monitors using pixels since I > think > that you can calibrate the captures using the local monitors. > Roni >=20 > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Sunday, September 25, 2011 5:20 PM > > To: Roni Even > > Cc: 'Duckworth, Mark'; clue@ietf.org > > Subject: RE: [clue] Support for information about the spacing between > > monitors. > > > > Ok. So the signaling that is needed is the gap between captures, not > > the gap between monitors. > > > > I don't think pixels is the right measure, since the relationship of > > pixels to distance depends on resolution. > > > > Steve > > > > -----Original Message----- > > From: Roni Even > > Sent: Sunday, September 25, 2011 8:41 AM > > To: 'Stephen Botzko' > > Cc: 'Duckworth, Mark' ; clue@ietf.org > > Subject: RE: [clue] Support for information about the spacing between > > monitors. > > > > Hi, > > > > What I mean is that the local capture is fixed based on the gap between > > the > > local monitors such that a person that stands between two cameras will > > look > > correct on the local two displays, There will be a missing part that is > > proportional to the gap. This is based on the gaps between the local > > monitors. > > > > Now if the remote monitors will have the same gap (In pixels) the > > rendering > > on the receiver will look the same as the local display, otherwise the > > renderer will need to adjust. > > > > > > > > Roni > > > > > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Sunday, September 25, 2011 4:21 AM > > > > > > [The entire original message is not included] >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Mon Sep 26 04:13:42 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A708921F8BC3 for ; Mon, 26 Sep 2011 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L27sixsbGbY for ; Mon, 26 Sep 2011 04:13:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4621F8B92 for ; Mon, 26 Sep 2011 04:13:41 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3773749vcb.31 for ; Mon, 26 Sep 2011 04:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WcfDV6wbFeFk4DoUUnVfUtD1Tdw+HgKjyH+HTJcGfMI=; b=PwOEn643t4WqDu7cLuaQxMTUBohBLGJTIZYXWwPn4rcCPO2sxkIL+sTwUYGYfQZVpW 4DZcHtGX+RRw0NnzcI9cwCqGr2/d1+D6LXkBOnev+sfUL8LDdEuJV6LG/9qUt5cYNQCd enZQltrwt9p9msB+7Htu+noxzgLWQUOpw3v64= MIME-Version: 1.0 Received: by 10.52.93.1 with SMTP id cq1mr5933723vdb.400.1317035783674; Mon, 26 Sep 2011 04:16:23 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 26 Sep 2011 04:16:23 -0700 (PDT) In-Reply-To: References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> Date: Mon, 26 Sep 2011 07:16:23 -0400 Message-ID: From: Stephen Botzko To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf307cfbbc0add9f04add64af5 Cc: "clue@ietf.org" Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 11:13:42 -0000 --20cf307cfbbc0add9f04add64af5 Content-Type: text/plain; charset=ISO-8859-1 One reason Telepresence systems use multiple cameras because that is the most cost-effective way to create a high resolution panorama. Creating and encoding a 5760 x 1080 image is not that easy. It is much simpler to create 3 1920x1080 images. This will only get worse when resolution increases to 4K. Using multiple captures to create the panorama also has advantages when there are multiple receivers and senders. You often want to see a portion of multiple rooms instead of just a single room. There are significant bandwidth issues if you are sending 2-4x more pixels than the receiver wants. One of the main reasons CLUE was formed was to enable such use of multiple captures. Stephen Botzko On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I guess there is something I'm not getting here. > > If the idea of the receiving side is to present a single continuous image > of what is sent why is it not asking for a single view that happens to have > an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the > receiver how that is then divided between 2 screens, if indeed it is. > > Surely how I choose to break up a single view between multiple monitors is > up to the local side, the same as if I choose to make one big screen out of > a 4x4 matrix of smaller screens? > > Or are you implying that the source actually needs to be 2 cameras to > support this? > > Keith > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Roni Even > > Sent: 25 September 2011 17:44 > > To: 'Stephen Botzko' > > Cc: clue@ietf.org > > Subject: Re: [clue] Support for information about the spacing between > > monitors. > > > > Steve, > > It is east to measure based on the local monitors using pixels since I > > think > > that you can calibrate the captures using the local monitors. > > Roni > > > > > -----Original Message----- > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Sunday, September 25, 2011 5:20 PM > > > To: Roni Even > > > Cc: 'Duckworth, Mark'; clue@ietf.org > > > Subject: RE: [clue] Support for information about the spacing between > > > monitors. > > > > > > Ok. So the signaling that is needed is the gap between captures, not > > > the gap between monitors. > > > > > > I don't think pixels is the right measure, since the relationship of > > > pixels to distance depends on resolution. > > > > > > Steve > > > > > > -----Original Message----- > > > From: Roni Even > > > Sent: Sunday, September 25, 2011 8:41 AM > > > To: 'Stephen Botzko' > > > Cc: 'Duckworth, Mark' ; clue@ietf.org > > > Subject: RE: [clue] Support for information about the spacing between > > > monitors. > > > > > > Hi, > > > > > > What I mean is that the local capture is fixed based on the gap between > > > the > > > local monitors such that a person that stands between two cameras will > > > look > > > correct on the local two displays, There will be a missing part that is > > > proportional to the gap. This is based on the gaps between the local > > > monitors. > > > > > > Now if the remote monitors will have the same gap (In pixels) the > > > rendering > > > on the receiver will look the same as the local display, otherwise the > > > renderer will need to adjust. > > > > > > > > > > > > Roni > > > > > > > > > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Sunday, September 25, 2011 4:21 AM > > > > > > > > > [The entire original message is not included] > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > --20cf307cfbbc0add9f04add64af5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One reason Telepresence systems use multiple cameras because that is the mo= st cost-effective way to create a high resolution panorama.=A0 Creating and= encoding a 5760 x 1080 image is not that easy.=A0 It is much simpler to cr= eate 3 1920x1080 images.=A0 This will only get worse when resolution increa= ses to 4K.

Using multiple captures to create the panorama also has advantages when= there are multiple receivers and senders.=A0 You often want to see a porti= on of multiple rooms instead of just a single room.=A0 There are significan= t bandwidth issues if you are sending 2-4x more pixels than the receiver wa= nts.

One of the main reasons CLUE was formed was to enable such use of multi= ple captures.

Stephen Botzko



On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith) = <keith.drage@alcatel-l= ucent.com> wrote:
I guess there is something I'm not gett= ing here.

If the idea of the receiving side is to present a single continuous image o= f what is sent why is it not asking for a single view that happens to have = an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the recei= ver how that is then divided between 2 screens, if indeed it is.

Surely how I choose to break up a single view between multiple monitors is = up to the local side, the same as if I choose to make one big screen out of= a 4x4 matrix of smaller screens?

Or are you implying that the source actually needs to be 2 cameras to suppo= rt this?

Keith

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Roni Even
> Sent: 25 September 2011 17:44
> To: 'Stephen Botzko'
> Cc: clue@ietf.org
> Subject: Re: [clue] Support for information about the spacing between<= br>
> monitors.
>
> Steve,
> It is east to measure based on the local monitors using pixels since I=
> think
> that you can calibrate the captures using the local monitors.
> Roni
>
> > -----Original Message-----
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 5:20 PM
> > To: Roni Even
> > Cc: 'Duckworth, Mark'; c= lue@ietf.org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Ok. =A0So the signaling that is needed is the gap between capture= s, not
> > the gap between monitors.
> >
> > I don't think pixels is the right measure, since the relation= ship of
> > pixels to distance depends on resolution.
> >
> > Steve
> >
> > -----Original Message-----
> > From: Roni Even <Even.= roni@huawei.com>
> > Sent: Sunday, September 25, 2011 8:41 AM
> > To: 'Stephen Botzko' <stephen.botzko@gmail.com>
> > Cc: 'Duckworth, Mark' <Mark.Duckworth@polycom.com>; clue@ietf.org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Hi,
> >
> > What I mean is that the local capture is fixed based on the gap b= etween
> > the
> > local monitors such that a person that stands between two cameras= will
> > look
> > correct on the local two displays, There will be a missing part t= hat is
> > proportional =A0to the gap. This is based on the gaps between the= local
> > monitors.
> >
> > Now if the remote monitors will have the same gap (In pixels) the=
> > rendering
> > on the receiver will look the same as the local display, otherwis= e the
> > renderer will need to adjust.
> >
> >
> >
> > Roni
> >
> >
> >
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 4:21 AM
> >
> >
> > [The entire original message is not included]
>
> ________________________= _______________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

--20cf307cfbbc0add9f04add64af5-- From keith.drage@alcatel-lucent.com Mon Sep 26 04:22:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4411E21F84AC for ; Mon, 26 Sep 2011 04:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNKcIdKbJqgP for ; Mon, 26 Sep 2011 04:22:01 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1F21F84A5 for ; Mon, 26 Sep 2011 04:22:00 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8QBNWLS031185 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Sep 2011 13:24:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 26 Sep 2011 13:24:32 +0200 From: "DRAGE, Keith (Keith)" To: Stephen Botzko Date: Mon, 26 Sep 2011 13:24:30 +0200 Thread-Topic: [clue] Support for information about the spacing between monitors. Thread-Index: Acx8Pbs4IYvo1kxyTAaL3ZWCnbtj4QAAJe7A Message-ID: References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE220C81FE0FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "clue@ietf.org" Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 11:22:02 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE220C81FE0FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So I guess what I am now getting is that: The sender is sending a single view which happens to be made up from two ca= meras. So the sender is saying, I am sending you two video streams which yo= u can stitch together to make a single view. How the receiver then presents them, be it as a narrow slot on a single mon= itor, on two monitors that directly equate to video streams, or on more mon= itors is entirely up to the receiver. Keith ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: 26 September 2011 12:16 To: DRAGE, Keith (Keith) Cc: Roni Even; clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monit= ors. One reason Telepresence systems use multiple cameras because that is the mo= st cost-effective way to create a high resolution panorama. Creating and e= ncoding a 5760 x 1080 image is not that easy. It is much simpler to create= 3 1920x1080 images. This will only get worse when resolution increases to= 4K. Using multiple captures to create the panorama also has advantages when the= re are multiple receivers and senders. You often want to see a portion of = multiple rooms instead of just a single room. There are significant bandwi= dth issues if you are sending 2-4x more pixels than the receiver wants. One of the main reasons CLUE was formed was to enable such use of multiple = captures. Stephen Botzko On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith) > wrote: I guess there is something I'm not getting here. If the idea of the receiving side is to present a single continuous image o= f what is sent why is it not asking for a single view that happens to have = an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the recei= ver how that is then divided between 2 screens, if indeed it is. Surely how I choose to break up a single view between multiple monitors is = up to the local side, the same as if I choose to make one big screen out of= a 4x4 matrix of smaller screens? Or are you implying that the source actually needs to be 2 cameras to suppo= rt this? Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of > Roni Even > Sent: 25 September 2011 17:44 > To: 'Stephen Botzko' > Cc: clue@ietf.org > Subject: Re: [clue] Support for information about the spacing between > monitors. > > Steve, > It is east to measure based on the local monitors using pixels since I > think > that you can calibrate the captures using the local monitors. > Roni > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Sunday, September 25, 2011 5:20 PM > > To: Roni Even > > Cc: 'Duckworth, Mark'; clue@ietf.org > > Subject: RE: [clue] Support for information about the spacing between > > monitors. > > > > Ok. So the signaling that is needed is the gap between captures, not > > the gap between monitors. > > > > I don't think pixels is the right measure, since the relationship of > > pixels to distance depends on resolution. > > > > Steve > > > > -----Original Message----- > > From: Roni Even > > > Sent: Sunday, September 25, 2011 8:41 AM > > To: 'Stephen Botzko' > > > Cc: 'Duckworth, Mark' >; clue@ietf.org > > Subject: RE: [clue] Support for information about the spacing between > > monitors. > > > > Hi, > > > > What I mean is that the local capture is fixed based on the gap between > > the > > local monitors such that a person that stands between two cameras will > > look > > correct on the local two displays, There will be a missing part that is > > proportional to the gap. This is based on the gaps between the local > > monitors. > > > > Now if the remote monitors will have the same gap (In pixels) the > > rendering > > on the receiver will look the same as the local display, otherwise the > > renderer will need to adjust. > > > > > > > > Roni > > > > > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Sunday, September 25, 2011 4:21 AM > > > > > > [The entire original message is not included] > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --_000_EDC0A1AE77C57744B664A310A0B23AE220C81FE0FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So I guess what I am now getting is th= at:

 

The sender is sending a single view wh= ich happens to be made up from two cameras. So the sender is saying, I am sendi= ng you two video streams which you can stitch together to make a single view.<= o:p>

 

How the receiver then presents them, b= e it as a narrow slot on a single monitor, on two monitors that directly equate = to video streams, or on more monitors is entirely up to the receiver.

 

Keith

 

From:= Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: 26 September 2011 12:1= 6
To: DRAGE, Keith (Keith)
Cc: Roni Even; clue@ietf.org=
Subject: Re: [clue] Support = for information about the spacing between monitors.

 

One reason Telepr= esence systems use multiple cameras because that is the most cost-effective way to create a high resolution panorama.  Creating and encoding a 5760 x 108= 0 image is not that easy.  It is much simpler to create 3 1920x1080 imag= es.  This will only get worse when resolution increases to 4K.

Using multiple captures to create the panorama also has advantages when the= re are multiple receivers and senders.  You often want to see a portion o= f multiple rooms instead of just a single room.  There are significant bandwidth issues if you are sending 2-4x more pixels than the receiver want= s.

One of the main reasons CLUE was formed was to enable such use of multiple captures.

Stephen Botzko


On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.c= om> wrote:

I guess there is something I'm not getting here.

If the idea of the receiving side is to present a single continuous image o= f what is sent why is it not asking for a single view that happens to have an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the receiver= how that is then divided between 2 screens, if indeed it is.

Surely how I choose to break up a single view between multiple monitors is = up to the local side, the same as if I choose to make one big screen out of a = 4x4 matrix of smaller screens?

Or are you implying that the source actually needs to be 2 cameras to suppo= rt this?

Keith


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]= On Behalf Of
> Roni Even

> Sent: 25 September 2011 17:44
> To: 'Stephen Botzko'
> Cc: clue@ietf.org
> Subject: Re: [clue] Support for information about the spacing between<= o:p>

> monitors.
>
> Steve,
> It is east to measure based on the local monitors using pixels since I=
> think
> that you can calibrate the captures using the local monitors.
> Roni
>
> > -----Original Message-----
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 5:20 PM
> > To: Roni Even
> > Cc: 'Duckworth, Mark'; clue@ietf= .org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Ok.  So the signaling that is needed is the gap between captures, not
> > the gap between monitors.
> >
> > I don't think pixels is the right measure, since the relationship= of
> > pixels to distance depends on resolution.
> >
> > Steve
> >
> > -----Original Message-----
> > From: Roni Even <Even.= roni@huawei.com>
> > Sent: Sunday, September 25, 2011 8:41 AM
> > To: 'Stephen Botzko' <stephen.botzko@gmail.com>
> > Cc: 'Duckworth, Mark' <Mark.Duckworth@polycom.com>; clue@ietf.org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Hi,
> >
> > What I mean is that the local capture is fixed based on the gap between
> > the
> > local monitors such that a person that stands between two cameras will
> > look
> > correct on the local two displays, There will be a missing part t= hat is
> > proportional  to the gap. This is based on the gaps between = the local
> > monitors.
> >
> > Now if the remote monitors will have the same gap (In pixels) the=
> > rendering
> > on the receiver will look the same as the local display, otherwis= e the
> > renderer will need to adjust.
> >
> >
> >
> > Roni
> >
> >
> >
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 4:21 AM
> >
> >
> > [The entire original message is not included]
>

> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue<= /p>

 

--_000_EDC0A1AE77C57744B664A310A0B23AE220C81FE0FRMRSSXCHMBSC3d_-- From stephen.botzko@gmail.com Mon Sep 26 04:36:14 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3521F8C0F for ; Mon, 26 Sep 2011 04:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7mc+09NQaai for ; Mon, 26 Sep 2011 04:36:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2721F8C0D for ; Mon, 26 Sep 2011 04:36:13 -0700 (PDT) Received: by vws5 with SMTP id 5so6710803vws.31 for ; Mon, 26 Sep 2011 04:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wHi2qcw2CaIlR8tOy1WOKzIsdMzT9l2Oj4zsH7znZ6c=; b=hYGtQ5QHh0tmCkv2ozyHkwM8lNY5yXUGnT5cfE3yBOQ9M/V7rO5jm8cxsPVKkRj4ma AU5lNCCMyi72g5gDjWFIIPmk4nsXDaC5wYC7HW9L2XbyyFnVsIGlmj1wFKEreZw463yM Fz6xeJMi3ZrqRwxOgm+oaOqsndygo29nlS+Ug= MIME-Version: 1.0 Received: by 10.52.27.239 with SMTP id w15mr5767883vdg.333.1317037135666; Mon, 26 Sep 2011 04:38:55 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 26 Sep 2011 04:38:55 -0700 (PDT) In-Reply-To: References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <073b01cc7ba2$61ba00c0$252e0240$%roni@huawei.com> Date: Mon, 26 Sep 2011 07:38:55 -0400 Message-ID: From: Stephen Botzko To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf307c9bc0a09e5f04add69a66 Cc: "clue@ietf.org" Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 11:36:14 -0000 --20cf307c9bc0a09e5f04add69a66 Content-Type: text/plain; charset=ISO-8859-1 Yes, that is the basic idea. We are calling the "view" a "scene", which is made up of an arbitrary number of audio or video "captures". There is some support for enabling multiple scenes within the same room (showing different parts of the room). Note also that there are some applications for having multiple cameras aimed at the same area (giving a left image, straight on image, and right image of the same space). Steve B. On Mon, Sep 26, 2011 at 7:24 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > So I guess what I am now getting is that:**** > > ** ** > > The sender is sending a single view which happens to be made up from two > cameras. So the sender is saying, I am sending you two video streams which > you can stitch together to make a single view.**** > > ** ** > > How the receiver then presents them, be it as a narrow slot on a single > monitor, on two monitors that directly equate to video streams, or on more > monitors is entirely up to the receiver.**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* 26 September 2011 12:16 > *To:* DRAGE, Keith (Keith) > *Cc:* Roni Even; clue@ietf.org > > *Subject:* Re: [clue] Support for information about the spacing between > monitors. > **** > > ** ** > > One reason Telepresence systems use multiple cameras because that is the > most cost-effective way to create a high resolution panorama. Creating and > encoding a 5760 x 1080 image is not that easy. It is much simpler to create > 3 1920x1080 images. This will only get worse when resolution increases to > 4K. > > Using multiple captures to create the panorama also has advantages when > there are multiple receivers and senders. You often want to see a portion > of multiple rooms instead of just a single room. There are significant > bandwidth issues if you are sending 2-4x more pixels than the receiver > wants. > > One of the main reasons CLUE was formed was to enable such use of multiple > captures. > > Stephen Botzko > > > **** > > On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote:**** > > I guess there is something I'm not getting here. > > If the idea of the receiving side is to present a single continuous image > of what is sent why is it not asking for a single view that happens to have > an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the > receiver how that is then divided between 2 screens, if indeed it is. > > Surely how I choose to break up a single view between multiple monitors is > up to the local side, the same as if I choose to make one big screen out of > a 4x4 matrix of smaller screens? > > Or are you implying that the source actually needs to be 2 cameras to > support this? > > Keith**** > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Roni Even**** > > > Sent: 25 September 2011 17:44 > > To: 'Stephen Botzko' > > Cc: clue@ietf.org > > Subject: Re: [clue] Support for information about the spacing between*** > * > > > monitors. > > > > Steve, > > It is east to measure based on the local monitors using pixels since I > > think > > that you can calibrate the captures using the local monitors. > > Roni > > > > > -----Original Message----- > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Sunday, September 25, 2011 5:20 PM > > > To: Roni Even > > > Cc: 'Duckworth, Mark'; clue@ietf.org > > > Subject: RE: [clue] Support for information about the spacing between > > > monitors. > > > > > > Ok. So the signaling that is needed is the gap between captures, not > > > the gap between monitors. > > > > > > I don't think pixels is the right measure, since the relationship of > > > pixels to distance depends on resolution. > > > > > > Steve > > > > > > -----Original Message----- > > > From: Roni Even > > > Sent: Sunday, September 25, 2011 8:41 AM > > > To: 'Stephen Botzko' > > > Cc: 'Duckworth, Mark' ; clue@ietf.org > > > Subject: RE: [clue] Support for information about the spacing between > > > monitors. > > > > > > Hi, > > > > > > What I mean is that the local capture is fixed based on the gap between > > > the > > > local monitors such that a person that stands between two cameras will > > > look > > > correct on the local two displays, There will be a missing part that is > > > proportional to the gap. This is based on the gaps between the local > > > monitors. > > > > > > Now if the remote monitors will have the same gap (In pixels) the > > > rendering > > > on the receiver will look the same as the local display, otherwise the > > > renderer will need to adjust. > > > > > > > > > > > > Roni > > > > > > > > > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Sunday, September 25, 2011 4:21 AM > > > > > > > > > [The entire original message is not included] > >**** > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf307c9bc0a09e5f04add69a66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, that is the basic idea.=A0

We are calling the "view"= a "scene", which is made up of an arbitrary number of audio or v= ideo "captures".=A0 There is some support for enabling multiple s= cenes within the same room (showing different parts of the room).=A0

Note also that there are some applications for having multiple cameras = aimed at the same area (giving a left image, straight on image, and right i= mage of the same space).

Steve B.
On Mon, Sep 26, 2011 at 7:24 AM, DRAGE, Keith (Keith) <= ;keith.drage@alcatel-luce= nt.com> wrote:

So I guess what I = am now getting is that:

=A0<= /span>

The sender is send= ing a single view which happens to be made up from two cameras. So the sender is saying, I am sendi= ng you two video streams which you can stitch together to make a single view.<= u>

=A0<= /span>

How the receiver t= hen presents them, be it as a narrow slot on a single monitor, on two monitors that directly equate = to video streams, or on more monitors is entirely up to the receiver.<= /span>

=A0<= /span>

Keith

=A0<= /span>

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: 26 September 2011 12:1= 6
To: DRAGE, Keith (Keith)
Cc: Roni Even; clue@ietf.org


Subject: Re: [clue] Support = for information about the spacing between monitors.

=A0

One reason Telepresen= ce systems use multiple cameras because that is the most cost-effective way to create a high resolution panorama.=A0 Creating and encoding a 5760 x 1080 image is not that easy.=A0 It is much simpler to create 3 1920x1080 images.= =A0 This will only get worse when resolution increases to 4K.

Using multiple captures to create the panorama also has advantages when the= re are multiple receivers and senders.=A0 You often want to see a portion of multiple rooms instead of just a single room.=A0 There are significant bandwidth issues if you are sending 2-4x more pixels than the receiver want= s.

One of the main reasons CLUE was formed was to enable such use of multiple captures.

Stephen Botzko


On Mon, Sep 26, 2011 at 6:55 AM, DRAGE, Keith (Keith= ) <k= eith.drage@alcatel-lucent.com> wrote:

I guess there is something I'm not getting here.=

If the idea of the receiving side is to present a single continuous image o= f what is sent why is it not asking for a single view that happens to have an aspect ratio of 32x9 rather that 16x9. Surely it is then up to the receiver= how that is then divided between 2 screens, if indeed it is.

Surely how I choose to break up a single view between multiple monitors is = up to the local side, the same as if I choose to make one big screen out of a = 4x4 matrix of smaller screens?

Or are you implying that the source actually needs to be 2 cameras to suppo= rt this?

Keith


> -----Original Message-----
> From: clue-= bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of
> Roni Even

> Sent: 25 September 2011 17:44
> To: 'Stephen Botzko'
> Cc: clue@ietf.org
> Subject: Re: [clue] Support for information about the spacing between<= u>

> monitors.
>
> Steve,
> It is east to measure based on the local monitors using pixels since I=
> think
> that you can calibrate the captures using the local monitors.
> Roni
>
> > -----Original Message-----
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 5:20 PM
> > To: Roni Even
> > Cc: 'Duckworth, Mark'; clue@ietf.org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Ok. =A0So the signaling that is needed is the gap between captures, not
> > the gap between monitors.
> >
> > I don't think pixels is the right measure, since the relation= ship of
> > pixels to distance depends on resolution.
> >
> > Steve
> >
> > -----Original Message-----
> > From: Roni Even <Even.roni@huawei.com>
> > Sent: Sunday, September 25, 2011 8:41 AM
> > To: 'Stephen Botzko' <stephen.botzko@gmail.com>
> > Cc: 'Duckworth, Mark' <Mark.Duckworth@polycom.com>; clue@ietf.org
> > Subject: RE: [clue] Support for information about the spacing bet= ween
> > monitors.
> >
> > Hi,
> >
> > What I mean is that the local capture is fixed based on the gap between
> > the
> > local monitors such that a person that stands between two cameras will
> > look
> > correct on the local two displays, There will be a missing part t= hat is
> > proportional =A0to the gap. This is based on the gaps between the local
> > monitors.
> >
> > Now if the remote monitors will have the same gap (In pixels) the=
> > rendering
> > on the receiver will look the same as the local display, otherwis= e the
> > renderer will need to adjust.
> >
> >
> >
> > Roni
> >
> >
> >
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Sunday, September 25, 2011 4:21 AM
> >
> >
> > [The entire original message is not included]
>

> _______________________________________________=
> clue mailing list
> clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue

=A0


--20cf307c9bc0a09e5f04add69a66-- From mary.ietf.barnes@gmail.com Tue Sep 27 16:05:49 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE721F8EF8 for ; Tue, 27 Sep 2011 16:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpIZTZzBuuBF for ; Tue, 27 Sep 2011 16:05:48 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C23A821F8EDB for ; Tue, 27 Sep 2011 16:05:47 -0700 (PDT) Received: by yic13 with SMTP id 13so6898702yic.31 for ; Tue, 27 Sep 2011 16:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HbJ5si1fUCEJJHjIpWYphPFJG5iKNNXoRcu3DoeaO6E=; b=lRby6LULrcyB7iu8/PtRPVoZQSgz/AztGrQdY2m8G7KvucXMnwqIm/O27JE56P3jDk oUHx3UKPHPd8RA2QpcztJGNut06AhwTY6iw+ZrDHh870v7G3xTe9Dtj+nH4H2w4Ah9S2 dYWmBdIDPH6AV9YXBoC328+GxStEzyiLIuvOo= MIME-Version: 1.0 Received: by 10.236.156.67 with SMTP id l43mr33893317yhk.10.1317164914265; Tue, 27 Sep 2011 16:08:34 -0700 (PDT) Received: by 10.236.108.178 with HTTP; Tue, 27 Sep 2011 16:08:34 -0700 (PDT) Date: Tue, 27 Sep 2011 18:08:34 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf303f67f8d34d8004adf45a58 Subject: [clue] CLUE WG Interim Meeting, Oct. 11-12th, 2011 (includes Webex info) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 23:05:49 -0000 --20cf303f67f8d34d8004adf45a58 Content-Type: text/plain; charset=ISO-8859-1 Hi all, As previously posted, the CLUE WG has scheduled an interim meeting for Oct. 11th-12th, 2011 (1.5 days). The f2f meeting will be held at the Polycom facility located at 100 Minuteman Road, Andover, Massachusetts. The Webex details for remote participation are below. The proposed agenda is as follows. Note, that the authors plan to have an updated framework document submitted by the end of this week (Sept. 30th) to allow enough time for review of the document before the meeting. Anyone else that would like agenda time, please contact the chairs no later than Sept. 30th, 2011. Oct. 11th, 2011 -------------------- 9:00-9:10 Chair - status, agenda bash 9:10-09:50 Discussion of any remaining open issues for the use cases and requirements 09:50-10:00 Short coffee break 10:00-11:30 Proposed framework discussion 11:30-13:00 Lunch 13:30-15:00 Proposed framework discussion 15:00-15:20 Break 15:20-17:00 CLUE and RTCWEB 17:00-18:00 Summary and identification of key items for discussion on Tuesday Oct. 12th, 2011 (note this agenda will be finalized based on the outcome of Tuesday's meeting) --------------------------- 08:30-08:45 Plans for the day 08:45-10:30 Discussion 10:30-10:45 Break 10:45-12:30 Discussion 12:30-13:00 Discussion of way forward and summary of action items Webex: ======== Topic: CLUE WG Interim Meeting Date: Every 1 day, from Tuesday, October 11, 2011 to Wednesday, October 12, 2011 Time: 8:30 am, Eastern Daylight Time (New York, GMT-04:00) Meeting Number: 969 145 615 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&RT=MiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&ORT=MiMxMQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=182521792&tollFree=0 Access code:969 145 615 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&ICS=MRS1&LD=1&RD=2&ST=1&SHA2=xBjAAyKlGU5WtZwaNwAEZK1vCvOPzxE9heViyuR6muc=&RT=MiMxMQ%3D%3D WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x969145615# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. **** --20cf303f67f8d34d8004adf45a58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,


<= /p>

As previously posted, the CLUE WG has scheduled an interim meeting for Oct.= 11th-12th, 2011 (1.5 days). =A0 The f2f meeting will be held at the Polyco= m facility located at =A0100 =A0Minuteman Road, Andover, Massachusetts. =A0= The Webex details for remote participation are below. =A0


The proposed agenda is as follows. = Note, that the authors plan to have an updated framework document submitted= by the end of this week (Sept. 30th) to allow enough time for review of th= e document before the meeting. =A0Anyone else that would like agenda time, = please contact the chairs no later than Sept. 30th, 2011.=A0


Oct. 11th, 2011
-------------= -------
9:00-9:10 Chair - status, agenda bash
9:10-09:50 Di= scussion of any remaining open issues for the use cases and requirements
09:50-10:00 S= hort coffee break
10:00-11:30 Proposed framework discussion
11:30-13:00 L= unch=A0
13:30-15:00 =A0=A0Proposed framework discussion=
15:00-15:20 = =A0Break
15:20-17:00 =A0CLUE and RTCWEB=A0
17:00-18:00 = =A0Summary and identification of key items for discussion on Tuesday=

Oc= t. 12th, 2011 (note this agenda will be finalized based on the outcome of T= uesday's meeting)
-------------= --------------
08:30-08:45 =A0Plans for the day
08:45-10:30 = =A0Discussion
10:30-10:45 =A0Break
10:45-12:30 = =A0Discussion
12:30-13:00 =A0Discussion of way forward and summary of= action items



Webex:

=3D=3D=3D=3D= =3D=3D=3D=3D


Topic: CLUE WG Interim Meeting
Date: Every= 1 day, from Tuesday, October 11, 2011 to Wednesday, October 12, 2011
T= ime: 8:30 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 969 145 615
Meeting Password: (This meeting does not re= quire a password.)


--------------------------------------------= -----------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.= com/workgreen/j.php?ED=3D182521792&UID=3D1251996147&RT=3DMiMxMQ%3D%= 3D
2. If requested, enter your name and email address.
3. If a password is= required, enter the meeting password: (This meeting does not require a pas= sword.)
4. Click "Join".

To view in other time zones = or languages, please click the link:
https://workgreen= .webex.com/workgreen/j.php?ED=3D182521792&UID=3D1251996147&ORT=3DMi= MxMQ%3D%3D

-------------------------------------------------------
To join the= audio conference only
------------------------------------------------= -------
To receive a call back, provide your phone number when you join= the meeting, or call the number below and enter the access code.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers= : https://wo= rkgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D1825= 21792&tollFree=3D0

Access code:969 145 615

---------------------------------------= ----------------
For assistance
-----------------------------------= --------------------
1. Go to https://workgreen.webex.com/workgreen/mc =
2. On the left navigation bar, click "Support".

You can c= ontact me at:
cmo= rgan@amsl.com
1-510-492-4085

To update this meeting to your calendar program (for example Microsoft = Outlook), click this link:
https://workgreen.webex.com/wo= rkgreen/j.php?ED=3D182521792&UID=3D1251996147&ICS=3DMRS1&LD=3D1= &RD=3D2&ST=3D1&SHA2=3DxBjAAyKlGU5WtZwaNwAEZK1vCvOPzxE9heViyuR6m= uc=3D&RT=3DMiMxMQ%3D%3D


WebEx will automatically setup Meeting Manager for Windows the firs= t time you join a meeting. To save time, you can setup prior to the meeting= by clicking this link:
https://workgreen.webex.com/= workgreen/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media fi= les requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your co= mputer by going to https://workgreen.webex.com/workgreen/syste= mdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.web= ex.com

CCP:+14087926300x969145615#

IMPORTANT NOTICE: This WebEx servic= e includes a feature that allows audio and any documents and other material= s exchanged or viewed during the session to be recorded. By joining this se= ssion, you automatically consent to such recordings. If you do not consent = to the recording, discuss your concerns with the meeting host prior to the = start of the recording or do not join the session. Please note that any suc= h recordings may be subject to discovery in the event of litigation.


--20cf303f67f8d34d8004adf45a58-- From Christian.Groves@nteczone.com Wed Sep 28 22:31:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2549821F8B6C for ; Wed, 28 Sep 2011 22:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLIfKhANx8Q2 for ; Wed, 28 Sep 2011 22:31:27 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2B28B21F8B6B for ; Wed, 28 Sep 2011 22:31:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYAAOj/g0520Ydr/2dsb2JhbAAMNZkKkUgBAQEBAwEBAS8BBRsbBAYRCxEEAQEBCRYIBwkDAgECARUfERMGAgEBh3q4BgOHDASlIQ Received: from ppp118-209-135-107.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.135.107]) by ipmail06.adl6.internode.on.net with ESMTP; 29 Sep 2011 15:04:14 +0930 Message-ID: <4E840350.6060907@nteczone.com> Date: Thu, 29 Sep 2011 15:34:08 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: clue@ietf.org References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com> <007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 05:31:28 -0000 Hello Allyn, Do you have an ETA on the framework draft update? It would be nice to get this in advance of the WG interim meeting so people can prepare inputs based on the latest information that people can also review before the meeting. Thanks, Christian On 19/09/2011 9:57 AM, Allyn Romanow (allyn) wrote: > > Hi Roni, > > The text in the draft hasn’t been updated yet, so you might find small > discrepancies with any slide deck which is more recent than the draft. > The more recent document is the one to be considered. We are due to > have a new draft before the interim meeting. > > It is meant for each capture set to be an aggregation of the media > captures describing a capture scene. Each capture set describes a > scene which is non-overlapping, not redundant, unique, with respect to > other capture sets. > > I’m sorry I couldn’t parse your last remark due to some typos. > > Regards, > > Allyn > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Wednesday, September 14, 2011 7:41 AM > *To:* Brian Baldino (bbaldino); clue@ietf.org > *Subject:* Re: [clue] Qusetion on Captyre Scene and Capture set > > Hi Brian, > > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > capture sets in slide 2. I think that the relation between the capture > scene and capture set is not clear. Looking at section 9 of the > framework draft I can see two capture sets (#1 and #2) and it says > that the receiver picks a row from each capture set. So is this one > capture scene or two. The text talk about sending capture sets but not > capture scenes and there is no drawing that include both. > > As for the presentation, a row in a capture set can include multiple > media captures that has implied spatial relation, so if you put the > presentation in a row with three other video captures how is it > spatially related. Can you put the presentation in any position in the > row. > > I als o unders n cannot be in a separate row in a capture set since > the selection is one row from a capture set. This leads me to think > that there can be more than one capture set or more than one scene if > we define the hierarchal relation between the tw. > > Regards > > Roni > > *From:*Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > *Sent:* Wednesday, September 14, 2011 4:53 PM > *To:* Roni Even; clue@ietf.org > *Subject:* RE: [clue] Qusetion on Captyre Scene a nd Captu /p> > > A capture has a ‘role’ attribute that describes it as presentation or > participant video, so for the current cases we’ve seen that as > sufficient (instead of putting a similar attribute on the entire > capture set). > > A capture set describes a single capture scene, so you couldn’t have > multiple capture sets describing the same ‘scene’, but I’d say how a > device decides to split up captures amongst scenes is somewhat up to > them. Splitting up presentation and participant captures into two > separate scenes seems to make sense as there’s no spatial relationship > between the two sets of receive side, I don’t think a receiver would > choose only a single capture scene to view, I think it would choose > captures from each capture set. > > -Brian > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Wednesday, September 14, 2011 5:58 AM > *To:* clue@ietf.org > *Subject:* [clue] Qusetion on Captyre Scene and Cap > > > Hi, > > In the last Interim meeting presentation on Capture sets > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the comments > that "There could be multiple capture scenes - For example another > scene for a presentation." > > In the next slide I saw "There can be multiple capture sets, such as > one for people and one for a presentation". > > Is there going to be a description for the capture scene that will > specify what is the capture scene of? > > As for capture sets do you see the presentation and people capture set > in the same scene or are they in a separate scenes, how do you decide > which one to use? > > Thanks > > Roni Even > > < oNormal> > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Fri Sep 30 10:37:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9549721F8BDE for ; Fri, 30 Sep 2011 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD98N7TrGq+N for ; Fri, 30 Sep 2011 10:37:42 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3821F8BCD for ; Fri, 30 Sep 2011 10:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=5150; q=dns/txt; s=iport; t=1317404437; x=1318614037; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ytgzJokXThwZkzjWavdRwso5DKBT23KzM9YESh51VZU=; b=C1xBm64SBPZZrHvzLRs3UfcX+TeTTPi1nkr68WKsqDz4fCgrNbs/CGNS SEzjo+abkJlvwOuhGNsbyXlnpSxREDFGI6o+elbrDQHwWBkctXq3K/YEP S7CXL7UpHICRCgAtc3XrlD55g+pfrAQmygBEW05REM2IoEOLu8ajokv59 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAOH9hU6rRDoH/2dsb2JhbABBmSGPEYEFgVMBAQEDAQEBAQ8BHQo0BBMEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodZBpl7AZ4TA4Y/YQSHdpEUjC8 X-IronPort-AV: E=Sophos;i="4.68,468,1312156800"; d="scan'208";a="5265793" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 30 Sep 2011 17:40:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8UHeZq0017362; Fri, 30 Sep 2011 17:40:35 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 10:40:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Sep 2011 10:40:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DBD2@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4E840350.6060907@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Qusetion on Captyre Scene and Capture set Thread-Index: Acx+aXIgxFCY68OXR4ac9KNkDP2jbwBLobcg References: <000901cc72dd$e742b7f0$b5c827d0$%roni@huawei.com><007e01cc72ec$4873f8f0$d95bead0$%roni@huawei.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC059E9940@xmb-sjc-221.amer.cisco.com> <4E840350.6060907@nteczone.com> From: "Allyn Romanow (allyn)" To: "Christian Groves" , X-OriginalArrivalTime: 30 Sep 2011 17:40:35.0453 (UTC) FILETIME=[0F404AD0:01CC7F98] Subject: Re: [clue] Qusetion on Captyre Scene and Capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 17:37:43 -0000 Hi Christian, =20 Yes, we're planning on making it available by Monday if not sooner. Best regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, September 28, 2011 10:34 PM > To: clue@ietf.org > Subject: Re: [clue] Qusetion on Captyre Scene and Capture set >=20 > Hello Allyn, >=20 > Do you have an ETA on the framework draft update? It would be nice to > get this in advance of the WG interim meeting so people can prepare > inputs based on the latest information that people can also review > before the meeting. >=20 > Thanks, Christian >=20 > On 19/09/2011 9:57 AM, Allyn Romanow (allyn) wrote: > > > > Hi Roni, > > > > The text in the draft hasn't been updated yet, so you might find > small > > discrepancies with any slide deck which is more recent than the > draft. > > The more recent document is the one to be considered. We are due to > > have a new draft before the interim meeting. > > > > It is meant for each capture set to be an aggregation of the media > > captures describing a capture scene. Each capture set describes a > > scene which is non-overlapping, not redundant, unique, with respect > to > > other capture sets. > > > > I'm sorry I couldn't parse your last remark due to some typos. > > > > Regards, > > > > Allyn > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Roni Even > > *Sent:* Wednesday, September 14, 2011 7:41 AM > > *To:* Brian Baldino (bbaldino); clue@ietf.org > > *Subject:* Re: [clue] Qusetion on Captyre Scene and Capture set > > > > Hi Brian, > > > > Looking at 3-CLUE_media_captures_for_Aug_interim.pptx I see multiple > > capture sets in slide 2. I think that the relation between the > capture > > scene and capture set is not clear. Looking at section 9 of the > > framework draft I can see two capture sets (#1 and #2) and it says > > that the receiver picks a row from each capture set. So is this one > > capture scene or two. The text talk about sending capture sets but > not > > capture scenes and there is no drawing that include both. > > > > As for the presentation, a row in a capture set can include multiple > > media captures that has implied spatial relation, so if you put the > > presentation in a row with three other video captures how is it > > spatially related. Can you put the presentation in any position in > the > > row. > > > > I als o unders n cannot be in a separate row in a capture set since > > the selection is one row from a capture set. This leads me to think > > that there can be more than one capture set or more than one scene if > > we define the hierarchal relation between the tw. > > > > Regards > > > > Roni > > > > *From:*Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > > *Sent:* Wednesday, September 14, 2011 4:53 PM > > *To:* Roni Even; clue@ietf.org > > *Subject:* RE: [clue] Qusetion on Captyre Scene a nd Captu /p> > > > > A capture has a 'role' attribute that describes it as presentation or > > participant video, so for the current cases we've seen that as > > sufficient (instead of putting a similar attribute on the entire > > capture set). > > > > A capture set describes a single capture scene, so you couldn't have > > multiple capture sets describing the same 'scene', but I'd say how a > > device decides to split up captures amongst scenes is somewhat up to > > them. Splitting up presentation and participant captures into two > > separate scenes seems to make sense as there's no spatial > relationship > > between the two sets of receive side, I don't think a receiver would > > choose only a single capture scene to view, I think it would choose > > captures from each capture set. > > > > -Brian > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Roni Even > > *Sent:* Wednesday, September 14, 2011 5:58 AM > > *To:* clue@ietf.org > > *Subject:* [clue] Qusetion on Captyre Scene and Cap > > > > > Hi, > > > > In the last Interim meeting presentation on Capture sets > > (3-CLUE_media_captures_for_Aug_interim.pptx) I noticed in the > comments > > that "There could be multiple capture scenes - For example another > > scene for a presentation." > > > > In the next slide I saw "There can be multiple capture sets, such as > > one for people and one for a presentation". > > > > Is there going to be a description for the capture scene that will > > specify what is the capture scene of? > > > > As for capture sets do you see the presentation and people capture > set > > in the same scene or are they in a separate scenes, how do you decide > > which one to use? > > > > Thanks > > > > Roni Even > > > > < oNormal> > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Sep 30 17:12:11 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0621F8515 for ; Fri, 30 Sep 2011 17:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.473 X-Spam-Level: X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSvWHjCOvImO for ; Fri, 30 Sep 2011 17:12:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D73221F8514 for ; Fri, 30 Sep 2011 17:12:09 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2512539vcb.31 for ; Fri, 30 Sep 2011 17:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LNc+9qXpPZ/6iuFzPo4QVGjOzMw27MgM9s6uDEn+LH8=; b=RnrSbapwQKb4u2F2EKa5L4LQ81N2JIEeIC6xAnnoDG+DUtuW6qrB9U5UNzB3bykRy8 XyzVGCBBipC3iRnr9ZonEyIE0KaVr0DV/JqzFMG8hV1r4nLiZEDd4y8+u+ok+4On1Rld rUxOe88/rHpttdHFcACmsDPyyR/jmnS761ELw= MIME-Version: 1.0 Received: by 10.52.66.15 with SMTP id b15mr11569319vdt.425.1317428103404; Fri, 30 Sep 2011 17:15:03 -0700 (PDT) Received: by 10.52.173.201 with HTTP; Fri, 30 Sep 2011 17:15:03 -0700 (PDT) Date: Fri, 30 Sep 2011 19:15:03 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3071c8ae1eda9e04ae31a20a Subject: [clue] Oct 11-12, 2011 Interim Meeting details X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 00:12:11 -0000 --20cf3071c8ae1eda9e04ae31a20a Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I have updated the CLUE WG wiki with all the details for the meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki There is a map for the facility as well as a file with travel logistics (i.e., transport from airport and hotels). Regards, Mary. --20cf3071c8ae1eda9e04ae31a20a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I have updated the CLUE WG wiki with all the d= etails for the meeting:

There is a map for the facility as well as a file with trave= l logistics (i.e., transport from airport and hotels).

=
Regards,
Mary.=A0


--20cf3071c8ae1eda9e04ae31a20a--