views:

57

answers:

2

I'm starting to look into technologies to support a project that involves video chat between one party using a web browser and another party using a fat client (technology TBD, per below).

I see three components that need to be identified (and I'd prefer to avoid reinventing any wheels): the web client (video recording & playback), fat client (video recording & playback), and a server to act as interchange between them.

When I last did similar work years ago Flash seemed to be the only game in town, but I suspect there are other viable options now. What set of technologies for the above components (or suggest an alternate architecture) fit my wishlist below?

  • Web-client side can be embedded in a web page and will have access to a local camera.
  • Fat client side must be so simple as to be automatic (i.e. no complex camera configuration)
    • Launching this side from a browser (e.g. WebStart) is legit
  • If there are different technologies used for the two clients, use a standard interchange technology between them.
  • My team is most comfortable in the Java ecosystem and would prefer technologies that are easily embeddable. But, this last point is negotiable (e.g. if Silverlight is a perfect fit, then perhaps we could go with C# instead for the fat client).

Thanks for any pointers!

A: 

Silverlight, with IIS7(.5). Silverlight supports streaming video and it supports webcams. It was also used for the olympics for videostreaming. And with the out-of-browser-support, you fit bot the web client, and the think client

Vidar Nordnes
A: 

HTML5 offers better video support (than HTML used to) - including streaming, the downside is that cross-browser support will probably be hit-and-miss.

Failing that, I'd go with Vidar's suggestion for Silverlight.

If you were in the .Net world there's a control you can use in a thick-client which is bascially a browser window - I assume there's an eqvialent in the Java world (?); this would allow you to hopefully re-use more code.

Adrian K