Due to Coronavirus; we are using conferencing tools heavily. What I see from other commercial video conferencing tools is that; once they share screen, they reduce the framerate alot but make the screen very crisp and easy to read for other.
Sometimes there is a 2-3 second delay on the screen when a user let’s say changes a word document page but it is always readable and all the graphics are crisp.
I believe having a crisp screenshare experience is much more important than having a fast (more fps) screenshare experience.
Thank you for the reply but the points you’ve added are not related to the technical aspects I’m in search for. All your suggestions are based on improving available bandwidth however this may not be possible under all technical situations.
While videoconferencing; there are some aspects more important than others; such that human brain continue processing audio while video can stutter and the magic of conversation does not dissolve. If it happens the other way; everyone is distracted.
Same issue applies to the screensharing as well. If the image on the screen is not crisp; then people cannot actively follow what you are speaking of. Zoom, Teams and such software handle this at the expense of FPS where we don’t really need fps while sharing the screen. A FPS of 1/2 or 1/3 would be just fine.
How can we tune the software according to it so we can have very crisp images while sharing the screen? From my 1 month experience; this is the only solid issue I’ve ever encountered.
Thanks for clarifying. The answer to your initial question is no, you can’t selectively lower participants use of bandwidth while in a meeting, except for muting everyone. You can however ask them to lower video quality but this is not ideal. Perhaps you could file a bug report requesting that specific behavior.
Jitsi Meet adjusts every participant’s video and audio feed depending on their connection. Whoever is sharing their connection will need to have high speed. Do you have connection speed information for the person sharing the screen that was not readable ? Where they using wifi only (cabled network is always best) ?
Many more external factors can affect your meeting, that’s why I mentioned a few that you can request participants to observe. Screen sharing is important for participant XYZ ? Please use cabled ethernet, mute your microphone, use push-to-talk, measure your speed and test your screen sharing before having a real meeting. That is always faster and easier than waiting for a new feature to be developed, tested and deployed.
I’m not sure if your responses are automated but they are totally out of scope of what I’m asking.
In Jitsi configuration file; you can set seperate framerate for screensharing so this option is available. If there is a bad bandwidth; set the FPS to a value lower than 1 like 2 or 3 secs per frame. Bandwidth will ALWAYS be an issue. You cannot ask people to use cable while the whole world is using laptops on Starbucks connected to free wifis. The solution lies in the software; not the cable.
Moreover; what I mention has already be implemented. Zoom has it. Microsoft teams has it. It’s doable. It’s not magic.
No, I have to agree with the original poster. Overall he is asking how we can reduce bandwidth by lowering framerate. You are saying that’s not possible without a lot of work. The truth is a lot of people need a simple solution right now that provides high quality audio with so-so video so that we can communicate effectively.
There is no reason that mobile clients shouldn’t be able to limit bandwidth by reducing video quality. Even youtube has settings to control the quality of video from 144p to 4k. If a user is on a slow line and wants to watch 4k video they can do that.
There is no reason that people on high or medium bandwidth connections shouldn’t be able to reduce the quality of video to allow more people to participate. Reducing the resolution would also be perfectly acceptable.
I wrote about this a week ago when I asked for focused low-bandwidth connections for mobile clients and I was completely ignored. I use Jitsi every day for class right now. I realize I’m not paying any money for it but I honestly would at this point if it meant I’d have better control of the bandwdth.
At this point my only option is to consider switching to Zoom which is overloaded but at least they are making the necessary improvements to their product so people can adapt instead of blowing them off.
Do you realize the size and resources of the development teams you are comparing JItsi Meet and 8x8 to ?
I am answering close to 40 requests for help per day here. The extraordinary amount of new users is why no one has been able to answer personally to you yet. If you can link to your unanswered message, I’ll do my best.
If adding a parameter to the URL in order to override default parameters or editing two configuration files on a self-hosted Jitsi Meet install is too much, then yes, you should be using other software and accepting their restrictions, privacy invasion and security issues.
If you won’t share tips for your participants and moderators to improve even slightly the conditions for everyone, you will face the same problems with any other software.
It is significant effort for all parties involved in your very specific scenario and conditions. This is not Google or Zoom! Even with the tiny amount of resources compared to such huge companies, Jitsi Meet just works for many people.
WhatsApp, Telegram and many more exist that already work, mostly, sometimes, in varying conditions.
Ask yourself why you are here demanding free help for a free resource hosted on servers that you don’t pay for instead of going for the alternative, then perhaps the effort required to improve, share and learn about Jitsi Meet will seem worth it as it does for me.
Not to be disrespectful but no, actually. I have no idea of the teams I am comparing and that honestly shouldn’t surprise you. You have an amazingly well done website that makes you look like a global level operation.
I’m using Jitsi Meet because it was recommended to me by a good friend of mine as an alternative to Zoom and Skype and subsequently I recommended it to all of my students, whom, by the way, are Japanese, because it’s a simple and elegant product but are also limited to mobile devices for the most part.
There has been a panic over webcams and everything has been sold out for two weeks. Tablets are also in short supply and people are nervous about spending money and signing up for new services in an emergency situation.
Also, if you need help with localization into Japanese, I will gladly donate my time. I’m glad to say that getting 30 Japanese students online with Jitsi has been extremely easy given none of them know English. The hardest part by far has been answering what “Jitsi” means.
Implementing bandwidth controls directly into the clients should reduce the time you spend supporting bandwidth issues. Right now there is a low bandwidth mode on smartphones but it simply turns off video altogether.
I am not surprised, that’s why I mentioned it. Most people install and use software without any regards to who is making it, for what reasons, and what resources are dedicated to it. Free software doesn’t follow most rules and motivation other projects do.
This would be most helpful. If you’re comfortable in GitHub, edit the appropriate files and file a pull request.
Right now translations are managed as direct contribution to language files in the source code itself (string files). You will need to sign a CLA, see here for more details.
Forum discussions remain that : discussions, opinion, help and workarounds for issues and problems.
Unless you file a proper bug report or find an existing one and contribute to it, the chances of getting developers attention here are lower. Learning how to contribute to bug reporting and quality assurance in general (QA) is also part of using Free open source software unless you only want to consume it.
Thankyou for the link to your post, I’ve read it and will reply there with useful suggestions.
Thank you for all the replies. We have no intention of blaming -or saying anything wrong at all- here.
We are all thankful to the devs who brought Jitsi to life. Jitsi is an open source app and depends on the community just like WebRTC which was opensourced by Google. This is a collaborative effort.
I truly understand the work being done here and I’m not comparing this to any of other companies dev teams however I’m just trying to point out one fundemental thing in video conferencing; screen sharing performance.
It’s not just piping the video stream thru vp8/h264 but also making it useable by everyone involved is important. Creating a presenter mode itself is a huge effort and I totally appreciate that.
What I’m suggesting to devs here is that screensharing is not the same thing as video-conference. It’s a total different story and I believe they already know this because you can at-least change fps min/max in Jitsi meet configuration files. That’s truly awesome but there’s further work I believe that needs to be done. It’s making the shared screen crisp irrelevant of the FPS or bandwidth requirement.
Wish I had the ability to edit code and send a pull-req but unfortunately I’m not that capable however I believe what I’m asking is doable. I’d really like to get a devs opinion on this.