CLUE WG co-chair --20cf307d05a68bfed404a9782cdd-- From Mark.Duckworth@polycom.com Fri Aug 5 14:02:10 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 D790811E80C3 for ; Fri, 5 Aug 2011 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvNVaZFISqAu for ; Fri, 5 Aug 2011 14:02:10 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60C11E80B2 for ; Fri, 5 Aug 2011 14:02:07 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 5 Aug 2011 14:02:22 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 5 Aug 2011 14:02:19 -0700 Thread-Topic: continuing "layout" discussion Thread-Index: AcxTsvb4KcK1pqKFRU6tEtH2M99T7g== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.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 Subject: [clue] continuing "layout" discussion 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, 05 Aug 2011 21:02:11 -0000 I'd like to continue the discussion about layout and rendering issues. The= re are many separate but related things involved. I want to break it down = into separate topics, and see how the topics are related to each other. An= d then we can discuss what CLUE needs to deal with and what is not in scope= . I don't know if I'm using the best terms for each topic. If not, please su= ggest better terms. My use of the term "layout" here is not consistent wit= h draft-wenger-clue-definitions-01, because I don't limit it to the renderi= ng side. But my use of the terms "render" and "source selction" is consist= ent with that draft. 1- video layout composed arrangement within a stream - when multiple video = sources are composed into one stream, they are arranged in some way. Typic= al examples are 2x2 grid, 3x3 grid, 1+5 (1 large plus 5 small), 1+PiP (1 la= rge plus one or more picture-in-picture). These arrangements can be select= ed automatically or based on user input. Arrangements can change over time= . Identifying this composed arrangement is separate from identifying or se= lecting which video images are used to fill in the composition. These arra= ngements can be constructed by an endpoint sending video, by an MCU, or by = an endpoint receiving video as it renders to a display. 2 - source selection and identification - when a device is composing a stre= am made up of other sources, it needs some way to choose which sources to u= se, and some way of choosing how to combine them or where to place video im= ages in the composed arrangement. Various automatic algorithms may be used= , or selections can be made based on user input. Selections can change ove= r time. One example is "select the two most recent talkers". It may also = be desirable to identify which sources are used and where they are placed, = for example so the receiving side can use this information in the user inte= rface. Source selection can be done by an endpoint as it sends media, by a= n MUC, or by an endpoint receiving media. 3 - spatial relation among streams - how multiple streams are related to ea= ch other spatially, to be rendered such that the spatial arrangement is con= sistent. The examples we've been using have multiple video streams that ar= e related in an ordered row from left to right. Audio is also included whe= n it is desirable to match spatial audio to video. 4 - multi stream media format - what the streams mean with respect to each = other, regardless of the actual content on the streams. For audio, example= s are stereo, 5.1 surround, binaural, linear array. (linear array is descr= ibed in the clue framework document). Perhaps 3D video formats would also = fit in this category. This information is needed in order to properly rend= er the media into light and sound for human observers. I see this at the s= ame level as identifying a codec, independent of the audio or video content= carried on the streams, and independent of how any composition of sources = is done. I think there is general agreement that items 3 and 4 are in scope for CLUE= , as they specifically deal with multiple streams to and from an endpoint. = And the framework draft includes these. Items 1 and 2 are not new, those = topics exist for traditional single stream videoconferencing. I'm not sure= what aspects of 1 and 2 should be in scope for CLUE. It is hard to tell f= rom the use cases and requirements. The framework draft includes them only= to a very limited extent. Mark Duckworth From stephane.cazeaux@orange-ftgroup.com Mon Aug 8 08:57:32 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 4F61121F8B0E for ; Mon, 8 Aug 2011 08:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 RWNHS7Ur+kyR for ; Mon, 8 Aug 2011 08:57:31 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2121F85A0 for ; Mon, 8 Aug 2011 08:57:30 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 36092FC4011; Mon, 8 Aug 2011 17:57:53 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 17112FC400E; Mon, 8 Aug 2011 17:57:53 +0200 (CEST) Received: from FTRDCH02.rd.francetelecom.fr ([10.194.32.13]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 17:56:50 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Mon, 8 Aug 2011 17:56:49 +0200 From: To: Thread-Topic: [clue] Comment on the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7g Date: Mon, 8 Aug 2011 15:56:48 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> In-Reply-To: <4E314AD3.1030406@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2011 15:56:50.0337 (UTC) FILETIME=[C8E63910:01CC55E3] Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case 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, 08 Aug 2011 15:57:32 -0000 Hi, To me, it should be part of the telepresence protocols at least to enable t= he interoperability, as the presentation based on video stream allows it.=20 The point is that video stream is not convenient for the use cases I sugges= ted. But it does not necessarily mean that we should bundle a full data sha= ring protocol with telepresence. Something simpler, like the RFB option of = draft-garcia-mmusic-sdp-collaboration, could be a candidate. Stephane. -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de P= aul Kyzivat Envoy=E9=A0: jeudi 28 juillet 2011 13:41 =C0=A0: CHATRAS Bruno RD-CORE-ISS Cc=A0: clue@ietf.org Objet=A0: Re: [clue] Comment on the presentation use case On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > I think we should take a look to > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 Maybe. But that is almost orthogonal to what I was suggesting. THanks, Paul (as individual) > Bruno > >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >> Paul Kyzivat >> Envoy=E9 : jeudi 28 juillet 2011 06:05 >> =C0 : Roni Even >> Cc : clue@ietf.org >> Objet : Re: [clue] Comment on the presentation use case >> >> On 7/27/11 11:28 PM, Roni Even wrote: >>> Hi, >>> HTTP is not defining a common data sharing protocol. WebEx may be >> carried >>> over HTTP but the data sharing application is not standard. What I >> meant is >>> that it can either be something that is a common data sharing >> protocol or >>> something that is carried as an RTP payload which require some common >>> defined protocol on top. >> >> I was being a bit tongue in cheek, though not entirely. >> Of course you are right - that if you want to push data to everybody >> you >> need more. >> >> But data sharing by pointing a video camera at a piece of paper is a >> tad >> out of date. Connecting the video port on a user's computer as a video >> source and distributing it with the other video is better than that. >> But >> its not nearly as convenient as webex or any of its competitors. >> >> It isn't entirely clear that its *necessary* to bundle the data sharing >> application with the telepresence protocols. Its kind of limiting since >> the web apps evolve very rapidly. Perhaps we should be doing the >> opposite of that: providing a way to embed the control of the >> telepresence system into a web app. >> >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>>> Paul Kyzivat >>>> Sent: Thursday, July 28, 2011 1:29 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Comment on the presentation use case >>>> >>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>> Hi Stephane, >>>>> >>>>> Is there a standard protocol that is used for conveying this >>>>> information, is it RTP based. >>>> >>>> AFAIK this is often http. (E.g. webex) >>>> >>>>> To me this is a separate application that can be integrated in the >>>>> application level and not as part of the multistream. >>>> >>>> I guess this depends on whether the support for it is integrated >> into >>>> the "room", or is just incidental equipment brought by the users, >> not >>>> formally related to the telepresence session. >>>> >>>> Thanks, >>>> Paul >>>> (speaking as an individual) >>>> >>>>> Roni >>>>> >>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>> *stephane.cazeaux@orange-ftgroup.com >>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>> *To:* clue@ietf.org >>>>> *Subject:* [clue] Comment on the presentation use case* >>>>> >>>>> ** >>>>> >>>>> *Hi,* >>>>> >>>>> ** >>>>> >>>>> *The presentation use case as described in the use-cases document >> is >>>>> based on the assumption that the presentation stream relies on a >>>> video >>>>> stream, and is limited to usage of presentation video streams. But >> we >>>>> could also consider collaborative use cases, meaningful for >>>>> telepresence, which are not covered by the existing text.* >>>>> >>>>> *I propose to complete the existing text as follows:* >>>>> >>>>> ** >>>>> >>>>> *Furthermore, although most today's systems use video streams for >>>>> presentations, there are use cases where this is not suitable. For >>>> example:* >>>>> >>>>> *- The professor which shares an electronic whiteboard (could be a >>>>> whiteboard application on a PC, with screen capture of the PC) >> where >>>> all >>>>> students can participate. Students will take control of the shared >>>>> whiteboard in turns.* >>>>> >>>>> *- In a multipoint meeting, a shared document can be kept always >>>> visible >>>>> in a screen, while other documents are presented on other screens >>>> (with >>>>> possible in turns presentation). For instance, for the purpose of >>>> shared >>>>> design document, notes taking, polls, etc. A shared document >> implies >>>>> that all participants can modify it in turns.* >>>>> >>>>> *"* >>>>> >>>>> ** >>>>> >>>>> ** >>>>> >>>>> *St ephane. v> >>>>> * >>>>> >>>>> * >>>>> * >>>>> >>>>> *_______________________________________________ >>>>> 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 From pkyzivat@alum.mit.edu Mon Aug 8 12:22:20 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 5846C21F8A51 for ; Mon, 8 Aug 2011 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 M55fa9ql9USA for ; Mon, 8 Aug 2011 12:22:19 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 442CA21F8876 for ; Mon, 8 Aug 2011 12:22:19 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id HvCy1h00B1swQuc53vNmjC; Mon, 08 Aug 2011 19:22:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id HvNk1h00r0tdiYw3bvNlTF; Mon, 08 Aug 2011 19:22:46 +0000 Message-ID: <4E403783.70706@alum.mit.edu> Date: Mon, 08 Aug 2011 15:22:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: stephane.cazeaux@orange-ftgroup.com References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case 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, 08 Aug 2011 19:22:20 -0000 On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > Hi, > > To me, it should be part of the telepresence protocols at least to enable the interoperability, as the presentation based on video stream allows it. > > The point is that video stream is not convenient for the use cases I suggested. But it does not necessarily mean that we should bundle a full data sharing protocol with telepresence. Something simpler, like the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a candidate. What I was suggesting is that maybe it would make sense to turn those relationships "inside out". For instance when I use a collaboration tool like Webex, the collaboration is set up first via the web, and defines the set of participants. Then a voice session can be added. For pragmatic reasons, the voice conferencing seems to be pretty distinct. (I'm not certain how webex handles video. I suspect it is doing it via the web, not the telephony conference.) Its not hard to imagine the same sort of setup, but with a multiparty telepresence session instead of the traditional voice conference. In such a case, you would probably want the collaboration tool (webex, or whatever) to mediate the UI for the web collaboration, the roster, etc. It might delegate a lot of that to the telepresence infrastructure. But that does raise some questions about how all the components fit together. Is there a single screen for the collaboration session in a telepresence room? What about input to that - keyboard, mouse, etc.? Or do we assume that each person in the room has their own computer with input, display, etc. and maybe a way to slave the web collaboration session to one or more of the big displays in the room? What probably *can't* be done right now is nail down a particular web collaboration service (e.g. Webex) or protocol. That does complicate slaving the collaboration session to a screen, unless its done by having someone connect a video connection to their own computer. Thanks, Paul > Stephane. > > > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Paul Kyzivat > Envoy� : jeudi 28 juillet 2011 13:41 > � : CHATRAS Bruno RD-CORE-ISS > Cc : clue@ietf.org > Objet : Re: [clue] Comment on the presentation use case > > On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: >> I think we should take a look to >> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 > > Maybe. But that is almost orthogonal to what I was suggesting. > > THanks, > Paul > (as individual) > >> Bruno >> >>> -----Message d'origine----- >>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >>> Paul Kyzivat >>> Envoy� : jeudi 28 juillet 2011 06:05 >>> � : Roni Even >>> Cc : clue@ietf.org >>> Objet : Re: [clue] Comment on the presentation use case >>> >>> On 7/27/11 11:28 PM, Roni Even wrote: >>>> Hi, >>>> HTTP is not defining a common data sharing protocol. WebEx may be >>> carried >>>> over HTTP but the data sharing application is not standard. What I >>> meant is >>>> that it can either be something that is a common data sharing >>> protocol or >>>> something that is carried as an RTP payload which require some common >>>> defined protocol on top. >>> >>> I was being a bit tongue in cheek, though not entirely. >>> Of course you are right - that if you want to push data to everybody >>> you >>> need more. >>> >>> But data sharing by pointing a video camera at a piece of paper is a >>> tad >>> out of date. Connecting the video port on a user's computer as a video >>> source and distributing it with the other video is better than that. >>> But >>> its not nearly as convenient as webex or any of its competitors. >>> >>> It isn't entirely clear that its *necessary* to bundle the data sharing >>> application with the telepresence protocols. Its kind of limiting since >>> the web apps evolve very rapidly. Perhaps we should be doing the >>> opposite of that: providing a way to embed the control of the >>> telepresence system into a web app. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Thursday, July 28, 2011 1:29 AM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Comment on the presentation use case >>>>> >>>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>>> Hi Stephane, >>>>>> >>>>>> Is there a standard protocol that is used for conveying this >>>>>> information, is it RTP based. >>>>> >>>>> AFAIK this is often http. (E.g. webex) >>>>> >>>>>> To me this is a separate application that can be integrated in the >>>>>> application level and not as part of the multistream. >>>>> >>>>> I guess this depends on whether the support for it is integrated >>> into >>>>> the "room", or is just incidental equipment brought by the users, >>> not >>>>> formally related to the telepresence session. >>>>> >>>>> Thanks, >>>>> Paul >>>>> (speaking as an individual) >>>>> >>>>>> Roni >>>>>> >>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>>> *stephane.cazeaux@orange-ftgroup.com >>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>>> *To:* clue@ietf.org >>>>>> *Subject:* [clue] Comment on the presentation use case* >>>>>> >>>>>> ** >>>>>> >>>>>> *Hi,* >>>>>> >>>>>> ** >>>>>> >>>>>> *The presentation use case as described in the use-cases document >>> is >>>>>> based on the assumption that the presentation stream relies on a >>>>> video >>>>>> stream, and is limited to usage of presentation video streams. But >>> we >>>>>> could also consider collaborative use cases, meaningful for >>>>>> telepresence, which are not covered by the existing text.* >>>>>> >>>>>> *I propose to complete the existing text as follows:* >>>>>> >>>>>> ** >>>>>> >>>>>> *Furthermore, although most today's systems use video streams for >>>>>> presentations, there are use cases where this is not suitable. For >>>>> example:* >>>>>> >>>>>> *- The professor which shares an electronic whiteboard (could be a >>>>>> whiteboard application on a PC, with screen capture of the PC) >>> where >>>>> all >>>>>> students can participate. Students will take control of the shared >>>>>> whiteboard in turns.* >>>>>> >>>>>> *- In a multipoint meeting, a shared document can be kept always >>>>> visible >>>>>> in a screen, while other documents are presented on other screens >>>>> (with >>>>>> possible in turns presentation). For instance, for the purpose of >>>>> shared >>>>>> design document, notes taking, polls, etc. A shared document >>> implies >>>>>> that all participants can modify it in turns.* >>>>>> >>>>>> *"* >>>>>> >>>>>> ** >>>>>> >>>>>> ** >>>>>> >>>>>> *St ephane. v> >>>>>> * >>>>>> >>>>>> * >>>>>> * >>>>>> >>>>>> *_______________________________________________ >>>>>> 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 > From pkyzivat@alum.mit.edu Tue Aug 9 06:03: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 EE9BB21F850E for ; Tue, 9 Aug 2011 06:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 BRLOx5RduTYg for ; Tue, 9 Aug 2011 06:03:03 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id D811421F8AA9 for ; Tue, 9 Aug 2011 06:03:02 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id JCds1h00B1ei1Bg5CD3Yqa; Tue, 09 Aug 2011 13:03:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id JD3X1h00A0tdiYw3kD3XRT; Tue, 09 Aug 2011 13:03:32 +0000 Message-ID: <4E413021.3010509@alum.mit.edu> Date: Tue, 09 Aug 2011 09:03:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] continuing "layout" discussion 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, 09 Aug 2011 13:03:04 -0000 On 8/5/11 5:02 PM, Duckworth, Mark wrote: > I'd like to continue the discussion about layout and rendering issues. There are many separate but related things involved. I want to break it down into separate topics, and see how the topics are related to each other. And then we can discuss what CLUE needs to deal with and what is not in scope. > > I don't know if I'm using the best terms for each topic. If not, please suggest better terms. My use of the term "layout" here is not consistent with draft-wenger-clue-definitions-01, because I don't limit it to the rendering side. But my use of the terms "render" and "source selction" is consistent with that draft. > > 1- video layout composed arrangement within a stream - when multiple video sources are composed into one stream, they are arranged in some way. Typical examples are 2x2 grid, 3x3 grid, 1+5 (1 large plus 5 small), 1+PiP (1 large plus one or more picture-in-picture). These arrangements can be selected automatically or based on user input. Arrangements can change over time. Identifying this composed arrangement is separate from identifying or selecting which video images are used to fill in the composition. These arrangements can be constructed by an endpoint sending video, by an MCU, or by an endpoint receiving video as it renders to a display. > > 2 - source selection and identification - when a device is composing a stream made up of other sources, it needs some way to choose which sources to use, and some way of choosing how to combine them or where to place video images in the composed arrangement. Various automatic algorithms may be used, or selections can be made based on user input. Selections can change over time. One example is "select the two most recent talkers". It may also be desirable to identify which sources are used and where they are placed, for example so the receiving side can use this information in the user interface. Source selection can be done by an endpoint as it sends media, by an MUC, or by an endpoint receiving media. > > 3 - spatial relation among streams - how multiple streams are related to each other spatially, to be rendered such that the spatial arrangement is consistent. The examples we've been using have multiple video streams that are related in an ordered row from left to right. Audio is also included when it is desirable to match spatial audio to video. > > 4 - multi stream media format - what the streams mean with respect to each other, regardless of the actual content on the streams. For audio, examples are stereo, 5.1 surround, binaural, linear array. (linear array is described in the clue framework document). Perhaps 3D video formats would also fit in this category. This information is needed in order to properly render the media into light and sound for human observers. I see this at the same level as identifying a codec, independent of the audio or video content carried on the streams, and independent of how any composition of sources is done. I was with you all the way until 4. That one I don't understand. The name you chose for this has connotations for me, but isn't fully in harmony with the definitions you give: If we consider audio, it makes sense that multiple streams can be rendered as if they came from different physical locations in the receiving room. That can be done by the receiver if it gets those streams separately, and has information about their intended relationships. It can also be done by the sender or MCU and passed on to the receiver as a single stream with stereo or binaural coding. So it seems to me you have two concepts here, not one. One has to do with describing the relationships between streams, and the other has to do with the encoding of spacial relationships *within* a single stream. Or, are you asserting that stereo and binaural are simply ways to encode multiple logical streams in one RTP stream, together with their spacial relationships? Thanks, Paul > I think there is general agreement that items 3 and 4 are in scope for CLUE, as they specifically deal with multiple streams to and from an endpoint. And the framework draft includes these. Items 1 and 2 are not new, those topics exist for traditional single stream videoconferencing. I'm not sure what aspects of 1 and 2 should be in scope for CLUE. It is hard to tell from the use cases and requirements. The framework draft includes them only to a very limited extent. > > Mark Duckworth > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Aug 10 08:33:15 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 7E99921F863C for ; Wed, 10 Aug 2011 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=0.227, 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 h8rC6GQidGqB for ; Wed, 10 Aug 2011 08:33:14 -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 7750721F8634 for ; Wed, 10 Aug 2011 08:33:14 -0700 (PDT) Received: by vxi29 with SMTP id 29so1160443vxi.31 for ; Wed, 10 Aug 2011 08:33:46 -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=O8gPR4N6UBZxyU+tkJP6T3Q7PJehXJ7AS4f65yhMJ18=; b=iFvE90v8TBGDVb2AvKsZqvrEsy5L+fwP6Fql4EdPZUgmz9tBJA9Hc5yacJ8p/WRB6m GXzMuCRGz22gAPHBqV8BS8ZlhHZgS0246xz7ZsrePg35PYFAoc6huKLLI0yoz90ac0HO pmIeYIWN6B4NIAH79zhsnkGaviifhhsdp/Hd4= MIME-Version: 1.0 Received: by 10.52.100.99 with SMTP id ex3mr2193247vdb.116.1312990426021; Wed, 10 Aug 2011 08:33:46 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Wed, 10 Aug 2011 08:33:45 -0700 (PDT) Date: Wed, 10 Aug 2011 10:33:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307f3286efbe2504aa286786 Subject: [clue] CLUE virtual Interim Meeting - August 23rd, 2011 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, 10 Aug 2011 15:33:15 -0000 --20cf307f3286efbe2504aa286786 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The doodle poll showed that Tuesday, August 23rd (11:00 am central) is the optimal date and time for the Interim meeting. I'll send the Webex info shortly. http://www.doodle.com/vmhdczdcrc7ck2k5 > > To determine the time for your timezone, please use the Timezone feature in > Doodle (I set the times using Central time). > > Regards, > Mary > CLUE WG co-chair > --20cf307f3286efbe2504aa286786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The doodle poll showed that Tuesday, August 23rd= (11:00 am central) is the optimal date and time for the Interim meeting. = =A0I'll send the Webex info shortly.

h= ttp://www.doodle.com/vmhdczdcrc7ck2k5

To deter= mine the time for your timezone, please use the Timezone feature in Doodle = (I set the times using Central time). =A0=A0=A0

Regards,
Mary
CLUE WG co-chair

--20cf307f3286efbe2504aa286786-- From wwwrun@ietfa.amsl.com Wed Aug 10 12:52:15 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 64BA511E8073; Wed, 10 Aug 2011 12:52:14 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110810195215.64BA511E8073@ietfa.amsl.com> Date: Wed, 10 Aug 2011 12:52:14 -0700 (PDT) Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting: August 23, 2011 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, 10 Aug 2011 19:52:15 -0000 The CLUE WG will hold an interim virtual meeting on: 2011-08-23, 16.00-18.00 GMT (starting at 9.00 Pacific, 11.00 Central, 12.00 Eastern) Agenda and details will be announced on the CLUE WG mailing list (http://www.ietf.org/mail-archive/web/clue/) as soon as available. From Mark.Duckworth@polycom.com Wed Aug 10 14:48:55 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 D356711E80BD for ; Wed, 10 Aug 2011 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 LjpZ50MB2aWw for ; Wed, 10 Aug 2011 14:48:55 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5A811E80AA for ; Wed, 10 Aug 2011 14:48:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 10 Aug 2011 14:49:25 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 10 Aug 2011 14:49:36 -0700 Thread-Topic: [clue] continuing "layout" discussion Thread-Index: AcxWlOS7i9j5CgQ1RMm1TCHmVfuG/wBCYeww Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> In-Reply-To: <4E413021.3010509@alum.mit.edu> 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 Subject: Re: [clue] continuing "layout" discussion 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, 10 Aug 2011 21:48:56 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, August 09, 2011 9:03 AM > To: clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion > > 4 - multi stream media format - what the streams mean with respect to > each other, regardless of the actual content on the streams. For > audio, examples are stereo, 5.1 surround, binaural, linear array. > (linear array is described in the clue framework document). Perhaps 3D > video formats would also fit in this category. This information is > needed in order to properly render the media into light and sound for > human observers. I see this at the same level as identifying a codec, > independent of the audio or video content carried on the streams, and > independent of how any composition of sources is done. >=20 > I was with you all the way until 4. That one I don't understand. > The name you chose for this has connotations for me, but isn't fully in > harmony with the definitions you give: I'm happy to change the name if you have a suggestion > If we consider audio, it makes sense that multiple streams can be > rendered as if they came from different physical locations in the > receiving room. That can be done by the receiver if it gets those > streams separately, and has information about their intended > relationships. It can also be done by the sender or MCU and passed on > to > the receiver as a single stream with stereo or binaural coding. Yes. It could also be done by the sender using the "linear array" audio ch= annel format. Maybe it is true that stereo or binaural audio channels woul= d always be sent as a single stream, but I was not assuming that yet, at le= ast not in general when you consider other types too, such as linear array = channels. > So it seems to me you have two concepts here, not one. One has to do > with describing the relationships between streams, and the other has to > do with the encoding of spacial relationships *within* a single stream. Maybe that is a better way to describe it, if you assume multi-channel audi= o is always sent with all the channels in the same RTP stream. Is that wha= t you mean? I was considering the linear array format to be another type of multi-chann= el audio, and I know people want to be able to send each channel in a separ= ate RTP stream. So it doesn't quite fit with how you separate the two conc= epts. In my view, identifying the separate channels by what they mean is t= he same concept for linear array and stereo. For example "this channel is = left, this channel is center, this channel is right". To me, that is the s= ame concept for identifying channels whether or not they are carried in the= same RTP stream. Maybe we are thinking the same thing but getting confused by terminology ab= out channels vs. streams. > Or, are you asserting that stereo and binaural are simply ways to > encode > multiple logical streams in one RTP stream, together with their spacial > relationships? No, that is not what I'm trying to say. Mark From pkyzivat@alum.mit.edu Thu Aug 11 06:01:20 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 D3D2A21F86AE for ; Thu, 11 Aug 2011 06:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 N1t-umC3EUQu for ; Thu, 11 Aug 2011 06:01:20 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 07D8E21F8596 for ; Thu, 11 Aug 2011 06:01:19 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id K0xi1h0041HzFnQ5811uwU; Thu, 11 Aug 2011 13:01:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id K11t1h02v0tdiYw3a11upJ; Thu, 11 Aug 2011 13:01:54 +0000 Message-ID: <4E43D2BE.5010102@alum.mit.edu> Date: Thu, 11 Aug 2011 09:01:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] continuing "layout" discussion 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, 11 Aug 2011 13:01:20 -0000 Inline On 8/10/11 5:49 PM, Duckworth, Mark wrote: >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, August 09, 2011 9:03 AM >> To: clue@ietf.org >> Subject: Re: [clue] continuing "layout" discussion > >>> 4 - multi stream media format - what the streams mean with respect to >> each other, regardless of the actual content on the streams. For >> audio, examples are stereo, 5.1 surround, binaural, linear array. >> (linear array is described in the clue framework document). Perhaps 3D >> video formats would also fit in this category. This information is >> needed in order to properly render the media into light and sound for >> human observers. I see this at the same level as identifying a codec, >> independent of the audio or video content carried on the streams, and >> independent of how any composition of sources is done. >> >> I was with you all the way until 4. That one I don't understand. >> The name you chose for this has connotations for me, but isn't fully in >> harmony with the definitions you give: > > I'm happy to change the name if you have a suggestion Not yet. Maybe once the concepts are more clearly defined I will have an opinion. >> If we consider audio, it makes sense that multiple streams can be >> rendered as if they came from different physical locations in the >> receiving room. That can be done by the receiver if it gets those >> streams separately, and has information about their intended >> relationships. It can also be done by the sender or MCU and passed on >> to >> the receiver as a single stream with stereo or binaural coding. > > Yes. It could also be done by the sender using the "linear array" audio channel format. Maybe it is true that stereo or binaural audio channels would always be sent as a single stream, but I was not assuming that yet, at least not in general when you consider other types too, such as linear array channels. >> So it seems to me you have two concepts here, not one. One has to do >> with describing the relationships between streams, and the other has to >> do with the encoding of spacial relationships *within* a single stream. > > Maybe that is a better way to describe it, if you assume multi-channel audio is always sent with all the channels in the same RTP stream. Is that what you mean? > > I was considering the linear array format to be another type of multi-channel audio, and I know people want to be able to send each channel in a separate RTP stream. So it doesn't quite fit with how you separate the two concepts. In my view, identifying the separate channels by what they mean is the same concept for linear array and stereo. For example "this channel is left, this channel is center, this channel is right". To me, that is the same concept for identifying channels whether or not they are carried in the same RTP stream. > > Maybe we are thinking the same thing but getting confused by terminology about channels vs. streams. Maybe. Let me try to restate what I now think you are saying: The audio may consist of several "channels". Each channel may be sent over its own RTP stream, or multiple channels may be multiplexed over an RTP stream. I guess much of this can also apply to video. When there are exactly two audio channels, they may be encoded as "stereo" or "binaural", which then affects how they should be rendered by the recipient. In these cases the primary info that is required about the individual channels is which is left and which is right. (And which perspective to use in interpretting left and right.) For other multi-channel cases more information is required about the role of each channel in order to properly render them. Thanks, Paul >> Or, are you asserting that stereo and binaural are simply ways to >> encode >> multiple logical streams in one RTP stream, together with their spacial >> relationships? > > No, that is not what I'm trying to say. > > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Aug 11 08:19: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 16EC921F85CA for ; Thu, 11 Aug 2011 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.208, 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 AERi-uA1UKcy for ; Thu, 11 Aug 2011 08:19: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 08C3521F85B9 for ; Thu, 11 Aug 2011 08:19:12 -0700 (PDT) Received: by vws12 with SMTP id 12so2191252vws.31 for ; Thu, 11 Aug 2011 08:19:47 -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=xWseIDoeIPF0y1lJecsrb7lEe7D+hG92FqZEzQBBGT4=; b=VY9ciidO7dtqZUY0+4+eGHJriZd/7+1mNIpUoLMNy2NEXoJ9UoS9MVhZWl53tNRMGu L4Rrt6xI1iNWDiiYt0mBoqbAjexzxdTF/N6PTSKVFED/zk3uSXpUrRsJRugcJ6p7k4AN dXk/mSDN69LCMz77OFbYedMWFKoWZczuVGwd4= MIME-Version: 1.0 Received: by 10.52.69.194 with SMTP id g2mr6470223vdu.451.1313075986110; Thu, 11 Aug 2011 08:19:46 -0700 (PDT) Received: by 10.52.160.71 with HTTP; Thu, 11 Aug 2011 08:19:45 -0700 (PDT) Date: Thu, 11 Aug 2011 10:19:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307cffd8b71a5504aa3c534b Subject: [clue] Webex Details: CLUE WG Virtual Interim Meeting 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, 11 Aug 2011 15:19:14 -0000 --20cf307cffd8b71a5504aa3c534b Content-Type: text/plain; charset=ISO-8859-1 Hello , IETF Secretariat invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Meeting Date: Tuesday, August 23, 2011 Time: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 963 755 542 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=181742197&UID=1249097532&RT=MiM0 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=181742197&UID=1249097532&ORT=MiM0 ------------------------------------------------------- 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=181742197&tollFree=0 Access code:963 755 542 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=181742197&UID=1249097532&ICS=MI&LD=1&RD=2&ST=1&SHA2=1sO7X9GoItG7qDII-/DUsH2iEIlMx8cUMEWOoPlBrjY=&RT=MiM0 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:+14087926300x963755542# 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. --20cf307cffd8b71a5504aa3c534b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello ,

IETF Secretariat invites you to at= tend this online meeting.

Topic: CLUE WG Virtual Interim Meeting =
Date: Tuesday, August 23, 2011
Time: 9:00 am, Pacific Daylight Time (= San Francisco, GMT-07:00)
Meeting Number: 963 755 542
Meeting Pas= sword: (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= =3D181742197&UID=3D1249097532&RT=3DMiM0
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 p= assword.)
4. Click "Join".

To view in other time z= ones or languages, please click the link:
https://workgreen.webex.= com/workgreen/j.php?ED=3D181742197&UID=3D1249097532&ORT=3DMiM0 =

-------------------------------------------------------
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 c= ode.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbe= rs: https://= workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D18= 1742197&tollFree=3D0

Access code:963 755 542

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://workgreen.webex.com/workgreen/= mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
amorris@amsl.com
1-510-492-4081

To add this meeting to your calendar program (for example Microsoft O= utlook), click this link:
https://workgreen.webex.com/workgreen/j.p= hp?ED=3D181742197&UID=3D1249097532&ICS=3DMI&LD=3D1&RD=3D2&a= mp;ST=3D1&SHA2=3D1sO7X9GoItG7qDII-/DUsH2iEIlMx8cUMEWOoPlBrjY=3D&RT= =3DMiM0

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://workgreen.webex.com/workgreen/systemd= iagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+14087926300x963755542#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent 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.

--20cf307cffd8b71a5504aa3c534b-- From mary.ietf.barnes@gmail.com Thu Aug 11 15:57:47 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 A837F11E8092 for ; Thu, 11 Aug 2011 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.394 X-Spam-Level: X-Spam-Status: No, score=-103.394 tagged_above=-999 required=5 tests=[AWL=0.204, 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 WhwnMcN5eDT3 for ; Thu, 11 Aug 2011 15:57:46 -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 865EC11E809C for ; Thu, 11 Aug 2011 15:57:46 -0700 (PDT) Received: by vxi29 with SMTP id 29so2512775vxi.31 for ; Thu, 11 Aug 2011 15:58:21 -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=IYwT+QqErEHTVUGqh9Q2aQngGQqqn3KHqD0DoJDR9TI=; b=kRU/e6V4OBcWkk/uR1xvkKWthNpj9MmjggNm1r6LojvUb7GeaUzgqeh2OOqjGqKL17 8jPGh0pddY9D+ke65Wv82iYgTtS0lA/Vr4dStY/4cCoEKlSNIphgQTGEnWc5ak/kdokK 7jRRb/j5BA1a5i3XRHVGW9NQbs2mKlUqSTAO4= MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr160322vdb.518.1313103501746; Thu, 11 Aug 2011 15:58:21 -0700 (PDT) Received: by 10.52.160.71 with HTTP; Thu, 11 Aug 2011 15:58:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Aug 2011 17:58:21 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307cfdd4c660c204aa42bbc9 Subject: Re: [clue] Webex Details: CLUE WG Virtual Interim Meeting 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, 11 Aug 2011 22:57:47 -0000 --20cf307cfdd4c660c204aa42bbc9 Content-Type: text/plain; charset=ISO-8859-1 As a reminder, all the materials for the meeting will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki There is a tentative agenda available at this time. Regards, Mary. On Thu, Aug 11, 2011 at 10:19 AM, Mary Barnes wrote: > Hello , > > IETF Secretariat invites you to attend this online meeting. > > Topic: CLUE WG Virtual Interim Meeting > Date: Tuesday, August 23, 2011 > Time: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 963 755 542 > 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=181742197&UID=1249097532&RT=MiM0 > 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=181742197&UID=1249097532&ORT=MiM0 > > ------------------------------------------------------- > 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=181742197&tollFree=0 > > Access code:963 755 542 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > > https://workgreen.webex.com/workgreen/j.php?ED=181742197&UID=1249097532&ICS=MI&LD=1&RD=2&ST=1&SHA2=1sO7X9GoItG7qDII-/DUsH2iEIlMx8cUMEWOoPlBrjY=&RT=MiM0 > > 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:+14087926300x963755542# > > 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. > > --20cf307cfdd4c660c204aa42bbc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a reminder, all the materials for the meeting will be available on the C= LUE WG wiki:

h= ttp://trac.tools.ietf.org/wg/clue/trac/wiki

Th= ere is a tentative agenda available at this time.

Regards,

Mary.=A0

On Thu, Aug 11, 2011 at 10:19 AM, Mary Barnes <= mary.ietf.barnes@gmail.com> wrote:

Hello ,

IE= TF Secretariat invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim Meeting
Date: Tuesday, August 23, 2011
Time: 9:00 am, Pacific Daylight Time (= San Francisco, GMT-07:00)
Meeting Number: 963 755 542
Meeting Pas= sword: (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= =3D181742197&UID=3D1249097532&RT=3DMiM0
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 p= assword.)
4. Click "Join".

To view in other time z= ones or languages, please click the link:
https://workgreen.webex.= com/workgreen/j.php?ED=3D181742197&UID=3D1249097532&ORT=3DMiM0 =

-------------------------------------------------------
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 c= ode.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbe= rs: https://= workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D18= 1742197&tollFree=3D0

Access code:963 755 542

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://workgreen.webex.com/workgreen/= mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
amorris@amsl.com
1-510-492-4081

To add this meeting to your calendar program (for example Microsoft O= utlook), click this link:
https://workgreen.webex.com/workgreen/j.p= hp?ED=3D181742197&UID=3D1249097532&ICS=3DMI&LD=3D1&RD=3D2&a= mp;ST=3D1&SHA2=3D1sO7X9GoItG7qDII-/DUsH2iEIlMx8cUMEWOoPlBrjY=3D&RT= =3DMiM0

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://workgreen.webex.com/workgreen/systemd= iagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+14087926300x963755542#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent 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.

--20cf307cfdd4c660c204aa42bbc9-- From stephane.cazeaux@orange-ftgroup.com Fri Aug 12 02:04: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 7902421F863A for ; Fri, 12 Aug 2011 02:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 8wqMJmN4qEbV for ; Fri, 12 Aug 2011 02:04:23 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id D389B21F867A for ; Fri, 12 Aug 2011 02:04:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 721608B8008; Fri, 12 Aug 2011 10:49:34 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 133B98B8007; Fri, 12 Aug 2011 10:49:34 +0200 (CEST) Received: from FTRDCH02.rd.francetelecom.fr ([10.194.32.13]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Aug 2011 10:48:42 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 10:48:42 +0200 From: To: Thread-Topic: [clue] Comment on the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoA== Date: Fri, 12 Aug 2011 08:48:41 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> In-Reply-To: <4E403783.70706@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2011 08:48:42.0948 (UTC) FILETIME=[A3ACB840:01CC58CC] Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case 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, 12 Aug 2011 09:04:24 -0000 Hi Paul, I understand your suggestion, and I am aware that it could be a solution. I= t certainly makes sense, but I am not sure of how it could be integrated in= CLUE. To me, this is a matter of application integration, at application l= evel. My suggestion is that we should think of a solution that provides more sati= sfying collaboration within telepresence, with the same level of interopera= bility and multistream interaction as presentation video stream provides, b= ut with more satisfying quality (video is not suitable for all kinds of sha= red documents) and more collaborative features. I don't think that the kind of relationship that you suggest is the only so= lution. Stephane.=20 -----Message d'origine----- De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Envoy=E9=A0: lundi 8 ao=FBt 2011 21:23 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf.org Objet=A0: Re: [clue] Comment on the presentation use case On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > Hi, > > To me, it should be part of the telepresence protocols at least to enable= the interoperability, as the presentation based on video stream allows it. > > The point is that video stream is not convenient for the use cases I sugg= ested. But it does not necessarily mean that we should bundle a full data s= haring protocol with telepresence. Something simpler, like the RFB option o= f draft-garcia-mmusic-sdp-collaboration, could be a candidate. What I was suggesting is that maybe it would make sense to turn those=20 relationships "inside out". For instance when I use a collaboration tool like Webex, the=20 collaboration is set up first via the web, and defines the set of=20 participants. Then a voice session can be added. For pragmatic reasons,=20 the voice conferencing seems to be pretty distinct. (I'm not certain how=20 webex handles video. I suspect it is doing it via the web, not the=20 telephony conference.) Its not hard to imagine the same sort of setup, but with a multiparty=20 telepresence session instead of the traditional voice conference. In=20 such a case, you would probably want the collaboration tool (webex, or=20 whatever) to mediate the UI for the web collaboration, the roster, etc.=20 It might delegate a lot of that to the telepresence infrastructure. But that does raise some questions about how all the components fit=20 together. Is there a single screen for the collaboration session in a=20 telepresence room? What about input to that - keyboard, mouse, etc.? Or=20 do we assume that each person in the room has their own computer with=20 input, display, etc. and maybe a way to slave the web collaboration=20 session to one or more of the big displays in the room? What probably *can't* be done right now is nail down a particular web=20 collaboration service (e.g. Webex) or protocol. That does complicate=20 slaving the collaboration session to a screen, unless its done by having=20 someone connect a video connection to their own computer. Thanks, Paul > Stephane. > > > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de P= aul Kyzivat > Envoy=E9 : jeudi 28 juillet 2011 13:41 > =C0 : CHATRAS Bruno RD-CORE-ISS > Cc : clue@ietf.org > Objet : Re: [clue] Comment on the presentation use case > > On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: >> I think we should take a look to >> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 > > Maybe. But that is almost orthogonal to what I was suggesting. > > THanks, > Paul > (as individual) > >> Bruno >> >>> -----Message d'origine----- >>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >>> Paul Kyzivat >>> Envoy=E9 : jeudi 28 juillet 2011 06:05 >>> =C0 : Roni Even >>> Cc : clue@ietf.org >>> Objet : Re: [clue] Comment on the presentation use case >>> >>> On 7/27/11 11:28 PM, Roni Even wrote: >>>> Hi, >>>> HTTP is not defining a common data sharing protocol. WebEx may be >>> carried >>>> over HTTP but the data sharing application is not standard. What I >>> meant is >>>> that it can either be something that is a common data sharing >>> protocol or >>>> something that is carried as an RTP payload which require some common >>>> defined protocol on top. >>> >>> I was being a bit tongue in cheek, though not entirely. >>> Of course you are right - that if you want to push data to everybody >>> you >>> need more. >>> >>> But data sharing by pointing a video camera at a piece of paper is a >>> tad >>> out of date. Connecting the video port on a user's computer as a video >>> source and distributing it with the other video is better than that. >>> But >>> its not nearly as convenient as webex or any of its competitors. >>> >>> It isn't entirely clear that its *necessary* to bundle the data sharing >>> application with the telepresence protocols. Its kind of limiting since >>> the web apps evolve very rapidly. Perhaps we should be doing the >>> opposite of that: providing a way to embed the control of the >>> telepresence system into a web app. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Thursday, July 28, 2011 1:29 AM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Comment on the presentation use case >>>>> >>>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>>> Hi Stephane, >>>>>> >>>>>> Is there a standard protocol that is used for conveying this >>>>>> information, is it RTP based. >>>>> >>>>> AFAIK this is often http. (E.g. webex) >>>>> >>>>>> To me this is a separate application that can be integrated in the >>>>>> application level and not as part of the multistream. >>>>> >>>>> I guess this depends on whether the support for it is integrated >>> into >>>>> the "room", or is just incidental equipment brought by the users, >>> not >>>>> formally related to the telepresence session. >>>>> >>>>> Thanks, >>>>> Paul >>>>> (speaking as an individual) >>>>> >>>>>> Roni >>>>>> >>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>>> *stephane.cazeaux@orange-ftgroup.com >>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>>> *To:* clue@ietf.org >>>>>> *Subject:* [clue] Comment on the presentation use case* >>>>>> >>>>>> ** >>>>>> >>>>>> *Hi,* >>>>>> >>>>>> ** >>>>>> >>>>>> *The presentation use case as described in the use-cases document >>> is >>>>>> based on the assumption that the presentation stream relies on a >>>>> video >>>>>> stream, and is limited to usage of presentation video streams. But >>> we >>>>>> could also consider collaborative use cases, meaningful for >>>>>> telepresence, which are not covered by the existing text.* >>>>>> >>>>>> *I propose to complete the existing text as follows:* >>>>>> >>>>>> ** >>>>>> >>>>>> *Furthermore, although most today's systems use video streams for >>>>>> presentations, there are use cases where this is not suitable. For >>>>> example:* >>>>>> >>>>>> *- The professor which shares an electronic whiteboard (could be a >>>>>> whiteboard application on a PC, with screen capture of the PC) >>> where >>>>> all >>>>>> students can participate. Students will take control of the shared >>>>>> whiteboard in turns.* >>>>>> >>>>>> *- In a multipoint meeting, a shared document can be kept always >>>>> visible >>>>>> in a screen, while other documents are presented on other screens >>>>> (with >>>>>> possible in turns presentation). For instance, for the purpose of >>>>> shared >>>>>> design document, notes taking, polls, etc. A shared document >>> implies >>>>>> that all participants can modify it in turns.* >>>>>> >>>>>> *"* >>>>>> >>>>>> ** >>>>>> >>>>>> ** >>>>>> >>>>>> *St ephane. v> >>>>>> * >>>>>> >>>>>> * >>>>>> * >>>>>> >>>>>> *_______________________________________________ >>>>>> 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 > From pkyzivat@alum.mit.edu Fri Aug 12 08:30: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 1CEE321F888A for ; Fri, 12 Aug 2011 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 JmM6B9CIkCks for ; Fri, 12 Aug 2011 08:30:08 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id D240121F8888 for ; Fri, 12 Aug 2011 08:30:07 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id KT7r1h00D1ZXKqc55TWlGa; Fri, 12 Aug 2011 15:30:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id KTWk1h01E0tdiYw3hTWlHi; Fri, 12 Aug 2011 15:30:45 +0000 Message-ID: <4E454723.4080501@alum.mit.edu> Date: Fri, 12 Aug 2011 11:30:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: stephane.cazeaux@orange-ftgroup.com References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case 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, 12 Aug 2011 15:30:09 -0000 On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > Hi Paul, > > I understand your suggestion, and I am aware that it could be a solution. It certainly makes sense, but I am not sure of how it could be integrated in CLUE. To me, this is a matter of application integration, at application level. > > My suggestion is that we should think of a solution that provides more satisfying collaboration within telepresence, with the same level of interoperability and multistream interaction as presentation video stream provides, but with more satisfying quality (video is not suitable for all kinds of shared documents) and more collaborative features. > I don't think that the kind of relationship that you suggest is the only solution. IMO the main thing is to not constrain the mechanism used for collaboration/web sharing. That stuff is evolving at "web speed". Anything you nail down that is constraining will be obsolete before it gets out. (I've been looking more at RTCWEB recently, and I'm wondering if perhaps CLUE ought to be based on that.) Thanks, Paul (as individual) > Stephane. > > > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy� : lundi 8 ao�t 2011 21:23 > � : CAZEAUX Stephane RD-BIZZ-CAE > Cc : clue@ietf.org > Objet : Re: [clue] Comment on the presentation use case > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: >> Hi, >> >> To me, it should be part of the telepresence protocols at least to enable the interoperability, as the presentation based on video stream allows it. >> >> The point is that video stream is not convenient for the use cases I suggested. But it does not necessarily mean that we should bundle a full data sharing protocol with telepresence. Something simpler, like the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a candidate. > > What I was suggesting is that maybe it would make sense to turn those > relationships "inside out". > > For instance when I use a collaboration tool like Webex, the > collaboration is set up first via the web, and defines the set of > participants. Then a voice session can be added. For pragmatic reasons, > the voice conferencing seems to be pretty distinct. (I'm not certain how > webex handles video. I suspect it is doing it via the web, not the > telephony conference.) > > Its not hard to imagine the same sort of setup, but with a multiparty > telepresence session instead of the traditional voice conference. In > such a case, you would probably want the collaboration tool (webex, or > whatever) to mediate the UI for the web collaboration, the roster, etc. > It might delegate a lot of that to the telepresence infrastructure. > > But that does raise some questions about how all the components fit > together. Is there a single screen for the collaboration session in a > telepresence room? What about input to that - keyboard, mouse, etc.? Or > do we assume that each person in the room has their own computer with > input, display, etc. and maybe a way to slave the web collaboration > session to one or more of the big displays in the room? > > What probably *can't* be done right now is nail down a particular web > collaboration service (e.g. Webex) or protocol. That does complicate > slaving the collaboration session to a screen, unless its done by having > someone connect a video connection to their own computer. > > Thanks, > Paul > >> Stephane. >> >> >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de Paul Kyzivat >> Envoy� : jeudi 28 juillet 2011 13:41 >> � : CHATRAS Bruno RD-CORE-ISS >> Cc : clue@ietf.org >> Objet : Re: [clue] Comment on the presentation use case >> >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: >>> I think we should take a look to >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 >> >> Maybe. But that is almost orthogonal to what I was suggesting. >> >> THanks, >> Paul >> (as individual) >> >>> Bruno >>> >>>> -----Message d'origine----- >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >>>> Paul Kyzivat >>>> Envoy� : jeudi 28 juillet 2011 06:05 >>>> � : Roni Even >>>> Cc : clue@ietf.org >>>> Objet : Re: [clue] Comment on the presentation use case >>>> >>>> On 7/27/11 11:28 PM, Roni Even wrote: >>>>> Hi, >>>>> HTTP is not defining a common data sharing protocol. WebEx may be >>>> carried >>>>> over HTTP but the data sharing application is not standard. What I >>>> meant is >>>>> that it can either be something that is a common data sharing >>>> protocol or >>>>> something that is carried as an RTP payload which require some common >>>>> defined protocol on top. >>>> >>>> I was being a bit tongue in cheek, though not entirely. >>>> Of course you are right - that if you want to push data to everybody >>>> you >>>> need more. >>>> >>>> But data sharing by pointing a video camera at a piece of paper is a >>>> tad >>>> out of date. Connecting the video port on a user's computer as a video >>>> source and distributing it with the other video is better than that. >>>> But >>>> its not nearly as convenient as webex or any of its competitors. >>>> >>>> It isn't entirely clear that its *necessary* to bundle the data sharing >>>> application with the telepresence protocols. Its kind of limiting since >>>> the web apps evolve very rapidly. Perhaps we should be doing the >>>> opposite of that: providing a way to embed the control of the >>>> telepresence system into a web app. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Thursday, July 28, 2011 1:29 AM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Comment on the presentation use case >>>>>> >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>>>> Hi Stephane, >>>>>>> >>>>>>> Is there a standard protocol that is used for conveying this >>>>>>> information, is it RTP based. >>>>>> >>>>>> AFAIK this is often http. (E.g. webex) >>>>>> >>>>>>> To me this is a separate application that can be integrated in the >>>>>>> application level and not as part of the multistream. >>>>>> >>>>>> I guess this depends on whether the support for it is integrated >>>> into >>>>>> the "room", or is just incidental equipment brought by the users, >>>> not >>>>>> formally related to the telepresence session. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> (speaking as an individual) >>>>>> >>>>>>> Roni >>>>>>> >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>>>> *stephane.cazeaux@orange-ftgroup.com >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>>>> *To:* clue@ietf.org >>>>>>> *Subject:* [clue] Comment on the presentation use case* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Hi,* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *The presentation use case as described in the use-cases document >>>> is >>>>>>> based on the assumption that the presentation stream relies on a >>>>>> video >>>>>>> stream, and is limited to usage of presentation video streams. But >>>> we >>>>>>> could also consider collaborative use cases, meaningful for >>>>>>> telepresence, which are not covered by the existing text.* >>>>>>> >>>>>>> *I propose to complete the existing text as follows:* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Furthermore, although most today's systems use video streams for >>>>>>> presentations, there are use cases where this is not suitable. For >>>>>> example:* >>>>>>> >>>>>>> *- The professor which shares an electronic whiteboard (could be a >>>>>>> whiteboard application on a PC, with screen capture of the PC) >>>> where >>>>>> all >>>>>>> students can participate. Students will take control of the shared >>>>>>> whiteboard in turns.* >>>>>>> >>>>>>> *- In a multipoint meeting, a shared document can be kept always >>>>>> visible >>>>>>> in a screen, while other documents are presented on other screens >>>>>> (with >>>>>>> possible in turns presentation). For instance, for the purpose of >>>>>> shared >>>>>>> design document, notes taking, polls, etc. A shared document >>>> implies >>>>>>> that all participants can modify it in turns.* >>>>>>> >>>>>>> *"* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *St ephane. v> >>>>>>> * >>>>>>> >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> *_______________________________________________ >>>>>>> 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 >> > > From Even.roni@huawei.com Sun Aug 14 03:12: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 B685C21F8661 for ; Sun, 14 Aug 2011 03:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.622 X-Spam-Level: X-Spam-Status: No, score=-105.622 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FRT_FOLLOW1=1.332, 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 DMZ8zFXvcGMp for ; Sun, 14 Aug 2011 03:12:58 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AB21F85BB for ; Sun, 14 Aug 2011 03:12:57 -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 <0LPW00LUXXQR6B@szxga04-in.huawei.com> for clue@ietf.org; Sun, 14 Aug 2011 18:13:39 +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 <0LPW0065AXQRUR@szxga04-in.huawei.com> for clue@ietf.org; Sun, 14 Aug 2011 18:13:39 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-16-191.red.bezeqint.net [79.180.16.191]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPW00I1AXQKT8@szxml12-in.huawei.com> for clue@ietf.org; Sun, 14 Aug 2011 18:13:39 +0800 (CST) Date: Sun, 14 Aug 2011 13:13:17 +0300 From: Roni Even To: clue@ietf.org Message-id: <02c701cc5a6a$cd8bdbb0$68a39310$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uf15amNaWv9+zvhSjz96LA)" Content-language: en-us Thread-index: Acxaasg6Cyi54ZGPRR+etvD1LpiaSA== Subject: [clue] Capture Scene and system description 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, 14 Aug 2011 10:12:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uf15amNaWv9+zvhSjz96LA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The way I read the framework is that it assumes one model of a generic endpoint described by the cameras having a left to right spatial relation. My view from the charter is that the description should also address the displays and camera positions which are not the same for all endpoint. Cameras can be centrally located or on top of each screen. The screen may be very close to one other or at some distance from one others. All this information is relevant of you want to convey the "being there" experience which is why we chartered this endpoint and not to achieve just a simple multi-stream connection. >From the charter: This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams I think that the current base model does not address this two bullets from the charter. My preference is to define the "Capture Scene" so it will have parameters that will enable the advertisement of the camera positions and the number of displays and their relative position. As for the camera viewpoint I think this is being discussed in a separate thread on the layout and I will address my comments there. BR Roni Even --Boundary_(ID_uf15amNaWv9+zvhSjz96LA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

The way I read the framework is that it assumes one model of a generic endpoint described by the cameras having a left to right spatial relation.

My view from the charter is that the description should also address the displays and camera positions which are not the same for all endpoint. Cameras can be centrally located or on top of each screen. The screen may be very close to one other or at some distance from one others. All this information is relevant of you want to convey the "being there" experience which is why we chartered this endpoint and not to achieve just a simple multi-stream connection.

From the charter:

This working group is chartered to specify the follo wing inf class=MsoNormal> about media streams from one entity to another entity:

* Spatial relationships of cameras, displays, microphones, and

loudspeakers - relative to each other and to likely positions of

participants

* Viewpoint, field of view/capture for

camera/microphone/display/loudspeaker - so that senders and

intermediate devices can understand how best to compose streams for

receivers, and the receiver will know the characteristics of its

received streams

I think that the current base model does not address this two bullets from the charter.

My preference is to define the "Capture Scene" so it will have parameters that will enable the advertisement of the camera positions and the number of displays and their relative position.

As for the camera viewpoint I think this is being discussed in a separate thread on the layout and I will address my comments there.

Roni Even

--Boundary_(ID_uf15amNaWv9+zvhSjz96LA)-- From bbaldino@cisco.com Mon Aug 15 13:20: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 568B421F8D4B for ; Mon, 15 Aug 2011 13:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_FOLLOW1=1.332, 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 GKIR27uUFMHJ for ; Mon, 15 Aug 2011 13:20:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0921F8D4A for ; Mon, 15 Aug 2011 13:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=12355; q=dns/txt; s=iport; t=1313439696; x=1314649296; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=1Hl3nmo3Im/JMxD86OqZIxnKAqD0h+7sW8jGCkQednE=; b=lpGImvIvAonEW1fPugXHrmRTLtV0n4IGv9nnjhQAdh7w6igfFnykEpDm 7b99STSgGooAeDHKM8aj6ejA+g3UxQ8SrHisxRyYw5XNj+EhPLwx7JDLV Ye8wEZHsrmwIaR/rukQqp6OR0OtQaq+7Ha8Eq1xjY6vLWyQm2mCS5XE05 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAEZ/SU6rRDoJ/2dsb2JhbABBgk2Ve49Od4FAAQEBAQMSAQkRA0IXAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqiJgGfBIVoXwSHX5BIjAA X-IronPort-AV: E=Sophos;i="4.67,375,1309737600"; d="scan'208,217";a="13322659" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 15 Aug 2011 20:21:35 +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 p7FKLZTR029844; Mon, 15 Aug 2011 20:21:35 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 13:21:35 -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_01CC5B88.ED8D4BF4" Date: Mon, 15 Aug 2011 13:21:34 -0700 Message-ID: In-Reply-To: <02c701cc5a6a$cd8bdbb0$68a39310$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Capture Scene and system description thread-index: Acxaasg6Cyi54ZGPRR+etvD1LpiaSABHcgjw References: <02c701cc5a6a$cd8bdbb0$68a39310$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 15 Aug 2011 20:21:35.0119 (UTC) FILETIME=[EDDBD9F0:01CC5B88] Subject: Re: [clue] Capture Scene and system description 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, 15 Aug 2011 20:20:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5B88.ED8D4BF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Roni, I agree that the current description of the framework doesn't provide a mechanism to describe the concepts you mentioned; we plan on adding support for them and the mechanisms for doing so will be added to the framework soon. Once we take our best shot at them we can make sure they cover the use cases you described. =20 -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, August 14, 2011 3:13 AM To: clue@ietf.org Subject: [clue] Capture Scene and system description =20 Hi, The way I read the framework is that it assumes one model of a generic endpoint described by the cameras having a left to right spatial relation. My view from the charter is that the description should also address the displays and camera positions which are not the same for all endpoint. Cameras can be centrally located or on top of each screen. The screen may be very close to one other or at some distance from one others. All this information is relevant of you want to convey the "being there" experience which is why we chartered this endpoint and not to achieve just a simple multi-stream connection. =20 >From the charter: This working group is chartered to specify the follo wing inf class=3DMsoNormal> about media streams from one entity to another = entity: =20 * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants =20 * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams =20 I think that the current base model does not address this two bullets from the charter.=20 My preference is to define the "Capture Scene" so it will have parameters that will enable the advertisement of the camera positions and the number of displays and their relative position. =20 As for the camera viewpoint I think this is being discussed in a separate thread on the layout and I will address my comments there. =20 BR Roni Even =20 =20 ------_=_NextPart_001_01CC5B88.ED8D4BF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Roni,

I agree that the current description of the framework = doesn’t provide a mechanism to describe the concepts you mentioned; we plan on = adding support for them and the mechanisms for doing so will be added to the = framework soon. Once we take our best shot at them we can make sure they = cover the use cases you described.

-Brian

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Sunday, August 14, 2011 3:13 AM
To: clue@ietf.org
Subject: [clue] Capture Scene and system = description

Hi,

The way I read the framework is that it assumes one = model of a generic endpoint described by the cameras having a left to right = spatial relation.

My view from the charter is that the description = should also address the displays and camera positions which are not the same for all endpoint. Cameras can be centrally located or on top of each screen. The = screen may be very close to one other or at some distance from one others. All = this information is relevant of you want to convey the "being = there" experience which is why we chartered this endpoint and not to achieve = just a simple multi-stream connection.

From the charter:

This working group is chartered to specify the = follo wing inf class=3DMsoNormal> about media streams from one entity to = another entity:

* Spatial relationships of cameras, = displays, microphones, and

loudspeakers - relative to each = other and to likely positions of

participants

* Viewpoint, field of view/capture = for

= camera/microphone/display/loudspeaker - so that senders and

intermediate devices can = understand how best to compose streams for

receivers, and the receiver will = know the characteristics of its

received streams

I think that the current base model does not = address this two bullets from the charter.

My preference is to define the "Capture = Scene" so it will have parameters that will enable the advertisement of the camera positions and the number of displays and their relative = position.

As for the camera viewpoint I think this is being = discussed in a separate thread on the layout and I will address my comments = there.

Roni Even

------_=_NextPart_001_01CC5B88.ED8D4BF4-- From eckelcu@cisco.com Mon Aug 15 13:21:08 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 1E49121F8D50 for ; Mon, 15 Aug 2011 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 o1JfFUDBKkrY for ; Mon, 15 Aug 2011 13:21:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3E21F8D4A for ; Mon, 15 Aug 2011 13:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5641; q=dns/txt; s=iport; t=1313439714; x=1314649314; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=8dn+y55XdPWRxmgHmMb+JI10dCQIgsbo7FxQ4Y8I/XY=; b=GeVru/i3RQlha6x/8y3zcvu1/OwQcZyuURfF65+rqevwa4T07IQLTlLd cUBxp2okL8bpKbOmvXB0LkcXL/qw3Pdqwrs2BVYYbS4iN5iksTAT/C6xc ojCr1uwfbEzniAmwb34VNyTqfdNrjdPGsSfwXv+atc9vxUCi4x+k4u3uU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAEZ/SU6rRDoH/2dsb2JhbABBDpg6j053gUABAQEBAgEBAQEPAR0KLQcEEwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEARIIGodOBJpUAZ8EhWhfBIdfkEiLKFg X-IronPort-AV: E=Sophos;i="4.67,375,1309737600"; d="scan'208";a="13328250" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2011 20:21: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 p7FKLkWw032396; Mon, 15 Aug 2011 20:21:46 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 13:21:46 -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: Mon, 15 Aug 2011 13:21:44 -0700 Message-ID: In-Reply-To: <4E43D2BE.5010102@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] continuing "layout" discussion Thread-Index: AcxYJtujoPLfXJRJTtC50DnQ79LPywDYQvaA References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com><4E413021.3010509@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 15 Aug 2011 20:21:46.0070 (UTC) FILETIME=[F462D760:01CC5B88] Subject: Re: [clue] continuing "layout" discussion 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, 15 Aug 2011 20:21:08 -0000 Please see inline. > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 11, 2011 6:02 AM > To: clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion >=20 > Inline >=20 > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >> Paul Kyzivat > >> Sent: Tuesday, August 09, 2011 9:03 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] continuing "layout" discussion > > > >>> 4 - multi stream media format - what the streams mean with respect to > >> each other, regardless of the actual content on the streams. For > >> audio, examples are stereo, 5.1 surround, binaural, linear array. > >> (linear array is described in the clue framework document). Perhaps 3D > >> video formats would also fit in this category. This information is > >> needed in order to properly render the media into light and sound for > >> human observers. I see this at the same level as identifying a codec, > >> independent of the audio or video content carried on the streams, and > >> independent of how any composition of sources is done. I do not think this is necessarily true. Taking audio as an example, you could have two audio streams that are mixed to form a single stereo audio stream, or you could have them as two independent (not mixed) streams that are associate with each other by some grouping mechanism. This group would be categorized as being stereo audio with one audio stream being the left and the other the right. The codec used for each could be different, though I agree they would typically be the same. Consequently, I think at attribute such as "stereo" as being more of a grouping concept, where the group may consist of: - multiple independent streams, each with potentially its own spatial orientation, codec, bandwidth, etc.,=20 - a single mixed stream Cheers, Charles > >> I was with you all the way until 4. That one I don't understand. > >> The name you chose for this has connotations for me, but isn't fully in > >> harmony with the definitions you give: > > > > I'm happy to change the name if you have a suggestion >=20 > Not yet. Maybe once the concepts are more clearly defined I will have an > opinion. >=20 > >> If we consider audio, it makes sense that multiple streams can be > >> rendered as if they came from different physical locations in the > >> receiving room. That can be done by the receiver if it gets those > >> streams separately, and has information about their intended > >> relationships. It can also be done by the sender or MCU and passed on > >> to > >> the receiver as a single stream with stereo or binaural coding. > > > > Yes. It could also be done by the sender using the "linear array" audio channel format. Maybe it > is true that stereo or binaural audio channels would always be sent as a single stream, but I was not > assuming that yet, at least not in general when you consider other types too, such as linear array > channels. >=20 > >> So it seems to me you have two concepts here, not one. One has to do > >> with describing the relationships between streams, and the other has to > >> do with the encoding of spacial relationships *within* a single stream. > > > > Maybe that is a better way to describe it, if you assume multi-channel audio is always sent with all > the channels in the same RTP stream. Is that what you mean? > > > > I was considering the linear array format to be another type of multi-channel audio, and I know > people want to be able to send each channel in a separate RTP stream. So it doesn't quite fit with > how you separate the two concepts. In my view, identifying the separate channels by what they mean is > the same concept for linear array and stereo. For example "this channel is left, this channel is > center, this channel is right". To me, that is the same concept for identifying channels whether or > not they are carried in the same RTP stream. > > > > Maybe we are thinking the same thing but getting confused by terminology about channels vs. streams. >=20 > Maybe. Let me try to restate what I now think you are saying: >=20 > The audio may consist of several "channels". >=20 > Each channel may be sent over its own RTP stream, > or multiple channels may be multiplexed over an RTP stream. >=20 > I guess much of this can also apply to video. >=20 > When there are exactly two audio channels, they may be encoded as > "stereo" or "binaural", which then affects how they should be rendered > by the recipient. In these cases the primary info that is required about > the individual channels is which is left and which is right. (And which > perspective to use in interpretting left and right.) >=20 > For other multi-channel cases more information is required about the > role of each channel in order to properly render them. >=20 > Thanks, > Paul >=20 >=20 > >> Or, are you asserting that stereo and binaural are simply ways to > >> encode > >> multiple logical streams in one RTP stream, together with their spacial > >> relationships? > > > > No, that is not what I'm trying to say. > > > > Mark > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Mon Aug 15 14:12: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 BF48721F8D17 for ; Mon, 15 Aug 2011 14:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.267, 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 0x9FSGLpR1rI for ; Mon, 15 Aug 2011 14:12:50 -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 49C7621F8D12 for ; Mon, 15 Aug 2011 14:12:50 -0700 (PDT) Received: by vxi29 with SMTP id 29so5241302vxi.31 for ; Mon, 15 Aug 2011 14:13: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=5NtnF6S6cAjeBmH+PB/4f/ao49DUzib84FtBV/k4HW4=; b=O6fn01pFmwFaIFixFhUJXQotGjiOU5YYuLaMYBcE4xQ/BVau9A9hZxomfQuuoku41F k4IVhW+5ASJfyTv8fz7vQzi8GQZj/lW6pFZZSYYnk3vBnbi+y83OTD7ZeIlz8iby3uCT tbslc/LBSw+Cz/Jabu7JzMufCspiXNf/zSLcw= MIME-Version: 1.0 Received: by 10.52.176.166 with SMTP id cj6mr4360489vdc.155.1313442816547; Mon, 15 Aug 2011 14:13:36 -0700 (PDT) Received: by 10.52.115.103 with HTTP; Mon, 15 Aug 2011 14:13:36 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu> Date: Mon, 15 Aug 2011 17:13:36 -0400 Message-ID: From: Stephen Botzko To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=bcaec5186a58835aaa04aa91bcb0 Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 15 Aug 2011 21:12:51 -0000 --bcaec5186a58835aaa04aa91bcb0 Content-Type: text/plain; charset=ISO-8859-1 Inline On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) wrote: > Please see inline. > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > > Sent: Thursday, August 11, 2011 6:02 AM > > To: clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Inline > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of > > >> Paul Kyzivat > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > >> To: clue@ietf.org > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > >>> 4 - multi stream media format - what the streams mean with respect > to > > >> each other, regardless of the actual content on the streams. For > > >> audio, examples are stereo, 5.1 surround, binaural, linear array. > > >> (linear array is described in the clue framework document). > Perhaps 3D > > >> video formats would also fit in this category. This information is > > >> needed in order to properly render the media into light and sound > for > > >> human observers. I see this at the same level as identifying a > codec, > > >> independent of the audio or video content carried on the streams, > and > > >> independent of how any composition of sources is done. > > I do not think this is necessarily true. Taking audio as an example, you > could have two audio streams that are mixed to form a single stereo > audio stream, or you could have them as two independent (not mixed) > streams that are associate with each other by some grouping mechanism. > This group would be categorized as being stereo audio with one audio > stream being the left and the other the right. The codec used for each > could be different, though I agree they would typically be the same. > Consequently, I think at attribute such as "stereo" as being more of a > grouping concept, where the group may consist of: > - multiple independent streams, each with potentially its own spatial > orientation, codec, bandwidth, etc., > - a single mixed stream > [sb] I do not understand this distinction. What do you mean when you say "two audio streams that are mixed to form a single stereo stream", and how is this different from the left and right grouping? > > Cheers, > Charles > > > >> I was with you all the way until 4. That one I don't understand. > > >> The name you chose for this has connotations for me, but isn't > fully in > > >> harmony with the definitions you give: > > > > > > I'm happy to change the name if you have a suggestion > > > > Not yet. Maybe once the concepts are more clearly defined I will have > an > > opinion. > > > > >> If we consider audio, it makes sense that multiple streams can be > > >> rendered as if they came from different physical locations in the > > >> receiving room. That can be done by the receiver if it gets those > > >> streams separately, and has information about their intended > > >> relationships. It can also be done by the sender or MCU and passed > on > > >> to > > >> the receiver as a single stream with stereo or binaural coding. > > > > > > Yes. It could also be done by the sender using the "linear array" > audio channel format. Maybe it > > is true that stereo or binaural audio channels would always be sent as > a single stream, but I was not > > assuming that yet, at least not in general when you consider other > types too, such as linear array > > channels. > > > > >> So it seems to me you have two concepts here, not one. One has to > do > > >> with describing the relationships between streams, and the other > has to > > >> do with the encoding of spacial relationships *within* a single > stream. > > > > > > Maybe that is a better way to describe it, if you assume > multi-channel audio is always sent with all > > the channels in the same RTP stream. Is that what you mean? > > > > > > I was considering the linear array format to be another type of > multi-channel audio, and I know > > people want to be able to send each channel in a separate RTP stream. > So it doesn't quite fit with > > how you separate the two concepts. In my view, identifying the > separate channels by what they mean is > > the same concept for linear array and stereo. For example "this > channel is left, this channel is > > center, this channel is right". To me, that is the same concept for > identifying channels whether or > > not they are carried in the same RTP stream. > > > > > > Maybe we are thinking the same thing but getting confused by > terminology about channels vs. streams. > > > > Maybe. Let me try to restate what I now think you are saying: > > > > The audio may consist of several "channels". > > > > Each channel may be sent over its own RTP stream, > > or multiple channels may be multiplexed over an RTP stream. > > > > I guess much of this can also apply to video. > > > > When there are exactly two audio channels, they may be encoded as > > "stereo" or "binaural", which then affects how they should be rendered > > by the recipient. In these cases the primary info that is required > about > > the individual channels is which is left and which is right. (And > which > > perspective to use in interpretting left and right.) > > > > For other multi-channel cases more information is required about the > > role of each channel in order to properly render them. > > > > Thanks, > > Paul > > > > > > >> Or, are you asserting that stereo and binaural are simply ways to > > >> encode > > >> multiple logical streams in one RTP stream, together with their > spacial > > >> relationships? > > > > > > No, that is not what I'm trying to say. > > > > > > Mark > > > _______________________________________________ > > > 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 > --bcaec5186a58835aaa04aa91bcb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline

On Mon, Aug 15, 2011 at 4:21 PM, C= harles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Please see inline.

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

> Sent: Thursday, August 11, 2011 6:02 AM

> To: clue@ietf.org
> Subject: Re: [clue] continuing "layout" discussion
>
> Inline
>
> On 8/10/11 5:49 PM, Duckworth, Mark wrote:
> >> -----Original Message-----
> >> From: clue-bounces@i= etf.org [mailto:clue-bounces@i= etf.org] On
Behalf Of
> >> Paul Kyzivat
> >> Sent: Tuesday, August 09, 2011 9:03 AM
> >> To: clue@ietf.org
> >> Subject: Re: [clue] continuing "layout" discussion<= br> > >
> >>> 4 - multi stream media format - what the streams mean wit= h respect
to
> >> each other, regardless of the actual content on the streams. = =A0For
> >> audio, examples are stereo, 5.1 surround, binaural, linear ar= ray.
> >> (linear array is described in the clue framework document). Perhaps 3D
> >> video formats would also fit in this category. =A0This inform= ation is
> >> needed in order to properly render the media into light and s= ound
for
> >> human observers. =A0I see this at the same level as identifyi= ng a
codec,
> >> independent of the audio or video content carried on the stre= ams,
and
> >> independent of how any composition of sources is done.

I do not think this is necessarily true. Taking audio as an exa= mple, you
could have two audio streams that are mixed to form a single stereo
audio stream, or you could have them as two independent (not mixed)
streams that are associate with each other by some grouping mechanism.
This group would be categorized as being stereo audio with one audio
stream being the left and the other the right. The codec used for each
could be different, though I agree they would typically be the same.
Consequently, I think at attribute such as "stereo" as being more= of a
grouping concept, where the group may consist of:
- multiple independent streams, each with potentially its own spatial
orientation, codec, bandwidth, etc.,
- a single mixed stream

[sb] I do not understand t= his distinction.=A0 What do you mean when you say "two audio streams t= hat are mixed to form a single stereo stream", and how is this differe= nt from the left and right grouping?
=A0

Cheers,
Charles

> >> I was with you all the way until 4. That one I don't unde= rstand.
> >> The name you chose for this has connotations for me, but isn&= #39;t
fully in
> >> harmony with the definitions you give:
> >
> > I'm happy to change the name if you have a suggestion
>
> Not yet. Maybe once the concepts are more clearly defined I will have<= br> an
> opinion.
>
> >> If we consider audio, it makes sense that multiple streams ca= n be
> >> rendered as if they came from different physical locations in= the
> >> receiving room. That can be done by the receiver if it gets t= hose
> >> streams separately, and has information about their intended<= br> > >> relationships. It can also be done by the sender or MCU and p= assed
on
> >> to
> >> the receiver as a single stream with stereo or binaural codin= g.
> >
> > Yes. =A0It could also be done by the sender using the "linea= r array"
audio channel format. =A0Maybe it
> is true that stereo or binaural audio channels would always be sent as=
a single stream, but I was not
> assuming that yet, at least not in general when you consider other
types too, such as linear array
> channels.
>
> >> So it seems to me you have two concepts here, not one. One ha= s to
do
> >> with describing the relationships between streams, and the ot= her
has to
> >> do with the encoding of spacial relationships *within* a sing= le
stream.
> >
> > Maybe that is a better way to describe it, if you assume
multi-channel audio is always sent with all
> the channels in the same RTP stream. =A0Is that what you mean?
> >
> > I was considering the linear array format to be another type of multi-channel audio, and I know
> people want to be able to send each channel in a separate RTP stream.<= br> So it doesn't quite fit with
> how you separate the two concepts. =A0In my view, identifying the
separate channels by what they mean is
> the same concept for linear array and stereo. =A0For example "thi= s
channel is left, this channel is
> center, this channel is right". =A0To me, that is the same concep= t for
identifying channels whether or
> not they are carried in the same RTP stream.
> >
> > Maybe we are thinking the same thing but getting confused by
terminology about channels vs. streams.
>
> Maybe. Let me try to restate what I now think you are saying:
>
> The audio may consist of several "channels".
>
> Each channel may be sent over its own RTP stream,
> or multiple channels may be multiplexed over an RTP stream.
>
> I guess much of this can also apply to video.
>
> When there are exactly two audio channels, they may be encoded as
> "stereo" or "binaural", which then affects how the= y should be rendered
> by the recipient. In these cases the primary info that is required
about
> the individual channels is which is left and which is right. (And
which
> perspective to use in interpretting left and right.)
>
> For other multi-channel cases more information is required about the > role of each channel in order to properly render them.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>
> >> Or, are you asserting that stereo and binaural are simply way= s to
> >> encode
> >> multiple logical streams in one RTP stream, together with the= ir
spacial
> >> relationships?
> >
> > No, that is not what I'm trying to say.
> >
> > Mark
> > _______________________________________________
> > 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
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec5186a58835aaa04aa91bcb0-- From Even.roni@huawei.com Mon Aug 15 14:22: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 2284721F8D48 for ; Mon, 15 Aug 2011 14:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 uBYLvHqXzdNo for ; Mon, 15 Aug 2011 14:22:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0422C21F8D3B for ; Mon, 15 Aug 2011 14:22:26 -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 <0LPZ0031PNEMQ8@szxga05-in.huawei.com> for clue@ietf.org; Tue, 16 Aug 2011 05:23:10 +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 <0LPZ00H96NELPW@szxga05-in.huawei.com> for clue@ietf.org; Tue, 16 Aug 2011 05:23:10 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-13-148.red.bezeqint.net [79.178.13.148]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPZ000WJNEBO0@szxml12-in.huawei.com>; Tue, 16 Aug 2011 05:23:09 +0800 (CST) Date: Tue, 16 Aug 2011 00:22:28 +0300 From: Roni Even In-reply-to: To: "'Charles Eckel (eckelcu)'" , 'Paul Kyzivat' , clue@ietf.org Message-id: <010001cc5b91$7604bfb0$620e3f10$%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: AcxYJtujoPLfXJRJTtC50DnQ79LPywDYQvaAAAInzpA= References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu> Subject: Re: [clue] continuing "layout" discussion 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, 15 Aug 2011 21:22:27 -0000 Hi, It looks to me like I agree with Charles but taking it to video I see that we have two separate entities which appear now in eth framework as one. We have three video captures devices or streams (similar to two audio streams) and we have the grouping which is left to right. Currently the left to right is assumed. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Charles Eckel (eckelcu) > Sent: Monday, August 15, 2011 11:22 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion > > Please see inline. > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > > Sent: Thursday, August 11, 2011 6:02 AM > > To: clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Inline > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of > > >> Paul Kyzivat > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > >> To: clue@ietf.org > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > >>> 4 - multi stream media format - what the streams mean with > respect > to > > >> each other, regardless of the actual content on the streams. For > > >> audio, examples are stereo, 5.1 surround, binaural, linear array. > > >> (linear array is described in the clue framework document). > Perhaps 3D > > >> video formats would also fit in this category. This information > is > > >> needed in order to properly render the media into light and sound > for > > >> human observers. I see this at the same level as identifying a > codec, > > >> independent of the audio or video content carried on the streams, > and > > >> independent of how any composition of sources is done. > > I do not think this is necessarily true. Taking audio as an example, > you > could have two audio streams that are mixed to form a single stereo > audio stream, or you could have them as two independent (not mixed) > streams that are associate with each other by some grouping mechanism. > This group would be categorized as being stereo audio with one audio > stream being the left and the other the right. The codec used for each > could be different, though I agree they would typically be the same. > Consequently, I think at attribute such as "stereo" as being more of a > grouping concept, where the group may consist of: > - multiple independent streams, each with potentially its own spatial > orientation, codec, bandwidth, etc., > - a single mixed stream > > Cheers, > Charles > > > >> I was with you all the way until 4. That one I don't understand. > > >> The name you chose for this has connotations for me, but isn't > fully in > > >> harmony with the definitions you give: > > > > > > I'm happy to change the name if you have a suggestion > > > > Not yet. Maybe once the concepts are more clearly defined I will have > an > > opinion. > > > > >> If we consider audio, it makes sense that multiple streams can be > > >> rendered as if they came from different physical locations in the > > >> receiving room. That can be done by the receiver if it gets those > > >> streams separately, and has information about their intended > > >> relationships. It can also be done by the sender or MCU and passed > on > > >> to > > >> the receiver as a single stream with stereo or binaural coding. > > > > > > Yes. It could also be done by the sender using the "linear array" > audio channel format. Maybe it > > is true that stereo or binaural audio channels would always be sent > as > a single stream, but I was not > > assuming that yet, at least not in general when you consider other > types too, such as linear array > > channels. > > > > >> So it seems to me you have two concepts here, not one. One has to > do > > >> with describing the relationships between streams, and the other > has to > > >> do with the encoding of spacial relationships *within* a single > stream. > > > > > > Maybe that is a better way to describe it, if you assume > multi-channel audio is always sent with all > > the channels in the same RTP stream. Is that what you mean? > > > > > > I was considering the linear array format to be another type of > multi-channel audio, and I know > > people want to be able to send each channel in a separate RTP stream. > So it doesn't quite fit with > > how you separate the two concepts. In my view, identifying the > separate channels by what they mean is > > the same concept for linear array and stereo. For example "this > channel is left, this channel is > > center, this channel is right". To me, that is the same concept for > identifying channels whether or > > not they are carried in the same RTP stream. > > > > > > Maybe we are thinking the same thing but getting confused by > terminology about channels vs. streams. > > > > Maybe. Let me try to restate what I now think you are saying: > > > > The audio may consist of several "channels". > > > > Each channel may be sent over its own RTP stream, > > or multiple channels may be multiplexed over an RTP stream. > > > > I guess much of this can also apply to video. > > > > When there are exactly two audio channels, they may be encoded as > > "stereo" or "binaural", which then affects how they should be > rendered > > by the recipient. In these cases the primary info that is required > about > > the individual channels is which is left and which is right. (And > which > > perspective to use in interpretting left and right.) > > > > For other multi-channel cases more information is required about the > > role of each channel in order to properly render them. > > > > Thanks, > > Paul > > > > > > >> Or, are you asserting that stereo and binaural are simply ways to > > >> encode > > >> multiple logical streams in one RTP stream, together with their > spacial > > >> relationships? > > > > > > No, that is not what I'm trying to say. > > > > > > Mark > > > _______________________________________________ > > > 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 From eckelcu@cisco.com Mon Aug 15 14:44:35 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 EBF0221F8CF7 for ; Mon, 15 Aug 2011 14:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 MQLvl06noKQT for ; Mon, 15 Aug 2011 14:44:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66121F8CF8 for ; Mon, 15 Aug 2011 14:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7368; q=dns/txt; s=iport; t=1313444721; x=1314654321; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5+bdJbLTTrrV83tAtxLuXdFmj68l9yfx85NVfRig4zU=; b=Q2U/ErYEry/tTOZPioPSHuLJ4lWNxyzNBOPsgwpzEnnBYmPTFzTrfb3T 65dOPbS35schYlmFrjrQvRD/WnKio0fB//+xFJ++wJLhFVd2ARyxJOrqp bpQjBZahaZNvRfsgiI41VP+1zjnJbtXcq57x0NZMNrTFFx981k2kPI4Kd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAADOTSU6rRDoG/2dsb2JhbABBmEiPTneBQAEBAQEDAQEBDwEdCi0HBAcMBAIBCBEEAQEBCgYXAQYBIAYfCQgBAQQTCBqHUpxLAZ8EhWhfBIdfkEiEYYcf X-IronPort-AV: E=Sophos;i="4.67,376,1309737600"; d="scan'208";a="13347683" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 15 Aug 2011 21:45:20 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7FLjKT6008568; Mon, 15 Aug 2011 21:45:20 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 14:45:19 -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: Mon, 15 Aug 2011 14:45:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] continuing "layout" discussion Thread-Index: AcxbkD0Rs5kNuIj8Qvyg+A9Bk9uN5QAA9LrQ References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com><4E413021.3010509@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com><4E43D2BE.5010102@alum.mit.edu>

From: "Charles Eckel (eckelcu)" To: "Stephen Botzko" X-OriginalArrivalTime: 15 Aug 2011 21:45:19.0707 (UTC) FILETIME=[A0BF22B0:01CC5B94] Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 15 Aug 2011 21:44:36 -0000 > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Monday, August 15, 2011 2:14 PM > To: Charles Eckel (eckelcu) > Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion >=20 > Inline >=20 >=20 > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) wrote: >=20 >=20 > Please see inline. >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat >=20 > > Sent: Thursday, August 11, 2011 6:02 AM >=20 > > To: clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Inline > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of > > >> Paul Kyzivat > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > >> To: clue@ietf.org > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > >>> 4 - multi stream media format - what the streams mean with respect > to > > >> each other, regardless of the actual content on the streams. For > > >> audio, examples are stereo, 5.1 surround, binaural, linear array. > > >> (linear array is described in the clue framework document). > Perhaps 3D > > >> video formats would also fit in this category. This information is > > >> needed in order to properly render the media into light and sound > for > > >> human observers. I see this at the same level as identifying a > codec, > > >> independent of the audio or video content carried on the streams, > and > > >> independent of how any composition of sources is done. >=20 >=20 > I do not think this is necessarily true. Taking audio as an example, you > could have two audio streams that are mixed to form a single stereo > audio stream, or you could have them as two independent (not mixed) > streams that are associate with each other by some grouping mechanism. > This group would be categorized as being stereo audio with one audio > stream being the left and the other the right. The codec used for each > could be different, though I agree they would typically be the same. > Consequently, I think at attribute such as "stereo" as being more of a > grouping concept, where the group may consist of: > - multiple independent streams, each with potentially its own spatial > orientation, codec, bandwidth, etc., > - a single mixed stream >=20 >=20 >=20 > [sb] I do not understand this distinction. What do you mean when you say "two audio streams that are > mixed to form a single stereo stream", and how is this different from the left and right grouping? In one case they are mixed by the source of the stream into a single stream, and in another they are sent as two separate streams by the source. The end result once rendered at the receiver may be the same, but what is sent is different. This example with audio is perhaps too simple. If you think of it as video that is composed into a single video stream vs. multiple via streams that are sent individually, the difference may be more clear. Cheers, Charles >=20 >=20 >=20 > Cheers, > Charles >=20 >=20 > > >> I was with you all the way until 4. That one I don't understand. > > >> The name you chose for this has connotations for me, but isn't > fully in > > >> harmony with the definitions you give: > > > > > > I'm happy to change the name if you have a suggestion > > > > Not yet. Maybe once the concepts are more clearly defined I will have > an > > opinion. > > > > >> If we consider audio, it makes sense that multiple streams can be > > >> rendered as if they came from different physical locations in the > > >> receiving room. That can be done by the receiver if it gets those > > >> streams separately, and has information about their intended > > >> relationships. It can also be done by the sender or MCU and passed > on > > >> to > > >> the receiver as a single stream with stereo or binaural coding. > > > > > > Yes. It could also be done by the sender using the "linear array" > audio channel format. Maybe it > > is true that stereo or binaural audio channels would always be sent as > a single stream, but I was not > > assuming that yet, at least not in general when you consider other > types too, such as linear array > > channels. > > > > >> So it seems to me you have two concepts here, not one. One has to > do > > >> with describing the relationships between streams, and the other > has to > > >> do with the encoding of spacial relationships *within* a single > stream. > > > > > > Maybe that is a better way to describe it, if you assume > multi-channel audio is always sent with all > > the channels in the same RTP stream. Is that what you mean? > > > > > > I was considering the linear array format to be another type of > multi-channel audio, and I know > > people want to be able to send each channel in a separate RTP stream. > So it doesn't quite fit with > > how you separate the two concepts. In my view, identifying the > separate channels by what they mean is > > the same concept for linear array and stereo. For example "this > channel is left, this channel is > > center, this channel is right". To me, that is the same concept for > identifying channels whether or > > not they are carried in the same RTP stream. > > > > > > Maybe we are thinking the same thing but getting confused by > terminology about channels vs. streams. > > > > Maybe. Let me try to restate what I now think you are saying: > > > > The audio may consist of several "channels". > > > > Each channel may be sent over its own RTP stream, > > or multiple channels may be multiplexed over an RTP stream. > > > > I guess much of this can also apply to video. > > > > When there are exactly two audio channels, they may be encoded as > > "stereo" or "binaural", which then affects how they should be rendered > > by the recipient. In these cases the primary info that is required > about > > the individual channels is which is left and which is right. (And > which > > perspective to use in interpretting left and right.) > > > > For other multi-channel cases more information is required about the > > role of each channel in order to properly render them. > > > > Thanks, > > Paul > > > > > > >> Or, are you asserting that stereo and binaural are simply ways to > > >> encode > > >> multiple logical streams in one RTP stream, together with their > spacial > > >> relationships? > > > > > > No, that is not what I'm trying to say. > > > > > > Mark > > > _______________________________________________ > > > 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 >=20 >=20 From stephen.botzko@gmail.com Tue Aug 16 06:19:17 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 2F3AC21F8A91 for ; Tue, 16 Aug 2011 06:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.252, 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 diNnMxP6hUWR for ; Tue, 16 Aug 2011 06:19:15 -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 84F4B21F8A66 for ; Tue, 16 Aug 2011 06:19:15 -0700 (PDT) Received: by vxi29 with SMTP id 29so5824916vxi.31 for ; Tue, 16 Aug 2011 06:20: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=iXyg6FNU8DWbR9MUd987m7cVw+d7rCIaIdwJKUSsVww=; b=VX3ndrkbZ7V8iOHm1ZbJ+jsVItzIkJ0R5mTejtAuw8SnY2TTak55UEQAuXSR70hXwa DOhl3WOFmb8pAYSY8Z4znOBuXSL0OXyUIYWTBB97VQiKKX4+Ra4+dO4SjEbvXZXHR4yh hKZr49r0lQkU+naJvXGMmVM2a5oHcGNgst2OQ= MIME-Version: 1.0 Received: by 10.52.183.37 with SMTP id ej5mr4716438vdc.423.1313500803637; Tue, 16 Aug 2011 06:20:03 -0700 (PDT) Received: by 10.52.115.103 with HTTP; Tue, 16 Aug 2011 06:20:03 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu>

Date: Tue, 16 Aug 2011 09:20:03 -0400 Message-ID: From: Stephen Botzko To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=bcaec548a379d0220a04aa9f3cac Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 16 Aug 2011 13:19:17 -0000 --bcaec548a379d0220a04aa9f3cac Content-Type: text/plain; charset=ISO-8859-1 I guess by "stream" you are meaning RTP stream? in which case by "mix" you perhaps mean that the left and right channels are placed in a single RTP stream??? What do you mean when you describe some audio captures as "independent" - are you thinking they come from different rooms???. I think in many respects audio distribution and spatial audio layout is at least as difficult as video layout, and have some unique issues. For one thing, you need to sort out how you should place the audio from human participants who are not on camera, and what should happen later on if some of those participants are shown. I suggest it is necessary to be very careful with terminology. In particular, I think it is important to distinguish composition from RTP transmission. Regards, Stephen Botzko On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) wrote: > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Monday, August 15, 2011 2:14 PM > > To: Charles Eckel (eckelcu) > > Cc: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Inline > > > > > > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) > wrote: > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of Paul Kyzivat > > > > > Sent: Thursday, August 11, 2011 6:02 AM > > > > > To: clue@ietf.org > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > Inline > > > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > > >> -----Original Message----- > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > On > > Behalf Of > > > >> Paul Kyzivat > > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > > >> To: clue@ietf.org > > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > > > >>> 4 - multi stream media format - what the streams mean with > respect > > to > > > >> each other, regardless of the actual content on the > streams. For > > > >> audio, examples are stereo, 5.1 surround, binaural, linear > array. > > > >> (linear array is described in the clue framework document). > > Perhaps 3D > > > >> video formats would also fit in this category. This > information is > > > >> needed in order to properly render the media into light and > sound > > for > > > >> human observers. I see this at the same level as > identifying a > > codec, > > > >> independent of the audio or video content carried on the > streams, > > and > > > >> independent of how any composition of sources is done. > > > > > > I do not think this is necessarily true. Taking audio as an > example, you > > could have two audio streams that are mixed to form a single > stereo > > audio stream, or you could have them as two independent (not > mixed) > > streams that are associate with each other by some grouping > mechanism. > > This group would be categorized as being stereo audio with one > audio > > stream being the left and the other the right. The codec used > for each > > could be different, though I agree they would typically be the > same. > > Consequently, I think at attribute such as "stereo" as being > more of a > > grouping concept, where the group may consist of: > > - multiple independent streams, each with potentially its own > spatial > > orientation, codec, bandwidth, etc., > > - a single mixed stream > > > > > > > > [sb] I do not understand this distinction. What do you mean when you > say "two audio streams that are > > mixed to form a single stereo stream", and how is this different from > the left and right grouping? > > In one case they are mixed by the source of the stream into a single > stream, and in another they are sent as two separate streams by the > source. The end result once rendered at the receiver may be the same, > but what is sent is different. This example with audio is perhaps too > simple. If you think of it as video that is composed into a single video > stream vs. multiple via streams that are sent individually, the > difference may be more clear. > > Cheers, > Charles > > > > > > > > > Cheers, > > Charles > > > > > > > >> I was with you all the way until 4. That one I don't > understand. > > > >> The name you chose for this has connotations for me, but > isn't > > fully in > > > >> harmony with the definitions you give: > > > > > > > > I'm happy to change the name if you have a suggestion > > > > > > Not yet. Maybe once the concepts are more clearly defined I > will have > > an > > > opinion. > > > > > > >> If we consider audio, it makes sense that multiple streams > can be > > > >> rendered as if they came from different physical locations > in the > > > >> receiving room. That can be done by the receiver if it gets > those > > > >> streams separately, and has information about their > intended > > > >> relationships. It can also be done by the sender or MCU and > passed > > on > > > >> to > > > >> the receiver as a single stream with stereo or binaural > coding. > > > > > > > > Yes. It could also be done by the sender using the "linear > array" > > audio channel format. Maybe it > > > is true that stereo or binaural audio channels would always be > sent as > > a single stream, but I was not > > > assuming that yet, at least not in general when you consider > other > > types too, such as linear array > > > channels. > > > > > > >> So it seems to me you have two concepts here, not one. One > has to > > do > > > >> with describing the relationships between streams, and the > other > > has to > > > >> do with the encoding of spacial relationships *within* a > single > > stream. > > > > > > > > Maybe that is a better way to describe it, if you assume > > multi-channel audio is always sent with all > > > the channels in the same RTP stream. Is that what you mean? > > > > > > > > I was considering the linear array format to be another type > of > > multi-channel audio, and I know > > > people want to be able to send each channel in a separate RTP > stream. > > So it doesn't quite fit with > > > how you separate the two concepts. In my view, identifying > the > > separate channels by what they mean is > > > the same concept for linear array and stereo. For example > "this > > channel is left, this channel is > > > center, this channel is right". To me, that is the same > concept for > > identifying channels whether or > > > not they are carried in the same RTP stream. > > > > > > > > Maybe we are thinking the same thing but getting confused by > > terminology about channels vs. streams. > > > > > > Maybe. Let me try to restate what I now think you are saying: > > > > > > The audio may consist of several "channels". > > > > > > Each channel may be sent over its own RTP stream, > > > or multiple channels may be multiplexed over an RTP stream. > > > > > > I guess much of this can also apply to video. > > > > > > When there are exactly two audio channels, they may be encoded > as > > > "stereo" or "binaural", which then affects how they should be > rendered > > > by the recipient. In these cases the primary info that is > required > > about > > > the individual channels is which is left and which is right. > (And > > which > > > perspective to use in interpretting left and right.) > > > > > > For other multi-channel cases more information is required > about the > > > role of each channel in order to properly render them. > > > > > > Thanks, > > > Paul > > > > > > > > > >> Or, are you asserting that stereo and binaural are simply > ways to > > > >> encode > > > >> multiple logical streams in one RTP stream, together with > their > > spacial > > > >> relationships? > > > > > > > > No, that is not what I'm trying to say. > > > > > > > > Mark > > > > _______________________________________________ > > > > 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 > > > > > > --bcaec548a379d0220a04aa9f3cac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess by "stream" you are meaning RTP stream?=A0 in which case = by "mix" you perhaps mean that the left and right channels are pl= aced in a single RTP stream???=A0 What do you mean when you describe some a= udio captures as "independent" - are you thinking they come from = different rooms???.

I think in many respects audio distribution and spatial audio layout is= at least as difficult as video layout, and have some unique issues.=A0 For= one thing, you need to sort out how you should place the audio from human = participants who are not on camera, and what should happen later on if some= of those participants are shown.=A0

I suggest it is necessary to be very careful with terminology.=A0 In pa= rticular, I think it is important to distinguish composition from RTP trans= mission.

Regards,
Stephen Botzko

On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) = <eckelcu@cisco.com> w= rote:

> -----Original Message-----
> From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> Sent: Monday, August 15, 2011 2:14 PM
> To: Charles Eckel (eckelcu)
> Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion
>
> Inline
>
>
> On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu)
<eckelcu@cisco.com> wrote: >
>
> =A0 =A0 =A0 Please see inline.
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: clue-b= ounces@ietf.org [mailto:clue-b= ounces@ietf.org] On
Behalf
> =A0 =A0 =A0 Of Paul Kyzivat
>
> =A0 =A0 =A0 > Sent: Thursday, August 11, 2011 6:02 AM
>
> =A0 =A0 =A0 > To: clue@ietf.org
> =A0 =A0 =A0 > Subject: Re: [clue] continuing "layout" dis= cussion
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Inline
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On 8/10/11 5:49 PM, Duckworth, Mark wrote:
> =A0 =A0 =A0 > >> -----Original Message-----
> =A0 =A0 =A0 > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]
On
> =A0 =A0 =A0 Behalf Of
> =A0 =A0 =A0 > >> Paul Kyzivat
> =A0 =A0 =A0 > >> Sent: Tuesday, August 09, 2011 9:03 AM
> =A0 =A0 =A0 > >> To: clue@ie= tf.org
> =A0 =A0 =A0 > >> Subject: Re: [clue] continuing "layout&= quot; discussion
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >>> 4 - multi stream media format - what the= streams mean with
respect
> =A0 =A0 =A0 to
> =A0 =A0 =A0 > >> each other, regardless of the actual content= on the
streams. =A0For
> =A0 =A0 =A0 > >> audio, examples are stereo, 5.1 surround, bi= naural, linear
array.
> =A0 =A0 =A0 > >> (linear array is described in the clue frame= work document).
> =A0 =A0 =A0 Perhaps 3D
> =A0 =A0 =A0 > >> video formats would also fit in this categor= y. =A0This
information is
> =A0 =A0 =A0 > >> needed in order to properly render the media= into light and
sound
> =A0 =A0 =A0 for
> =A0 =A0 =A0 > >> human observers. =A0I see this at the same l= evel as
identifying a
> =A0 =A0 =A0 codec,
> =A0 =A0 =A0 > >> independent of the audio or video content ca= rried on the
streams,
> =A0 =A0 =A0 and
> =A0 =A0 =A0 > >> independent of how any composition of source= s is done.
>
>
> =A0 =A0 =A0 I do not think this is necessarily true. Taking audio as a= n
example, you
> =A0 =A0 =A0 could have two audio streams that are mixed to form a sing= le
stereo
> =A0 =A0 =A0 audio stream, or you could have them as two independent (n= ot
mixed)
> =A0 =A0 =A0 streams that are associate with each other by some groupin= g
mechanism.
> =A0 =A0 =A0 This group would be categorized as being stereo audio with= one
audio
> =A0 =A0 =A0 stream being the left and the other the right. The codec u= sed
for each
> =A0 =A0 =A0 could be different, though I agree they would typically be= the
same.
> =A0 =A0 =A0 Consequently, I think at attribute such as "stereo&qu= ot; as being
more of a
> =A0 =A0 =A0 grouping concept, where the group may consist of:
> =A0 =A0 =A0 - multiple independent streams, each with potentially its = own
spatial
> =A0 =A0 =A0 orientation, codec, bandwidth, etc.,
> =A0 =A0 =A0 - a single mixed stream
>
>
>
> [sb] I do not understand this distinction. =A0What do you mean when yo= u
say "two audio streams that are
> mixed to form a single stereo stream", and how is this different = from
the left and right grouping?

In one case they are mixed by the source of the stream into a s= ingle
stream, and in another they are sent as two separate streams by the
source. The end result once rendered at the receiver may be the same,
but what is sent is different. This example with audio is perhaps too
simple. If you think of it as video that is composed into a single video stream vs. multiple via streams that are sent individually, the
difference may be more clear.

Cheers,
Charles

>
>
>
> =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 Charles
>
>
> =A0 =A0 =A0 > >> I was with you all the way until 4. That one= I don't
understand.
> =A0 =A0 =A0 > >> The name you chose for this has connotations= for me, but
isn't
> =A0 =A0 =A0 fully in
> =A0 =A0 =A0 > >> harmony with the definitions you give:
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > I'm happy to change the name if you have a s= uggestion
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Not yet. Maybe once the concepts are more clearly def= ined I
will have
> =A0 =A0 =A0 an
> =A0 =A0 =A0 > opinion.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > >> If we consider audio, it makes sense that mu= ltiple streams
can be
> =A0 =A0 =A0 > >> rendered as if they came from different phys= ical locations
in the
> =A0 =A0 =A0 > >> receiving room. That can be done by the rece= iver if it gets
those
> =A0 =A0 =A0 > >> streams separately, and has information abou= t their
intended
> =A0 =A0 =A0 > >> relationships. It can also be done by the se= nder or MCU and
passed
> =A0 =A0 =A0 on
> =A0 =A0 =A0 > >> to
> =A0 =A0 =A0 > >> the receiver as a single stream with stereo = or binaural
coding.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Yes. =A0It could also be done by the sender usin= g the "linear
array"
> =A0 =A0 =A0 audio channel format. =A0Maybe it
> =A0 =A0 =A0 > is true that stereo or binaural audio channels would = always be
sent as
> =A0 =A0 =A0 a single stream, but I was not
> =A0 =A0 =A0 > assuming that yet, at least not in general when you c= onsider
other
> =A0 =A0 =A0 types too, such as linear array
> =A0 =A0 =A0 > channels.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > >> So it seems to me you have two concepts here= , not one. One
has to
> =A0 =A0 =A0 do
> =A0 =A0 =A0 > >> with describing the relationships between st= reams, and the
other
> =A0 =A0 =A0 has to
> =A0 =A0 =A0 > >> do with the encoding of spacial relationship= s *within* a
single
> =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Maybe that is a better way to describe it, if yo= u assume
> =A0 =A0 =A0 multi-channel audio is always sent with all
> =A0 =A0 =A0 > the channels in the same RTP stream. =A0Is that what = you mean?
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > I was considering the linear array format to be = another type
of
> =A0 =A0 =A0 multi-channel audio, and I know
> =A0 =A0 =A0 > people want to be able to send each channel in a sepa= rate RTP
stream.
> =A0 =A0 =A0 So it doesn't quite fit with
> =A0 =A0 =A0 > how you separate the two concepts. =A0In my view, ide= ntifying
the
> =A0 =A0 =A0 separate channels by what they mean is
> =A0 =A0 =A0 > the same concept for linear array and stereo. =A0For = example
"this
> =A0 =A0 =A0 channel is left, this channel is
> =A0 =A0 =A0 > center, this channel is right". =A0To me, that i= s the same
concept for
> =A0 =A0 =A0 identifying channels whether or
> =A0 =A0 =A0 > not they are carried in the same RTP stream.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Maybe we are thinking the same thing but getting= confused by
> =A0 =A0 =A0 terminology about channels vs. streams.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Maybe. Let me try to restate what I now think you are= saying:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The audio may consist of several "channels"= .
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Each channel may be sent over its own RTP stream,
> =A0 =A0 =A0 > or multiple channels may be multiplexed over an RTP s= tream.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I guess much of this can also apply to video.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > When there are exactly two audio channels, they may b= e encoded
as
> =A0 =A0 =A0 > "stereo" or "binaural", which the= n affects how they should be
rendered
> =A0 =A0 =A0 > by the recipient. In these cases the primary info tha= t is
required
> =A0 =A0 =A0 about
> =A0 =A0 =A0 > the individual channels is which is left and which is= right.
(And
> =A0 =A0 =A0 which
> =A0 =A0 =A0 > perspective to use in interpretting left and right.)<= br> > =A0 =A0 =A0 >
> =A0 =A0 =A0 > For other multi-channel cases more information is req= uired
about the
> =A0 =A0 =A0 > role of each channel in order to properly render them= .
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 > =A0 =A0 =A0 Paul
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > >> Or, are you asserting that stereo and binaur= al are simply
ways to
> =A0 =A0 =A0 > >> encode
> =A0 =A0 =A0 > >> multiple logical streams in one RTP stream, = together with
their
> =A0 =A0 =A0 spacial
> =A0 =A0 =A0 > >> relationships?
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > No, that is not what I'm trying to say.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Mark
> =A0 =A0 =A0 > > _______________________________________________<= br> > =A0 =A0 =A0 > > clue mailing list
> =A0 =A0 =A0 > > clue@ietf.org
> =A0 =A0 =A0 > > https://www.ietf.org/mailman/listinfo/clue
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > _______________________________________________
> =A0 =A0 =A0 > clue mailing list
> =A0 =A0 =A0 > clue@ietf.org > =A0 =A0 =A0 > https://www.ietf.org/mailman/listinfo/clue
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 clue mailing list
> =A0 =A0 =A0 clue@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue
>
>

--bcaec548a379d0220a04aa9f3cac-- From eckelcu@cisco.com Tue Aug 16 13:22: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 125BC21F8B00 for ; Tue, 16 Aug 2011 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 wNqAXf0jAQZ2 for ; Tue, 16 Aug 2011 13:22:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BF65F21F8B03 for ; Tue, 16 Aug 2011 13:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=10596; q=dns/txt; s=iport; t=1313526186; x=1314735786; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0pDGZ6RW2jCmqRSMlQZYkVvS5cCRaJAxsjukysnwgi8=; b=QH3dr6VGm9tGGWxiVV9P+gRt8E7YxSqLnmg+U/brJG4h4D0B3OKiSu/s +88VyoC9nsrJhdcbzftgF198nsD8ZEz+Yt37JacqqEpdLmwsyytzdXPEG /4mBcWt4s0WxpTbq54UaTEJVMoxzwes+HkYJCsu+c1asN1L0tqlqtsUgV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAM/QSk6rRDoG/2dsb2JhbABBmG6PVXeBQAEBAQEDAQEBDwEdCi0HBAcMBAIBCBEEAQEBCgYXAQYBIAYfCQgBAQQTCBqHUpp3AZ84hWlfBIdfkEiEYYcf X-IronPort-AV: E=Sophos;i="4.68,235,1312156800"; d="scan'208";a="13699421" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 16 Aug 2011 20:23:05 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7GKN46H029326; Tue, 16 Aug 2011 20:23:05 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 13:23:02 -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: Tue, 16 Aug 2011 13:23:01 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] continuing "layout" discussion Thread-Index: AcxcFzb78VHrrjMFQ4imR+ZssKuA5AAOduhA References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com><4E413021.3010509@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com><4E43D2BE.5010102@alum.mit.edu>

From: "Charles Eckel (eckelcu)" To: "Stephen Botzko" X-OriginalArrivalTime: 16 Aug 2011 20:23:02.0731 (UTC) FILETIME=[4C7E21B0:01CC5C52] Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 16 Aug 2011 20:22:18 -0000 I am distinguishing between: (1) a single RTP stream that consists of a single stereo audio stream (2) two RTP streams, one that contains left speaker audio and the other than contains right speaker audio (2) could also be transmitted in a single RTP stream using SSRC multiplexing. Let me call that (2b).=20 (2) and (2b) are essentially the same. Just the RTP mechanism employed is difference. (1) is different from (2) and (2b) in that the audio signal encoded is actually different. Cheers, Charles > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Tuesday, August 16, 2011 6:20 AM > To: Charles Eckel (eckelcu) > Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion >=20 > I guess by "stream" you are meaning RTP stream? in which case by "mix" you perhaps mean that the left > and right channels are placed in a single RTP stream??? What do you mean when you describe some audio > captures as "independent" - are you thinking they come from different rooms???. >=20 > I think in many respects audio distribution and spatial audio layout is at least as difficult as video > layout, and have some unique issues. For one thing, you need to sort out how you should place the > audio from human participants who are not on camera, and what should happen later on if some of those > participants are shown. >=20 > I suggest it is necessary to be very careful with terminology. In particular, I think it is important > to distinguish composition from RTP transmission. >=20 > Regards, > Stephen Botzko >=20 >=20 >=20 > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) wrote: >=20 >=20 > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Monday, August 15, 2011 2:14 PM > > To: Charles Eckel (eckelcu) > > Cc: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Inline > > > > > > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) > wrote: > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of Paul Kyzivat > > > > > Sent: Thursday, August 11, 2011 6:02 AM > > > > > To: clue@ietf.org > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > Inline > > > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > > >> -----Original Message----- > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > On > > Behalf Of > > > >> Paul Kyzivat > > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > > >> To: clue@ietf.org > > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > > > >>> 4 - multi stream media format - what the streams mean with > respect > > to > > > >> each other, regardless of the actual content on the > streams. For > > > >> audio, examples are stereo, 5.1 surround, binaural, linear > array. > > > >> (linear array is described in the clue framework document). > > Perhaps 3D > > > >> video formats would also fit in this category. This > information is > > > >> needed in order to properly render the media into light and > sound > > for > > > >> human observers. I see this at the same level as > identifying a > > codec, > > > >> independent of the audio or video content carried on the > streams, > > and > > > >> independent of how any composition of sources is done. > > > > > > I do not think this is necessarily true. Taking audio as an > example, you > > could have two audio streams that are mixed to form a single > stereo > > audio stream, or you could have them as two independent (not > mixed) > > streams that are associate with each other by some grouping > mechanism. > > This group would be categorized as being stereo audio with one > audio > > stream being the left and the other the right. The codec used > for each > > could be different, though I agree they would typically be the > same. > > Consequently, I think at attribute such as "stereo" as being > more of a > > grouping concept, where the group may consist of: > > - multiple independent streams, each with potentially its own > spatial > > orientation, codec, bandwidth, etc., > > - a single mixed stream > > > > > > > > [sb] I do not understand this distinction. What do you mean when you > say "two audio streams that are > > mixed to form a single stereo stream", and how is this different from > the left and right grouping? >=20 >=20 > In one case they are mixed by the source of the stream into a single > stream, and in another they are sent as two separate streams by the > source. The end result once rendered at the receiver may be the same, > but what is sent is different. This example with audio is perhaps too > simple. If you think of it as video that is composed into a single video > stream vs. multiple via streams that are sent individually, the > difference may be more clear. >=20 > Cheers, > Charles >=20 >=20 > > > > > > > > Cheers, > > Charles > > > > > > > >> I was with you all the way until 4. That one I don't > understand. > > > >> The name you chose for this has connotations for me, but > isn't > > fully in > > > >> harmony with the definitions you give: > > > > > > > > I'm happy to change the name if you have a suggestion > > > > > > Not yet. Maybe once the concepts are more clearly defined I > will have > > an > > > opinion. > > > > > > >> If we consider audio, it makes sense that multiple streams > can be > > > >> rendered as if they came from different physical locations > in the > > > >> receiving room. That can be done by the receiver if it gets > those > > > >> streams separately, and has information about their > intended > > > >> relationships. It can also be done by the sender or MCU and > passed > > on > > > >> to > > > >> the receiver as a single stream with stereo or binaural > coding. > > > > > > > > Yes. It could also be done by the sender using the "linear > array" > > audio channel format. Maybe it > > > is true that stereo or binaural audio channels would always be > sent as > > a single stream, but I was not > > > assuming that yet, at least not in general when you consider > other > > types too, such as linear array > > > channels. > > > > > > >> So it seems to me you have two concepts here, not one. One > has to > > do > > > >> with describing the relationships between streams, and the > other > > has to > > > >> do with the encoding of spacial relationships *within* a > single > > stream. > > > > > > > > Maybe that is a better way to describe it, if you assume > > multi-channel audio is always sent with all > > > the channels in the same RTP stream. Is that what you mean? > > > > > > > > I was considering the linear array format to be another type > of > > multi-channel audio, and I know > > > people want to be able to send each channel in a separate RTP > stream. > > So it doesn't quite fit with > > > how you separate the two concepts. In my view, identifying > the > > separate channels by what they mean is > > > the same concept for linear array and stereo. For example > "this > > channel is left, this channel is > > > center, this channel is right". To me, that is the same > concept for > > identifying channels whether or > > > not they are carried in the same RTP stream. > > > > > > > > Maybe we are thinking the same thing but getting confused by > > terminology about channels vs. streams. > > > > > > Maybe. Let me try to restate what I now think you are saying: > > > > > > The audio may consist of several "channels". > > > > > > Each channel may be sent over its own RTP stream, > > > or multiple channels may be multiplexed over an RTP stream. > > > > > > I guess much of this can also apply to video. > > > > > > When there are exactly two audio channels, they may be encoded > as > > > "stereo" or "binaural", which then affects how they should be > rendered > > > by the recipient. In these cases the primary info that is > required > > about > > > the individual channels is which is left and which is right. > (And > > which > > > perspective to use in interpretting left and right.) > > > > > > For other multi-channel cases more information is required > about the > > > role of each channel in order to properly render them. > > > > > > Thanks, > > > Paul > > > > > > > > > >> Or, are you asserting that stereo and binaural are simply > ways to > > > >> encode > > > >> multiple logical streams in one RTP stream, together with > their > > spacial > > > >> relationships? > > > > > > > > No, that is not what I'm trying to say. > > > > > > > > Mark > > > > _______________________________________________ > > > > 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 > > > > >=20 >=20 >=20 From stephen.botzko@gmail.com Tue Aug 16 14:13: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 DE79911E808E for ; Tue, 16 Aug 2011 14:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.239, 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 fqlBH4xZkGrr for ; Tue, 16 Aug 2011 14:13:27 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0679821F8B4F for ; Tue, 16 Aug 2011 14:13:12 -0700 (PDT) Received: by qyk34 with SMTP id 34so1664467qyk.10 for ; Tue, 16 Aug 2011 14:14: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=5bgFaOcsaoUom7MlZiOdQwfo3lnv1Jl2rz/OVZ+99aY=; b=j9CcQqHy0chECr0SFOaj1iayn48nvP4Am+OSpGlbz9KNmVm6lBJ55kE4mL9DMwkDv8 x9UfIHIHA7K5F3MjXJuBWClgk776jsyIvUQermJ85dP0Fko7Vw9cO90baQEHnXzBYp8+ UiNqV34xsBuyim8piaYkXmqLcSpgBwZSq+60Q= MIME-Version: 1.0 Received: by 10.52.182.6 with SMTP id ea6mr244566vdc.222.1313529241937; Tue, 16 Aug 2011 14:14:01 -0700 (PDT) Received: by 10.52.115.103 with HTTP; Tue, 16 Aug 2011 14:14:01 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu>

Date: Tue, 16 Aug 2011 17:14:01 -0400 Message-ID: From: Stephen Botzko To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=bcaec5486194de26c404aaa5dbd8 Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 16 Aug 2011 21:13:29 -0000 --bcaec5486194de26c404aaa5dbd8 Content-Type: text/plain; charset=ISO-8859-1 Well, the audio in (1) and (2b) is certainly packetized differently. But not compressed differently (unless you are assuming that the signal in (1) is jointly encoded stereo - which it could be I guess, but it would be unusual for telepresence systems). Also, the audio in (1) is not mixed, no matter how it is encoded. In any event, I believe that the difference between (1) and (2) and (2b) is really a transport question that has nothing to do with layout. The same information is needed to enable proper rendering, and once the streams are received, they are rendered in precisely the same way. Regards, Stephen Botzko On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu) wrote: > I am distinguishing between: > > (1) a single RTP stream that consists of a single stereo audio stream > (2) two RTP streams, one that contains left speaker audio and the other > than contains right speaker audio > > (2) could also be transmitted in a single RTP stream using SSRC > multiplexing. Let me call that (2b). > (2) and (2b) are essentially the same. Just the RTP mechanism employed > is difference. > (1) is different from (2) and (2b) in that the audio signal encoded is > actually different. > > Cheers, > Charles > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Tuesday, August 16, 2011 6:20 AM > > To: Charles Eckel (eckelcu) > > Cc: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > I guess by "stream" you are meaning RTP stream? in which case by > "mix" you perhaps mean that the left > > and right channels are placed in a single RTP stream??? What do you > mean when you describe some audio > > captures as "independent" - are you thinking they come from different > rooms???. > > > > I think in many respects audio distribution and spatial audio layout > is at least as difficult as video > > layout, and have some unique issues. For one thing, you need to sort > out how you should place the > > audio from human participants who are not on camera, and what should > happen later on if some of those > > participants are shown. > > > > I suggest it is necessary to be very careful with terminology. In > particular, I think it is important > > to distinguish composition from RTP transmission. > > > > Regards, > > Stephen Botzko > > > > > > > > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) > wrote: > > > > > > > -----Original Message----- > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Monday, August 15, 2011 2:14 PM > > > To: Charles Eckel (eckelcu) > > > Cc: Paul Kyzivat; clue@ietf.org > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > Inline > > > > > > > > > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) > > wrote: > > > > > > > > > Please see inline. > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > Behalf > > > Of Paul Kyzivat > > > > > > > Sent: Thursday, August 11, 2011 6:02 AM > > > > > > > To: clue@ietf.org > > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > > > Inline > > > > > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > > > >> -----Original Message----- > > > > >> From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] > > On > > > Behalf Of > > > > >> Paul Kyzivat > > > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > > > >> To: clue@ietf.org > > > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > > > > > >>> 4 - multi stream media format - what the streams > mean with > > respect > > > to > > > > >> each other, regardless of the actual content on the > > streams. For > > > > >> audio, examples are stereo, 5.1 surround, binaural, > linear > > array. > > > > >> (linear array is described in the clue framework > document). > > > Perhaps 3D > > > > >> video formats would also fit in this category. > This > > information is > > > > >> needed in order to properly render the media into > light and > > sound > > > for > > > > >> human observers. I see this at the same level as > > identifying a > > > codec, > > > > >> independent of the audio or video content carried > on the > > streams, > > > and > > > > >> independent of how any composition of sources is > done. > > > > > > > > > I do not think this is necessarily true. Taking audio as > an > > example, you > > > could have two audio streams that are mixed to form a > single > > stereo > > > audio stream, or you could have them as two independent > (not > > mixed) > > > streams that are associate with each other by some > grouping > > mechanism. > > > This group would be categorized as being stereo audio > with one > > audio > > > stream being the left and the other the right. The codec > used > > for each > > > could be different, though I agree they would typically > be the > > same. > > > Consequently, I think at attribute such as "stereo" as > being > > more of a > > > grouping concept, where the group may consist of: > > > - multiple independent streams, each with potentially > its own > > spatial > > > orientation, codec, bandwidth, etc., > > > - a single mixed stream > > > > > > > > > > > > [sb] I do not understand this distinction. What do you mean > when you > > say "two audio streams that are > > > mixed to form a single stereo stream", and how is this > different from > > the left and right grouping? > > > > > > In one case they are mixed by the source of the stream into a > single > > stream, and in another they are sent as two separate streams by > the > > source. The end result once rendered at the receiver may be the > same, > > but what is sent is different. This example with audio is > perhaps too > > simple. If you think of it as video that is composed into a > single video > > stream vs. multiple via streams that are sent individually, the > > difference may be more clear. > > > > Cheers, > > Charles > > > > > > > > > > > > > > > > Cheers, > > > Charles > > > > > > > > > > >> I was with you all the way until 4. That one I > don't > > understand. > > > > >> The name you chose for this has connotations for > me, but > > isn't > > > fully in > > > > >> harmony with the definitions you give: > > > > > > > > > > I'm happy to change the name if you have a > suggestion > > > > > > > > Not yet. Maybe once the concepts are more clearly > defined I > > will have > > > an > > > > opinion. > > > > > > > > >> If we consider audio, it makes sense that multiple > streams > > can be > > > > >> rendered as if they came from different physical > locations > > in the > > > > >> receiving room. That can be done by the receiver if > it gets > > those > > > > >> streams separately, and has information about their > > intended > > > > >> relationships. It can also be done by the sender or > MCU and > > passed > > > on > > > > >> to > > > > >> the receiver as a single stream with stereo or > binaural > > coding. > > > > > > > > > > Yes. It could also be done by the sender using the > "linear > > array" > > > audio channel format. Maybe it > > > > is true that stereo or binaural audio channels would > always be > > sent as > > > a single stream, but I was not > > > > assuming that yet, at least not in general when you > consider > > other > > > types too, such as linear array > > > > channels. > > > > > > > > >> So it seems to me you have two concepts here, not > one. One > > has to > > > do > > > > >> with describing the relationships between streams, > and the > > other > > > has to > > > > >> do with the encoding of spacial relationships > *within* a > > single > > > stream. > > > > > > > > > > Maybe that is a better way to describe it, if you > assume > > > multi-channel audio is always sent with all > > > > the channels in the same RTP stream. Is that what you > mean? > > > > > > > > > > I was considering the linear array format to be > another type > > of > > > multi-channel audio, and I know > > > > people want to be able to send each channel in a > separate RTP > > stream. > > > So it doesn't quite fit with > > > > how you separate the two concepts. In my view, > identifying > > the > > > separate channels by what they mean is > > > > the same concept for linear array and stereo. For > example > > "this > > > channel is left, this channel is > > > > center, this channel is right". To me, that is the > same > > concept for > > > identifying channels whether or > > > > not they are carried in the same RTP stream. > > > > > > > > > > Maybe we are thinking the same thing but getting > confused by > > > terminology about channels vs. streams. > > > > > > > > Maybe. Let me try to restate what I now think you are > saying: > > > > > > > > The audio may consist of several "channels". > > > > > > > > Each channel may be sent over its own RTP stream, > > > > or multiple channels may be multiplexed over an RTP > stream. > > > > > > > > I guess much of this can also apply to video. > > > > > > > > When there are exactly two audio channels, they may be > encoded > > as > > > > "stereo" or "binaural", which then affects how they > should be > > rendered > > > > by the recipient. In these cases the primary info that > is > > required > > > about > > > > the individual channels is which is left and which is > right. > > (And > > > which > > > > perspective to use in interpretting left and right.) > > > > > > > > For other multi-channel cases more information is > required > > about the > > > > role of each channel in order to properly render them. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > > > >> Or, are you asserting that stereo and binaural are > simply > > ways to > > > > >> encode > > > > >> multiple logical streams in one RTP stream, > together with > > their > > > spacial > > > > >> relationships? > > > > > > > > > > No, that is not what I'm trying to say. > > > > > > > > > > Mark > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > --bcaec5486194de26c404aaa5dbd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, the audio in (1) and (2b) is certainly packetized differently.=A0 But= not compressed differently (unless you are assuming that the signal in (1)= is jointly encoded stereo - which it could be I guess, but it would be unu= sual for telepresence systems). Also, the audio in (1) is not mixed, no mat= ter how it is encoded.

In any event, I believe that the difference between (1) and (2) and (2b= ) is really a transport question that has nothing to do with layout. The sa= me information is needed to enable proper rendering, and once the streams a= re received, they are rendered in precisely the same way.

Regards,
Stephen Botzko

On Tue, Au= g 16, 2011 at 4:23 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> I am distinguishing between:

(1) a single RTP stream that consists of a single stereo audio stream
(2) two RTP streams, one that contains left speaker audio and the other
than contains right speaker audio

(2) could also be transmitted in a single RTP stream using SSRC
multiplexing. Let me call that (2b).
(2) and (2b) are essentially the same. Just the RTP mechanism employed
is difference.
(1) is different from (2) and (2b) in that the audio signal encoded is
actually different.

Cheers,
Charles

> -----Original Message-----
> From: Stephen Botzko [mailto:stephen.botzko@gmail.com]

> Sent: Tuesday, August 16, 2011= 6:20 AM
> To: Charles Eckel (eckelcu)
> Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion
>
> I guess by "stream" you are meaning RTP stream? =A0in which = case by
"mix" you perhaps mean that the left
> and right channels are placed in a single RTP stream??? =A0What do you=
mean when you describe some audio
> captures as "independent" - are you thinking they come from = different
rooms???.
>
> I think in many respects audio distribution and spatial audio layout is at least as difficult as video
> layout, and have some unique issues. =A0For one thing, you need to sor= t
out how you should place the
> audio from human participants who are not on camera, and what should happen later on if some of those
> participants are shown.
>
> I suggest it is necessary to be very careful with terminology. =A0In particular, I think it is important
> to distinguish composition from RTP transmission.
>
> Regards,
> Stephen Botzko
>
>
>
> On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu)
<eckelcu@cisco.com> wrote: >
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> =A0 =A0 =A0 > Sent: Monday, August 15, 2011 2:14 PM
> =A0 =A0 =A0 > To: Charles Eckel (eckelcu)
> =A0 =A0 =A0 > Cc: Paul Kyzivat; cl= ue@ietf.org
> =A0 =A0 =A0 > Subject: Re: [clue] continuing "layout" dis= cussion
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Inline
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckel= cu)
> =A0 =A0 =A0 <eckelcu@cisco.com= > wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Please see inline.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > =A0 =A0 =A0 > From: clue-bounces@ietf.org
[mailto:clue-bounces@ietf.org]= On
> =A0 =A0 =A0 Behalf
> =A0 =A0 =A0 > =A0 =A0 =A0 Of Paul Kyzivat
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, August 11, 2011 6:02= AM
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > To: clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [clue] continuing "= ;layout" discussion
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Inline
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > On 8/10/11 5:49 PM, Duckworth, Mark = wrote:
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> -----Original Message-----<= br> > =A0 =A0 =A0 > =A0 =A0 =A0 > >> From: clue-bounces@ietf.org
[mailto:clue-bounces@ietf.org]=
> =A0 =A0 =A0 On
> =A0 =A0 =A0 > =A0 =A0 =A0 Behalf Of
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> Paul Kyzivat
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> Sent: Tuesday, August 09, 2= 011 9:03 AM
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> To: clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> Subject: Re: [clue] continu= ing "layout" discussion
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > >>> 4 - multi stream media = format - what the streams
mean with
> =A0 =A0 =A0 respect
> =A0 =A0 =A0 > =A0 =A0 =A0 to
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> each other, regardless of t= he actual content on the
> =A0 =A0 =A0 streams. =A0For
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> audio, examples are stereo,= 5.1 surround, binaural,
linear
> =A0 =A0 =A0 array.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> (linear array is described = in the clue framework
document).
> =A0 =A0 =A0 > =A0 =A0 =A0 Perhaps 3D
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> video formats would also fi= t in this category.
This
> =A0 =A0 =A0 information is
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> needed in order to properly= render the media into
light and
> =A0 =A0 =A0 sound
> =A0 =A0 =A0 > =A0 =A0 =A0 for
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> human observers. =A0I see t= his at the same level as
> =A0 =A0 =A0 identifying a
> =A0 =A0 =A0 > =A0 =A0 =A0 codec,
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> independent of the audio or= video content carried
on the
> =A0 =A0 =A0 streams,
> =A0 =A0 =A0 > =A0 =A0 =A0 and
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> independent of how any comp= osition of sources is
done.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 I do not think this is necessarily true. = Taking audio as
an
> =A0 =A0 =A0 example, you
> =A0 =A0 =A0 > =A0 =A0 =A0 could have two audio streams that are mix= ed to form a
single
> =A0 =A0 =A0 stereo
> =A0 =A0 =A0 > =A0 =A0 =A0 audio stream, or you could have them as t= wo independent
(not
> =A0 =A0 =A0 mixed)
> =A0 =A0 =A0 > =A0 =A0 =A0 streams that are associate with each othe= r by some
grouping
> =A0 =A0 =A0 mechanism.
> =A0 =A0 =A0 > =A0 =A0 =A0 This group would be categorized as being = stereo audio
with one
> =A0 =A0 =A0 audio
> =A0 =A0 =A0 > =A0 =A0 =A0 stream being the left and the other the r= ight. The codec
used
> =A0 =A0 =A0 for each
> =A0 =A0 =A0 > =A0 =A0 =A0 could be different, though I agree they w= ould typically
be the
> =A0 =A0 =A0 same.
> =A0 =A0 =A0 > =A0 =A0 =A0 Consequently, I think at attribute such a= s "stereo" as
being
> =A0 =A0 =A0 more of a
> =A0 =A0 =A0 > =A0 =A0 =A0 grouping concept, where the group may con= sist of:
> =A0 =A0 =A0 > =A0 =A0 =A0 - multiple independent streams, each with= potentially
its own
> =A0 =A0 =A0 spatial
> =A0 =A0 =A0 > =A0 =A0 =A0 orientation, codec, bandwidth, etc.,
> =A0 =A0 =A0 > =A0 =A0 =A0 - a single mixed stream
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > [sb] I do not understand this distinction. =A0What do= you mean
when you
> =A0 =A0 =A0 say "two audio streams that are
> =A0 =A0 =A0 > mixed to form a single stereo stream", and how i= s this
different from
> =A0 =A0 =A0 the left and right grouping?
>
>
> =A0 =A0 =A0 In one case they are mixed by the source of the stream int= o a
single
> =A0 =A0 =A0 stream, and in another they are sent as two separate strea= ms by
the
> =A0 =A0 =A0 source. The end result once rendered at the receiver may b= e the
same,
> =A0 =A0 =A0 but what is sent is different. This example with audio is<= br> perhaps too
> =A0 =A0 =A0 simple. If you think of it as video that is composed into = a
single video
> =A0 =A0 =A0 stream vs. multiple via streams that are sent individually= , the
> =A0 =A0 =A0 difference may be more clear.
>
> =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 Charles
>
>
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 > =A0 =A0 =A0 Charles
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> I was with you all the way = until 4. That one I
don't
> =A0 =A0 =A0 understand.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> The name you chose for this= has connotations for
me, but
> =A0 =A0 =A0 isn't
> =A0 =A0 =A0 > =A0 =A0 =A0 fully in
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> harmony with the definition= s you give:
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > I'm happy to change the nam= e if you have a
suggestion
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Not yet. Maybe once the concepts are= more clearly
defined I
> =A0 =A0 =A0 will have
> =A0 =A0 =A0 > =A0 =A0 =A0 an
> =A0 =A0 =A0 > =A0 =A0 =A0 > opinion.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> If we consider audio, it ma= kes sense that multiple
streams
> =A0 =A0 =A0 can be
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> rendered as if they came fr= om different physical
locations
> =A0 =A0 =A0 in the
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> receiving room. That can be= done by the receiver if
it gets
> =A0 =A0 =A0 those
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> streams separately, and has= information about their
> =A0 =A0 =A0 intended
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> relationships. It can also = be done by the sender or
MCU and
> =A0 =A0 =A0 passed
> =A0 =A0 =A0 > =A0 =A0 =A0 on
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> to
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> the receiver as a single st= ream with stereo or
binaural
> =A0 =A0 =A0 coding.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > Yes. =A0It could also be done b= y the sender using the
"linear
> =A0 =A0 =A0 array"
> =A0 =A0 =A0 > =A0 =A0 =A0 audio channel format. =A0Maybe it
> =A0 =A0 =A0 > =A0 =A0 =A0 > is true that stereo or binaural audi= o channels would
always be
> =A0 =A0 =A0 sent as
> =A0 =A0 =A0 > =A0 =A0 =A0 a single stream, but I was not
> =A0 =A0 =A0 > =A0 =A0 =A0 > assuming that yet, at least not in g= eneral when you
consider
> =A0 =A0 =A0 other
> =A0 =A0 =A0 > =A0 =A0 =A0 types too, such as linear array
> =A0 =A0 =A0 > =A0 =A0 =A0 > channels.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> So it seems to me you have = two concepts here, not
one. One
> =A0 =A0 =A0 has to
> =A0 =A0 =A0 > =A0 =A0 =A0 do
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> with describing the relatio= nships between streams,
and the
> =A0 =A0 =A0 other
> =A0 =A0 =A0 > =A0 =A0 =A0 has to
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> do with the encoding of spa= cial relationships
*within* a
> =A0 =A0 =A0 single
> =A0 =A0 =A0 > =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe that is a better way to d= escribe it, if you
assume
> =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio is always sent with a= ll
> =A0 =A0 =A0 > =A0 =A0 =A0 > the channels in the same RTP stream.= =A0Is that what you
mean?
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > I was considering the linear ar= ray format to be
another type
> =A0 =A0 =A0 of
> =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio, and I know
> =A0 =A0 =A0 > =A0 =A0 =A0 > people want to be able to send each = channel in a
separate RTP
> =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 So it doesn't quite fit with
> =A0 =A0 =A0 > =A0 =A0 =A0 > how you separate the two concepts. = =A0In my view,
identifying
> =A0 =A0 =A0 the
> =A0 =A0 =A0 > =A0 =A0 =A0 separate channels by what they mean is > =A0 =A0 =A0 > =A0 =A0 =A0 > the same concept for linear array an= d stereo. =A0For
example
> =A0 =A0 =A0 "this
> =A0 =A0 =A0 > =A0 =A0 =A0 channel is left, this channel is
> =A0 =A0 =A0 > =A0 =A0 =A0 > center, this channel is right".= =A0To me, that is the
same
> =A0 =A0 =A0 concept for
> =A0 =A0 =A0 > =A0 =A0 =A0 identifying channels whether or
> =A0 =A0 =A0 > =A0 =A0 =A0 > not they are carried in the same RTP= stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe we are thinking the same = thing but getting
confused by
> =A0 =A0 =A0 > =A0 =A0 =A0 terminology about channels vs. streams. > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Maybe. Let me try to restate what I = now think you are
saying:
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > The audio may consist of several &qu= ot;channels".
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Each channel may be sent over its ow= n RTP stream,
> =A0 =A0 =A0 > =A0 =A0 =A0 > or multiple channels may be multiple= xed over an RTP
stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > I guess much of this can also apply = to video.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > When there are exactly two audio cha= nnels, they may be
encoded
> =A0 =A0 =A0 as
> =A0 =A0 =A0 > =A0 =A0 =A0 > "stereo" or "binaural= ", which then affects how they
should be
> =A0 =A0 =A0 rendered
> =A0 =A0 =A0 > =A0 =A0 =A0 > by the recipient. In these cases the= primary info that
is
> =A0 =A0 =A0 required
> =A0 =A0 =A0 > =A0 =A0 =A0 about
> =A0 =A0 =A0 > =A0 =A0 =A0 > the individual channels is which is = left and which is
right.
> =A0 =A0 =A0 (And
> =A0 =A0 =A0 > =A0 =A0 =A0 which
> =A0 =A0 =A0 > =A0 =A0 =A0 > perspective to use in interpretting = left and right.)
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > For other multi-channel cases more i= nformation is
required
> =A0 =A0 =A0 about the
> =A0 =A0 =A0 > =A0 =A0 =A0 > role of each channel in order to pro= perly render them.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Paul
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> Or, are you asserting that = stereo and binaural are
simply
> =A0 =A0 =A0 ways to
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> encode
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> multiple logical streams in= one RTP stream,
together with
> =A0 =A0 =A0 their
> =A0 =A0 =A0 > =A0 =A0 =A0 spacial
> =A0 =A0 =A0 > =A0 =A0 =A0 > >> relationships?
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > No, that is not what I'm tr= ying to say.
> =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > > Mark
> =A0 =A0 =A0 > =A0 =A0 =A0 > > _______________________________= ________________
> =A0 =A0 =A0 > =A0 =A0 =A0 > > clue mailing list
> =A0 =A0 =A0 > =A0 =A0 =A0 > > clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > > https://www.ietf.org/mailman/list= info/clue
> =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 > =A0 =A0 =A0 > clu= e@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > https://www.ietf.org/mailman/listinfo/= clue
> =A0 =A0 =A0 > =A0 =A0 =A0 _________________________________________= ______
> =A0 =A0 =A0 > =A0 =A0 =A0 clue mailing list
> =A0 =A0 =A0 > =A0 =A0 =A0 clue@iet= f.org
> =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue<= /a>
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
>
>
>

--bcaec5486194de26c404aaa5dbd8-- From eckelcu@cisco.com Tue Aug 16 14:39:26 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 27EFF11E80F9 for ; Tue, 16 Aug 2011 14:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-0.217, 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 osQpbxOAYWxY for ; Tue, 16 Aug 2011 14:39:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C225C11E80EF for ; Tue, 16 Aug 2011 14:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=14212; q=dns/txt; s=iport; t=1313530814; x=1314740414; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oKZv4hM+ok1auwvmJAWzfQB2N/zFsZ3ppLECi+9sogs=; b=KIuryQDoXX97rd/tbbhwsiZuYIfQDfPoUcbuMczkPLIUyo94zFitHWTW 9fiKrrrxdO9xFs2pz1Q/CfPJK3TvWMZR8M86hKbrZ5OF/aia+GN9xswLB LrXiODEnEvYKkRSMOcRWBkRwYuXSzZiJFnfghtCOJbKdb/SV+6JUsX3rp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAJzjSk6rRDoJ/2dsb2JhbAA7Bphvj1V3gUABAQEBAwEBAQ8BHQotBwQHBQcEAgEIEQQBAQEKBhcBBgEgBh8JCAEBBBMIGodSm00BnyiDMoI3XwSHX5BIhGGHHw X-IronPort-AV: E=Sophos;i="4.68,236,1312156800"; d="scan'208";a="13716553" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 16 Aug 2011 21:40:13 +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 p7GLeCop021464; Tue, 16 Aug 2011 21:40:13 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 14:40:12 -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: Tue, 16 Aug 2011 14:40:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] continuing "layout" discussion Thread-Index: AcxcWW5KBW5fbJZTSCGTySuMAtQXEAAAx3pQ References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com><4E413021.3010509@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com><4E43D2BE.5010102@alum.mit.edu>

From: "Charles Eckel (eckelcu)" To: "Stephen Botzko" X-OriginalArrivalTime: 16 Aug 2011 21:40:12.0713 (UTC) FILETIME=[142D5190:01CC5C5D] Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 16 Aug 2011 21:39:26 -0000 Agreed. The difference I am trying to point out is that in (1), the information you need to describe the audio stream for appropriate rendering is already handled quite well by existing SIP/SDP/RTP and most implementations, whereas you need CLUE for (2) and (2b). Cheers, Charles > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Tuesday, August 16, 2011 2:14 PM > To: Charles Eckel (eckelcu) > Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion >=20 > Well, the audio in (1) and (2b) is certainly packetized differently. But not compressed differently > (unless you are assuming that the signal in (1) is jointly encoded stereo - which it could be I guess, > but it would be unusual for telepresence systems). Also, the audio in (1) is not mixed, no matter how > it is encoded. >=20 > In any event, I believe that the difference between (1) and (2) and (2b) is really a transport > question that has nothing to do with layout. The same information is needed to enable proper > rendering, and once the streams are received, they are rendered in precisely the same way. >=20 > Regards, > Stephen Botzko >=20 >=20 > On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu) wrote: >=20 >=20 > I am distinguishing between: >=20 > (1) a single RTP stream that consists of a single stereo audio stream > (2) two RTP streams, one that contains left speaker audio and the other > than contains right speaker audio >=20 > (2) could also be transmitted in a single RTP stream using SSRC > multiplexing. Let me call that (2b). > (2) and (2b) are essentially the same. Just the RTP mechanism employed > is difference. > (1) is different from (2) and (2b) in that the audio signal encoded is > actually different. >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] >=20 > > Sent: Tuesday, August 16, 2011 6:20 AM > > To: Charles Eckel (eckelcu) > > Cc: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > I guess by "stream" you are meaning RTP stream? in which case by > "mix" you perhaps mean that the left > > and right channels are placed in a single RTP stream??? What do you > mean when you describe some audio > > captures as "independent" - are you thinking they come from different > rooms???. > > > > I think in many respects audio distribution and spatial audio layout > is at least as difficult as video > > layout, and have some unique issues. For one thing, you need to sort > out how you should place the > > audio from human participants who are not on camera, and what should > happen later on if some of those > > participants are shown. > > > > I suggest it is necessary to be very careful with terminology. In > particular, I think it is important > > to distinguish composition from RTP transmission. > > > > Regards, > > Stephen Botzko > > > > > > > > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) > wrote: > > > > > > > -----Original Message----- > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Monday, August 15, 2011 2:14 PM > > > To: Charles Eckel (eckelcu) > > > Cc: Paul Kyzivat; clue@ietf.org > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > Inline > > > > > > > > > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel (eckelcu) > > wrote: > > > > > > > > > Please see inline. > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > Behalf > > > Of Paul Kyzivat > > > > > > > Sent: Thursday, August 11, 2011 6:02 AM > > > > > > > To: clue@ietf.org > > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > > > Inline > > > > > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > > > >> -----Original Message----- > > > > >> From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] > > On > > > Behalf Of > > > > >> Paul Kyzivat > > > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > > > >> To: clue@ietf.org > > > > >> Subject: Re: [clue] continuing "layout" discussion > > > > > > > > > >>> 4 - multi stream media format - what the streams > mean with > > respect > > > to > > > > >> each other, regardless of the actual content on the > > streams. For > > > > >> audio, examples are stereo, 5.1 surround, binaural, > linear > > array. > > > > >> (linear array is described in the clue framework > document). > > > Perhaps 3D > > > > >> video formats would also fit in this category. > This > > information is > > > > >> needed in order to properly render the media into > light and > > sound > > > for > > > > >> human observers. I see this at the same level as > > identifying a > > > codec, > > > > >> independent of the audio or video content carried > on the > > streams, > > > and > > > > >> independent of how any composition of sources is > done. > > > > > > > > > I do not think this is necessarily true. Taking audio as > an > > example, you > > > could have two audio streams that are mixed to form a > single > > stereo > > > audio stream, or you could have them as two independent > (not > > mixed) > > > streams that are associate with each other by some > grouping > > mechanism. > > > This group would be categorized as being stereo audio > with one > > audio > > > stream being the left and the other the right. The codec > used > > for each > > > could be different, though I agree they would typically > be the > > same. > > > Consequently, I think at attribute such as "stereo" as > being > > more of a > > > grouping concept, where the group may consist of: > > > - multiple independent streams, each with potentially > its own > > spatial > > > orientation, codec, bandwidth, etc., > > > - a single mixed stream > > > > > > > > > > > > [sb] I do not understand this distinction. What do you mean > when you > > say "two audio streams that are > > > mixed to form a single stereo stream", and how is this > different from > > the left and right grouping? > > > > > > In one case they are mixed by the source of the stream into a > single > > stream, and in another they are sent as two separate streams by > the > > source. The end result once rendered at the receiver may be the > same, > > but what is sent is different. This example with audio is > perhaps too > > simple. If you think of it as video that is composed into a > single video > > stream vs. multiple via streams that are sent individually, the > > difference may be more clear. > > > > Cheers, > > Charles > > > > > > > > > > > > > > > > Cheers, > > > Charles > > > > > > > > > > >> I was with you all the way until 4. That one I > don't > > understand. > > > > >> The name you chose for this has connotations for > me, but > > isn't > > > fully in > > > > >> harmony with the definitions you give: > > > > > > > > > > I'm happy to change the name if you have a > suggestion > > > > > > > > Not yet. Maybe once the concepts are more clearly > defined I > > will have > > > an > > > > opinion. > > > > > > > > >> If we consider audio, it makes sense that multiple > streams > > can be > > > > >> rendered as if they came from different physical > locations > > in the > > > > >> receiving room. That can be done by the receiver if > it gets > > those > > > > >> streams separately, and has information about their > > intended > > > > >> relationships. It can also be done by the sender or > MCU and > > passed > > > on > > > > >> to > > > > >> the receiver as a single stream with stereo or > binaural > > coding. > > > > > > > > > > Yes. It could also be done by the sender using the > "linear > > array" > > > audio channel format. Maybe it > > > > is true that stereo or binaural audio channels would > always be > > sent as > > > a single stream, but I was not > > > > assuming that yet, at least not in general when you > consider > > other > > > types too, such as linear array > > > > channels. > > > > > > > > >> So it seems to me you have two concepts here, not > one. One > > has to > > > do > > > > >> with describing the relationships between streams, > and the > > other > > > has to > > > > >> do with the encoding of spacial relationships > *within* a > > single > > > stream. > > > > > > > > > > Maybe that is a better way to describe it, if you > assume > > > multi-channel audio is always sent with all > > > > the channels in the same RTP stream. Is that what you > mean? > > > > > > > > > > I was considering the linear array format to be > another type > > of > > > multi-channel audio, and I know > > > > people want to be able to send each channel in a > separate RTP > > stream. > > > So it doesn't quite fit with > > > > how you separate the two concepts. In my view, > identifying > > the > > > separate channels by what they mean is > > > > the same concept for linear array and stereo. For > example > > "this > > > channel is left, this channel is > > > > center, this channel is right". To me, that is the > same > > concept for > > > identifying channels whether or > > > > not they are carried in the same RTP stream. > > > > > > > > > > Maybe we are thinking the same thing but getting > confused by > > > terminology about channels vs. streams. > > > > > > > > Maybe. Let me try to restate what I now think you are > saying: > > > > > > > > The audio may consist of several "channels". > > > > > > > > Each channel may be sent over its own RTP stream, > > > > or multiple channels may be multiplexed over an RTP > stream. > > > > > > > > I guess much of this can also apply to video. > > > > > > > > When there are exactly two audio channels, they may be > encoded > > as > > > > "stereo" or "binaural", which then affects how they > should be > > rendered > > > > by the recipient. In these cases the primary info that > is > > required > > > about > > > > the individual channels is which is left and which is > right. > > (And > > > which > > > > perspective to use in interpretting left and right.) > > > > > > > > For other multi-channel cases more information is > required > > about the > > > > role of each channel in order to properly render them. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > > > >> Or, are you asserting that stereo and binaural are > simply > > ways to > > > > >> encode > > > > >> multiple logical streams in one RTP stream, > together with > > their > > > spacial > > > > >> relationships? > > > > > > > > > > No, that is not what I'm trying to say. > > > > > > > > > > Mark > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > >=20 >=20 >=20 From Even.roni@huawei.com Tue Aug 16 16:34: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 72AA311E80F6 for ; Tue, 16 Aug 2011 16:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=-3.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 4OYL06Boj5dn for ; Tue, 16 Aug 2011 16:34:47 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE511E80EA for ; Tue, 16 Aug 2011 16:34:46 -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 <0LQ1008MRO7B43@szxga03-in.huawei.com> for clue@ietf.org; Wed, 17 Aug 2011 07:35:35 +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 <0LQ100ASAO7B2D@szxga03-in.huawei.com> for clue@ietf.org; Wed, 17 Aug 2011 07:35:35 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-13-148.red.bezeqint.net [79.178.13.148]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQ1009M4O71WU@szxml12-in.huawei.com>; Wed, 17 Aug 2011 07:35:35 +0800 (CST) Date: Wed, 17 Aug 2011 02:34:45 +0300 From: Roni Even In-reply-to: To: "'Charles Eckel (eckelcu)'" , 'Stephen Botzko' Message-id: <02a501cc5c6d$1a2bf1e0$4e83d5a0$%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: AcxcWW5KBW5fbJZTSCGTySuMAtQXEAAAx3pQAAPPhbA= References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu>

Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 16 Aug 2011 23:34:48 -0000 Hi guys, In case 1 according to RFC 3551 (section 4.1) 2 channels in the rtpmap means left and right channels described as stereo. Are you saying that for the 2 and 2b case you also assume stereo capture or can it be any other way of creating the two audio streams from the same room (Binaural recording (not common), or some other arrangements of the microphones). But this talk about the capture side. I think that Christer talked about the rendering side and not only on the capture side. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Charles Eckel (eckelcu) > Sent: Wednesday, August 17, 2011 12:40 AM > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion > > Agreed. The difference I am trying to point out is that in (1), the > information you need to describe the audio stream for appropriate > rendering is already handled quite well by existing SIP/SDP/RTP and > most > implementations, whereas you need CLUE for (2) and (2b). > > Cheers, > Charles > > > -----Original Message----- > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > Sent: Tuesday, August 16, 2011 2:14 PM > > To: Charles Eckel (eckelcu) > > Cc: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Well, the audio in (1) and (2b) is certainly packetized differently. > But not compressed differently > > (unless you are assuming that the signal in (1) is jointly encoded > stereo - which it could be I guess, > > but it would be unusual for telepresence systems). Also, the audio in > (1) is not mixed, no matter how > > it is encoded. > > > > In any event, I believe that the difference between (1) and (2) and > (2b) is really a transport > > question that has nothing to do with layout. The same information is > needed to enable proper > > rendering, and once the streams are received, they are rendered in > precisely the same way. > > > > Regards, > > Stephen Botzko > > > > > > On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu) >

On Tue, Aug 16, 2= 011 at 5:40 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
Agreed. The difference I am trying to point out is that in (1), the
information you need to describe the audio stream for appropriate
rendering is already handled quite well by existing SIP/SDP/RTP and most implementations, whereas you need CLUE for (2) and (2b).

Cheers,
Charles

> -----Original Message-----
> From: Stephen Botzko [mailto:stephen.botzko@gmail.com]

> Sent: Tuesday, August 16, 2011= 2:14 PM
> To: Charles Eckel (eckelcu)
> Cc: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] continuing "layout" discussion
>
> Well, the audio in (1) and (2b) is certainly packetized differently. But not compressed differently
> (unless you are assuming that the signal in (1) is jointly encoded
stereo - which it could be I guess,
> but it would be unusual for telepresence systems). Also, the audio in<= br> (1) is not mixed, no matter how
> it is encoded.
>
> In any event, I believe that the difference between (1) and (2) and (2b) is really a transport
> question that has nothing to do with layout. The same information is needed to enable proper
> rendering, and once the streams are received, they are rendered in
precisely the same way.
>
> Regards,
> Stephen Botzko
>
>
> On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu)
<eckelcu@cisco.com> wrote: >
>
> =A0 =A0 =A0 I am distinguishing between:
>
> =A0 =A0 =A0 (1) a single RTP stream that consists of a single stereo a= udio
stream
> =A0 =A0 =A0 (2) two RTP streams, one that contains left speaker audio = and
the other
> =A0 =A0 =A0 than contains right speaker audio
>
> =A0 =A0 =A0 (2) could also be transmitted in a single RTP stream using= SSRC
> =A0 =A0 =A0 multiplexing. Let me call that (2b).
> =A0 =A0 =A0 (2) and (2b) are essentially the same. Just the RTP mechan= ism
employed
> =A0 =A0 =A0 is difference.
> =A0 =A0 =A0 (1) is different from (2) and (2b) in that the audio signa= l
encoded is
> =A0 =A0 =A0 actually different.
>
> =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 Charles
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
>
> =A0 =A0 =A0 > Sent: Tuesday, August 16, 2011 6:20 AM
> =A0 =A0 =A0 > To: Charles Eckel (eckelcu)
> =A0 =A0 =A0 > Cc: Paul Kyzivat; cl= ue@ietf.org
> =A0 =A0 =A0 > Subject: Re: [clue] continuing "layout" dis= cussion
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I guess by "stream" you are meaning RTP str= eam? =A0in which case
by
> =A0 =A0 =A0 "mix" you perhaps mean that the left
> =A0 =A0 =A0 > and right channels are placed in a single RTP stream?= ?? =A0What
do you
> =A0 =A0 =A0 mean when you describe some audio
> =A0 =A0 =A0 > captures as "independent" - are you thinkin= g they come from
different
> =A0 =A0 =A0 rooms???.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I think in many respects audio distribution and spati= al audio
layout
> =A0 =A0 =A0 is at least as difficult as video
> =A0 =A0 =A0 > layout, and have some unique issues. =A0For one thing= , you need
to sort
> =A0 =A0 =A0 out how you should place the
> =A0 =A0 =A0 > audio from human participants who are not on camera, = and what
should
> =A0 =A0 =A0 happen later on if some of those
> =A0 =A0 =A0 > participants are shown.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I suggest it is necessary to be very careful with ter= minology.
In
> =A0 =A0 =A0 particular, I think it is important
> =A0 =A0 =A0 > to distinguish composition from RTP transmission.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Regards,
> =A0 =A0 =A0 > Stephen Botzko
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckel= cu)
> =A0 =A0 =A0 <eckelcu@cisco.com= > wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > =A0 =A0 =A0 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Monday, August 15, 2011 2:14 P= M
> =A0 =A0 =A0 > =A0 =A0 =A0 > To: Charles Eckel (eckelcu)
> =A0 =A0 =A0 > =A0 =A0 =A0 > Cc: Paul Kyzivat; clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [clue] continuing "= ;layout" discussion
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > Inline
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > On Mon, Aug 15, 2011 at 4:21 PM, Cha= rles Eckel
(eckelcu)
> =A0 =A0 =A0 > =A0 =A0 =A0 <= eckelcu@cisco.com> wrote:
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Please see inline.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Messa= ge-----
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > From: clue-bounces@ietf.org
> =A0 =A0 =A0 [mailto:clue-boun= ces@ietf.org] On
> =A0 =A0 =A0 > =A0 =A0 =A0 Behalf
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Of Paul Kyzivat
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, Aug= ust 11, 2011 6:02 AM
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > To: clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [clue]= continuing "layout"
discussion
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Inline
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > On 8/10/11 5:49 PM,= Duckworth, Mark wrote:
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> -----Origi= nal Message-----
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> From: clue-bounces@ietf.org
> =A0 =A0 =A0 [mailto:clue-boun= ces@ietf.org]
> =A0 =A0 =A0 > =A0 =A0 =A0 On
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Behalf Of
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Paul Kyziv= at
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Sent: Tues= day, August 09, 2011 9:03 AM
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> To: clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Subject: R= e: [clue] continuing "layout"
discussion
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >>> 4 - mu= lti stream media format - what the
streams
> =A0 =A0 =A0 mean with
> =A0 =A0 =A0 > =A0 =A0 =A0 respect
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 to
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> each other= , regardless of the actual
content on the
> =A0 =A0 =A0 > =A0 =A0 =A0 streams. =A0For
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> audio, exa= mples are stereo, 5.1 surround,
binaural,
> =A0 =A0 =A0 linear
> =A0 =A0 =A0 > =A0 =A0 =A0 array.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> (linear ar= ray is described in the clue
framework
> =A0 =A0 =A0 document).
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Perhaps 3D
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> video form= ats would also fit in this
category.
> =A0 =A0 =A0 This
> =A0 =A0 =A0 > =A0 =A0 =A0 information is
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> needed in = order to properly render the
media into
> =A0 =A0 =A0 light and
> =A0 =A0 =A0 > =A0 =A0 =A0 sound
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 for
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> human obse= rvers. =A0I see this at the same
level as
> =A0 =A0 =A0 > =A0 =A0 =A0 identifying a
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 codec,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> independen= t of the audio or video content
carried
> =A0 =A0 =A0 on the
> =A0 =A0 =A0 > =A0 =A0 =A0 streams,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 and
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> independen= t of how any composition of
sources is
> =A0 =A0 =A0 done.
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 I do not think this is n= ecessarily true. Taking
audio as
> =A0 =A0 =A0 an
> =A0 =A0 =A0 > =A0 =A0 =A0 example, you
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 could have two audio str= eams that are mixed to
form a
> =A0 =A0 =A0 single
> =A0 =A0 =A0 > =A0 =A0 =A0 stereo
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 audio stream, or you cou= ld have them as two
independent
> =A0 =A0 =A0 (not
> =A0 =A0 =A0 > =A0 =A0 =A0 mixed)
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 streams that are associa= te with each other by
some
> =A0 =A0 =A0 grouping
> =A0 =A0 =A0 > =A0 =A0 =A0 mechanism.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 This group would be cate= gorized as being stereo
audio
> =A0 =A0 =A0 with one
> =A0 =A0 =A0 > =A0 =A0 =A0 audio
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 stream being the left an= d the other the right.
The codec
> =A0 =A0 =A0 used
> =A0 =A0 =A0 > =A0 =A0 =A0 for each
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 could be different, thou= gh I agree they would
typically
> =A0 =A0 =A0 be the
> =A0 =A0 =A0 > =A0 =A0 =A0 same.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Consequently, I think at= attribute such as
"stereo" as
> =A0 =A0 =A0 being
> =A0 =A0 =A0 > =A0 =A0 =A0 more of a
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 grouping concept, where = the group may consist
of:
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 - multiple independent s= treams, each with
potentially
> =A0 =A0 =A0 its own
> =A0 =A0 =A0 > =A0 =A0 =A0 spatial
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 orientation, codec, band= width, etc.,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 - a single mixed stream<= br> > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > [sb] I do not understand this distin= ction. =A0What do
you mean
> =A0 =A0 =A0 when you
> =A0 =A0 =A0 > =A0 =A0 =A0 say "two audio streams that are
> =A0 =A0 =A0 > =A0 =A0 =A0 > mixed to form a single stereo stream= ", and how is this
> =A0 =A0 =A0 different from
> =A0 =A0 =A0 > =A0 =A0 =A0 the left and right grouping?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 In one case they are mixed by the source = of the stream
into a
> =A0 =A0 =A0 single
> =A0 =A0 =A0 > =A0 =A0 =A0 stream, and in another they are sent as t= wo separate
streams by
> =A0 =A0 =A0 the
> =A0 =A0 =A0 > =A0 =A0 =A0 source. The end result once rendered at t= he receiver may
be the
> =A0 =A0 =A0 same,
> =A0 =A0 =A0 > =A0 =A0 =A0 but what is sent is different. This examp= le with audio
is
> =A0 =A0 =A0 perhaps too
> =A0 =A0 =A0 > =A0 =A0 =A0 simple. If you think of it as video that = is composed
into a
> =A0 =A0 =A0 single video
> =A0 =A0 =A0 > =A0 =A0 =A0 stream vs. multiple via streams that are = sent
individually, the
> =A0 =A0 =A0 > =A0 =A0 =A0 difference may be more clear.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 > =A0 =A0 =A0 Charles
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Cheers,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Charles
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> I was with= you all the way until 4. That
one I
> =A0 =A0 =A0 don't
> =A0 =A0 =A0 > =A0 =A0 =A0 understand.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> The name y= ou chose for this has
connotations for
> =A0 =A0 =A0 me, but
> =A0 =A0 =A0 > =A0 =A0 =A0 isn't
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 fully in
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> harmony wi= th the definitions you give:
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > I'm happy = to change the name if you have a
> =A0 =A0 =A0 suggestion
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Not yet. Maybe once= the concepts are more
clearly
> =A0 =A0 =A0 defined I
> =A0 =A0 =A0 > =A0 =A0 =A0 will have
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 an
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > opinion.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> If we cons= ider audio, it makes sense that
multiple
> =A0 =A0 =A0 streams
> =A0 =A0 =A0 > =A0 =A0 =A0 can be
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> rendered a= s if they came from different
physical
> =A0 =A0 =A0 locations
> =A0 =A0 =A0 > =A0 =A0 =A0 in the
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> receiving = room. That can be done by the
receiver if
> =A0 =A0 =A0 it gets
> =A0 =A0 =A0 > =A0 =A0 =A0 those
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> streams se= parately, and has information
about their
> =A0 =A0 =A0 > =A0 =A0 =A0 intended
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> relationsh= ips. It can also be done by the
sender or
> =A0 =A0 =A0 MCU and
> =A0 =A0 =A0 > =A0 =A0 =A0 passed
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 on
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> to
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> the receiv= er as a single stream with stereo
or
> =A0 =A0 =A0 binaural
> =A0 =A0 =A0 > =A0 =A0 =A0 coding.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Yes. =A0It cou= ld also be done by the sender
using the
> =A0 =A0 =A0 "linear
> =A0 =A0 =A0 > =A0 =A0 =A0 array"
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 audio channel format. = =A0Maybe it
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > is true that stereo= or binaural audio channels
would
> =A0 =A0 =A0 always be
> =A0 =A0 =A0 > =A0 =A0 =A0 sent as
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 a single stream, but I w= as not
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > assuming that yet, = at least not in general
when you
> =A0 =A0 =A0 consider
> =A0 =A0 =A0 > =A0 =A0 =A0 other
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 types too, such as linea= r array
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > channels.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> So it seem= s to me you have two concepts
here, not
> =A0 =A0 =A0 one. One
> =A0 =A0 =A0 > =A0 =A0 =A0 has to
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 do
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> with descr= ibing the relationships between
streams,
> =A0 =A0 =A0 and the
> =A0 =A0 =A0 > =A0 =A0 =A0 other
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 has to
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> do with th= e encoding of spacial
relationships
> =A0 =A0 =A0 *within* a
> =A0 =A0 =A0 > =A0 =A0 =A0 single
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe that is = a better way to describe it,
if you
> =A0 =A0 =A0 assume
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio is a= lways sent with all
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the channels in the= same RTP stream. =A0Is that
what you
> =A0 =A0 =A0 mean?
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > I was consider= ing the linear array format to
be
> =A0 =A0 =A0 another type
> =A0 =A0 =A0 > =A0 =A0 =A0 of
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio, and= I know
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > people want to be a= ble to send each channel in
a
> =A0 =A0 =A0 separate RTP
> =A0 =A0 =A0 > =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 So it doesn't quite = fit with
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > how you separate th= e two concepts. =A0In my
view,
> =A0 =A0 =A0 identifying
> =A0 =A0 =A0 > =A0 =A0 =A0 the
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 separate channels by wha= t they mean is
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the same concept fo= r linear array and stereo.
For
> =A0 =A0 =A0 example
> =A0 =A0 =A0 > =A0 =A0 =A0 "this
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 channel is left, this ch= annel is
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > center, this channe= l is right". =A0To me, that
is the
> =A0 =A0 =A0 same
> =A0 =A0 =A0 > =A0 =A0 =A0 concept for
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 identifying channels whe= ther or
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > not they are carrie= d in the same RTP stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe we are t= hinking the same thing but
getting
> =A0 =A0 =A0 confused by
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 terminology about channe= ls vs. streams.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Maybe. Let me try t= o restate what I now think
you are
> =A0 =A0 =A0 saying:
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > The audio may consi= st of several "channels".
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Each channel may be= sent over its own RTP
stream,
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > or multiple channel= s may be multiplexed over
an RTP
> =A0 =A0 =A0 stream.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > I guess much of thi= s can also apply to video.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > When there are exac= tly two audio channels,
they may be
> =A0 =A0 =A0 encoded
> =A0 =A0 =A0 > =A0 =A0 =A0 as
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > "stereo" = or "binaural", which then affects how
they
> =A0 =A0 =A0 should be
> =A0 =A0 =A0 > =A0 =A0 =A0 rendered
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > by the recipient. I= n these cases the primary
info that
> =A0 =A0 =A0 is
> =A0 =A0 =A0 > =A0 =A0 =A0 required
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 about
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the individual chan= nels is which is left and
which is
> =A0 =A0 =A0 right.
> =A0 =A0 =A0 > =A0 =A0 =A0 (And
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 which
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > perspective to use = in interpretting left and
right.)
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > For other multi-cha= nnel cases more information
is
> =A0 =A0 =A0 required
> =A0 =A0 =A0 > =A0 =A0 =A0 about the
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > role of each channe= l in order to properly
render them.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Thanks,=
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Paul > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Or, are yo= u asserting that stereo and
binaural are
> =A0 =A0 =A0 simply
> =A0 =A0 =A0 > =A0 =A0 =A0 ways to
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> encode
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> multiple l= ogical streams in one RTP stream,
> =A0 =A0 =A0 together with
> =A0 =A0 =A0 > =A0 =A0 =A0 their
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 spacial
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> relationsh= ips?
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > No, that is no= t what I'm trying to say.
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Mark
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
_______________________________________________
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > clue mailing l= ist
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > https://www.ietf= .org/mailman/listinfo/clue
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> =A0 =A0 =A0 > =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 > =A0 =A0 =A0 > =A0 =A0 =A0 > clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > https://www.ietf.org/= mailman/listinfo/clue
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 ________________________= _______________________
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 clue mailing list
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 clue@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailm= an/listinfo/clue
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
>
>
>

--20cf3079b87015c09804aaa94d16-- From stephen.botzko@gmail.com Tue Aug 16 18:35: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 C058321F862F for ; Tue, 16 Aug 2011 18:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 ZisEeKe73if6 for ; Tue, 16 Aug 2011 18:35:50 -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 6732121F861E for ; Tue, 16 Aug 2011 18:35:50 -0700 (PDT) Received: by vxi29 with SMTP id 29so564629vxi.31 for ; Tue, 16 Aug 2011 18:36:40 -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=JDjlbgLfGjhjmOs2cZ72+29Rc7aovhrc/lI19lJBJLw=; b=fIZb8MSQ3WIuXrdjYuTdAY3lqjLuLjnJRRCCh8ojAMC5YS8vwVoakmgp9Bo1N6UGZX xk4vhSOVDLmwWp8wxYx3V/+xEYJMkpMYlp5oNpn+2p5V9VKL3vxkKjPRzJbqIHpgHWMK yw+Qo499xofdkWzTrRYlspfeTicjRe6/LFM54= MIME-Version: 1.0 Received: by 10.52.182.6 with SMTP id ea6mr431367vdc.222.1313544999955; Tue, 16 Aug 2011 18:36:39 -0700 (PDT) Received: by 10.52.115.103 with HTTP; Tue, 16 Aug 2011 18:36:39 -0700 (PDT) In-Reply-To: <02a501cc5c6d$1a2bf1e0$4e83d5a0$%roni@huawei.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu>

<02a501cc5c6d$1a2bf1e0$4e83d5a0$%roni@huawei.com> Date: Tue, 16 Aug 2011 21:36:39 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=bcaec54861941e6cc804aaa98716 Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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, 17 Aug 2011 01:35:52 -0000 --bcaec54861941e6cc804aaa98716 Content-Type: text/plain; charset=ISO-8859-1 Hi Roni For this particular discussion, all of the two channel transmissions are "stereo", they are just transported differently. As far as the framework draft is concerned, the various microphone arrangements are accounted for by the signaling of the 1-100 indices for each channel. Binaural is something else- either an HRTF function is applied to the two channels prior to rendering (which was Christer's case with the central rendering server), or you have a dummy head with microphones in the ears in the telepresence room to make the capture. Not sure if we need to distinguish the capture and render cases right now. Regards, Stephen On Tue, Aug 16, 2011 at 7:34 PM, Roni Even wrote: > Hi guys, > In case 1 according to RFC 3551 (section 4.1) 2 channels in the rtpmap > means > left and right channels described as stereo. Are you saying that for the 2 > and 2b case you also assume stereo capture or can it be any other way of > creating the two audio streams from the same room (Binaural recording (not > common), or some other arrangements of the microphones). But this talk > about > the capture side. > > I think that Christer talked about the rendering side and not only on the > capture side. > > Roni > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Charles Eckel (eckelcu) > > Sent: Wednesday, August 17, 2011 12:40 AM > > To: Stephen Botzko > > Cc: clue@ietf.org > > Subject: Re: [clue] continuing "layout" discussion > > > > Agreed. The difference I am trying to point out is that in (1), the > > information you need to describe the audio stream for appropriate > > rendering is already handled quite well by existing SIP/SDP/RTP and > > most > > implementations, whereas you need CLUE for (2) and (2b). > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > Sent: Tuesday, August 16, 2011 2:14 PM > > > To: Charles Eckel (eckelcu) > > > Cc: Paul Kyzivat; clue@ietf.org > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > Well, the audio in (1) and (2b) is certainly packetized differently. > > But not compressed differently > > > (unless you are assuming that the signal in (1) is jointly encoded > > stereo - which it could be I guess, > > > but it would be unusual for telepresence systems). Also, the audio in > > (1) is not mixed, no matter how > > > it is encoded. > > > > > > In any event, I believe that the difference between (1) and (2) and > > (2b) is really a transport > > > question that has nothing to do with layout. The same information is > > needed to enable proper > > > rendering, and once the streams are received, they are rendered in > > precisely the same way. > > > > > > Regards, > > > Stephen Botzko > > > > > > > > > On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu) > > wrote: > > > > > > > > > I am distinguishing between: > > > > > > (1) a single RTP stream that consists of a single stereo audio > > stream > > > (2) two RTP streams, one that contains left speaker audio and > > the other > > > than contains right speaker audio > > > > > > (2) could also be transmitted in a single RTP stream using SSRC > > > multiplexing. Let me call that (2b). > > > (2) and (2b) are essentially the same. Just the RTP mechanism > > employed > > > is difference. > > > (1) is different from (2) and (2b) in that the audio signal > > encoded is > > > actually different. > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > > > > > Sent: Tuesday, August 16, 2011 6:20 AM > > > > To: Charles Eckel (eckelcu) > > > > Cc: Paul Kyzivat; clue@ietf.org > > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > > > I guess by "stream" you are meaning RTP stream? in which case > > by > > > "mix" you perhaps mean that the left > > > > and right channels are placed in a single RTP stream??? What > > do you > > > mean when you describe some audio > > > > captures as "independent" - are you thinking they come from > > different > > > rooms???. > > > > > > > > I think in many respects audio distribution and spatial audio > > layout > > > is at least as difficult as video > > > > layout, and have some unique issues. For one thing, you need > > to sort > > > out how you should place the > > > > audio from human participants who are not on camera, and what > > should > > > happen later on if some of those > > > > participants are shown. > > > > > > > > I suggest it is necessary to be very careful with terminology. > > In > > > particular, I think it is important > > > > to distinguish composition from RTP transmission. > > > > > > > > Regards, > > > > Stephen Botzko > > > > > > > > > > > > > > > > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (eckelcu) > > > wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > > > > > Sent: Monday, August 15, 2011 2:14 PM > > > > > To: Charles Eckel (eckelcu) > > > > > Cc: Paul Kyzivat; clue@ietf.org > > > > > Subject: Re: [clue] continuing "layout" discussion > > > > > > > > > > Inline > > > > > > > > > > > > > > > On Mon, Aug 15, 2011 at 4:21 PM, Charles Eckel > > (eckelcu) > > > > wrote: > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > > Of Paul Kyzivat > > > > > > > > > > > Sent: Thursday, August 11, 2011 6:02 AM > > > > > > > > > > > To: clue@ietf.org > > > > > > Subject: Re: [clue] continuing "layout" > > discussion > > > > > > > > > > > > Inline > > > > > > > > > > > > On 8/10/11 5:49 PM, Duckworth, Mark wrote: > > > > > > >> -----Original Message----- > > > > > > >> From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] > > > > On > > > > > Behalf Of > > > > > > >> Paul Kyzivat > > > > > > >> Sent: Tuesday, August 09, 2011 9:03 AM > > > > > > >> To: clue@ietf.org > > > > > > >> Subject: Re: [clue] continuing "layout" > > discussion > > > > > > > > > > > > > >>> 4 - multi stream media format - what the > > streams > > > mean with > > > > respect > > > > > to > > > > > > >> each other, regardless of the actual > > content on the > > > > streams. For > > > > > > >> audio, examples are stereo, 5.1 surround, > > binaural, > > > linear > > > > array. > > > > > > >> (linear array is described in the clue > > framework > > > document). > > > > > Perhaps 3D > > > > > > >> video formats would also fit in this > > category. > > > This > > > > information is > > > > > > >> needed in order to properly render the > > media into > > > light and > > > > sound > > > > > for > > > > > > >> human observers. I see this at the same > > level as > > > > identifying a > > > > > codec, > > > > > > >> independent of the audio or video content > > carried > > > on the > > > > streams, > > > > > and > > > > > > >> independent of how any composition of > > sources is > > > done. > > > > > > > > > > > > > > > I do not think this is necessarily true. Taking > > audio as > > > an > > > > example, you > > > > > could have two audio streams that are mixed to > > form a > > > single > > > > stereo > > > > > audio stream, or you could have them as two > > independent > > > (not > > > > mixed) > > > > > streams that are associate with each other by > > some > > > grouping > > > > mechanism. > > > > > This group would be categorized as being stereo > > audio > > > with one > > > > audio > > > > > stream being the left and the other the right. > > The codec > > > used > > > > for each > > > > > could be different, though I agree they would > > typically > > > be the > > > > same. > > > > > Consequently, I think at attribute such as > > "stereo" as > > > being > > > > more of a > > > > > grouping concept, where the group may consist > > of: > > > > > - multiple independent streams, each with > > potentially > > > its own > > > > spatial > > > > > orientation, codec, bandwidth, etc., > > > > > - a single mixed stream > > > > > > > > > > > > > > > > > > > > [sb] I do not understand this distinction. What do > > you mean > > > when you > > > > say "two audio streams that are > > > > > mixed to form a single stereo stream", and how is this > > > different from > > > > the left and right grouping? > > > > > > > > > > > > In one case they are mixed by the source of the stream > > into a > > > single > > > > stream, and in another they are sent as two separate > > streams by > > > the > > > > source. The end result once rendered at the receiver may > > be the > > > same, > > > > but what is sent is different. This example with audio > > is > > > perhaps too > > > > simple. If you think of it as video that is composed > > into a > > > single video > > > > stream vs. multiple via streams that are sent > > individually, the > > > > difference may be more clear. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > >> I was with you all the way until 4. That > > one I > > > don't > > > > understand. > > > > > > >> The name you chose for this has > > connotations for > > > me, but > > > > isn't > > > > > fully in > > > > > > >> harmony with the definitions you give: > > > > > > > > > > > > > > I'm happy to change the name if you have a > > > suggestion > > > > > > > > > > > > Not yet. Maybe once the concepts are more > > clearly > > > defined I > > > > will have > > > > > an > > > > > > opinion. > > > > > > > > > > > > >> If we consider audio, it makes sense that > > multiple > > > streams > > > > can be > > > > > > >> rendered as if they came from different > > physical > > > locations > > > > in the > > > > > > >> receiving room. That can be done by the > > receiver if > > > it gets > > > > those > > > > > > >> streams separately, and has information > > about their > > > > intended > > > > > > >> relationships. It can also be done by the > > sender or > > > MCU and > > > > passed > > > > > on > > > > > > >> to > > > > > > >> the receiver as a single stream with stereo > > or > > > binaural > > > > coding. > > > > > > > > > > > > > > Yes. It could also be done by the sender > > using the > > > "linear > > > > array" > > > > > audio channel format. Maybe it > > > > > > is true that stereo or binaural audio channels > > would > > > always be > > > > sent as > > > > > a single stream, but I was not > > > > > > assuming that yet, at least not in general > > when you > > > consider > > > > other > > > > > types too, such as linear array > > > > > > channels. > > > > > > > > > > > > >> So it seems to me you have two concepts > > here, not > > > one. One > > > > has to > > > > > do > > > > > > >> with describing the relationships between > > streams, > > > and the > > > > other > > > > > has to > > > > > > >> do with the encoding of spacial > > relationships > > > *within* a > > > > single > > > > > stream. > > > > > > > > > > > > > > Maybe that is a better way to describe it, > > if you > > > assume > > > > > multi-channel audio is always sent with all > > > > > > the channels in the same RTP stream. Is that > > what you > > > mean? > > > > > > > > > > > > > > I was considering the linear array format to > > be > > > another type > > > > of > > > > > multi-channel audio, and I know > > > > > > people want to be able to send each channel in > > a > > > separate RTP > > > > stream. > > > > > So it doesn't quite fit with > > > > > > how you separate the two concepts. In my > > view, > > > identifying > > > > the > > > > > separate channels by what they mean is > > > > > > the same concept for linear array and stereo. > > For > > > example > > > > "this > > > > > channel is left, this channel is > > > > > > center, this channel is right". To me, that > > is the > > > same > > > > concept for > > > > > identifying channels whether or > > > > > > not they are carried in the same RTP stream. > > > > > > > > > > > > > > Maybe we are thinking the same thing but > > getting > > > confused by > > > > > terminology about channels vs. streams. > > > > > > > > > > > > Maybe. Let me try to restate what I now think > > you are > > > saying: > > > > > > > > > > > > The audio may consist of several "channels". > > > > > > > > > > > > Each channel may be sent over its own RTP > > stream, > > > > > > or multiple channels may be multiplexed over > > an RTP > > > stream. > > > > > > > > > > > > I guess much of this can also apply to video. > > > > > > > > > > > > When there are exactly two audio channels, > > they may be > > > encoded > > > > as > > > > > > "stereo" or "binaural", which then affects how > > they > > > should be > > > > rendered > > > > > > by the recipient. In these cases the primary > > info that > > > is > > > > required > > > > > about > > > > > > the individual channels is which is left and > > which is > > > right. > > > > (And > > > > > which > > > > > > perspective to use in interpretting left and > > right.) > > > > > > > > > > > > For other multi-channel cases more information > > is > > > required > > > > about the > > > > > > role of each channel in order to properly > > render them. > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > > > > > > > >> Or, are you asserting that stereo and > > binaural are > > > simply > > > > ways to > > > > > > >> encode > > > > > > >> multiple logical streams in one RTP stream, > > > together with > > > > their > > > > > spacial > > > > > > >> relationships? > > > > > > > > > > > > > > No, that is not what I'm trying to say. > > > > > > > > > > > > > > Mark > > > > > > > > > _______________________________________________ > > > > > > > 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 > > --bcaec54861941e6cc804aaa98716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni

For this particular discussion, all of the two channel trans= missions are "stereo", they are just transported differently.=A0 =

As far as the framework draft is concerned, the various microphone = arrangements are accounted for by the signaling of the 1-100 indices for ea= ch channel.

Binaural is something else- either an HRTF function is applied to the t= wo channels prior to rendering (which was Christer's case with the cent= ral rendering server), or you have a dummy head with microphones in the ear= s in the telepresence room to make the capture.=A0 Not sure if we need to d= istinguish the capture and render cases right now.

Regards,
Stephen

On Tue, Aug 16, 2= 011 at 7:34 PM, Roni Even <Even.roni@huawei.com> wrote:

Hi guys,
In case 1 according to RFC 3551 (section 4.1) 2 channels in the rtpmap mean= s
left and right channels described as stereo. Are you saying that for the 2<= br> and 2b case you also assume stereo capture or can it be any other way of creating the two audio streams =A0from the same room (Binaural recording (n= ot
common), or some other arrangements of the microphones). But this talk abou= t
the capture side.

I think that Christer talked about the rendering side and not only on the capture side.

Roni

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

> Charles Eckel (eckelcu)
> Sent: Wednesday, August 17, 2011 12:40 AM
> To: Stephen Botzko
> Cc: clue@ietf.org

> Subject: Re: [clue] continuing "= ;layout" discussion
>
> Agreed. The difference I am trying to point out is that in (1), the > information you need to describe the audio stream for appropriate
> rendering is already handled quite well by existing SIP/SDP/RTP and > most
> implementations, whereas you need CLUE for (2) and (2b).
>
> Cheers,
> Charles
>
> > -----Original Message-----
> > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > Sent: Tuesday, August 16, 2011 2:14 PM
> > To: Charles Eckel (eckelcu)
> > Cc: Paul Kyzivat; clue@ietf.org<= /a>
> > Subject: Re: [clue] continuing "layout" discussion
> >
> > Well, the audio in (1) and (2b) is certainly packetized different= ly.
> But not compressed differently
> > (unless you are assuming that the signal in (1) is jointly encode= d
> stereo - which it could be I guess,
> > but it would be unusual for telepresence systems). Also, the audi= o in
> (1) is not mixed, no matter how
> > it is encoded.
> >
> > In any event, I believe that the difference between (1) and (2) a= nd
> (2b) is really a transport
> > question that has nothing to do with layout. The same information= is
> needed to enable proper
> > rendering, and once the streams are received, they are rendered i= n
> precisely the same way.
> >
> > Regards,
> > Stephen Botzko
> >
> >
> > On Tue, Aug 16, 2011 at 4:23 PM, Charles Eckel (eckelcu)
> <eckelcu@cisco.com> wro= te:
> >
> >
> > =A0 =A0 I am distinguishing between:
> >
> > =A0 =A0 (1) a single RTP stream that consists of a single stereo = audio
> stream
> > =A0 =A0 (2) two RTP streams, one that contains left speaker audio= and
> the other
> > =A0 =A0 than contains right speaker audio
> >
> > =A0 =A0 (2) could also be transmitted in a single RTP stream usin= g SSRC
> > =A0 =A0 multiplexing. Let me call that (2b).
> > =A0 =A0 (2) and (2b) are essentially the same. Just the RTP mecha= nism
> employed
> > =A0 =A0 is difference.
> > =A0 =A0 (1) is different from (2) and (2b) in that the audio sign= al
> encoded is
> > =A0 =A0 actually different.
> >
> > =A0 =A0 Cheers,
> > =A0 =A0 Charles
> >
> >
> > =A0 =A0 > -----Original Message-----
> > =A0 =A0 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> >
> > =A0 =A0 > Sent: Tuesday, August 16, 2011 6:20 AM
> > =A0 =A0 > To: Charles Eckel (eckelcu)
> > =A0 =A0 > Cc: Paul Kyzivat; c= lue@ietf.org
> > =A0 =A0 > Subject: Re: [clue] continuing "layout" di= scussion
> > =A0 =A0 >
> > =A0 =A0 > I guess by "stream" you are meaning RTP st= ream? =A0in which case
> by
> > =A0 =A0 "mix" you perhaps mean that the left
> > =A0 =A0 > and right channels are placed in a single RTP stream= ??? =A0What
> do you
> > =A0 =A0 mean when you describe some audio
> > =A0 =A0 > captures as "independent" - are you thinki= ng they come from
> different
> > =A0 =A0 rooms???.
> > =A0 =A0 >
> > =A0 =A0 > I think in many respects audio distribution and spat= ial audio
> layout
> > =A0 =A0 is at least as difficult as video
> > =A0 =A0 > layout, and have some unique issues. =A0For one thin= g, you need
> to sort
> > =A0 =A0 out how you should place the
> > =A0 =A0 > audio from human participants who are not on camera,= and what
> should
> > =A0 =A0 happen later on if some of those
> > =A0 =A0 > participants are shown.
> > =A0 =A0 >
> > =A0 =A0 > I suggest it is necessary to be very careful with te= rminology.
> In
> > =A0 =A0 particular, I think it is important
> > =A0 =A0 > to distinguish composition from RTP transmission. > > =A0 =A0 >
> > =A0 =A0 > Regards,
> > =A0 =A0 > Stephen Botzko
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 > On Mon, Aug 15, 2011 at 5:45 PM, Charles Eckel (ecke= lcu)
> > =A0 =A0 <eckelcu@cisco.co= m> wrote:
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > -----Original Message-----
> > =A0 =A0 > =A0 =A0 =A0 > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
> > =A0 =A0 > =A0 =A0 =A0 > Sent: Monday, August 15, 2011 2:14 = PM
> > =A0 =A0 > =A0 =A0 =A0 > To: Charles Eckel (eckelcu)
> > =A0 =A0 > =A0 =A0 =A0 > Cc: Paul Kyzivat; clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [clue] continuing &quo= t;layout" discussion
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > Inline
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > On Mon, Aug 15, 2011 at 4:21 PM, Ch= arles Eckel
> (eckelcu)
> > =A0 =A0 > =A0 =A0 =A0 <eckelcu@cisco.com> wrote:
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Please see inline.
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > -----Original Mess= age-----
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > From: clue-bounces@ietf.org
> > =A0 =A0 [mailto:clue-bou= nces@ietf.org] On
> > =A0 =A0 > =A0 =A0 =A0 Behalf
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Of Paul Kyzivat
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Sent: Thursday, Au= gust 11, 2011 6:02 AM
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > To: clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Subject: Re: [clue= ] continuing "layout"
> discussion
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Inline
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > On 8/10/11 5:49 PM= , Duckworth, Mark wrote:
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> -----Orig= inal Message-----
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> From: clue-bounces@ietf.org
> > =A0 =A0 [mailto:clue-bou= nces@ietf.org]
> > =A0 =A0 > =A0 =A0 =A0 On
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Behalf Of
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Paul Kyzi= vat
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Sent: Tue= sday, August 09, 2011 9:03 AM
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> To: clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Subject: = Re: [clue] continuing "layout"
> discussion
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >>> 4 - m= ulti stream media format - what the
> streams
> > =A0 =A0 mean with
> > =A0 =A0 > =A0 =A0 =A0 respect
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 to
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> each othe= r, regardless of the actual
> content on the
> > =A0 =A0 > =A0 =A0 =A0 streams. =A0For
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> audio, ex= amples are stereo, 5.1 surround,
> binaural,
> > =A0 =A0 linear
> > =A0 =A0 > =A0 =A0 =A0 array.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> (linear a= rray is described in the clue
> framework
> > =A0 =A0 document).
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Perhaps 3D
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> video for= mats would also fit in this
> category.
> > =A0 =A0 This
> > =A0 =A0 > =A0 =A0 =A0 information is
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> needed in= order to properly render the
> media into
> > =A0 =A0 light and
> > =A0 =A0 > =A0 =A0 =A0 sound
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 for
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> human obs= ervers. =A0I see this at the same
> level as
> > =A0 =A0 > =A0 =A0 =A0 identifying a
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 codec,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> independe= nt of the audio or video content
> carried
> > =A0 =A0 on the
> > =A0 =A0 > =A0 =A0 =A0 streams,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 and
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> independe= nt of how any composition of
> sources is
> > =A0 =A0 done.
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 I do not think this is = necessarily true. Taking
> audio as
> > =A0 =A0 an
> > =A0 =A0 > =A0 =A0 =A0 example, you
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 could have two audio st= reams that are mixed to
> form a
> > =A0 =A0 single
> > =A0 =A0 > =A0 =A0 =A0 stereo
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 audio stream, or you co= uld have them as two
> independent
> > =A0 =A0 (not
> > =A0 =A0 > =A0 =A0 =A0 mixed)
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 streams that are associ= ate with each other by
> some
> > =A0 =A0 grouping
> > =A0 =A0 > =A0 =A0 =A0 mechanism.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 This group would be cat= egorized as being stereo
> audio
> > =A0 =A0 with one
> > =A0 =A0 > =A0 =A0 =A0 audio
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 stream being the left a= nd the other the right.
> The codec
> > =A0 =A0 used
> > =A0 =A0 > =A0 =A0 =A0 for each
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 could be different, tho= ugh I agree they would
> typically
> > =A0 =A0 be the
> > =A0 =A0 > =A0 =A0 =A0 same.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Consequently, I think a= t attribute such as
> "stereo" as
> > =A0 =A0 being
> > =A0 =A0 > =A0 =A0 =A0 more of a
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 grouping concept, where= the group may consist
> of:
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 - multiple independent = streams, each with
> potentially
> > =A0 =A0 its own
> > =A0 =A0 > =A0 =A0 =A0 spatial
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 orientation, codec, ban= dwidth, etc.,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 - a single mixed stream=
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > [sb] I do not understand this disti= nction. =A0What do
> you mean
> > =A0 =A0 when you
> > =A0 =A0 > =A0 =A0 =A0 say "two audio streams that are
> > =A0 =A0 > =A0 =A0 =A0 > mixed to form a single stereo strea= m", and how is this
> > =A0 =A0 different from
> > =A0 =A0 > =A0 =A0 =A0 the left and right grouping?
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 In one case they are mixed by the source= of the stream
> into a
> > =A0 =A0 single
> > =A0 =A0 > =A0 =A0 =A0 stream, and in another they are sent as = two separate
> streams by
> > =A0 =A0 the
> > =A0 =A0 > =A0 =A0 =A0 source. The end result once rendered at = the receiver may
> be the
> > =A0 =A0 same,
> > =A0 =A0 > =A0 =A0 =A0 but what is sent is different. This exam= ple with audio
> is
> > =A0 =A0 perhaps too
> > =A0 =A0 > =A0 =A0 =A0 simple. If you think of it as video that= is composed
> into a
> > =A0 =A0 single video
> > =A0 =A0 > =A0 =A0 =A0 stream vs. multiple via streams that are= sent
> individually, the
> > =A0 =A0 > =A0 =A0 =A0 difference may be more clear.
> > =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 Cheers,
> > =A0 =A0 > =A0 =A0 =A0 Charles
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Cheers,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Charles
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> I was wit= h you all the way until 4. That
> one I
> > =A0 =A0 don't
> > =A0 =A0 > =A0 =A0 =A0 understand.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> The name = you chose for this has
> connotations for
> > =A0 =A0 me, but
> > =A0 =A0 > =A0 =A0 =A0 isn't
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 fully in
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> harmony w= ith the definitions you give:
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > I'm happy= to change the name if you have a
> > =A0 =A0 suggestion
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Not yet. Maybe onc= e the concepts are more
> clearly
> > =A0 =A0 defined I
> > =A0 =A0 > =A0 =A0 =A0 will have
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 an
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > opinion.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> If we con= sider audio, it makes sense that
> multiple
> > =A0 =A0 streams
> > =A0 =A0 > =A0 =A0 =A0 can be
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> rendered = as if they came from different
> physical
> > =A0 =A0 locations
> > =A0 =A0 > =A0 =A0 =A0 in the
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> receiving= room. That can be done by the
> receiver if
> > =A0 =A0 it gets
> > =A0 =A0 > =A0 =A0 =A0 those
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> streams s= eparately, and has information
> about their
> > =A0 =A0 > =A0 =A0 =A0 intended
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> relations= hips. It can also be done by the
> sender or
> > =A0 =A0 MCU and
> > =A0 =A0 > =A0 =A0 =A0 passed
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 on
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> to
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> the recei= ver as a single stream with stereo
> or
> > =A0 =A0 binaural
> > =A0 =A0 > =A0 =A0 =A0 coding.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Yes. =A0It co= uld also be done by the sender
> using the
> > =A0 =A0 "linear
> > =A0 =A0 > =A0 =A0 =A0 array"
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 audio channel format. = =A0Maybe it
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > is true that stere= o or binaural audio channels
> would
> > =A0 =A0 always be
> > =A0 =A0 > =A0 =A0 =A0 sent as
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 a single stream, but I = was not
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > assuming that yet,= at least not in general
> when you
> > =A0 =A0 consider
> > =A0 =A0 > =A0 =A0 =A0 other
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 types too, such as line= ar array
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > channels.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> So it see= ms to me you have two concepts
> here, not
> > =A0 =A0 one. One
> > =A0 =A0 > =A0 =A0 =A0 has to
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 do
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> with desc= ribing the relationships between
> streams,
> > =A0 =A0 and the
> > =A0 =A0 > =A0 =A0 =A0 other
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 has to
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> do with t= he encoding of spacial
> relationships
> > =A0 =A0 *within* a
> > =A0 =A0 > =A0 =A0 =A0 single
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 stream.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe that is= a better way to describe it,
> if you
> > =A0 =A0 assume
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio is = always sent with all
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the channels in th= e same RTP stream. =A0Is that
> what you
> > =A0 =A0 mean?
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > I was conside= ring the linear array format to
> be
> > =A0 =A0 another type
> > =A0 =A0 > =A0 =A0 =A0 of
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 multi-channel audio, an= d I know
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > people want to be = able to send each channel in
> a
> > =A0 =A0 separate RTP
> > =A0 =A0 > =A0 =A0 =A0 stream.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 So it doesn't quite= fit with
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > how you separate t= he two concepts. =A0In my
> view,
> > =A0 =A0 identifying
> > =A0 =A0 > =A0 =A0 =A0 the
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 separate channels by wh= at they mean is
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the same concept f= or linear array and stereo.
> For
> > =A0 =A0 example
> > =A0 =A0 > =A0 =A0 =A0 "this
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 channel is left, this c= hannel is
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > center, this chann= el is right". =A0To me, that
> is the
> > =A0 =A0 same
> > =A0 =A0 > =A0 =A0 =A0 concept for
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 identifying channels wh= ether or
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > not they are carri= ed in the same RTP stream.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Maybe we are = thinking the same thing but
> getting
> > =A0 =A0 confused by
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 terminology about chann= els vs. streams.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Maybe. Let me try = to restate what I now think
> you are
> > =A0 =A0 saying:
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > The audio may cons= ist of several "channels".
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > Each channel may b= e sent over its own RTP
> stream,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > or multiple channe= ls may be multiplexed over
> an RTP
> > =A0 =A0 stream.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > I guess much of th= is can also apply to video.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > When there are exa= ctly two audio channels,
> they may be
> > =A0 =A0 encoded
> > =A0 =A0 > =A0 =A0 =A0 as
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > "stereo"= or "binaural", which then affects how
> they
> > =A0 =A0 should be
> > =A0 =A0 > =A0 =A0 =A0 rendered
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > by the recipient. = In these cases the primary
> info that
> > =A0 =A0 is
> > =A0 =A0 > =A0 =A0 =A0 required
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 about
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > the individual cha= nnels is which is left and
> which is
> > =A0 =A0 right.
> > =A0 =A0 > =A0 =A0 =A0 (And
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 which
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > perspective to use= in interpretting left and
> right.)
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > For other multi-ch= annel cases more information
> is
> > =A0 =A0 required
> > =A0 =A0 > =A0 =A0 =A0 about the
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > role of each chann= el in order to properly
> render them.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Thanks= ,
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 Paul > > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> Or, are y= ou asserting that stereo and
> binaural are
> > =A0 =A0 simply
> > =A0 =A0 > =A0 =A0 =A0 ways to
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> encode > > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> multiple = logical streams in one RTP stream,
> > =A0 =A0 together with
> > =A0 =A0 > =A0 =A0 =A0 their
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 spacial
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >> relations= hips?
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > No, that is n= ot what I'm trying to say.
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > Mark
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> _______________________________________________
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > clue mailing = list
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > > https://www.iet= f.org/mailman/listinfo/clue
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > >
> > =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<= br> > > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 > https://www.ietf.org= /mailman/listinfo/clue
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 _______________________= ________________________
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 clue mailing list
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 clue@ietf.org
> > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mail= man/listinfo/clue
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 > =A0 =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 >
> > =A0 =A0 >
> >
> >
> >
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

--bcaec54861941e6cc804aaa98716-- From Even.roni@huawei.com Tue Aug 16 21:54:08 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 D58E321F8888 for ; Tue, 16 Aug 2011 21:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.073 X-Spam-Level: X-Spam-Status: No, score=-105.073 tagged_above=-999 required=5 tests=[AWL=1.525, 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 h7H2SFhbhML6 for ; Tue, 16 Aug 2011 21:54:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7921F8880 for ; Tue, 16 Aug 2011 21:54:05 -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 <0LQ2007562W5KD@szxga04-in.huawei.com> for clue@ietf.org; Wed, 17 Aug 2011 12:52:54 +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 <0LQ200BQY2W5KS@szxga04-in.huawei.com> for clue@ietf.org; Wed, 17 Aug 2011 12:52:53 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-13-148.red.bezeqint.net [79.178.13.148]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQ20020S2V8L6@szxml11-in.huawei.com>; Wed, 17 Aug 2011 12:52:53 +0800 (CST) Date: Wed, 17 Aug 2011 07:51:37 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' Message-id: <02bc01cc5c99$6375adb0$2a610910$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gqO9ck5CtHUS9J9QrBvA5Q)" Content-language: en-us Thread-index: Acxcfl4GQlxhjyvZRbGGwK0sMoRhtAAGCkKQ References: <44C6B6B2D0CF424AA90B6055548D7A61AE9B48AD@CRPMBOXPRD01.polycom.com> <4E413021.3010509@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AEA65C62@CRPMBOXPRD01.polycom.com> <4E43D2BE.5010102@alum.mit.edu>

<02a501cc5c6d$1a2bf1e0$4e83d5a0$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] continuing "layout" discussion 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: ,

Subject:	I-D Action: = draft-alvestrand-one-rtp-01.txt
Date: =	Wed, 17 Aug 2011 01:48:18 -0700
From: =	internet-drafts@ietf.org
Reply-To:	internet-drafts@ietf.org
To: =	i-d-announce@ietf.org