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

Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

webrtchacks.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#81

Post by Half-Shot »

jteppinette wrote: post #77
overthelake wrote: post #72

Earlier quoted context omitted.

Riot isn't an alternative to Jitsi so much as a complement to it. Matrix is for text chat, and Riot uses Jitsi for calls; while you can embed a Jitsi client into Riot rooms, and it auto-shares the URL, AFAIK group calls are not E2EE even if the room is. One-on-one calls through Riot _are_ encrypted, but only if made in a one-on-one direct chat.

The riot features page makes it seem very "built-in" ( https://about.riot.im/features#voice-video ).

riot.im hosts its own Jitsi instance which is built into the UI, so hitting the call button in a room will spawn an embedded Jitsi call in the room.

Recently we added the option for people to use their own self hosted Jitsi instances, if they prefer.

(1:1 calls at the moment are normal WebRTC, directly over Matrix)

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#82

Post by moron4hire »

saghul wrote: post #74
moron4hire wrote: post #24

Earlier quoted context omitted.

I had 4 people, so either the docs are wrong or they have forgone the video bridge on my server and are using their own.

If you had 4 people the video was going trhough the JVB for sure. Since a Jitsi Meet installation uses multiple components, maybe you didn't shut them all? Video shenanigans can be a dark art, but not that magical ;-)

All installed on one server, physically shut the entire server down.

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#83

Post by endgame »

applecrazy wrote: post #80
saghul wrote: post #73

Earlier quoted context omitted.

We use a technique called simulcast. It consists on making every participant "work a bit harder" for the good of the bunch. That is, every participant sends 3 separate video resolutions to the server: 720p, 480p and 180p (this may change due to bandwidth constraints). Then the server will only forward the approopriate layer to each other participant. So, if you are only seeing me in a thumbnail it will only forward t…

Naive (and perhaps stupid) question here, why don't you request just the 720p feed from each participant and then rescale the streams as clients need them?

The server would have to downscale the received stream. That's at least one round of downscaling for each participant, possibly more if you want to send different quality versions of the same stream down to different participants.

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#84

Post by jteppinette »

Half-Shot wrote: post #81
jteppinette wrote: post #77

Earlier quoted context omitted.

The riot features page makes it seem very "built-in" ( https://about.riot.im/features#voice-video ).

riot.im hosts its own Jitsi instance which is built into the UI, so hitting the call button in a room will spawn an embedded Jitsi call in the room. Recently we added the option for people to use their own self hosted Jitsi instances, if they prefer. (1:1 calls at the moment are normal WebRTC, directly over Matrix)

Thanks for the clarification!

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#85

Post by chronicler »

steveharman wrote: post #48

We did our daily standup call with it yesterday (mostly audio). 12 people, on a $3 Scaleway Debian instance (2GB RAM). Worked perfectly. Obviously as we stopped using Zoom we have to manually upload all our personal data to Facebook now.

Did you use cascading SFUs? What did you deploy? I'd like to set up my own turn server and use jitsi.

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#86

Post by Certhas »

steveharman wrote: post #48

We did our daily standup call with it yesterday (mostly audio). 12 people, on a $3 Scaleway Debian instance (2GB RAM). Worked perfectly. Obviously as we stopped using Zoom we have to manually upload all our personal data to Facebook now.

We tried to but with most of our team on Firefox it simply doesn't work unfortunately. Zoom has been the only thing reliable for us.

It's a bit ironic that somewhere, someone is switching from Firefox to Chrome because of data concerns with Zoom.

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#87

Post by gregmac »

saghul wrote: post #73
littlestymaar wrote: post #52

Earlier quoted context omitted.

> The Jistsi team says the server needs roughly 5.5Mbps per Chrome user. That sounds like a lot! I wonder why an almost still image can use that much bandwidth, I guess it has to do with the low-latency requirement but I would love more details on that.

We use a technique called simulcast. It consists on making every participant "work a bit harder" for the good of the bunch. That is, every participant sends 3 separate video resolutions to the server: 720p, 480p and 180p (this may change due to bandwidth constraints). Then the server will only forward the approopriate layer to each other participant. So, if you are only seeing me in a thumbnail it will only forward t…

SVC spatial and quality layers [1] sound like a really good solution to the bandwidth issue. From my (extremely limited) understanding, basically if you skip certain packets you get a lower resolution/quality stream. A client sends a single stream at the best quality it can tolerate, and then the SFU can forward whichever layers to each client depending on what resolution that client wants.

What's the state of this in jitsi? I can only find limited info about SVC [2] and that is only on temporal layer. How much bandwidth does it even save in practice - maybe it's not worth the complexity trade-off?

[1] http://webrtchacks.staging.wpengine.com/chrome-vp9-svc/

[2] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/s...

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#88

Post by passerby1 »

Certhas wrote: post #86
steveharman wrote: post #48

We did our daily standup call with it yesterday (mostly audio). 12 people, on a $3 Scaleway Debian instance (2GB RAM). Worked perfectly. Obviously as we stopped using Zoom we have to manually upload all our personal data to Facebook now.

We tried to but with most of our team on Firefox it simply doesn't work unfortunately. Zoom has been the only thing reliable for us. It's a bit ironic that somewhere, someone is switching from Firefox to Chrome because of data concerns with Zoom.

What does prevent your team from using "ungoogled chromium"?

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#89

Post by LinuxBender »

bsima wrote: post #69
cf wrote: post #57

Are there any good tutorials for how to setup Jitsi to work for 30-50 people? The discussion forums are hard to navigate.

consider using mumble

mumble / murmur is great, I host it for family and friends to use. That said, it's only voice and text. No video or screen sharing yet.

Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)

#90

Post by j1elo »

ofrzeta wrote: post #58

Alternatives to Jitsi are Janus (mentioned in this thread) but also OpenVidu (formerly Kurento) and Mediasoup which provide building blocks to roll your own. All of these also have demos that you can use out of the box for our own conferences.

Just a nitpick: Kurento still exists on its own, and provides a generalist framework of components to build a service that can handle media.

OpenVidu is one such service, it builds _upon_ Kurento, and itself can be used to make videoconference rooms very easily. Otherwise, Kurento is just a media server that handles media but doesn't have the concept of "rooms", "publishers", "consumers", escalability, reliability, etc. so you would have to develop all those things on your own.

Post reply on HN