On 10/03/2007, at 4:01 PM, gurcharan khanna wrote:
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.
Gurcharan,
chris
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: gurcharan.khanna@xxxxxxx Http: www.rit.edu/~gskpop
--- Bruce Curtis bruce.curtis@xxxxxxxx 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: gurcharan.khanna@xxxxxxx http://www.rit.edu/~gskpop
Christoph Willing +61 7 3365 8350 QCIF Access Grid Manager University of Queensland