View Issue Details

IDProjectCategoryView StatusLast Update
0000176Composrchatpublic2017-03-24 15:55
ReporterChris GrahamAssigned To 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version 
Summary0000176: Implement webcam chat
DescriptionImplement webcam support in the chat rooms, showing all users webcams down the left of the chat room.

This issue used to be about a Flash implementation, but that's no longer realistic. A modern implementation would be more complex, requiring a WebRTC implementation and a great deal of architecture roll-out. Things have got more complex as the world has moved away from having this kind of thing being self-hosted, with companies instead investing in service-based solutions.

There are various comments below about integration service-based solutions, which is a lot simpler, but obviously has down-sides.

CometChat has video chat on the Platinum version also.
TagsType: External costs
Attach Tags
Time estimation (hours)120
Sponsorship open



2010-08-16 10:45

reporter   ~0000084

Hey Chris, would it be possible to add a Desktop display option? So instead of streaming a webcam display have the ability to stream your desktop display. This added feature would make doing webinars of all kinds a huge draw to this system. Webinars are relatively expensive and if Composr had this built in I could see this being one of your strongest selling points to businesses.

Chris Graham

2010-08-16 11:29

administrator   ~0000085

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.

Chris Graham

2012-08-23 20:56

administrator   ~0000904

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).

Rishi Saravanan

2012-09-03 22:04

reporter   ~0000934

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?

Chris Graham

2012-09-03 22:17

administrator   ~0000935

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:
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.

Rishi Saravanan

2012-09-03 22:54

reporter   ~0000936

I'll definitely be interested in helping manifest this one

Chris Graham

2012-09-04 18:18

administrator   ~0000940

Last edited: 2012-09-04 18:58

View 2 revisions

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.

Chris Graham

2012-09-04 18:22

administrator   ~0000941

Some more notes I made for myself...

Useful blog posts:

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

Rishi Saravanan

2012-09-04 21:01

reporter   ~0000944

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.


2015-02-16 14:27

reporter   ~0002570

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.

Chris Graham

2015-02-16 14:30

administrator   ~0002571

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.

Chris Graham

2015-02-16 16:07

administrator   ~0002575

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.

Chris Graham

2015-06-29 13:44

administrator   ~0002929

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.

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.


2015-06-30 04:52

administrator   ~0002934

Last edited: 2015-06-30 04:53

View 2 revisions

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

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


2015-06-30 06:35

reporter   ~0002935

There is a free licence at

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.

Chris Graham

2015-07-03 18:00

administrator   ~0002937

"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 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.


2015-07-10 09:58

administrator   ~0002946

Last edited: 2015-07-10 10:03

View 3 revisions

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.

Patrick Schmalstig

2016-03-18 04:10

administrator   ~0003449

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.

Issue History

Date Modified Username Field Change
2016-03-15 02:39 Chris Graham Time estimation (hours) 12 => 120
2016-03-15 02:39 Chris Graham Description Updated View Revisions
2016-03-15 02:39 Chris Graham Additional Information Updated View Revisions
2016-03-18 04:10 Patrick Schmalstig Note Added: 0003449
2017-05-06 23:44 Chris Graham Tag Renamed External costs => Type: External costs