Hacker News Reader

Comment by Kwpolska | Hacker News Reader

My experience with Jitsi Meet has been quite bad. My previous employer was a cheapskate, and they self-hosted Jitsi Meet. Random disconnections and instability were pretty much a daily occurrence, some people were disconnected every few seconds. While I suppose the self-hosting by Cheapskate Inc. was the main culprit, Jitsi’s screen sharing wasn’t looking very good.

View on HN

My last employers were cheapskates too (I love 'em for it) and they just used meet.jit.si for calls. It was a lot more stable than self-hosted jitsi. That said there were almost always microphone or video issues using it, just because people weren't used to it I guess. It made job interviews fun. It was a nice live test to show how a potential employee handled adversity.

We’ve made significant tweaks to screen-sharing in the past 2-3 stable releases, in case you feel inclined to check us out again :-)

Aside from consuming a ton of resources when screen sharing, my experience with Jitsi meet has been very good. It consumes two cores of my 5900X (1 for the Firefox process, and another for some system process I don’t recall exactly) but it works. This was with sharing a 4K screen.

I have run jitsi on cheap VMs and it worked decently. But you need quite some cores to serve all the traffic. Ultimately I ended up having as many 2-4core VMs as I had concurrent calls.

how is the meet.jit.si hosted? i assume with lots and lots of random users, the bandwidth and processing costs to be astronomical

For a large proportion of users I expect the audio/video to be peer to peer thanks to WebRTC. Other traffic (for that set of users) should be minimal.

My company self-hosts an instance and it's excellent.

So someone hosted $software on a shitty server, and you blame $software for the shitty performance? To draw any conclusions you should look at meet.jit.si (hosted by Jitsi), no?

Reply on news.ycombinator.com