Hi Juliusz, Tim, all,
thank you very much for the detailed answers, this helps me a lot.
You are right, I dont know Galène good enough to say where is the problem, and I don’t want to guess. So better I measure it properly on the next test and bring you real numbers.
My feeling, maybe I am wrong, is this... with three or four people it worked without any problem, so when ten broke everything it surprised me. I would understand that fifty or hundred would cause issues... But now I understand from you that with an sfu the server upload grows very fast, ten cameras is already around ninety copies, not two or three times more than four. So maybe ten is already a big jump. This is what I want to measure, not assume.
So for the next test I would really like your help what to measure and where.
I run the docker image, valentt/galene. Your faq says docker is not good for the network. So what is the correct docker setup, is host networking the right thing? Which udp port should I open with the new udp multiplexing? And how do I make Galène show the real public ip and not the private one from the container?
If I run relay test from a client and it fails, does this already mean the problem is media and ice and not bandwidth? What should I look for in the ice trace log?
Tim says I need around hundred megabit uplink. For some cameras on the default send limit, how much server upload I need, and does simulcast keep it under control? I will measure it with iftop during the test. And the stats page, what does it show me per client, can I read it during the test?
Your point about the client side being weaker. With ten or fifteen cameras, how many people overload their own upload on the default? Should I make the default lower for big meetings? Can one bad upload spoil the room for everybody?
And kicked out under load, could this be the file limit too low inside the container?
So my plan is, before the test I check host networking and the version and the file limit. During, I run relay test, I turn on the ice log, I read the stats page, I measure the server upload, and from each client I collect the outgoing bitrate and the lost packets. Then I bring you the numbers so we see together if it is docker network, server upload, one bad client, or the browser.
About Firefox and DJ Stern, I understand, I will tell people to use Chrome (although I used Firefox with no problem), and the raise hand button I will fix like I promised.
I also like your idea of a test your microphone and camera button on the login page. The camera can stay off by default, that is fine (I never thought to turn it on by default, just to make sure it works before joining in...), but people should be able to check right away that their microphone and camera actually work, before they join. I think that would really help the ones who click connect without reading the screen.
Thank you, I really want to make this work good.
Valent
Best regards,
|
|
Valent Turković
CEO
|
On 2026-07-20T12:14:23+02:00, Juliusz Chroboczek <jch@irif.fr> wrote:
> The default could be set in the group definition. chat-only for
> lecture, camera+microphone for chat or meeting. This way the person
> setting up the group can make the decision based on how the group is
> used.
There are two different issues here.
First, there's whether the camera and microphone should be switched on
when entering a group. On this subject: I feel very strongly that Galene
should *never* switch on the user's camera or microphone without an
explicit action from the user. I also think that a user who enters
a group should be forced to lurk in silence for a few seconds before they
are allowed to turn their camera on, so that they can check they are in
the right meeting.
For these reasons, switching on the camera automatically upon entering
a group is not something I'll implement in Galene.
The other issue is whether we should request the browser permission to use
the camera and microphone at login time, or whether we should do it at the
last possible moment as we do currently. The advantage of requesting them
early is that joining the discussion has lower friction; the advantage of
asking them later is that we don't worry the user uselessly.
I think the right solution is to have a button "test your microphone and
camera" on the login page that leads to a simple echo page.
-- Juliusz
