Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?
Yes, I think it defaults to 720p.
Thanks for the information.
The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.
Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client
No, it's an estimate of what could be sent under the current conditions,
taking into account bottlenecks along the way.
Thanks. I will check these values in the next tests that I will do.
Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.
Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.
So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?
You are probably sending 640x360 and also 320x180. This could be because
of the bandwidth estimation, or because of the camera. You are shown in
full-screen on the receiver's end (if I understand correctly), so the
bridge forwards the highest higher of the available resolutions, i.e.
For what I was watching with guvcview, the lowest resolution of my camera
is 320x240 (did you mean to that?) and the highest is 1280x720.
If 720p (1280x720) is the default resolution when config.resolution is
not used, I would have to see why I would be sending such a low resolution.
Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
Interesting. Thanks for sharing this video.
In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?
I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).
Very interesting. Thank you for sharing this document. From what I can
see, among the statistics we have:
* conferences - The current number of conferences.
* participants - The current number of participants.
But these seem to be general values, or is there some way to know the
number of participants in each conference?
Thanks for your reply and your time.
You are welcome. And thank you for your interest in the project.
It is a very interesting project. Now I am trying to adapt some aspects.
Do you know if there is a way to disable the thumb-up button? This
button works in meet.jit.si, but it has no effect on the installation
made from Debian packages. And I would like to keep the interface as
clear as possible with only what users see useful.
P.S.: If you know of any way to restrict users that can connect to a
conference, as I consulted in the other email, I would appreciate any
One option is to manually lock a specific room. This way people joining
will need a password specific for that room. You can lock it by clicking
the "share the link" button in the menu on top, and then adding a password.
If this doesn't work for you, there are ways to require authentication
from the XMPP server. But I'm afraid I don't know much of the details
there, so someone else will have to chime in, if you have any questions
Yes. Thanks for the tip. I was referring to using authentication. I was
testing that by configuring Prosody + Jicofo. In this scenario I found
If all conferences are always started by the same organizer, there is no
problem. But suppose that conference A has a single organizer that is
A', and conference B has a single organizer that is B'. If B' wants to
be a participant in conference A, after B' joins to this conference, it
will show two organizers (A' and B') when only one organizer is
expected: A'. This would be a side effect of Chrome/Chromium (and
Firefox) when automatically cached the B' credentials.
It seems that this side effect is due to a cookie that Jitsi Meet saves
on localStorage. Is there any way to remove that cookie automatically
after end each conference to avoid this effect?
Thanks for your reply and your time.
On 10/01/17 17:19, Boris Grozev wrote: