[HN Gopher] JaaS: The team that builds Jitsi can now also run it...
___________________________________________________________________
JaaS: The team that builds Jitsi can now also run it for you
Author : buovjaga
Score : 380 points
Date : 2021-01-28 06:53 UTC (16 hours ago)
(HTM) web link (jitsi.org)
(TXT) w3m dump (jitsi.org)
| robertkrahn01 wrote:
| 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
| zelphirkalt wrote:
| Is it only available for MacOS? When I go to the download page,
| it only shows me download for MacOS.
| sverhagen wrote:
| Under the download button it says:
|
| > or join the waitlist for Windows and Linux
| PietKachelhout wrote:
| But that Typeform has too many questions.
| robertkrahn01 wrote:
| Yeah, we're are currently working on Windows, it's almost
| ready. Expect a first beta in a few weeks.
| aloer wrote:
| 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
| mstade wrote:
| Hi! This looks great. I'm assuming it being free is temporary,
| do you have any information on future pricing?
| robertkrahn01 wrote:
| 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.
| emmanueloga_ wrote:
| 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 :-)
| robertkrahn01 wrote:
| 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.
| cloogshicer wrote:
| 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.
| mguerville wrote:
| 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
| kwindla wrote:
| > 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.
| cloogshicer wrote:
| 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.
| kwindla wrote:
| > 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.
| cloogshicer wrote:
| 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.
| kwindla wrote:
| 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.
| cloogshicer wrote:
| 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.
| kwindla wrote:
| 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. :-)
| rkangel wrote:
| 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.
| saghul wrote:
| 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!
| nikisweeting wrote:
| 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?
| darkteflon wrote:
| 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.
| saghul wrote:
| > 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.
| trestenhortz wrote:
| Are you concerned amazon will take your business?
| saghul wrote:
| No. They have a similar offering of their own. We also run
| our infra on AWS so they are getting business from us
| already.
| telesilla wrote:
| 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.
| saghul wrote:
| > 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 :-)
| gregoriol wrote:
| 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?
| saghul wrote:
| Yes! You are welcome to build your own UI with lib-jitsi-meet.
| css wrote:
| 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.
| saghul wrote:
| When running from a browser, Chrome specially lowers the
| framerate and prefers higher resolution. Not sure we can tune
| it for high fps.
| cudder wrote:
| > 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.
| argument_clinic wrote:
| 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.
| turbinerneiter wrote:
| https://imgur.com/a/uf1mTxy
|
| 99$/month for 300 MAU
| arcturus17 wrote:
| 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?
| turbinerneiter wrote:
| 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.
| arcturus17 wrote:
| 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.
| worble wrote:
| 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?
| kwindla wrote:
| 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.)
| ourcat wrote:
| 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. ;)
| Bswift wrote:
| 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!
| jefftk wrote:
| 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.
| sudosysgen wrote:
| There are other JaaS providers that might have better
| pricing for you
| philipps wrote:
| 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_account wrote:
| If MAUs is hard, then don't use MAU as a billing metric?
| Charge for concurrent connections or by the minute maybe?
| avianlyric wrote:
| Sounds like it. But at 35cents / month, that doesn't sound
| like a bad outcome.
| owens99 wrote:
| 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.
| jrh206 wrote:
| 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
| glaive123 wrote:
| 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.
| emcho wrote:
| (Jitsi Dev here) Most of our customers are actually
| developers and that's how the service is intended. Hope
| this helps
| jrh206 wrote:
| Yes, exactly. This offering is a Zoom alternative
| eznzt wrote:
| This is like people saying fastmail pricing is reasonable
| because other providers gyp you too.
| mstade wrote:
| 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.
| JacobSuperslav wrote:
| it isn't? i used it for years and been very happy.
| eznzt wrote:
| The marginal cost of the service they provide is like 10%
| of what they charge, or even less.
| vharuck wrote:
| 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.
| tomashubelbauer wrote:
| 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.
| eznzt wrote:
| I expect to pay a reasonable price. Being overcharged by
| 90% is not reasonable.
| marcinzm wrote:
| Restaurants charge 4-5x the cost of ingredients. So I
| take it you never eat out?
| eznzt wrote:
| 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.
| marcinzm wrote:
| 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.
| [deleted]
| [deleted]
| cryptonym wrote:
| 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 ?
| saghul wrote:
| Millions of users per month doing video conferencing?
| jamespo wrote:
| Of course not
| owens99 wrote:
| No. I meant for a normal SPA or CRUD app without video.
| saghul wrote:
| 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.
| emcho wrote:
| (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.
| sandGorgon wrote:
| Do consider pricing on the peak number of simultaneous
| streams (like Pusher.com does)
| Stephen304 wrote:
| 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.
| thedracle wrote:
| 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; }
| TYPE_FASTER wrote:
| 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!
| saghul wrote:
| 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_FASTER wrote:
| Awesome, thanks for the reply.
| pqdbr wrote:
| Great news!
| gardnr wrote:
| Is it still owned by atlassian?
| saghul wrote:
| Nope, we're part of the 8x8 happy family now.
| luto wrote:
| they sold it in 2018.
|
| https://techcrunch.com/2018/10/29/atlassian-sells-jitsi-an-o...
| acatsdream wrote:
| Will there be a flutter sdk?
| saghul wrote:
| 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.
| petters wrote:
| Seems much more expensive than e.g. OpenTok. Aren't they similar?
| saghul wrote:
| The pricing models are vastly different AFAIK. How are you
| comparing them?
| fiatjaf wrote:
| 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.
| saghul wrote:
| > 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.
| nikisweeting wrote:
| I don't know about others but I much prefer running a docker
| container than a random binary.
| theandrewbailey wrote:
| 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...
| buovjaga wrote:
| Over at The Document Foundation, we use a Salt setup with no
| Docker:
| https://git.libreoffice.org/infra/salt/+/refs/heads/master/j...
| kitkat_new wrote:
| when will E2EE get out of Beta?
| svarlamov wrote:
| 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/
| saghul wrote:
| > 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.
| riedel wrote:
| 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).
| saghul wrote:
| > 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!
| anticensor wrote:
| BigBlueButton is more suitable for larger conferences.
| svarlamov wrote:
| 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...
| pojntfx wrote:
| Awesome! Chose Jitsi a while back for my old high school's COVID
| chat system and it's been working flawlessly.
| saghul wrote:
| Glad to hear this! <3
| d0100 wrote:
| 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
| saghul wrote:
| Would love to hear more about those problems. Have you opened
| GH issues / community posts?
| mike_d wrote:
| 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.
| lozf wrote:
| Jitsi were using "meet" years before google, way back when
| Hangouts was still newish and quite good.
| amenod wrote:
| 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".
| peterburkimsher wrote:
| 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 :)
| zelphirkalt wrote:
| 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!
| johnxie wrote:
| 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
| kabes wrote:
| If I understand correctly this is for jitsi meet. Is a hosted
| version of the jitsi SFU standalone also planned?
| saghul wrote:
| Hey there! Jitsi dev here. What do you have in mind? Feel free
| to contact us at: jaastech@8x8.com
| kabes wrote:
| Something with an API similar to Vonage/Tokbox or Twilio
| video.
| saghul wrote:
| Gotcha. We are thinking about that. Please reach out to us
| and let's talk about it: jaastech@8x8.com
___________________________________________________________________
(page generated 2021-01-28 23:03 UTC)