saghul

Glad to hear the defaults worked well for you!

Jitsi is xo posee of several moving parts, and making sure everything works well out of the box is something we deeply care about.

Privacy is an important aspect.

Authentication can be another important one, if you want to integrate with your existing SSO or other auth mechanism.

Last, customization. While this can be done via JaaS too (our CPaaS offering) you will always have full control over your deployment if you self-host it.

Yep, you can think of it as a Google Meet / Zoom / Teams you can self-host.

Can you elaborate on the reliability issues?

Those on an iPad, were they using the app or the mobile web app?

Thank you!

Hey there, Saul from the Jitsi team :-)

Self-hosting is one of the use cases we spend a lot of time on, recently venturing into a hybrid model with JaaS components.

If there is any pain point with self-hosting, please let us know!

I seem to remember they used to indent Python code with 2 spaces. Glad to see it's 4 now.

Not my project but found if while looking into the "asdf" project's performance issues ticket: https://github.com/asdf-vm/asdf/issues/290#issuecomment-1406...

Very happy for Matt and the Prosody team. This is further validation of their good work.

We use Prosody successfully for powering the signalling in Jitsi Meet. Its extensibility has allowed us to develop many many features easily.

We have a SaaS model called Jitsi as a Service (JaaS): https://jaas.8x8.vc and recently launched “components” which a way to connect your self-hosted instance to our cloud for PSTN dial-in support.

Yes you can! While in “large view” mode, when you are looking at the large video / screen-share with all the thumbnails on the right, there is an arrow at the bottom pointing right wards. Click it and that will hide the filmstrip altogether just leaving the large view.

This the current most used model. It trades having to do expensive mixing on the server with more bandwidth and vise streams on the clients.

Since each participant sends several resolutions, each receiver will only get what they ask for. In a “gallery” style view, each video is not in full HD, for example.

Thanks for the kind words!

The chat is quite limited indeed. Our primary use case is audio / video media, and we see chat as more of a "supporting" channel, to share links, etc.

Never say never though, given enough time, we could make it better :-)

I don't think there is comprehensive information about that. We all do pretty much the same, implement the Selective Forwarding Unit (SFU) model.

The idea is the SFU will receive a number of streams for each user (usually up to 3, in low, mid and high resolutions) and then it will forward one of them to each other participant depending on things like available bandwidth, requested video size, etc.

There are a number of Open Source implementations available, in case you want to study it deeper:

- Jitsi videobridge: https://github.com/jitsi/jitsi-videobridge

- Janus: https://github.com/meetecho/janus-gateway

- mediasoup: https://github.com/versatica/mediasoup

- (p)ion: https://github.com/pion/ion-sfu

- meddoze: https://github.com/medooze/media-server-node

And probably more!

Nice to see this here :-)

I'm one of the developers working on Jitsi Meet, feel free to AMA!

They do say "The Gitea project will of course remain open source, and a community project."

It's not clear to me if they intend to further develop Gitea or work on the non open parts. Looking at the reactions and the announcement it looks like everyone assumes the latter.

I wonder why not both?

Nice work! Does this mean that intercepting WebRTC media traffic is now possible? It's DTLS, so I guess I'll have to check it out!

Has this been reported to Chromium / WebRTC? At a quick glance I don't see it in the WebRTC bug tracker.

The thread pool can be made larger with the environment variable. The author didn't mention they were running into that issue, however.

The question I have is why were those lookups a problem in the first place? It's just a metric, is it really important that it's sent one tick later?

As another commented pointed out the "solution" only uses a single IP, even if the resolver returned multiple.

I would not use this in production.

It's both free and open source (https://github.com/utmapp/UTM). You can pay 10$ to get automatic updates, which IMHO is a very fair price and you are helping support the project.

This is incredible. Not only the final result is breathtaking, but the intermediate projects you created to support it are awesome too! The duckyPad looks very nice too!

We do have VOSK support already. I haven’t heard of whisper, but it does sound like a good GSoC project for next year!

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

What a weird take.

How else would we have implemented this? WASM has facilitated introducing these technologies into web applications, it literally wasn’t possible before.

Thanks to emscripten it wasn’t even that hard to get rnnoise working on WASM: https://github.com/jitsi/rnnoise-wasm

I concede WASM does open the possibility of adding opaque stuff to web apps but IMHO the benefits outweigh the drawbacks at this point.

While we’ve had rnnoise integration for a while it was for “noisy environment” notifications, this is the first time we use it to actually filter audio.

Also audio worklets weren’t a thing when we first introduced it.

I’m not aware of any other open source (and better) models, but if any come up, we’ll certainly check them out!

I came back to MTG a few years ago and these 2 formats hit my sweet spot right in the center!

The only drawback is the cost of the cards, but some communities allow proxies.

Might be the nostalgia, but there is something beautiful in the apparently simple and yet complex old cards.

Now that's some commitment!

I haven't had any issues with mine (OLED model) FWIW. If you have an OLED model I think there is a way to put the card in the PSVSD, which might be more reliable.

What about it? Some people may not have a choice but they'd still like to improve their privacy / security.