>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?
(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.
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.
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.)
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!
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
> 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.
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?
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.
> 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.
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?
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?
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.
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?
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).
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...
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.
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.
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.
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.
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.
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.
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.
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.
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. :-)
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
> 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.
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.
> 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.
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.
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.
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.
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".
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 :)
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!
>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?