<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I implemented this at a former job using completely open source
tools and off-the-shelf components: (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://vimeo.com/25094355">http://vimeo.com/25094355</a>)<br>
<br>
We used vlc to encode the video from an HD webcam and display it on
the other end. We had the audio in a separate vlc stream. There was
a web server with some simple web services that maintained the list
of rooms and which IP+port each connection was on. It was still P2P,
with the web services acting as a mediator. The awesome part was
having a shared partially transparent desktop that both people could
interact with.<br>
<br>
Some lessons learned:<br>
<br>
1) We had to go through a lot of hoops to get the latency as low as
possible. Even a couple tenths of a second is annoying enough to
make the system practically useless. Bandwidth can be cranked down
quite a bit until you have barely recognizable blocky video, but
it's still useful as long as the latency is low.<br>
<br>
2) Because the latency was so low, any jitter would freak out VLC,
so we had to have a process that watched VLC and restarted it if
anything went wrong. The UI also had a way to reconnect the feeds.<br>
<br>
3) We did have issues with networks that couldn't open a port and
forward it to our systems. I imagine that wouldn't be so much of a
problem here where we have more control over our networks.<br>
<br>
4) Ubuntu+Compiz is pretty awesome for being able to write rules for
making windows maximized, forced in front, and partially
transparent. Windows and Mac couldn't even come close to
accomplishing it.<br>
<br>
5) Video telepresence is cool, but bandwidth heavy and breaks apart
quickly when there are multiple feeds. That's why we separated the
video and audio. The audio had lower latency and bandwidth, and it
was easy to connect to multiple people to get the teleconference
effect, but for video we settled on being able to see only one of
the feeds at a time. This had the additional advantage of allowing
anyone to participate no matter what hardware they had.<br>
<br>
6) You NEED noise canceling mic/speaker setups. With any kind of
audio delay, you have the mic picking up the speaker, and then you
get a feedback loop that gets out of control. The noise canceling
mic/speakers solve this.<br>
<br>
Bob Baddeley<br>
<br>
On 01/19/2012 10:52 AM, Elmar mc.fly Lecher wrote:
<blockquote cite="mid:4F184A42.7010704@ramdrive.org" type="cite">
<pre wrap="">Am 19.01.2012 17:44, schrieb Chris Weiss:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Jan 19, 2012 at 10:30 AM, Elmar mc.fly Lecher
<a class="moz-txt-link-rfc2396E" href="mailto:mc.fly@ramdrive.org"><mc.fly@ramdrive.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I would propose using chaosvpn for the link between the hackerspaces.
</pre>
</blockquote>
<pre wrap="">telepresence is very latency sensitive, I'm not sure if a VPN would
perform well enough for HD video. VPNs tend to even mess up simple
64Kbps audio.
</pre>
</blockquote>
<pre wrap="">
The reason why we use tinc is that we use it for VOIP. The ccc voip
system has been the main user for our network.
Low latency is also the reason why "full mesh" was one of the design
principals
mc.fly ...
_______________________________________________
Discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.hackerspaces.org">Discuss@lists.hackerspaces.org</a>
<a class="moz-txt-link-freetext" href="http://lists.hackerspaces.org/mailman/listinfo/discuss">http://lists.hackerspaces.org/mailman/listinfo/discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>