VidChat? Plz?

[Orchard]

Michael if you are looking into modifying your service to have an option to allow video conferencing and music for games, you should open up a thread(and post a link to it here and on the other threads you popped into) asking what features people are looking for. That way you get a coherent list of what your target audience is looking for.

If you can bring your prices down to around what Oovoo used to be, but support more then 6 people that would be nice. Though I don't know if that would be feasible. Oovoo must have raised their prices for some reason.

Yes, but that reason could easily have been 'greed'. Remember, Oovoo doesn't have a lot of real visible competition in terms of what they are doing. I would argue that they NEED a competitor in order to survive. Skype is INSANELY popular, but it's also free and works (IIRC) on a different bandwidth model and (most importantly) does not support 6-way video. Or even 3-way. Some days I'm not even sure they really care that much about 2-way video....

[RPTroll]

Agrreed. Although it would be nice to find some open source/free software to adopt as a standard so folks can hop from game to game without relearning/redownloading/reregistering for each new DM they try.

[BigO]

I'm sure there's a good answer for this, but what I don't understand is why there has to be a bandwidth cost at all with video chat. Seems like you could do it peer-to-peer just fine. And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

By the way, iChat on mac does multi-party video very well, and for free. Of course everyone has to be using a mac, but from where I sit, that's not a bad thing...

[Orchard]

I'm sure there's a good answer for this, but what I don't understand is why there has to be a bandwidth cost at all with video chat. Seems like you could do it peer-to-peer just fine. And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

By the way, iChat on mac does multi-party video very well, and for free. Of course everyone has to be using a mac, but from where I sit, that's not a bad thing...

Yeah, I wouldn't mind owning a mac...except that I can't roll my own...

WELL...I guess I COULD, but it's not EXACTLY in keeping with the EULA....

...and I'm still confused as to why the OSS community hasn't come up with a viable p2p multi-party chat solution...

[Full Bleed]

For the lifetime of iTabletop, which is still a startup and thus a gamble.

True, it's a consideration. But you should probably define "startup" a little more accurately when placing doubt in people's minds.

iTabletop had been around a little while before I initially signed up with them on 9/21/07 to follow their development. So, it has been fully operational *at least 20 months* in the current version, which is perfectly respectable in what it does (though, until now, I've obviously opted to use MT and Oovoo exclusively.)

But, to be even more accurate about the timeline, the itabletop.com Domain was registered: 28-FEB-07. More than 2 years ago.


To me there is nothing to indicate that it won't be around for another 20+ months as the Silverlight-based version they are developing is significantly better than the Flash-based version they have available now. That's my official "break-even" when compared to Oovoo (though it's 11 months on Oovoo's new pricing structure for 11-way VC versus Oovoo's 6.)

So, for us, if the service lasts a year the "risk" was worth it. Beyond that, the investment pays off big. In life there is always risk/reward.

And, for the record, now that I've seen the Silverlight development videos, I'm even more confident that we made the right call as just about every major deficiency in the current version has been addressed and it'll be an even better compliment to my MT use... which is currently on hiatus.

[Full Bleed]

I'm sure there's a good answer for this, but what I don't understand is why there has to be a bandwidth cost at all with video chat. Seems like you could do it peer-to-peer just fine. And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

By the way, iChat on mac does multi-party video very well, and for free. Of course everyone has to be using a mac, but from where I sit, that's not a bad thing...

This isn't a Mac or PC issue. It's an upstream bandwidth issue. If iChat can do multiparty VC p2p, then it's cutting some corners. Low resolution, low voice-quality, and/or lower fps per stream. The average broadband connection simply can't serve decent rez, audio, and fps to more than a couple locations simultaneously (if that.)

If you personally have to serve every connection you're going to need a lot of upstream, which many people do not have. Voice takes around 56 to 128k (depending on the quality/content). Video can range from 128 to 512 easily enough for 15-30 fps (resolution dependent.) Now connect to 6 people and multiply accordingly.

There may be a day when this is feasible and everyone will have 3mbs+ up. But many people still only have 256-386k upstream with their broadband provider right now so a central server is the only way to have quality VC (which I judge to be 15fps+ with at least phone quality voice.)

[BigO]

If iChat can do multiparty VC p2p, then it's cutting some corners. Low resolution, low voice-quality, and/or lower fps per stream. The average broadband connection simply can't serve decent rez, audio, and fps to more than a couple locations simultaneously (if that.)

I didn't say iChat was p2p, I just said it was free. I have no idea what their server model is, though it probably is going through a server.

They are clearly not cutting corners though, it's the best quality of any other video chat client I have ever used. Better than skype, better than ooVoo, on the same connection.

[werole]

I didn't say iChat was p2p, I just said it was free. I have no idea what their server model is, though it probably is going through a server.

Yeah, iChat's does use a centralized server model, and the server depends on which service you are going though (ie, where your user account lives) MobileMe goes through Apple servers, whereas AIM goes through AOL servers.

I'm sure there's a good answer for this, but what I don't understand is why there has to be a bandwidth cost at all with video chat. Seems like you could do it peer-to-peer just fine. And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

I investigated p2p as an option, but there's no p2p streaming technology that I'm aware of that allows live broadcast of video. There are some tools that allow you to use p2p connections to stream pre-recorded video, but obviously that wouldn't work for video chat. From my understanding, the difficulty lies in the fact that a central server is needed to handle compressing the incoming data into a streamable format (CPU intensive), and serving it in a way that can be played with little to no latency (the current standard for doing so is the RTMP protocol which requires such a centralized server). Also, keep in mind that if there are multiple people, a stream must not simply be sent to a single user, but must be "multicast" so that numerous users can pickup the same video feed without the need to create multiple copies of the feed (something the RTMP server handles)

Here's some more info from wikipedia:
http://en.wikipedia.org/wiki/Streaming_media

[Orchard]

I didn't say iChat was p2p, I just said it was free. I have no idea what their server model is, though it probably is going through a server.

Yeah, iChat's does use a centralized server model, and the server depends on which service you are going though (ie, where your user account lives) MobileMe goes through Apple servers, whereas AIM goes through AOL servers.

I'm sure there's a good answer for this, but what I don't understand is why there has to be a bandwidth cost at all with video chat. Seems like you could do it peer-to-peer just fine. And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

I investigated p2p as an option, but there's no p2p streaming technology that I'm aware of that allows live broadcast of video. There are some tools that allow you to use p2p connections to stream pre-recorded video, but obviously that wouldn't work for video chat. From my understanding, the difficulty lies in the fact that a central server is needed to handle compressing the incoming data into a streamable format (CPU intensive), and serving it in a way that can be played with little to no latency (the current standard for doing so is the RTMP protocol which requires such a centralized server). Also, keep in mind that if there are multiple people, a stream must not simply be sent to a single user, but must be "multicast" so that numerous users can pickup the same video feed without the need to create multiple copies of the feed (something the RTMP server handles)

Here's some more info from wikipedia:
http://en.wikipedia.org/wiki/Streaming_media

In otherwords, in order to make it happen, someone would need to write a p2p streaming library from scratch that was designed for this. I'd volunteer if I knew even the SLIGHTEST thing about where to begin. I don't, and by the time I figure it out, it will have been solved by someone MUCH MUCH MUCH smarter than I am. Several times.

[Full Bleed]

I didn't say iChat was p2p, I just said it was free. I have no idea what their server model is, though it probably is going through a server.

Heh, well, reading the posting I responded to that sounds like what you were saying since you segued right from wondering why people didn't use p2p to iChat.

And no, I don't mean p2p in the bittorrent sense, but p2p meaning that the video is passing back and forth between the people talking and not doing a round trip through a central server.

By the way, iChat on mac does multi-party video very well, and for free.

Just checked out the Wiki for iChat... cool that it's free, but does it only support 4-way VC? I don't even see mention of VC as a feature on the Apple site.

[BigO]

Just checked out the Wiki for iChat... cool that it's free, but does it only support 4-way VC? I don't even see mention of VC as a feature on the Apple site.

I don't know how many it supports. 4 is the most that I have attempted personally. It might do more than that, or perhaps not. I don't know. There are more features listed here but that's a list of what's new, and the video was already in the app so it doesn't mention it.

There's some awesome stuff, including built-in recording, screen sharing, and iChat theater where you can play movies or other media assets for the viewers. All kinds of great uses for gamers and business folk alike.

[Azhrei]

Also, keep in mind that if there are multiple people, a stream must not simply be sent to a single user, but must be "multicast" so that numerous users can pickup the same video feed without the need to create multiple copies of the feed (something the RTMP server handles)

And therein lies the simplest solution: set up a multicast network.

Multicast network packets are those sent to IP addresses that are not valid for a single host, such as 224.x.x.x -- they are not point-to-point packets but neither are they truly "broadcast" packets.

Multicast packets are sent to all hosts who have "registered" for receipt of the given destination. So if I have 4 computers on a network and only one of them registers for 224.0.1.14, then the gateway device for that computer will be told to forward packets for 224.0.1.14 to the network segment. The gateway device will then notify his gateway device, and so on, until it reaches the Internet. Now any packets destined for 224.0.1.14 will be sent to the ISP who will forward them to your gateway device (probably a router), which then sends them further downstream until they get to your computer.

The beauty of this is what happens if another computer on your network registers for 224.0.1.14 -- the gateway device(s) record the registration, but no additional packets flow to the ISP, because the ISP already is sending them to your router.

Unfortunately, many IP stacks don't implement multicast correctly or are filled with bugs. Nothing we can do about that here, so let's just assume they all work.

Suppose that those 4 computers mentioned above all wanted to multicast to each other? Each would need its own multicast address. For example, 224.1.12.101 thru 224.1.12.104. Each computer would register as a listener on the multicast addresses and would publish its own video on its multicast address. All done!

As there are many gateway devices between your home computer and your friends who are gaming with you, not all of them may support multicast addresses. So using a VPN package (such as OpenVPN, Hamachi, IPSec, or something else) would put all of the machines on the same virtual "LAN" and now when they register for the multicast addresses, the packets would be forwarded over the VPN layer.

The above should work fine, if the VPN layer supports multicasting. If it doesn't, then your SOL (Sorta Out of Luck).

Disclaimer: I haven't tried any of this, but I don't see any glaring reasons why it wouldn't work if the IP stack support is there.

[Orchard]

Also, keep in mind that if there are multiple people, a stream must not simply be sent to a single user, but must be "multicast" so that numerous users can pickup the same video feed without the need to create multiple copies of the feed (something the RTMP server handles)

And therein lies the simplest solution: set up a multicast network.

Multicast network packets are those sent to IP addresses that are not valid for a single host, such as 224.x.x.x -- they are not point-to-point packets but neither are they truly "broadcast" packets.

Multicast packets are sent to all hosts who have "registered" for receipt of the given destination. So if I have 4 computers on a network and only one of them registers for 224.0.1.14, then the gateway device for that computer will be told to forward packets for 224.0.1.14 to the network segment. The gateway device will then notify his gateway device, and so on, until it reaches the Internet. Now any packets destined for 224.0.1.14 will be sent to the ISP who will forward them to your gateway device (probably a router), which then sends them further downstream until they get to your computer.

The beauty of this is what happens if another computer on your network registers for 224.0.1.14 -- the gateway device(s) record the registration, but no additional packets flow to the ISP, because the ISP already is sending them to your router.

Unfortunately, many IP stacks don't implement multicast correctly or are filled with bugs. Nothing we can do about that here, so let's just assume they all work.

Suppose that those 4 computers mentioned above all wanted to multicast to each other? Each would need its own multicast address. For example, 224.1.12.101 thru 224.1.12.104. Each computer would register as a listener on the multicast addresses and would publish its own video on its multicast address. All done!

As there are many gateway devices between your home computer and your friends who are gaming with you, not all of them may support multicast addresses. So using a VPN package (such as OpenVPN, Hamachi, IPSec, or something else) would put all of the machines on the same virtual "LAN" and now when they register for the multicast addresses, the packets would be forwarded over the VPN layer.

The above should work fine, if the VPN layer supports multicasting. If it doesn't, then your SOL (Sorta Out of Luck).

Disclaimer: I haven't tried any of this, but I don't see any glaring reasons why it wouldn't work if the IP stack support is there.

So, the trick, as I see it, is to find an OSS VPN layer that allows multi-cast, then a p2p vid chat that uses minimal bandwidth should be possible? Sounds awesome.

[Azhrei]

I found this:

Summary: The paper first discusses the popular applications such as remote video at present and the process of multicast communication. Then, based on the analysis of IPSec VPN protocol architecture, it is illustrated why IPSec VPN can't integrate well with multicast tunnel, and a small-scale multicast application over improved IPSec protocol is proposed including its structure and procedure. To verify the model and the protocol, the software FreeSWAN is improved for designing and realizing it, environmental testing and data analysis are also carried out after the realization of the prototype system.

It sounds like they modified the FreeSWAN package to support multicast tunneling over the IPSec VPN software.

On Linux, this would be extremely easy, since modern Linux kernels already have tunneling devices! For example, a device named tun0 can create Layer 2 networks which act like VPNs (but without any packet encryption security).

I've said this before, but it should be simple to configure a multicast network on the tunnel device, but it would require support by the tunnel stack. The way multicasting works is that the applicaiton makes a special API call to request reception of the packets, and the network stack is supposed to let the gateway device know about the request. If the tunnel is point-to-point such notification probably isn't necessary, but the API call has to at least return the right value -- something that says the request was successful.

I'll keep looking over the next couple of days.

(Edit: I also came across this wiki entry http://www.grid-appliance.org/wiki/index.php/IPOP which describes an "IP Over P2P" tool. This sounds very exciting as it would almost directly satisfy the needs for P2P video streaming. I can just see firing up VLC Server with a webcam attached and sending the output to a multicast address on a VPN. Very cool! )

[Full Bleed]

So, the trick, as I see it, is to find an OSS VPN layer that allows multi-cast, then a p2p vid chat that uses minimal bandwidth should be possible? Sounds awesome.

Guess I'll believe it when I see it. I am most certainly not understanding what's being said here... but it still sounds more like a server model than what most of us understand a p2p model to be.