Congrats on the launch jech! These are the things that have made me really excited about Galène. If you are doing broadcasting/teaching you really can't beat it.
* The build/deploy is INSANELY easy. `go build` and a certificate.
* UI is a joy to use. Load it up, no frustrating loading screens or spinners. A clean layout that effectively uses the screen real estate.
* UI/Backend is decoupled and documented. Read `README.FRONTEND` it clearly lays out how to bring your own frontend.
* Built in a way you can learn from. The code is clear and concise, I have learned a lot from reading it and brought back ideas to my own work!
Great, works out of the box. I'd add an anonymous option to the login, even though you can leave the password empty.
Also, an indicator if TURN is used and if it's non-encrypted or encrypted would be great.
Jitsi is a great piece of software, as are the other alternatives listed on the web page. The opposition is not with other self-hosted videoconferencing solutions, but with cloud-based systems that impose restrictive usage conditions.
How do we convince people to switch to self-hosted solutions? I think that part of the solution lies in making them easier to deploy: ideally every high school, every community college should be able to have their own videoconferencing server, which can be used for lectures, for practicals, for student-teacher meetings ("office hours"), and hopefully for student socialisation (although in my experience students tend to prefer Discord, notwithstanding their outrageous usage conditions).
Galène is designed to be as easy and cheap to deploy as reasonable. It also has a number of features that make it useful for practicals (sharing multiple windows simultaneously, automatic creation of subgroups), which we found very difficult to organise online during the first French lockdown.
I thought the same. Really cool they list the alternatives on the project page. But a little something on why they did not use the alternatives but built their own would be very helpful for those evaluating the options.
Nice. I have been toying in this space myself and programmatic alternatives to the existing solutions I think are the way forward.
The future features are exactly what I'm looking for. Namely simulcast support to help bandwidth limited clients and server scalability/redundancy especially in a WAN scenario.
- it would be good to document/visualise the different components. AFAICT coturn is used to connect peers; what is galene responsible for? Signalling and room management?
- A big, clear link to the code on Github is always nice
Galène is not peer-to-peer: it's a traditional centralised server, where all media traffic goes through Galène. TURN is only used if the user's network blocks the UDP traffic between the client and Galène (TURN can use TCP, and can run on an unblocked port such as 443 or 1194).
Before Galène, I experimented with a pure peer-to-peer system, with end-to-end encryption. I found it to be too unreliable for group communication: with just 5 people in a group, you need to establish 10 peer-to-peer WebRTC flows, and the likelihood that all of them work well is essentially zero.
Very interesting. How does it work scaling? Possible to have one loadbalancer with multiple servers? With autscaling? Or only works with one server for now?
For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core
Scaling wise what are you trying to do?
* You can put different rooms on different servers. They don't have to aware of each other.
* If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers.
* If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.
[+] [-] Sean-Der|5 years ago|reply
* The build/deploy is INSANELY easy. `go build` and a certificate.
* UI is a joy to use. Load it up, no frustrating loading screens or spinners. A clean layout that effectively uses the screen real estate.
* UI/Backend is decoupled and documented. Read `README.FRONTEND` it clearly lays out how to bring your own frontend.
* Built in a way you can learn from. The code is clear and concise, I have learned a lot from reading it and brought back ideas to my own work!
[+] [-] 5Qn8mNbc2FNCiVV|5 years ago|reply
[deleted]
[+] [-] sylwester|5 years ago|reply
[+] [-] jech|5 years ago|reply
Good idea. I'll check with Alain (the UI guy).
> if it's non-encrypted or encrypted
It's always encrypted (WebRTC doesn't support plaintext communcation). If we ever add an option for end-to-end encryption, we'll add an indicator.
[+] [-] sylwester|5 years ago|reply
[+] [-] spicyramen|5 years ago|reply
[+] [-] jech|5 years ago|reply
How do we convince people to switch to self-hosted solutions? I think that part of the solution lies in making them easier to deploy: ideally every high school, every community college should be able to have their own videoconferencing server, which can be used for lectures, for practicals, for student-teacher meetings ("office hours"), and hopefully for student socialisation (although in my experience students tend to prefer Discord, notwithstanding their outrageous usage conditions).
Galène is designed to be as easy and cheap to deploy as reasonable. It also has a number of features that make it useful for practicals (sharing multiple windows simultaneously, automatic creation of subgroups), which we found very difficult to organise online during the first French lockdown.
[+] [-] cies|5 years ago|reply
[+] [-] kodablah|5 years ago|reply
The future features are exactly what I'm looking for. Namely simulcast support to help bandwidth limited clients and server scalability/redundancy especially in a WAN scenario.
[+] [-] alexchamberlain|5 years ago|reply
- it would be good to document/visualise the different components. AFAICT coturn is used to connect peers; what is galene responsible for? Signalling and room management?
- A big, clear link to the code on Github is always nice
[+] [-] jech|5 years ago|reply
Before Galène, I experimented with a pure peer-to-peer system, with end-to-end encryption. I found it to be too unreliable for group communication: with just 5 people in a group, you need to establish 10 peer-to-peer WebRTC flows, and the likelihood that all of them work well is essentially zero.
[+] [-] bilekas|5 years ago|reply
> This server is used in production, please don't overload it.
HN Might inadvertently cause that! :)
[+] [-] jech|5 years ago|reply
[+] [-] ortenheim|5 years ago|reply
[+] [-] Sean-Der|5 years ago|reply
* You can put different rooms on different servers. They don't have to aware of each other.
* If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers.
* If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.
[+] [-] daimoc42|5 years ago|reply
[deleted]