We built a video conferencing app using JavaScript in hours

medium.com

7 points·aaronjil··5 comments

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.

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.

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

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.

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.

Reply on news.ycombinator.com