[GEM-dev] Re: [PD] multiple_window feature of Gem?

[B. Bogart]

Hi Jeremy,

Ah I did not realize DVTS was multicast capable.

Is UltraVideoconferencing open-source or IP-restricted?
Indeed the project sounds very interesting. I hope to hear about the
future developments. Have you spoken to how this may help the TOT
lighTWIST system?

B.


Jeremy Cooperstock wrote:
> Greetings all,
>  IIRC, the TOT project is using DVTS or a derivative thereof, in which
> case, the software is already multicast capable (although perhaps not in
> the base release).
>
>  Our UltraVideoconferencing system is expected to gain multicast
> capability (hopefully for both IPv4 and IPv6) later this year and this
> would serve (at least) for DV, analog, or SDI video distribution.  Since
> our needs entail processing of the video as per the requirements of each
> receiver, and with minimal latency, DV would not be a suitable candidate
> for this purpose, given the encoding and decoding costs, so we're
> considering instead raw transmission of a bounding box region of
> segmented (i.e. background-removed) video.  In the typical case, this
> payload would fit comfortably on a 100Mbps network, although
> segmentation problems or scene discontinuities that lead to full frame
> transmission would require either compression or gigabit infrastructure.
>
> - Jeremy
>
> B. Bogart wrote:
>
>> Thanks for the link, I'll take a look when I have more time.
>>
>> Ok so its Chromium itself that passes the texture data through the
>> cluster. Indeed video would be more difficult, but with a 1Gbps
>> multicast lan one should easily be able to distribute a DV stream to all
>> machines... in theory! Are there multicast DV streamers???
>>
>> The streaming part fits very well into TOT.
>>
>> I've CCed Franz Hildgen and Simon Piette who are looking after the DV
>> point-2-point application teleCHACHA.
>>
>> Franz and Simon, we're talking about pd/Gem working in a cluster
>> context, where the GL context is forwarded to a number of machines that
>> each processes and projects one part of the image. This is very closely
>> related to the lighTWIST and pixelTANGO integration problem.
>>
>> Would it be possible to multicast a DV stream to all the cluster
>> machines, so that each could use the stream in its portion of the final
>> image?
>>
>> Mike Wozniewski from McGill is looking at using chromium with pd/Gem for
>> a cave application.
>>
>> B>
>>
>> Mike Wozniewski wrote:
>>
>>> Hey.
>>>
>>>> I did not see a link to any in depth documentation from chromium.
>>>
>>>
>>>
>>>
>>> Check http://chromium.sourceforge.net/doc/index.html. Very
>>> comprehensive.
>>>
>>>> I'm not a c++ programmer so I'm not sure
>>>> what it would involve to build these functions into GL wappers for Gem.
>>>> I'm not sure how the functions latch onto an existing context, and how
>>>> the whole thing works architecturally (what parts run on what machines,
>>>> master slave connections etc..
>>>
>>>
>>>
>>>
>>> Well, from the docs, it seems that we don't have to do anything at all
>>> to Gem. This is because Chromium disguises itself as the OpenGL library
>>> - ie, when a GL instruction is made, Chromium intercepts and the regular
>>> system OpenGL library sits idle.
>>>
>>>> I just wonder about performance, considering the speed of the AGP bus
>>>> for texture transfers vs ethernet transport between the source and
>>>> destination for the texture! especially if your talking about moving
>>>> video...
>>>
>>>
>>>
>>>
>>> So according to http://brighton.ncsa.uiuc.edu/%7Eprajlich/wall/ppb.html,
>>> when distributing video, the movie has to first be played in "write
>>> mode", where all textures are cached onto the disks across the cluster.
>>> Then subsequent playback is done in "read mode", where it's just read
>>> from local disk on each machine. I see problems with this in that all
>>> videos have to exist on disk first (no streaming from live cameras), the
>>> first playback is going to be SLOW, and if you have many many video
>>> clips this could be extremely annoying.
>>>
>>>> (are you guys even using video in your cave application?)
>>>
>>>
>>>
>>>
>>> Not yet. But we will eventually want to put video avatars of remote
>>> participants into the world (ouch - this is not going to work with the
>>> above mentioned strategy).
>>>
>>> -Mike
>>>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050323/5942eb92/attachment.pgp>