saghul

It is our belief that by doing this we'll also be helping adoption. If a browser vendor (any of them) propoes an API, but nobody uses it, why would the rest care to implement it?

The ability to do E2EE is kind of a big deal, even though insertable streams can be used for other things, so we hope other browser vendors join the effort.

There have been other approaches in the past such as PERC [0] and ongoing related ones like MLS [1], this is a relevant topic these days.

[0]: https://datatracker.ietf.org/group/perc/documents/ [1]: https://datatracker.ietf.org/wg/mls/about/

We’ve kept the entire packet header unencrypted so the effect is more visible. The final implementation will just leave the minimum required bytes (1 or 2) of the header unencrypted.

We don't have a way to turn these on from the UI, but here is how you can disable all audio processing:

https://meet.jit.si/YourRoonNameHere#config.disableAP=true

Jitsi will use up to 2.5Mbps for the user "on stage" (the large view) and about 200Kbps for each thumbnail.

You can use these numbers and your usual conference size to calculate how much data you'd use and then calculate the cost of that.

It should work fine, since it would create a virtual webcam. Please drop by https://github.com/jitsi/jitsi-meet/issues/5425 if you run into issues.

I didn't choose it at random ;-)

Hey there, saghul from Jitsi here. Have you reported that to us? I have deployed several self-hosste instances with Lets Enccrypt and haven't seen this, but there might a bug lurking somewhere.

Yes, you can deploy Jigasi (https://github.com/jitsi/jigasi) to VoIP access to Jitsi Meet.

Good work!

You may whant to set this override on the iframe API: https://github.com/jitsi/jitsi-meet/blob/master/interface_co...

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 ;-)

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 the 180p layer. If I become the active speaker (or you choose to pin me to the large view) the server will immediately switch to forwarding the 720p layer.

In addtion, we use SVC with temporal layers, so thumbnails may be given at just 15fps or even less.

We do have a trick up our sleeve (but IIRC it haad to be disabled for the time being) which involves disabling the ssimulcast layers that nobody is requesting. That is, if nobody iss seeing me in the large view, why send the 720p layer at all?

Hope that helps!

Correct.

The videobridge receives all streams from all participants and forwards the appropriate ones to the other participants.

We are working on this right this instant. Expect updates soon!

They are completely different projects. Jitsi (desktop) was a multi-protocol desktop client whicch supported SIP, XMPP, IRC, etc.

At one point in time it gained the hability to do multi-party video conferencing, where one participant would become the "focus" and forward everyone's video to everyone else.

This was the inception of the concept of an SFU or Selective Forwarding Unit.

Then, in order to scale this up the SFU was extrated to a standalone project: Jitsi Videobridge.

Roughly around then, WebRTC became a thing and Jitsi was already doing many of the required things to bring the experience to the web, so work continued with Jitsi Meet, a WebRTC compatible video conferencing system.

Jitsi Meet is our present and future, but Jitsi (desktop) lives on both as pieces of the puzzle (Jitsi Videobriidge, Jigasi and Jicofo use parts of it) and as a community project, where people interested in keeping it alive ssubmit fixes / improvements.

Note that this article is about the legacy Jitsi desktop application, and NOT about Jitsi Meet, the WebRTC compatible video conferencing project. Source: I'm a Jitsi dev.

Most of the Jitsi devs are employed by 8x8, which offers a service based on it: https://8x8.vc and it also integrates it in Virtual Office, it's core product. Disclaimer: I work for 8x8.

At least on iOS the heavy lifting seems to be done by the TwilioVideo library: https://github.com/twilio/twilio-video-app-ios/blob/c9d5410b... ... which is not Open Source: https://cocoapods.org/pods/TwilioVideo

We are making progress at making our support for Firefox on par with Chrome again. This is bound to be complete soon!

Hey there, any chance you remember when you tested this? We have recently fixed a number of problems with screen-sharing indeed!

Hey there, Jitsi dev here. Great questions, let me try to clarify.

Jitsi is now owned by 8x8, which has a clear business model. We recently launched 8x8 Meetings, which is a rebranded Jitsi Meet with a few extra bells and whistles.

We (Jitsi) have remained Open Source while navigating through 2 acquisitions (Atlassian and 8x8) and being Open Source is in our DNA. Thus, remaining in this state was always a non-negotiable item during acquisition talks.

Hey there, Jitsi dev here.

Yes, that is correct (except the Atlassian bit, we are owned by 8x8 now).

Currently WebRTC does not provide the necessary tools to make E2EE possible while still being able to use smart video routing techniques such as simulcast and SVC.

There is hope! In order to be able to have E2EE 2 things are needed:

* some metadata must be available without decrypting packets, this is (mostly?) available as RTP packet extensions, called "frame markings" * an API is necessary to be able to inject one's own encrypting engine in the WebRTC chain, Google is working on this API and hopefully it's available later in the year. Google is calling this "insertable streams": https://www.chromestatus.com/feature/6321945865879552

Happy to answer any questions!

I've been working 32 hour weeks ever since my daughter was born 2 years ago. Mondays are my day off, we go to music classes, walk on the park and just spend time together.

On tuesdays I'm "hungry" when I go back to work. I think this is the perfect balance for me and I feel I'm more productive than ever.

It may not be for everyone, and it's definitely a privilege, but if you can, I really encourage you to try it out.

There is an ongoing effort to bring it into libuv: https://github.com/libuv/libuv/pull/2322 Looks like using liburing might be the way to go, since it's MIT licensed.

They bought the IP, not the product.

Also free for open source projects: https://www.jetbrains.com/opensource/ I've applied and got one in the past. Can recommend!

> To give you an idea what we are doing; an React Native app that sell and connect a very specific type of workshops with costumers over custom WebRTC Video chat(fork of React Native-based Jitsi Meet). What I can tell, I haven't seen another custom Jitsi-Meet integration yet that gives the ability customize the UI that we have.

I'm sorry I cannot give you advice for your future endeavors, but if your code ends up shelved, please consider sharing your Jitsi Meet customizations with us (I'm one of the Jitsi core devs) so we can improve the SDK.

Best of luck!

Is it ready for prime time? IIRC it has only been around for the last couple of releases which makes me worry a bit.

Never heard of [1] before. Impressive stuff.

Ah, didn't know that, TIL!