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

1–10 of 115 posts

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

#3

Post by buovjaga »

enriquto wrote: post #2

I would love to use this instead of zoom. Any news about firefox support?

Patches are being reviewed: https://github.com/jitsi/lib-jitsi-meet/pull/1062

Included: "Fix the order of the simulcast streams for Firefox."

Subscribe to this issue to keep track of things: https://github.com/jitsi/jitsi-meet/issues/4758

From the latest comments you can see that Firefox upstream is also improving things.

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

#6

Post by lioeters »

enriquto wrote: post #2

I would love to use this instead of zoom. Any news about firefox support?

They're actively working on it - in the GitHub issue below, Jitsi devs have been engaged with the community, as recently as yesterday.

100% support for Firefox (and other non-Chrome browsers)

https://github.com/jitsi/jitsi-meet/issues/4758

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

#7

Post by supermatt »

hirako2000 wrote: post #4

It's a fantastic open source solution. Can be self hosted. It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic

The server (jitsi videobridge) DOES have the keys to decrypt the traffic - i.e. its not e2e encrypted. This is par for the course with webrtc SFUs (there are some "workarounds" to support e2e encryption over webrtc I mentioned in another thread).

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

#8

Post by kodablah »

I have been considering developing a simple video conferencing solution using this approach with WebRTC. Basically, I was planning on doing something like this example [0] of server-side peers or just a set of forced TURN servers, whichever approach being deployed on servers at the edge.

I figured using anycast IPs, and having server to server communication across regions before then sending back down to the client would be ideal. Each offer and answer signaling would be done via distributed pubsub (e.g. embedded nats) and general persistence also distributed (e.g. something simple like dqlite). Has anyone had success with distributing WebRTC channels like this? Are there any concerns with redistributing, say, raw h.264 and opus as is without special concern for buffering or transcoding? How do slower consumers handle a fast set of UDP packets?

Also, I doubt there's a way, but anyone familiar with an end to end encrypted approach with WebRTC and DTLS when a server is in the middle? I figure not since offer/answer is for a single peer instead of broadcast and I see no approach in the browser to doubly encrypt media streams.

0 - https://github.com/pion/webrtc/tree/master/examples/broadcas...

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

#9

Post by supermatt »

kodablah wrote: post #8

I have been considering developing a simple video conferencing solution using this approach with WebRTC. Basically, I was planning on doing something like this example [0] of server-side peers or just a set of forced TURN servers, whichever approach being deployed on servers at the edge. I figured using anycast IPs, and having server to server communication across regions before then sending back down to the client w…

Using your first solution (a custom pion SFU relay), and selectively routing the streams between "edge" servers would be similar to Octo, as shown here.

Using TURN servers instead would not have the benefit of SFU (i.e. clients will have to upload to each peer) - i.e. its still a full mesh network.

Using TURN servers with SFU would work similar to your pion solution, however it would also use more bandwidth, as it would be forwarding the same streams multiple times for each peer routed through that TURN server (instead of once per stream with SFU)

As for e2e encryption over webrtc via an SFU - yes, this is possible, but its currently very messy (wasm video encoding and encryption streamed over an SFU-bound datachannel with full mesh distribution of the encryption key). There are plans to implement "Insertable Streams" which you will be able to transform (e.g. encrypt) which will allow this to work without the hacks.

Post reply on HN