
We built a video conferencing app using JavaScript in hours - aaronjil
https://medium.com/@aydankirk92/how-we-built-a-video-conferencing-app-in-hours-9a35ed930ed0
======
jokoon
I'm still curious what is the underlying server tech that takes care of the
video stream, and if it's tcp only or does some udp too.

I guess the server doesn't modify the video stream. Since browsers are able to
read the webcam, do they use hardware acceleration to compress the video
stream? Is there a collection of formats?

I still wish we could go back to p2p video streaming like Skype was doing.

~~~
i-am-curious
P2P scales quadratically, central server scales linearly. You might argue the
cost is not borne by the operator but imagine what happens if Zoom was P2P. It
would probably bring down the internet.

Moreover P2P would require more upload bandwidth per user from users. P2P just
doesn't make sense for standard video conferencing.

~~~
XCSme
> central server scales linearly

Assuming that the server combines all the incoming streams into a single
output stream, otherwise it still has to broadcast N-1 streams to each of the
N users.

~~~
i-am-curious
But why would you not combine them? In fact, I can easily see people being
lazy and combining just on N sized stream to reduce server overhead especially
if there is compression on top.

------
fareesh
I'm currently using Twilio's programmable video for a mobile product I'm
building.

I did a lot of the same review and reached similar conclusions. The popular
open-source self-hosted solutions seem incredibly bloated and buggy.

Twilio's offering also manages scaling and infrastructure. I suspect it's
cheaper to go with their solution in the beginning and having a self-hosted
solution will only become cheaper beyond a certain amount of
concurrency/usage. They also offer recording, composition and a couple of
other useful features.

If anyone has implemented a self hosted solution that's cheaper to host
yourself I'd be interested in reading about it.

