Chris, Another user-oriented issue is: if I have to choose among all possible streams, how do I choose? Before I run out of bandwidth, I normally choose based on content. Some streams are redundant, some are empty rooms, etc. In order to choose, I need to know/see what it is I'm choosing. So, ideally, I would be able to see thumbnails/low res versions of streams so I could decide whether or not I want to connect to them. I do this now with normal vic, although all the bits from all the streams are always hitting my network. With the limited bandwidth demands of current vic streams this is not a problem. But with HD streams, choosing only some streams becomes more critical.
Thanks, -gurcharan Christoph Willing wrote: > > On 10/03/2007, at 4:55 AM, Bruce Curtis wrote: > >> >> On Mar 9, 2007, at 8:55 AM, gurcharan khanna wrote: >> >>> All, >>> >>> I think sending all stream types is a great idea, so the receiver >>> can choose the resolutions >>> needed. >>> >>> A related issue is bandwidth limitations. If I choose to receive 261 >>> instead of HD for that >>> reason, then I may not be able to tolerate all those bits on my >>> network. So, then the issue >>> becomes, how do I tell the source not to even send me the HD stream >>> for instance but only >>> the 261 streams? If the HD and 261 are two separate modules, then >>> that would work. If they >>> somehow are all integrated, maybe then that becomes a problem? >>> >>> -gurcharan >> >> Two ways to allow the receiver to choose between the streams would >> be to >> >> 1. Send the streams in separate multicast groups. >> >> 2. Use Source Specific Multicast (SSM) and source the streams >> from two different unicast source IP numbers. > > > Gurcharan, > > Our current plan is to use the first of these methods that Bruce > mentions. A twist on the AG toolkit's built in dynamic address > allocation mechanism for new stream types makes this possible. Each > new DV or HDV Producer is allocated a new multicast address. Any new > DV or HDV Consumer is given a list of streams to choose from _before_ > subscribing to any of them. > > That means that for DV & HDV, there'll be a separate vic instance for > each video source being viewed (as distinct to the default H261 video > services which show all available video sources for a venue in the > same vic instance). This is all sort of working now, but there is a > problem with VenueClients up to v3.0.2 not being updated with new > stream information after initially entering a venue; that will be > fixed for AG 3.1. > > > chris > > >>> Christoph Willing wrote: >>>> >>>> On 09/03/2007, at 3:49 AM, John I Quebedeaux Jr wrote: >>>> >>>>> Someone asked me about this camera for HD use on the AG: >>>>> http://www.picturephone.com/products/sony_evi_hd1.htm >>>>> >>>>> Anyone have any experience with it? I'm wondering if it was used, >>>>> how to best "capture" it into a system for use on the AG... >>>>> interest in using HD is high here. I'm more concerned about >>>>> logistical issues with high resolution images on displays that >>>>> don't have that much "resolution" space - particularly if several >>>>> sites are involved. >>>> >>>> >>>> John, >>>> >>>> With regard to screen space logistics, we've developed a version of >>>> vic that does DV and HDV - full details and perhaps a demo at the >>>> forthcoming AG Retreat. One of the changes is the ability to resize >>>> the video window(s) to any size you like. Thus you could accomodate >>>> several streams at smaller than true HD size when display space >>>> becomes tight. >>>> >>>> BTW, I think that when DV, HDV, HD are all more common in the AG, >>>> best practice will be to always send those formats as duplicates of >>>> standard H261 streams so that other sites can choose to view their >>>> own preferred mix of H261 and higher resolution formats (somewhat >>>> avoiding the screen real estate problem you raised, not to mention >>>> bandwidth issues). The cameras we've been testing with have a >>>> number of simultaneous outputs available so its trivial to send >>>> both DV/HDV and H261 at the same time. >>>> >>>> >>>> chris >>>> >>>> >>>> Christoph Willing +61 7 3365 8350 >>>> QCIF Access Grid Manager >>>> University of Queensland >>>> >>>> >>>> >>> >>> --------------------------- >>> Gurcharan S. Khanna, Ph.D. >>> Director of Research Computing >>> Office of the Vice President for Research >>> >>> Director, Interactive Collaboration Environments Laboratory, >>> Center for the Advancing the Study of Cyberinfrastructure >>> --- >>> Rochester Institute of Technology >>> 1 Lomb Memorial Drive >>> Rochester, New York 14623-5603 >>> Phone: 585-475-7504 ~ Cell: 585-355-1603 >>> Email: [email protected] >>> Http: www.rit.edu/~gskpop >>> >> >> >> --- >> Bruce Curtis [email protected] >> Certified NetAnalyst II 701-231-8527 >> North Dakota State University >> > > Christoph Willing +61 7 3365 8350 > QCIF Access Grid Manager > University of Queensland > > > -- --- Gurcharan S. Khanna, Ph.D. Director of Research Computing Office of the Vice President for Research --- Director, Interactive Collaboration Environments Laboratory, Center for the Advancing the Study of Cyberinfrastructure --- Rochester Institute of Technology 1 Lomb Memorial Drive Rochester, New York 14623-5603 Phone: 585-475-7504 ~ Cell: 585-355-1603 Email: [email protected] http://www.rit.edu/~gskpop
