<html>
<head>
</head>
<body>
Jay,<br>
<br>
Just curious - on your PIG with the USB camera, are you having the problem
that I and others have been having with the bluish tint?<br>
<br>
Darin Oman<br>
NCAR<br>
<br>
Jay Beavers wrote:<br>
<blockquote type="cite" cite="mid:79107D208BA38C45A4E45F62673A434D06049B83@red-msg-07.redmond.corp.microsoft.com">
<pre wrap="">We're just using standard tower workstations -- a Dell Precision 530 for<br>instance. For smaller environments, I'm using the smaller form factor<br>PCs like the mini configuration Precision 340. The holdup there has<br>been the lack of a good half height AGP video card with multiple video<br>outs.<br><br>I've finally got a hold of a half height AGP NVIDIA Quadro4 NVS 200<br>which drives two displays. If you're doing small nodes (1-3 cameras,<br>1-2 displays), the combination of a Precision 340 with the Quadro4 would<br>be great -- 2'x2'x4". For most AG node scenarios though, I'd stick with<br>the Precision 530.<br><br>We've been trying out laptop portable nodes, but we're still faced with<br>three problems:<br><br> * Laptops come with 1394, but without power so a clunky external 1394<br>powered hub with power adapter is needed, or we have to stick with 1 USB<br>camera (Logitech QuickCam Pro 3000)<br> * Pushing large amounts of multicast over wireless 802.
11a has failed<br>on our first set of 802.11a equipment (Proxim Harmony). 802.11b is<br>working OK, but isn't a scalable solution.<br> * A Gentner XAP-400 et al is a little hard to move around ;-) and the<br>ClearOne didn't work well enough to replace it.<br><br>The first two aren't showstoppers for laptop deployments, but the third<br>is.<br><br> - jcb<br><br>-----Original Message-----<br>From: Jonathan C. Humfrey [<a class="moz-txt-link-freetext" href="mailto:jch@cs.ucsb.edu">mailto:jch@cs.ucsb.edu</a>] <br>Sent: Thursday, August 29, 2002 9:02 AM<br>To: Jay Beavers<br>Cc: Osland, CD (Chris) ; <a class="moz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>multicast environment <br><br><br><br>Jay,<br><br>Can you tell me what the exact setup of your display machine is? Are<br>they<br>rackmount? I have had a real problem with our display machine which<br>uses<br>a SuperM
icro motherboard made for a server and we end up getting a lot<br>of<br>loss in the rendering process... we're looking for a rackmount dual<br>processor machine that will render much more effectively. Any<br>suggestions?<br><br>Jonathan<br><br>On Thu, 29 Aug 2002, Jay Beavers wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">We're using 1394 cameras in addition to analog PCI based capture<br></pre>
</blockquote>
<pre wrap=""><!---->cards.<br></pre>
<blockquote type="cite">
<pre wrap="">1394 cameras have many advantages (integrated power, control, and data<br>cables; higher quality all-digital signal; lower CPU utilization) and<br>one of them is that realistically you can fit 3 cameras per PCI slot.<br>In other work at MSResearch that involve camera arrays, they use 5+<br></pre>
</blockquote>
<pre wrap=""><!---->1394<br></pre>
<blockquote type="cite">
<pre wrap="">cameras running at 640x480 and software to create one very large,<br></pre>
</blockquote>
<pre wrap=""><!---->highly<br></pre>
<blockquote type="cite">
<pre wrap="">detailed image that appears as one virtual large video source. You<br></pre>
</blockquote>
<pre wrap=""><!---->can<br></pre>
<blockquote type="cite">
<pre wrap="">see this in the papers on the 'Ring Camera'. This isn't ready for<br>AG-like scenario trials yet, as it's still in early prototype stage.<br><br>With the continuing march upwards in PC capacity, I don't foresee<br>multi-node computers as being required by number or quality of video<br>streams. We're quite happy doing multiple capture and multiple render<br>streams on our dual P-IV workstations today, and we could easily go up<br>in capacity over 50% by moving from our 1.7 GHz CPUs to 2.8 GHz CPUs<br>that are now available (and go from 400 MHz dual channel RD-RAM to 533<br>MHz dual channel RD-RAM at the same time). We take advantage of the<br></pre>
</blockquote>
<pre wrap=""><!---->CPU<br></pre>
<blockquote type="cite">
<pre wrap="">assist provided by cards like the NVIDIA GeForce and the DirectX Video<br>Acceleration architecture that is part of DirectShow which allows the<br>graphics card to offload significant portions of the decoding and<br>rendering.<br><br>We are using multiple computers per node now for pure logistical<br>reasons. We're using one computer to handle all the A/V traffic, a<br>wireless Tablet PC to drive PowerPoint with ink, and a laptop as the<br>administrative/diagnostic console. Our hope is to make the<br>administrative console needed only for occasional onsite diagnostics<br>(like adjusting the microphone gain/gating settings for the room) as<br>operations continues to get simpler. Our admin console used to be on<br>the A/V node, but we found it is too disruptive to use to have the<br>operator run over to the A/V node whenever any adjustments need to be<br>made ;-) We're looking at other solutions, like moving the A/V node<br></pre>
</blockquote>
<pre wrap=""><!---->to<br></pre>
<blockquote type="cite">
<pre wrap="">an operations closet or using Mira devices (LCD monitors with Remote<br>Desktop logic built in) or providing a web-based admin interface<br>directly on the A/V node to keep the Admin functions integrated on the<br>A/V node.<br><br>We can make signals from multiple computers 'appear' to be from one<br>logical place by sending signals from the same CName, at least until<br></pre>
</blockquote>
<pre wrap=""><!---->we<br></pre>
<blockquote type="cite">
<pre wrap="">start using SSM and then the IP address becomes important. I don't<br></pre>
</blockquote>
<pre wrap=""><!---->have<br></pre>
<blockquote type="cite">
<pre wrap="">a clear concept of whether we would ever use the same CName among more<br>than one computer. In our scenario, education, we generally give a<br>'room' CName to the A/V workstation (E.G. <a class="moz-txt-link-abbreviated" href="mailto:MSR-113-1021@Microsoft.Com">MSR-113-1021@Microsoft.Com</a>)<br>and use a 'professor' CName (E.G. <a class="moz-txt-link-abbreviated" href="mailto:DrBob@Washington.Edu">DrBob@Washington.Edu</a>) for the Tablet<br>PC and an 'operator' CName (E.G. <a class="moz-txt-link-abbreviated" href="mailto:JBeavers@Microsoft.Com">JBeavers@Microsoft.Com</a>) for the<br>operator's console. Strictly speaking, what's a "node" in that design<br>and what are just "personal" devices?<br><br> - jcb<br><br>-----Original Message-----<br>From: Osland, CD (Chris) [<a class="moz-txt-link-freetext" href="mailto:C.D.Osland@rl.ac.uk">mailto:C.D.Osland@rl.ac.uk</a>] <br>Sent: Thursday, August 29, 2002 7:21 AM<br>To: Jay Beavers; <a class="m
oz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>multicast environment <br><br>It may not be relevant (I'm not in any sense a network type person)<br>but I foresee a requirement for more than one capture computer to<br>be regarded as part of a single node. There are already times when<br>I would like to put out more than 4 video streams, and I also want<br>to start to use higher bandwidth links (e.g. 640x480, 800x600 and<br>1024x768 off computers). There aren't many motherboards with more<br>than 6 PCI slots, and with one gone on networking, a second video<br>capture computer that appeared seamlessly in the venue would be a<br>bonus.<br><br>I don't know whether this requires what you are discussing; if it<br>doesn't, please ignore!<br><br>Cheers<br><br>Chris Osland<br><br>____________________________________________________________________<br>Chris Osland
Office tel: +44 (0) 1235 446565<br>Digital Media and Access Grid Medialab tel: +44 (0) 1235 446459<br>BIT Department Access Grid room tel: +44 (0) 1235 445666<br>e-mail: <a class="moz-txt-link-abbreviated" href="mailto:C.D.Osland@rl.ac.uk">C.D.Osland@rl.ac.uk</a> Fax: +44 (0) 1235 445597<br><br>CLRC Rutherford Appleton Laboratory (Bldg. R18)<br>Chilton, DIDCOT, Oxon OX11 0QX, UK<br><br>[The contents of this email are confidential and <br>are for the use of the intended recipient only.<br>If you are not the intended recipient do not take <br>any action on it or show it to anyone else,<br>but return this email to the sender and delete your copy of it.]<br><br><br><br><br><br>-----Original Message-----<br>From: Jay Beavers [<a class="moz-txt-link-freetext" href="mailto:jbeavers@microsoft.com">mailto:jbeavers@microsoft.com</a>]<br>Sent: 29 August 2002 06:19<br>To: <a class="moz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag
-tech@mcs.anl.gov</a><br>Subject: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>multicast environment <br><br><br>FYI, thought I would forward over this discussion I started on the<br></pre>
</blockquote>
<pre wrap=""><!---->IETF<br></pre>
<blockquote type="cite">
<pre wrap="">AVT mailing list (AVT owns RTP, the transport of AG).<br><br>We're looking into enabling browsing of active participants in Venues<br>that you're interested in but not joined to, as well as thinking about<br>tiering multicast traffic between 'important' and 'less important'<br>streams.<br><br>If anyone on AG-Tech has thoughts in this area, I'd love to hear them.<br><br> - jcb<br><br>-----Original Message-----<br>From: Colin Perkins [<a class="moz-txt-link-freetext" href="mailto:csp@isi.edu">mailto:csp@isi.edu</a>] <br>Sent: Tuesday, August 27, 2002 12:10 PM<br>To: Jay Beavers<br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:avt@ietf.org">avt@ietf.org</a><br>Subject: Re: [AVT] Multiple IP address scenarios in a multicast<br>environment <br><br>Comments inline...<br><br>--> "Jay Beavers" writes:<br></pre>
<blockquote type="cite">
<pre wrap="">Scenario 1, Who's Talking?<br><br>An application is using RTP over multicast UDP on an IPv4, IGMPv2<br>network. When a client subscribes to a multicast group address using<br>IGMPv2, the client receives all traffic on that multicast group<br></pre>
</blockquote>
<pre wrap="">address,<br></pre>
<blockquote type="cite">
<pre wrap="">including all RTP and RTCP traffic, regardless of sender or port.<br><br>The client application can join any one of 30 available multicast<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->group<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">addresses. The list of possible multicast group addresses and their<br>associated details is obtained via a unicast query once at the start<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->of<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the client application. The client wants to get some information<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->about<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">who is in each multicast group, preferably by receiving the RTCP SDES<br>traffic from each multicast group on port 5005.<br><br>For discussion sake, there are five clients in each multicast group,<br>each client sending 1 Mb/s of RTP traffic. Each client is assumed to<br>have at least 10 Mb/s of quality connectivity to an unloaded network<br>backbone.<br><br>Problem 1:<br><br>If the client application sends a multicast group address join<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->request<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">for all 30 multicast group addresses, they will receive the RTCP SDES<br>traffic, but also the RTP traffic from each multicast group. This<br></pre>
</blockquote>
<pre wrap="">works<br></pre>
<blockquote type="cite">
<pre wrap="">out to 30 * 5 * 1 Mb/s = 150 Mb/s of aggregate traffic, vastly<br></pre>
</blockquote>
<pre wrap="">exceeding<br></pre>
<blockquote type="cite">
<pre wrap="">the 10 Mb/s client network capacity.<br><br>Potential Solution 1:<br><br>Are there any thoughts about how to approach this? I hesitate to<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->load<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">group membership state on a server due to scalability, reliability,<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->and<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">stale data concerns.<br></pre>
</blockquote>
<pre wrap="">Valid concerns. If you did choose this approach, a well connected<br></pre>
</blockquote>
<pre wrap=""><!---->group<br></pre>
<blockquote type="cite">
<pre wrap="">member could listen to the RTCP and allow SNMP queries (the RTP MIB<br></pre>
</blockquote>
<pre wrap=""><!---->can<br></pre>
<blockquote type="cite">
<pre wrap="">provide SDES information).<br><br></pre>
<blockquote type="cite">
<pre wrap="">Source Specific Multicast wouldn't solve this, as I would need to<br>subscribe to all sources to receive their RTCP traffic which would<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->also<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">bring down their RTP traffic unless RTP and RTCP were separated onto<br>separate IP addresses. I've also wondered if RTCP SDES traffic could<br></pre>
</blockquote>
<pre wrap="">be<br></pre>
<blockquote type="cite">
<pre wrap="">duplicated to one shared multicast group address, the problem being<br>knowing which SSRCs are associated with which multicast group<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->addresses<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(associated by a RTCP APP packet perhaps?)<br></pre>
</blockquote>
<pre wrap="">Or use two multicast groups per session, one for the data and one for<br>the<br>RTCP? <br><br></pre>
<blockquote type="cite">
<pre wrap="">---<br><br>Scenario 2, We're All Equal, But Some Are More Equal Than Others:<br><br>The same application is running, but the number of participants has<br>increased, perhaps because the conversations are using a lecture or<br>panel discussion model. Now we have a few (5?) important clients and<br></pre>
</blockquote>
<pre wrap="">50<br></pre>
<blockquote type="cite">
<pre wrap="">less important clients.<br><br>It's decided that the important clients should continue sending the 1<br>Mb/s of data. Less important clients can send an occasional (every<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->30<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">seconds) high resolution snapshot as well as 100 kb/s of A/V streams.<br><br>If all data is sent over one multicast group address, the aggregate<br>network bandwidth is 5 * 1 Mb/s + 50 * 100 kb/s = 10 Mb/s, severely<br>stretching the network capacity of the clients. The clients would<br>prefer to receive the streams for important clients and the snapshots<br>for less important clients. Optionally, the 100 kb/s streams from<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->the<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">less important clients would be enabled on a stream by stream basis.<br><br>Problem 2:<br><br>Source Specific Multicast has some relevance here, as it could be<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->used<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to subscribe to a subset of the less important client A/V streams.<br>However, the client would still want to receive RTCP and snapshot<br>information from all clients.<br><br>Potential Solution 2:<br><br>Traffic could be broken into two multicast group addresses again,<br></pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->with<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">unfiltered traffic (RTCP, RTP snapshots) being on one address and<br></pre>
</blockquote>
<pre wrap="">source<br></pre>
<blockquote type="cite">
<pre wrap="">filtered traffic (RTP A/V streams) being on a separate address. This<br>would also allow IGMPv2 networks to work, as clients on that network<br>could subscribe to only the traffic on the unfiltered multicast group<br>address and lose only the capacity to see A/V streams from the less<br>important clients.<br></pre>
</blockquote>
<pre wrap="">You could also run two RTP sessions, one for the "important" clients,<br>and<br>one for the rest, each with their own RTCP. The CNAME fields would let<br>you<br>relate participants between the sessions.<br><br></pre>
<blockquote type="cite">
<pre wrap="">---<br><br>In both these cases, the solution involves sending RTCP on a separate<br></pre>
</blockquote>
<pre wrap="">IP<br></pre>
<blockquote type="cite">
<pre wrap="">address from its associated RTP streams, which certainly isn't<br></pre>
</blockquote>
<pre wrap="">mentioned<br></pre>
<blockquote type="cite">
<pre wrap="">in RFC 1889 anywhere. Any other thoughts on how to approach these<br>scenarios?<br></pre>
</blockquote>
<pre wrap="">See above. I don't have strong objections to sending RTCP on a<br></pre>
</blockquote>
<pre wrap=""><!---->separate<br></pre>
<blockquote type="cite">
<pre wrap="">multicast group to the associated RTP, in the first example.<br><br>Colin<br><br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
</body>
</html>