Business calls, I've had a problem with video. It's often too cumbersome and gives too much info about the visual aspect of myself when it's not necessary and when I don't want it to happen. (e.g., getting on a call with a stranger or clients.) Using the "voice" call, I won't worry over washing my face at 9am in the morning.
Which is the reason I created http://voicechatapi.com (shameless plug)
By the way, it works fine for me in Chrome.
Now not to say that it is bad thing. It is great. It is what Google wanted (well they want people to use the web more and use Microsoft and iOS only products less).
So you as a developer know that underneath the wiring is really simple and basic but hey if users like it and it works out for them. One of these products might win.
We think that widespread adoption of a service like this will only be achieved if the service "just works" and is adapted to users' needs through constant development, and also through building a living brand that people love. We are currently a team of 8 working full-time on this, not only programming, but also with marketing, design & user testing.
Usually there is a limit on how many you can do without putting a conference server, 5 is quite okay for HD video on a laptop. Typically in these cases (mesh scenarios) the CPU/memory is a limitation than capacity. Upto 10, if everyone is doing SD video. So services pick a number 7 or 8 to limit the participants in a video some doing HD, some doing SD. This number is smaller if you pick iPad/tablets and higher if you are on a MacPro or something with multiple GPUs (possibly in these cases limited by capacity).
If the service builds a MCU (or conference bridge) those typically do not have such limitations, it then depends on how you multiplex the streams, mix them or selectively forward them, if the server is just forwarding packets, or decrypting them and re-encrypting them because it is transcoding or re-writing RTP headers, etc.
- I set the background image but it didn't appear (the dialog box for that seems to have no 'OK' or 'Save' button)
- It would be good to have a microphone level indicator, so I can see whether my microphone has been properly detected and working. There is one in Google Hangout but is rather small and not very good IMHO.
As for the background image issue, can you e-mail us at firstname.lastname@example.org for follow up?
Fyi, there's also screen-sharing (hover the mouse over your own window for the option), which works nicely (Chrome).
Didn't get to test desktop share but if it works as well as the video chat did we will definitely be using this for client presentations.
We would previously use Skype and/or join.me for client calls, but like gchat a login or installs were necessary (even if only for the host). This is a much simpler and elegant alternative. Particularly with the background option.
Love it so far!
>"No, I'm in my underwear. Please take me back." //
Lol, nice tone.
Dialog to enable webcam didn't appear for me though.
Kubuntu 13.10, FF 26.0
Firefox 26 on Debian Linux, however, never shows the prompt. The appear.in page just asks me to use the menu that should have (but didn't) appear.
I've just checked, and the (Linux Firefox) camera/mic permissions menu fails to appear on the other WebRTC conferencing sites linked in this thread, too. So it's definitely not just appear.in.
[Edited to add:] For others suffering from the same problem, the bug report linked in parent suggests it may be fixed in FF 27, which will apparently be released during the week of Feb 4th.
LE: I'm actually really, really impressed by this. It's bloody great, good job to these guys and to whoever works on similar projects.
I realize Mobile Safari may not be a supported browser, but a graceful failure with some sort of explanation wouldn't hurt, would it?
Pretty awesome overall, though!
Failed to get camera access.
Please grant camera access to use appear.in
"All communication between your browser and appear.in is transmitted over an encrypted connection (SSL). Video and audio transmitted in the service is sent directly between the participants in a room and is encrypted (SRTP) with client generated encryption keys. In some cases, due to NAT/firewall restrictions, the encrypted data content will be relayed through our server."
We have strict access controls to the server, but the messages are sent via Amazon. We realise that this is not ideal, and we want to, when the DataChannels API has matured a bit, move message sending to a strict P2P model as well. There are some issues with that (total ordering of messages for one) which need to be solved first, but we're positive that those challenges can be solved.