Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I built a fun video meeting app with 2D physics and proximity chat

flat.social

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#61

Post by CodeBeater »

fooblat wrote: post #14
CodeBeater wrote: post #8

This seems to be a take on Gather.town with more realistic graphics. My team has been using Gather for almost a year now, so I'll give it a shot.

How does your team use it and how would you rate it? My CEO wanted to introduce Gather with the idea that everyone would be in it working all day. He wanted to be able to "stroll by" whenever to see what people are up to. The team unanimous voted against this so we didn't get it.

All in all it was all a very incidental experience. Our CTO came out of the blue showing this thing, he spent an afternoon designing a floor flor the developers that mimics the IRL office.

At the beginning it all felt gimmicky and felt like the novelty factor would wear off quite quickly, but there was this one specific instance that made it "click" in everyone's head, and it happened right at the end of a regular meeting.

We finished the discussion and most attendants quickly dispersed, some people were still at the table trying to fix a bug, and we needed some input from this one specific person to do so. So someone just strolled to where that person was, and asked him to come to the table. It all felt very natural, and the way we were able to quickly get the information we needed without having to awkwardly drag a bunch of people into a Google Meet was just magical.

Today we use it everyday, full time, it all feels very natural and we don't really think about it, because it works so well.

Recently the CTO also opened a "floor" (I.E another Gather instance entirely) for the sales and marketing team (whose headcount in the hundreds) and linked both "floors" using their "portal" feature. Awesome!

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#63

Post by jupp0r »

jhugo wrote: post #51
jupp0r wrote: post #43

Earlier quoted context omitted.

Even if you use stream forwarding only, network will be a major O(n) cost factor when using cloud providers, at least for video. There is also some super interesting middle ground between full video forwarding and selective reencoding by using SVC for cheap video resizing on the backend.

SFUs aren't forwarding everything. Using either discrete simulcast layers or SVC they're forwarding one size out of several (usually 3) to each other participant. Bandwidth will be a high cost no matter what (and anyone planning to scale up real-time video better be prepared to move off the cloud at some point) but needing compute resources for encode/decode on the backend makes large scale realtime video infeasible…

You can avoid bandwidth costs: use peer to peer networking below some number of participant threshold.

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#64

Post by jhugo »

jupp0r wrote: post #63
jhugo wrote: post #51

Earlier quoted context omitted.

SFUs aren't forwarding everything. Using either discrete simulcast layers or SVC they're forwarding one size out of several (usually 3) to each other participant. Bandwidth will be a high cost no matter what (and anyone planning to scale up real-time video better be prepared to move off the cloud at some point) but needing compute resources for encode/decode on the backend makes large scale realtime video infeasible…

You can avoid bandwidth costs: use peer to peer networking below some number of participant threshold.

P2P is fine for n=2 (and most videoconferencing systems already try to flow media peer-to-peer in this case), but it often has a pretty severe impact on UX if you go much beyond that.

Even with say n=5, P2P pushes the required upstream bandwidth beyond what is practical with tight realtime constraints on a surprising proportion of home and office connections, especially when Wi-Fi is involved. SFU cuts the upstream bandwidth requirement to be constant rather than a factor of how many other participants are in the conference.

There's also the fact that a significant proportion of offices, and an increasing proportion of homes, simply cannot establish the needed P2P connectivity due to double NAT, firewall, etc. For them you'll be providing a TURN server, which brings back the bandwidth requirement.

The bandwidth costs, if you move off the clouds, are actually quite manageable compared to the compute costs if you try to do decode/encode on the servers.

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#65

Post by jupp0r »

jhugo wrote: post #64
jupp0r wrote: post #63

Earlier quoted context omitted.

You can avoid bandwidth costs: use peer to peer networking below some number of participant threshold.

P2P is fine for n=2 (and most videoconferencing systems already try to flow media peer-to-peer in this case), but it often has a pretty severe impact on UX if you go much beyond that. Even with say n=5, P2P pushes the required upstream bandwidth beyond what is practical with tight realtime constraints on a surprising proportion of home and office connections, especially when Wi-Fi is involved. SFU cuts the upstream b…

“If you move off the clouds” can be very expensive. You now need a globally distributed fleet of servers at different providers and ops and administrative manpower to make sure bills get paid and servers get patched and audited.

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#66

Post by jhugo »

jupp0r wrote: post #65
jhugo wrote: post #64

Earlier quoted context omitted.

P2P is fine for n=2 (and most videoconferencing systems already try to flow media peer-to-peer in this case), but it often has a pretty severe impact on UX if you go much beyond that. Even with say n=5, P2P pushes the required upstream bandwidth beyond what is practical with tight realtime constraints on a surprising proportion of home and office connections, especially when Wi-Fi is involved. SFU cuts the upstream b…

“If you move off the clouds” can be very expensive. You now need a globally distributed fleet of servers at different providers and ops and administrative manpower to make sure bills get paid and servers get patched and audited.

Yes, it can be expensive, but nowhere near as expensive as paying per-GiB rates to a cloud for your traffic (which itself is nowhere near as expensive as paying a cloud's rates for compute if you try to do decode/encode in the cloud).

If we are talking about doing realtime video at large scale, we can assume that there is good ops competency in-house. If not, honestly, what are you doing?

Managing fleets of servers across several of the "automation-friendly-but-not-cloud" providers using modern tools is not difficult for some moderately-expensive-but-not-as-expensive-as-cloud-services ops engineers.

Re: Show HN: I built a fun video meeting app with 2D physics and proximity chat

#67

Post by dmje »

I started off thinking ...man, ANOTHER damn video calling app / virtual workspace / etc...

...and then I started scrolling through some of the fun stuff, like using avatars in games..and as I scrolled I thought more and more "this is fun...I could use this".

Haven't actually dug in and tried it, and don't know if it'll stick - but getting over the hump of my cynicism is definitely an achievement worth celebrating - well done :-)

Post reply on HN