5 ms·
Questions below: Our tech implements server-mediated video chat for up to 6 participants. It requires some processing power on the server, but it is designed w
by DanBlake 13y ago
Questions below:
Our tech implements server-mediated video chat for up to 6 participants. It requires some processing power on the server, but it is designed with a "scale-out" architecture so you should be able to get it running cheaply at scale without major rewrites.
Custom server or public? ( fms/wowza/etc. ) How many streams per server can it handle? Why bother with a server doing relay if its only 6 people?
It's currently iOS only, but it should work to copy the iPhone code's structure to implement clients for all relevant platforms -- Android, WinPhone, Blackberry, web, and/or desktop.
It is my understanding that developing video chat for android is a major clusterfuck. Not only does each O/S version create crazy complications, the differences and nuances required just across phone models is a nightmare. For instance, on a Evo you need to flip the image. On a newer droid the f/b camera is reversed from the API. Its enough that developing video chat for android is a nightmare in disguise
Performance will be critical for slower devices, so you'll need to implement it carefully.
The video codec is h.264 at 144x144. (We experimented with up to 320x320 and found that with current connection quality on phones, especially on urban wifi and 3G, sticking with a low-resolution default tends to produce the best user experience.)
Don't things look like shit in 144x144 for non-group calls? Do you scale larger when its just a 1 to 1 call?
The audio codec is Opus at 16 KHz.
Are you muxing connections together on the server? Do you lose individual volume control per feed?
I think the most important question is related to server technology. If you can only get a small amount of users on each server, its not going to be possible to be profitable moving forward.
- lincolnq 13y agoCustom server or public? We created a custom server. We wrote our own server code, that's just how it was designed. Android If you think it will be hard, you're probably right. Thanks for the info. Resolution Yeah, 144x144 is definitely a bit blurry. With a bit more work you could upgrade the resolution for 1-on-1 chats. We didn't put that work in yet. Audio You could control the volume per feed -- but that said, when you use the Voice Processing I/O unit, Apple does a pretty good job figuring out a decent microphone level, so it was not necessary. I can provide more detailed answers but you should contact me privately.
- DanBlake 13y agoMost important question from above: How many users per server are you able to do, and what are the specs of that server?
- lincolnq 13y agoThe limiting factor is concurrent video chatters. We only got into the four figure userbase, so we didn't have even enough to push a single AWS C3.large instance to its limits. Contact me privately for more info.
- changdizzle 13y agoHi! I work in BD @ TokBox and we released our native Android SDK utilizing WebRTC about a month and a half ago, check it out here - https://tokbox.com/opentok/libraries/client/android/ https://tokbox.com/opentok/libraries/client/android/ If you have any questions feel free to e-mail me at edward [at] tokbox [dot] com
- pfisch 13y agoWhich android devices is this compatible with?
- changdizzle 13y agocurrently 4.1 (jelly bean) and above and we "officially" only support S3 although many of our partners have gotten the suite of samsung and LG devices to work with the SDK
- marquis 13y agotokbox is a great API, it also has client->client data messaging so you can build quite rich apps around the video/audio chat. Was impressed.
- changdizzle 13y agothanks, we always love to hear about happy customers - keeps us going!