JaaS: The team that builds Jitsi can now also run it for you(jitsi.org)

410 pointsby buovjaga5 tahun yang lalu117 comments

JaaS: The team that builds Jitsi can now also run it for you

https://jitsi.org/blog/jaas-the-team-that-builds-jitsi-can-now-also-run-it-for-you/

119 comments

worble5 tahun yang lalu

Looking for pricing, I get to this page: https://www.8x8.com/products/apis/video

>We're charging on a Monthly Active User (MAU)

>Pricing starts at $0.35/MAU and decreases based on volume.

>An MAU is defined as a unique user who attended at least one meeting, with at least one other user, in the same month. To determine a unique user, we store an identifier on the device's local storage, and that will remain the same as long as the user uses the same browser and same device and doesn't clear their local cache data. Mobile is similar. An identifier remains across updates and gets removed if you delete the app.

So does that mean that if they are running Cookie AutoDelete or Temporary Containers addons, or simply clear all their browser data after exiting, any single user could easily eat all your user limit if they just repeatedly connected to the service? Or, even just having a single person connect on their desktop, laptop and phone once would eat 3 of your licenses?

thedracle5 tahun yang lalu

Jitsi is open source, so you can look at the exact mechanics of their billing counter to answer your question:

It's all orchestrated from here: https://github.com/jitsi/jitsi-meet/blob/master/react/featur...

Which generates the MAU ID via:

react/features/billing-counter/functions.js:80

/* * Returns the stored billing id (or generates a new one if none is present). * * @returns {string} */

export function getBillingId() {

    let billingId = jitsiLocalStorage.getItem(BILLING_ID);

    if (!billingId) {
        billingId = uuid.v4();
        jitsiLocalStorage.setItem(BILLING_ID, billingId);
    }

    return billingId;
}

emcho5 tahun yang lalu

(Jitsi Dev here) Yes you are correct. Cookie delete is indeed something that would trigger a new user count. So far we haven't seen this happen but if you believe your users would be massively cleaning cookies, we are happy to have a conversation and find a work around for you.

Stephen3045 tahun yang lalu

FWIW, me and my team would likely be super into paying for a hosted Jitsi if there was another pricing structure. We run our own but keeping it running smoothly takes away dev energy. Counting usage like this just seems very ripe for abuse by anybody who wishes to harm the group.

saghul5 tahun yang lalu

Please do reach out to us, we just got started and are happy to discuss.

sandGorgon5 tahun yang lalu

Do consider pricing on the peak number of simultaneous streams (like Pusher.com does)

kwindla5 tahun yang lalu

Pricing for real-time video is hard. There are pretty large variable costs to run a service like this.

WebRTC is peer-to-peer, architecturally. But if you run the service you pay for bandwidth for users behind firewalls (because you need to forward the audio/video through TURN servers) and for calls with more than 3 or 4 people (because you need to offload some of the cpu/bandwidth from the clients).

Bandwidth and media server CPU set the floor for what you need to charge.

As a SaaS, you can charge per <usage> or charge per <user>. Each pricing model is good for a different subset of your customers. With fairly large variable costs, usage-based pricing is easier to model for you, but not necessarily for your customers.

For example, your (developer) customers that charge a flat rate per "seat" per month for their products will have trouble projecting what their margin will be if you charge them per video minute.

The industry Jitsi/8x8 competes in is gradually moving towards $0.0015/minute as the rough cost of video for customers with significant volume. So one way to look at Jitsi's pricing model is that they are projecting an average of ~4 hours of video per month per unique user. ($0.35 / $0.0015 / 60). Which seems ... low?

This is separate from the question above about how they track unique users, which I agree is really interesting!

Also, and again separately from Jitsi, there's also a long history of not-so-transparent pricing in the telecommunications world. One of the major SaaS video platforms advertises peer-to-peer calls as free on their service. And they are, if you don't count the TURN bandwidth they bill you for.

(Disclaimer: as the cofounder of Daily.co, a YC company that competes with this Jitsi service, I think about variable vs per-user pricing way too much. tldr; we can almost always do better for you than any of our competitors, partly because we're happy to talk to you and put together custom pricing based on your use case. But it's also true that most of our customers, especially our largest customers, don't select us primarily based on price. Empirically, we win on ease of use, video quality, API flexibility, and developer support. So under-pricing isn't an optimal business strategy, either.)

Bswift5 tahun yang lalu

Just wanted to say that daily.co was crucial to my company during the early months of the lockdown. We had a fully integrated telehealth option deployed for our users in a weekend. You all are amazing!

orixilus5 tahun yang lalu

Same here :) best solution all around. Easy/quick to implement and affordable

ourcat5 tahun yang lalu

I'd never heard of Daily.co before. Looks great! Nice work.

I'm about to start building out an idea I've had based on WebRTC/MediaSoup/nginx-RTMP and ffmpeg. (But not for 'live' video calls though).

And having just seen your Jobs page, I think I might drop you guys a line, once I've got something working. ;)

jefftk5 tahun yang lalu

I'm currently using Twilio for echo.jefftk.com, and paying $0.004/minute (I'm very low volume).

I was considering switching to this, but their pricing is a terrible fit for my "most calls have mostly people who've never used it before" situation.

sudosysgen5 tahun yang lalu

There are other JaaS providers that might have better pricing for you

philipps5 tahun yang lalu

I would still like to see an answer to the questions above. In particular, does a user who connects on three devices count as three MAUs?

Spare_account5 tahun yang lalu

If MAUs is hard, then don't use MAU as a billing metric? Charge for concurrent connections or by the minute maybe?

avianlyric5 tahun yang lalu

Sounds like it. But at 35cents / month, that doesn’t sound like a bad outcome.

owens995 tahun yang lalu

That’s way too expensive. My $80/month server bill can support millions of users per month but would only get me <300 MAUs on this service?

Edit: my guess is I misunderstood who they are targeting with this. Thought they were targeting developers who want to integrate Jitsi with an existing product.

jrh2065 tahun yang lalu

Personally, I feel like this is really generous pricing

Compare it to, e.g. Slack (https://app.slack.com/plans/T01JN93179R?geocode=en-gb) or Zoom (https://zoom.us/pricing)

Notwithstanding any accounting issues raised by worble, which I'm sure will be ironed out over time

glaive1235 tahun yang lalu

They must be targeting people who just want to use this for internal purposes, rather than developers who want to integrate Jitsi with an existing product.

emcho5 tahun yang lalu

(Jitsi Dev here) Most of our customers are actually developers and that's how the service is intended. Hope this helps

jrh2065 tahun yang lalu

Yes, exactly. This offering is a Zoom alternative

eznzt5 tahun yang lalu

This is like people saying fastmail pricing is reasonable because other providers gyp you too.

mstade5 tahun yang lalu

I don't get it, what's wrong with fastmail's pricing? I've been a customer for years and never thought much about it.

JacobSuperslav5 tahun yang lalu

it isn't? i used it for years and been very happy.

eznzt5 tahun yang lalu

The marginal cost of the service they provide is like 10% of what they charge, or even less.

vharuck5 tahun yang lalu

If you believe this, start a competing service. There is no moral or practical rule that forces prices down to cost without external reason. If Fastmail is making big bucks, and customers are happy with the price, that's good for everyone.

tomashubelbauer5 tahun yang lalu

Do you go to restaurants expecting to pay only the total cost of ingredients for your meal? Fastmail provides an excellent service and if anything I feel as though I underpay for what I'm getting. I'm happy to know they have a healthy margin to pay their developers from and improve the product.

[deleted]5 tahun yang lalu

eznzt5 tahun yang lalu

I expect to pay a reasonable price. Being overcharged by 90% is not reasonable.

marcinzm5 tahun yang lalu

Restaurants charge 4-5x the cost of ingredients. So I take it you never eat out?

eznzt5 tahun yang lalu

I have worked in one and no they don't. Most restaurants barely break even by the end of the month once you factor in all costs (like employees, rent...), which I did in the example of fastmail.

marcinzm5 tahun yang lalu

You said marginal cost which is not all costs. Marginal cost is equivalent to ingredients and does not include fixed costs which likely make up the majority fo their expenses.

JacobSuperslav5 tahun yang lalu

Any good alternatives you could recommend?

[deleted]5 tahun yang lalu

saghul5 tahun yang lalu

Millions of users per month doing video conferencing?

jamespo5 tahun yang lalu

Of course not

owens995 tahun yang lalu

No. I meant for a normal SPA or CRUD app without video.

saghul5 tahun yang lalu

Then what are you trying to compare? The pricing includes all video traffic relaying, which is the non-trivial part of these types of setups.

cryptonym5 tahun yang lalu

Not the best comparison. Probably depends on your use-case.

How much does it cost to setup and maintain the platform (actually reachable from end users) 24/24 at 99.99 ? Global infra ? Dealing with HIPAA/GDPR ?

robertkrahn015 tahun yang lalu

CoScreen, an app sharing and pair programming tool [1] runs on Jitsi / JaaS. I work on that project. We're really happy with the service since a reliable and fast global infrastructure is key for what we offer.

[1] https://www.coscreen.co

aloer5 tahun yang lalu

Can you tell us a little bit about the technology you use to make the virtual screen work on MacOS?

Someone recently posted something requiring an “HDMI dummy plug” (a fake display adapter?) to create a virtual screen. How did you solve it on a pure software level?

I would like to understand better what kind of api access your solution requires and I have trouble finding the right words to google.

- I assume you have to use undocumented internal APIs?

- do you have to inject code into higher privileged processes such as the Dock or window manager?

Edit: your page looks broken on mobile Safari with content blockers enabled via Firefox focus. The whole part above fold stays white

emmanueloga_5 tahun yang lalu

This looks really polished (...at least judging by the great marketing video...) will have to try it!.

May I ask how long have you guys been working on this? Just curious :-)

robertkrahn015 tahun yang lalu

Thanks :) The idea has been around for a number of years but only beginning of last year (pre covid) we made the leap and started working full time on the project.

zelphirkalt5 tahun yang lalu

Is it only available for MacOS? When I go to the download page, it only shows me download for MacOS.

robertkrahn015 tahun yang lalu

Yeah, we're are currently working on Windows, it's almost ready. Expect a first beta in a few weeks.

sverhagen5 tahun yang lalu

Under the download button it says:

> or join the waitlist for Windows and Linux

PietKachelhout5 tahun yang lalu

But that Typeform has too many questions.

mstade5 tahun yang lalu

Hi! This looks great. I'm assuming it being free is temporary, do you have any information on future pricing?

robertkrahn015 tahun yang lalu

Thank you! We've not yet made a final decision about pricing yet, the first priority is to make it as reliable as we can and support multiple OS. However, there will very likely be some kind of free tier, similar to Slack and Zoom.

saghul5 tahun yang lalu

Hey all, saghul from team Jitsi here. Didn't expect this to spread so fast, thanks everyone!

Happy to answer any questions you may have!

darkteflon5 tahun yang lalu

Hi saghul, thanks for dropping by.

We’re currently running self-hosted Jitsi Meet in production and have been very happy with performance - particularly stability. We would however be interested in switching to JaaS as we’d like to get away from managing our own infra and just host a landing page through, e.g., NextJS on Vercel, with a JaaS iFrame.

The landing page mentions deep customisation but when clicking through to the documentation I see only custom branding, etc., through the developer web console. We have some customisations on the front-end (custom kick messages, auto-enabling lobbies, etc). Is it possible to make these sorts of customisations to JaaS? It seems like an iFrame is the recommended integration so would be great to get a sense if any of these things are possible. Could you speak generally to the degree of customisation possible outside of the developer web console?

Thanks in advance.

saghul5 tahun yang lalu

> We would however be interested in switching to JaaS as we’d like to get away from managing our own infra and just host a landing page through, e.g., NextJS on Vercel, with a JaaS iFrame.

This is indeed what we had in mind when building JaaS.

> We have some customisations on the front-end (custom kick messages, auto-enabling lobbies, etc). Is it possible to make these sorts of customisations to JaaS?

Depends on exactly what. As we just launched we are learning what our customers want and adding new APIs and more customization options pretty rapidly. Please get in touch and let's discuss what APIs / customizations you'd need.

> Could you speak generally to the degree of customisation possible outside of the developer web console?

As you mentioned before, the iframe API is indeed the recommended way for integrating.

darkteflon5 tahun yang lalu

Thanks for the response saghul, we’ll get in touch.

nikisweeting5 tahun yang lalu

We host music events where ~500-2000 people watch a shared stream, and some subset of those people break off into video chat rooms to hang out with each other.

We'd love to pay for JaaS to host the video room portion of events, however the MAU pricing model doesn't work well for events that only last a day or two. Is there any alternative pricing model that charges by the day or minute?

saghul5 tahun yang lalu

Please reach out. We are happy to talk about it and find ways to accommodate other use cases.

trestenhortz5 tahun yang lalu

Are you concerned amazon will take your business?

saghul5 tahun yang lalu

No. They have a similar offering of their own. We also run our infra on AWS so they are getting business from us already.

jonas_kgomo5 tahun yang lalu

Is there a simple tutorial or resources on how to get started ?

telesilla5 tahun yang lalu

One of the great things about Jitsi are the config options:

https://meet.jit.si/JitsiMeetAPIExampletest#config.p2p.enabl...

Should give you stereo, high-quality audio suitable for music, with echo cancellation disabled.

One of the things that makes Jitsi not perfect however is that I understand that Jitsi Videobridge is an SFU, thus not appropriate for a large conference. Perhaps now they have a way to monetise, they can add this and charge for bandwidth/CPU usage.

saghul5 tahun yang lalu

> One of the things that makes Jitsi not perfect however is that I understand that Jitsi Videobridge is an SFU, thus not appropriate for a large conference.

On the contrary, this is how you can scale up to large conferences. We do bridge cascading, you can read more about it here: https://jitsi.org/blog/jitsi-meet-now-with-geographical-brid...

We are now working on very large conferences, expect some news soon :-)

TYPE_FASTER5 tahun yang lalu

I really like Jitsi. I've been running it on a Digital Ocean droplet for my own use.

The one feature I've been missing is remote control during a screen sharing session. I understand it was removed for security reasons (https://github.com/jitsi/jitsi-meet-electron/issues/431). Are there any plans to implement the feature again in the future?

Thanks!

saghul5 tahun yang lalu

Yes, it will come back. We have so many things in our plate that not everything can be acted upon in a timely manner. Don't despair :-)

TYPE_FASTER5 tahun yang lalu

Awesome, thanks for the reply.

pqdbr5 tahun yang lalu

Great news!

d01005 tahun yang lalu

Jitsi is great and we've been using it for some time.

We switched from a custom WebRTC because error handling becomes too complex with browser permissions and connection.

It does work much better, however there are still a few times that video just doesn't work, with no way to debug why

saghul5 tahun yang lalu

Would love to hear more about those problems. Have you opened GH issues / community posts?

d01005 tahun yang lalu

Mostly some clients not connecting, just a blank screen. No error message available

I havent been able to reproduce yet

cudder5 tahun yang lalu

> Free for up to 25 monthly active users

This is the only mention of pricing that I can find on your site unless I sign up. I wonder what the cost is for >25 MAU.

turbinerneiter5 tahun yang lalu

https://imgur.com/a/uf1mTxy

99$/month for 300 MAU

arcturus175 tahun yang lalu

Video is crazy expensive.

I know the underlying infra is complex, but these costs mean you would need a lot of capital and a very aggressive monetization strategy from the get-go to even get started, no?

turbinerneiter5 tahun yang lalu

In my mind I'm comparing this to Teams/Slack/Zoom and so on - in that context it is cheap, no?

Not sure if this is the right context tough.

arcturus175 tahun yang lalu

No, you're right.

I was thinking in terms of B2C economics... $99 for 300 MAU would be crazy for a consumer startup product. $99 for 300 internal business users is completely different.

argument_clinic5 tahun yang lalu

BTW, having to sign up just to see the price is a big no-no for me and I'd probably not sign up just to see it.

svarlamov5 tahun yang lalu

Congrats this seems like a very needed product! We tried Jitsi for our web app (1), but ultimately settled on Daily.co for it's pricing and easy developer experience. How does JaaS stability compare to Jitsi? Any one here chose Jitsi over Daily?

1. https://codingrooms.com/

riedel5 tahun yang lalu

This is great since selfhosted jitsi somehow developed into an IT support nightmare for us. Would be awesome to hear how they are doing the scaling. Our IT only offers jitsi only for max 10 ppl in a room which keeps us from using it at least in 50% of the cases. Also some users are reporting problems, so it would really be great to see a supported desktop app for all relevant platforms for those that struggle to get the browser setup right. Also native performance background effects has become something that at least could support bits of privacy in this crazy home office world ( it is not always e2ee that makes the difference).

saghul5 tahun yang lalu

> Would be awesome to hear how they are doing the scaling.

Shameless plug: https://fosdem.org/2021/schedule/event/jitsi_scaling/

> so it would really be great to see a supported desktop app for all relevant platforms

We have an Electron based app: https://github.com/jitsi/jitsi-meet-electron

> Also native performance background effects

This is in the works, we have to be able to share some news soon!

anticensor5 tahun yang lalu

BigBlueButton is more suitable for larger conferences.

svarlamov5 tahun yang lalu

Oddly enough, we also used BigBlueButton for a while and really loved the additional features like the whiteboard but also had to drop it because we were doing more support for BBB than our core product...

saghul5 tahun yang lalu

> ultimately settled on Daily.co for it's pricing and easy developer experience.

I can't comment on pricing, but would you mind elaborating on the DX part?

> How does JaaS stability compare to Jitsi?

They are the same. JaaS is a different deployment from meet.jit.si, using the same tech.

pojntfx5 tahun yang lalu

Awesome! Chose Jitsi a while back for my old high school's COVID chat system and it's been working flawlessly.

saghul5 tahun yang lalu

Glad to hear this! <3

johnxie5 tahun yang lalu

Taskade's video chat runs on Jitsi, on the same page with our collaborative task list. We're happy with the performance and integration so far.

You can test out our implementation no signup needed: https://www.taskade.com/new

kabes5 tahun yang lalu

If I understand correctly this is for jitsi meet. Is a hosted version of the jitsi SFU standalone also planned?

saghul5 tahun yang lalu

Hey there! Jitsi dev here. What do you have in mind? Feel free to contact us at: [email protected]

kabes5 tahun yang lalu

Something with an API similar to Vonage/Tokbox or Twilio video.

saghul5 tahun yang lalu

Gotcha. We are thinking about that. Please reach out to us and let's talk about it: [email protected]

gregoriol5 tahun yang lalu

Would it work with lib-jitsi-meet?

In other words, would you jitsi be able to take care of the hosting while we develop a custom interface with the lib?

saghul5 tahun yang lalu

Yes! You are welcome to build your own UI with lib-jitsi-meet.

fiatjaf5 tahun yang lalu

I tried to run a Jitsi server. It's a madness full of Docker impossible things to run and a very long and confusing configuration file.

I wonder why can't these things be provided as binaries with a simple set of settings.

Now they offer Jitsi as a service for free up to 25 users? That's great though. It should cover 99% of normal people use cases, so no one will use meet.jit.si anymore.

buovjaga5 tahun yang lalu

Over at The Document Foundation, we use a Salt setup with no Docker: https://git.libreoffice.org/infra/salt/+/refs/heads/master/j...

saghul5 tahun yang lalu

> I tried to run a Jitsi server. It's a madness full of Docker impossible things to run and a very long and confusing configuration file.

Sorry to hear that. Any chance you can provide some more details on what you tried and didn't work? I'd like to improve on this.

> I wonder why can't these things be provided as binaries with a simple set of settings.

That's kind of what they already are, but at certain degree of complexity it unfortunately leaks back to the user.

fiatjaf5 tahun yang lalu

No, sorry, I don't remember anymore. But it was just a hobby server for a group of friends to use and we've given up since.

I just remember being forced to install docker and edit a docker-compose.yml, and then configs would show up in other parts of the system that were not the directory I was in.

Then finally I got the server and people could join but they couldn't see the others. Anyway, I probably didn't invest the right amount of time and focus to get it working.

theandrewbailey5 tahun yang lalu

I set up a Jitsi instance last year, and it didn't involve Docker at all. Getting the ports set up was the biggest issue.

I used this guide: https://jitsi.github.io/handbook/docs/devops-guide/devops-gu...

nikisweeting5 tahun yang lalu

I don't know about others but I much prefer running a docker container than a random binary.

css5 tahun yang lalu

What is the screen sharing performance of this like? When I tried to set up the Jitsi integration for Mattermost earlier this week, even with only 3 people in a call, we could not get the stream over 1-2 fps. Discord handles native-res 60fps streaming.

saghul5 tahun yang lalu

When running from a browser, Chrome specially lowers the framerate and prefers higher resolution. Not sure we can tune it for high fps.

cloogshicer5 tahun yang lalu

Does anybody know a video conferencing tool with low CPU usage while screen sharing? All the tools I've tried, including Jitsi, slow down my computer to a crawl.

rkangel5 tahun yang lalu

Fundamentally, generic screen sharing is going to involve running a video encoder live (because that's what you're doing - generating a video stream of your desktop). Something needs to do that work, and unless your GPU can it's going to be the CPU.

The only way around it that I know is a 'remote desktop' type protocol where you send drawing primitives to reconstruct the desktop on the other end. That is obviously a much more complicated thing to get working and is better for different use cases.

kwindla5 tahun yang lalu

As a user, I think Google Meet probably has the most cpu-friendly default settings for screensharing. They limit the framerate to 5fps, and they're careful to use either the native size of the screen or half the native size (which avoids at least some expensive scaling code paths).

This is hard/impossible to get right on every machine, because encoder implementations vary widely across all the hardware and operating system combinations. For example, using h264 instead of vp8 might help with cpu usage a lot on an older macOS machine, but make cpu usage worse on a newer macOS machine or some specific windows machine.

Here are settings we recommend to developers building apps that include screen-sharing using our video APIs: https://gist.github.com/kwindla/5d5a8190aee36dc00a5ef8e6c901...

Max-width of 640 for the camera. Max-width of 1920 for the screenshare, framerate limited to 5fps, and manually decimate the screenshare width by half if it's larger than 1920. ymmv, but these settings use ~30% of the cpu on a typical mid-range Windows or macOS machine, for the sending side of a two-person cam+screenshare call.

cloogshicer5 tahun yang lalu

Hey, thank you for the recommendation and detailed info! Sadly Google meet is empirically one of the worst one, even without screen sharing CPU hovers at ~60%, with screen sharing it's completely unusable.

My use case is live coding sessions in education btw.

kwindla5 tahun yang lalu

I'm always interested in data points, so thank you! If you don't mind, I'd love to hear what hardware/OS you're using. We have a lot of test devices, and it sounds like your particular setup is one that Google (and possibly we) aren't doing a good job factoring into our settings defaults/workarounds/special cases. So I think we maybe need another test device. :-)

mguerville5 tahun yang lalu

I’ve had similar issues and have not found a tool that cooperated better. Here are a few things that helped though: - App police (mac app) to reduce cpu allocation for any given app - unplug external display monitor during video calls - turn off any video enhancing settings in app (mirror video, enhanced light, etc) as well as virtual background or background blur

It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog

kwindla5 tahun yang lalu

> It’s crazy that I’m 2021 we don’t have video calling that isn’t a ginormous performance hog

It sure is. On the other hand, the big tech companies did not view video calls as a critical use case until ~9 months ago.

You can see this in how much Chrome has improved in its last 3 releases. A year ago, you could play ~15 videos simultaneously in a page on Chrome before <stalling, chaos, and crashing>. Now, on the same machine, you can play >50. This matters for video calls because the standard stream topology these days for multi-party calls is 1 up, N down, where N is the number of participants in the call.

Hardware and OS support is critical, too, so this is an ecosystem challenge.

  - encoder pipelines don't do low-resolution streams very well, which matters for large video calls
  - encoder pipelines don't do variable framerate, variable resolution, large resolution/low-framerate, and "non-standard" resolutions as well as they could
  - hardware support for newer codecs (vp9, h265, av1) would help
  - decoder pipelines aren't great at decoding lots of small videos in parallel

Everyone focused on single-stream video playback for the last few years, which led to really amazing improvements watching video. Nobody complains anymore about their fan spinning up every time they watch Netflix. Now we have to put the same effort into the building blocks needed for video calls.

cloogshicer5 tahun yang lalu

Thank you for the detailed reply.

On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore.

That said I agree with a lot of your points and I totally get why it is this way. It's just sad that it's mainly due to business reasons.

I think part of it that video conferencing is too cheap/free. It's just a bad business to be in.

kwindla5 tahun yang lalu

> On the one hand, yes, it's a hard problem, on the other hand, if you think about how much a modern video game does 60 times per second, it's not that hard anymore.

Agreed! Modern GPUs are amazing, as is the software stack on top of them. (Crufty, fragile, maddening, inconsistent ... and amazing.)

For the next-gen needs of video calling, some combination of Nvidia, Apple, Intel, Arm, Microsoft, Google, codec IP owners, and a bunch of mobile chipset manufacturers are going to have to agree on a bunch of stuff. That never happens in a logical, straightforward way.

For the past 10 years Nvidia has been betting that a really big chunk of their future growth will come from powering machine learning applications of all kinds. They're probably ... right? (I mean, I have no idea.) But as someone who cares a lot about video and only intramurally about machine learning, I find that frustrating. There's a lot of relatively low-hanging fruit, from a technical perspective, in hardware codec support.

cloogshicer5 tahun yang lalu

Thanks for your response! Unfortunately I'm already doing all those things.

Agreed, I think it's insane. How come there isn't a single App out there that works well for such a key technology? I guess it's a really hard problem to solve.

gardnr5 tahun yang lalu

Is it still owned by atlassian?

luto5 tahun yang lalu

they sold it in 2018.

https://techcrunch.com/2018/10/29/atlassian-sells-jitsi-an-o...

saghul5 tahun yang lalu

Nope, we're part of the 8x8 happy family now.

acatsdream5 tahun yang lalu

Will there be a flutter sdk?

saghul5 tahun yang lalu

We have no plans for it at this point. We provide native SDKs for Android and iOS and IIRC there is already a 3rd party Flutter module which exposes our native SDKs to Flutter.

petters5 tahun yang lalu

Seems much more expensive than e.g. OpenTok. Aren't they similar?

saghul5 tahun yang lalu

The pricing models are vastly different AFAIK. How are you comparing them?

kitkat_new5 tahun yang lalu

when will E2EE get out of Beta?

saghul5 tahun yang lalu

Hard to tell. We're calling it beta because we may change how the feature works, not because it doesn't work properly yet.

mike_d5 tahun yang lalu

Now that they have commercialized the project, I suspect a rebranding away from "Meet" is probably coming next. It is obviously confusingly similar to Google Meet.

amenod5 tahun yang lalu

Well, they can also just wait for Google to either rename or kill off their product. /s

On a more serious note, it was never confusing to me - I didn't even notice they share the same word until now tbh. And quick search for "meet videoconferencing" shows quite a few of the products named similarly. To me it is almost as generic as "chat".

lozf5 tahun yang lalu

Jitsi were using "meet" years before google, way back when Hangouts was still newish and quite good.

peterburkimsher5 tahun yang lalu

I host the Asia-Pacific weekly meetup for BeWelcome every Thursday night, starting in about an hour (23:00 NZDT, 18:00 UTC+8)

https://meet.jit.si/BeWelcome-Chat_4MembersVolunteers

BeWelcome is like CouchSurfing, but free and open-source. The leaders therefore chose to support other OSS where possible, including Jitsi. Less than 25 people attend regularly, but hopefully it can grow (not many people travelling these days, it's nice to hear first-hand about life in Singapore, China, Korea, Germany, Italy). If we have Jitsi-related issues, I'll try to let you know! And you're all welcome to drop in and find out more :)

zelphirkalt5 tahun yang lalu

It is probably offtopic here and therefore you are downvoted by other people, but personally I thank you for getting the word out there. Hope to join a meeting soon!