[AG-TECH] Sony EVI-HD1 camera
gskpop at cis.rit.edu
Sat Mar 10 00:01:56 CST 2007
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.
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:
>>> I think sending all stream types is a great idea, so the receiver
>>> can choose the resolutions
>>> 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?
>> 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.
> 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.
>>> 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:
>>>>> 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.
>>>> 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.
>>>> 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 at rit.edu
>>> Http: www.rit.edu/~gskpop
>> Bruce Curtis bruce.curtis at ndsu.edu
>> 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 at rit.edu
More information about the ag-tech