To be honest, I'm not sure. I know Javascript can't do it, and I don't think flash can, and I doubt even Java can, so it probably would need to be a new browser plugin. As one would be needed for each browser, written by a very experienced desktop programmer, that is probably explaining why it is typically costly.

Note that browsers are starting to implement APIs to allow webcam access via Javascript, so this feature probably would best be implemented in that direction (Flash is dying a fast death - mobile support was recently dropped).

Does this mean users being able to talk with each other live, like skype video? Or just seeing each other's faces while they type messages?

It would be like Skype video. However I don't know how well this would work without running some tests. There could be performance problems in terms of processing the stream, uploading it, and distributing it out, or stability problems given how new this all is. A browser support table is here:
http://caniuse.com/stream
In short, Google Chrome and Opera support it. Firefox will in the coming months. However, Internet Explorer has no sign of supporting it yet. A Flash-based workaround seems to be available, but I suspect it will have stability and performance issues.

I'll definitely be interested in helping manifest this one

I've looked into this some more.

We would be using the upcoming GetUserMedia API, which is a larger part of the WebRTC specification

My webcam takes frame filesizes of 275kb (JPEG) and 25 frames/sec is considered normal video, which would be 60 Megabits/sec. This would lead to 90 minutes (roughly the length of a film) being 35 gigabytes, which is roughly 30 times the normal filesize of an h264 encoded movie. The discrepancy here is because movie formats (like h264) make use of the fact that not everything changes each frame.

With a compromised frame rate and lower resolution, we can possibly 'get away' with doing this while still taking a lot of still frames and calling it video. It would require roughly 2 Megabits/sec per user for a frame filesize of 15kb (JPEG) and 15 frames/sec, which is on the lowest end of workable quality.

WebRTC is progressing on the basis of setting up "peer to peer" VP8 streams of video (VP8 being Google's video format). i.e. video streams don't go through the central server, and don't get processed directly using normal web technologies (HTML, HTTP, Javascript) - it is a direct stream between participants in a chat. However, the WebRTC that is present in current web browsers doesn't yet implement this - the true video support they currently have is not streamable except on the user's own machine. So right now all we can think about is the aforementioned method of using lots of still frames.

Another complexity is that Microsoft are being difficult. They are supporting WebRTC in a sense by participating on the WebRTC committee -- but they also are trying to pitch their own specification to that committee and calling that WebRTC. It is unclear where things will go, but there is a serious issue because if the browsers can't agree on a base streaming video format, it's not going to work. Microsoft are heavily incentivised to block VP8 because they get patent royalties for use of h264 which is the current defacto standard, and because also they own Skype and don't want things to get too interoperable using non-Skype technology. Other browsers are unlikely to adopted h264 due to patent royalties, which has been the same problem with the adoption of HTML5 video playback. So again, for now it looks like we are stuck with still frames.

What I am getting to is that it looks like this kind of approach will be compromised for the time being. I can't make decent guarantees about performance, which could turn out very poor. But I think at least a few days work would be required to tell if that would be the case or not.
Going back to the original idea of using Flash would also be a bad idea, given that Flash is quickly a dying technology - Mac users are starting to refuse to install it, and most tablet computers now cannot run it.

Specifically, my concerns about performance would be as follows:
- Low resolution and low framework might not be very satisfactory, and it's not something we can ramp up too easily as it is so bandwidth intensive if we don't use true video streams. Full screen would be out of the question.
- I'm not sure how quickly JPEG frames can be encoded; the JPEG code is unlikely to be as optimal as video compression (which is often hardware-accelerated)
- There are likely to be big latency issues going through a central server using HTTP technology. Above the need to go through a central server, trying to get the frame download perfectly synchronised with the frame upload is unlikely to work well - so some significant time would be lost in that. Also, each frame would be sent via a new HTTP connection, and it takes some round-trip times to establish a connection, and also possibly some time stuck in queues and reestablishing a routing path
- Audio does not seem to be implement in browsers yet, which also lessens the use a lot
- The server would be stressed with the bandwidth requirements brokering all the streams. If 4 users are in a chat room, that's 24 megabits download required from the server (and 8 megabits upload)

My suggestion would be to wait until WebRTC has settled down and full peer to peer video streaming is available. It is hard to say how easy that would be to implement though, given the Microsoft situation.

Some more notes I made for myself...

Useful blog posts:
http://bloggeek.me/webrtc-codec-wars/
http://www.html5rocks.com/en/tutorials/getusermedia/intro/
http://blog.chromium.org/2012/04/chromes-webrtc-roadmap.html

WebRTC is being spear-headed by Google, and is partly based on their acquisition of video codec and VOIP companies.

Thanks Chris for taking the time to look into this some more. Definitely sounds good to wait, and I look forward to helping sponsor this when it becomes feasible.

Is the integration of Google "Hangouts" any option? That gives you a 9 way conversation and does work really well. Moderators or admins can take control of a remote PC also IF given permission to do so. as well showing functions on the moderators screen. We would definitely assist sponsoring this Chris.

I don't think it really is. I had a quick look the other day, and the API they offer I think is for integrating stuff into Hangouts (i.e. apps). It's come up a few times that Google don't seem to be offering any useful APIs for Google+. Specifically we'd need some way of either telling it to run off our own accounts, or linking accounts.

I'll give it some more thought though.

I think this could be an option, if you're happy with the user being taken off-site to do it.

Essentially chat rooms would get a button allowing users to go off and continue the chat in a shared Google+ Hangout.

The users would need their own Google accounts, it wouldn't operate via their Composr accounts.
However, we could additionally implement a Google login button to Composr, to allow binding Composr accounts to Google+ accounts, for automatic Composr login and so that Composr profiles show a link to the Google+ profile.

It turned out the above is not possible. Google had an Open Source toolkit, which stopped working when they made changes to Hangouts (and they didn't even have the grace to announce it anywhere). I think they want to avoid people tying into their communication tools outside their core social network / focusing their resources on their core projects.

However!

https://talky.io/
Talky seems awesome and trivial for us to integrate.

I think we will refresh how we handle chat scenarios in the future:
1) Standard Composr chat rooms and IM and shoutbox
2) Tutorial for how to integrate an IRC chat into the chat lobby template using an iframe (drop the XMPP addon: XMPP libraries/software turned out very fragile/unstable, and server requirements too high, and the big companies dropped support for it so it's kind of dying)
3) Tutorial for how to integrate start video chat links into the chat room template, using talkly.

I don't love that we'd be using other people's private services, but realistically, maintaining major communications infrastructure is beyond the reach of non-enterprises anyway. There are too many requirements across servers, software and general architecture, and too much expertise in maintaining it and keeping it updated in a changing landscape.

If we do get large enterprise clients funding us to do tighter integrations, we can look at direct integration of the libraries the company behind talkly has developed, documenting how to set up a STURN/ICE/TURN client and any free services for this already out there, and maintaining a PHP IRC client implementation that is tightly bound. This does not seem likely though, as we're probably talking $30k to just get going on either WebRTC or creating/upgrading an IRC client, plus regular ongoing maintenance work as standards change.

Maybe if you have RTMP streaming available with your hosting, you could try and integrate VideoWhisper @ http://sourceforge.net/projects/phplivestream/

It has already been made into plugins/addons for Elgg, WordPress and others.

There is a free licence at http://www.videowhisper.com/?p=FREE+Video+Conference

What's Included with a paid License
A license is for a domain (or subdomain). Only 1 license is required per domain and includes:
Unlimited Use
Unlimited simultaneous connections, users, rooms, session time.
All Integrations

License Purchase (USD) $450/lifetime
License Upgrade from Level 2 License (USD) $100/lifetime
License Upgrade from Level 1 License (USD) $200/lifetime
License Rental (USD) $45/mo

I have not tested it but if it works like Skype4Buisiness or Hangouts where there is ability to run a webinar presentation I would suggest it would be quite worthwhile.

ALL of the webinar products like Cisco Webex , Skype for Business (ex Microsoft Lync), Hangouts and Facebook video all use hosted server environments so there is no suggestion that Composr would develop infrastructure I wouldn't think. Microsoft are launching the new Skype clients from now through to July 7 after which the old Skype clients won't work I believe.

Video integration in the chat room or in fact replacing chat with video might be a whole lot more exciting for many. The chat module does not really excite in its current form. Saying all of this is easy especially while v10 is yet to roll out in any shape. We can't deviate from a v10 deployment so I would park this until v10 is out and we would be prepared to throw some dollars at some work around this if it is an Composr development. I have some ideas on how we could set up client meetings using something like this. Some way of setting up a subscription model or a pay as you use it might be something to consider, possibly using a user group. Payments linked to PayPal etc.

Thanks for the link Kingblast.

"Maybe if you have RTMP streaming available with your hosting, you could try and integrate VideoWhisper"

It's Flash (I checked the code quickly, "Flash was not detected in your browser: Flash plugin is required to use this application!").
We have to assume nowadays users won't have it, as it is not default installed on Mac and increasingly users just refuse to install it. It won't run on ARM processors and is not developed for mobile/most-tablet devices. Largely this issue is looking to the future on what is a long-term sustainable solution.

The other big issues are price and applicability for integration. Most of the conferencing products either cost money, or cost money to use their APIs, or have no APIs at all (e.g. hangouts), or make egregious requirements (like all users having pre-created accounts).

So in summary, any solution we put our weight behind:
- Must use WebRTC, definitely not Flash, or Silverlight, or custom plugins (like Google Hangouts does on IE)
- Must be free
- Must provide an API, or a zero-API room creation method
- If it's an API, that API must be free
- Must have a seamless experience, no pre-account creation needed by users
- Must work on shared hosting
- Must not provide any onerous restrictions, like pre-approving anyone using their API, or tight quotas
- Must work on all platforms

WebRTC solutions don't quite hit the final point yet, but they will soon.

This is why I think talky.io is pretty close to perfect.

Display of adverts etc I think is acceptable, as that is not fundamentally breaking the flow of the experience of adding extra requirements.

I was quoting their website but I believe there are a few different versions of their offering available. I haven't tried it out personally and I was suggesting it might be a possible solution for those who wished to try a basic integration. I wasn't suggesting that this was the ideal solution for core Composr. I just know VideoWhisper has been around for quite a while now, has good feedback and that some members may want webcam chat now :) Talky sounds good though.

I agree with Chris on not using Flash. Due to how locked down I have my computer nowadays for security threats, my firewall/antivirus won't even permit the running of Flash in my web browser.

Flash is a very bad choice nowadays for anything. It's very insecure.