6 ms·

Not really sure what this offers compared to Jitsi. The author says Jitsi is complicated, but my company switched to onprem jitsi at the start of covid and it's

by drudoo 5y ago

Not really sure what this offers compared to Jitsi. The author says Jitsi is complicated, but my company switched to onprem jitsi at the start of covid and it's been a pretty smooth ride (5000+ users).

fock 5y ago
galene is a single GO-binary afaik. Jitsi needs and XMPP-server installed.
- jhugo 5y ago
  The separate components of Jitsi make it quite clean to scale and customise though. A monolith doesn't seem superior except for the very smallest deployments where simplicity is key.
  - Monotoko 5y ago
    I made quite a bit of money as a freelancer at the start of covid setting up Jitsi servers for clients - it isn't easy... especially when you start to have multiple servers etc
    - jhugo 5y ago
      It's true that it's complex, but the complexity is easily managed with modern tools. It fits very neatly into k8s for larger deployments, for example.
  - jech 5y ago
    > A monolith doesn't seem superior except for the very smallest deployments True. Galene is designed to encourage small deployments: it's a single binary that is simple enough and cheap enough so that every high school can have their own instance and not rely on an external IT team. For large deployments, where accidental complexity is not as much of an issue, you'd most probably want to use some more complex and more flexible software.
- throwaway81523 5y ago
  Wait, this is written in Go? Nothing wrong with that, but why is it called Pyrite which evokes that snakey language?
  - detaro 5y ago
    > Pyrite is a web(RTC) client for the Galène videoconference server. So probably a play on the name of the parent project.
  - rgj 5y ago
    “ I searched where the name Galene came from and learned that it is a lead-containing mineral. It would only be logical to name this side-project after another mineral. Pyrite, or a fool's gold, felt to be a good description.”
  - kortex 5y ago
    Not to be confused with https://github.com/microsoft/pyright https://github.com/microsoft/pyright and dozens more smaller projects.
craigxyz 5y ago
Are you using Jitsi meet or the lib? I've been trying to work with the API to integrate into a solution and it hasn't been pretty.
Sean-Der 5y ago
I don't know Jitsi at all, but the things about Galene (and Pyrite) I have enjoyed. * Low resource requirements. You can serve lots of users off a Rasp Pi * Single binary + JSON Config. * Designed to be modified. Galene is API driven so you can ship your own custom UI. I co-ran a conference a while back and Galene let us give a custom experience easily. Users had no idea what we were using on the backend, and we customized it exactly to what we wanted. * Written in Go/Easy to understand. You can get into the guts of Galene's jitter buffer etc.. pretty easily. Great for learning and understanding the software you are running. * Maintainers are really accessible! Galene's developer runs a mailing list and you get bounce ideas of him and some other really smart people on it.
pthatcherg 5y ago
I was curious and looked through the code of Galene briefly and found the following, which may partially answer your question. For context, I am familiar with the Jitsi code and have written a calling server (and written about it: https://signal.org/blog/how-to-build-encrypted-group-calls/ https://signal.org/blog/how-to-build-encrypted-group-calls/). Galene appears to be less mature than Jitsi. For example, it uses REMB feedback messages from the client to calculate allowable bitrates rather than calculating the bitrates itself (as Jitsi and Signal's SFU do). Worse, it appears that what it does with that information is erroneous. I could be wrong, but it looks like the bitrate allocation code (see https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L334 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5...) only allocates the bitrate for one of the video streams, not all of them. Perhaps the author did not realize that there is one REMB sent back for all the video streams by WebRTC rather than one per stream (see, for example, here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc;l=514?q=Buildremb&ss=chromium%2Fchromium%2Fsrc https://source.chromium.org/chromium/chromium/src/+/main:thi...). Further, I find the spatial layer switching code to be strange. For examples, it doesn't go down a layer unless it's 150% over the estimated allowable bitrate, which gives a lot of opportunity for inducing latency. In short, I think Galene has a ways to go before it works as well as Jitsi (Videobridge), and thus Pyrite group calls are unlikely to work as well as Jitsi group calls (for 1:1 calls, I don't know; I didn't look into that). Oh, and just a reminder, the SFU we use for Signal group calls is also open source: https://github.com/signalapp/Signal-Calling-Service https://github.com/signalapp/Signal-Calling-Service.
- jech 5y ago
  Thanks for the review, pthatcherg. > For example, it uses REMB feedback messages from the client to calculate allowable bitrates rather than calculating the bitrates itself (as Jitsi and Signal's SFU do). I'm not sure what you are saying. Galene listens to REMB messages and computes its own bitrate, then combines the two informations. https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L317 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5... > I could be wrong, but it looks like the bitrate allocation code only allocates the bitrate for one of the video streams, not all of them The code you point at is not the bitrate allocation code, it's the code that chooses which scalable layer to assign to a given client. The code you're looking for is here: https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L893 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5... > In short, I think Galene has a ways to go before it works as well as Jitsi (Videobridge) [...] the SFU we use for Signal group calls is also open source Jitsi VideoBridge is a great piece of software, no doubt about it. I'm sure that Signal's SFU is competently done too.

by drudoo 5y ago

fock 5y ago

galene is a single GO-binary afaik. Jitsi needs and XMPP-server installed.

jhugo 5y ago
The separate components of Jitsi make it quite clean to scale and customise though. A monolith doesn't seem superior except for the very smallest deployments where simplicity is key.
- Monotoko 5y ago
  I made quite a bit of money as a freelancer at the start of covid setting up Jitsi servers for clients - it isn't easy... especially when you start to have multiple servers etc
  - jhugo 5y ago
    It's true that it's complex, but the complexity is easily managed with modern tools. It fits very neatly into k8s for larger deployments, for example.
- jech 5y ago
  > A monolith doesn't seem superior except for the very smallest deployments True. Galene is designed to encourage small deployments: it's a single binary that is simple enough and cheap enough so that every high school can have their own instance and not rely on an external IT team. For large deployments, where accidental complexity is not as much of an issue, you'd most probably want to use some more complex and more flexible software.
throwaway81523 5y ago
Wait, this is written in Go? Nothing wrong with that, but why is it called Pyrite which evokes that snakey language?
- detaro 5y ago
  > Pyrite is a web(RTC) client for the Galène videoconference server. So probably a play on the name of the parent project.
- rgj 5y ago
  “ I searched where the name Galene came from and learned that it is a lead-containing mineral. It would only be logical to name this side-project after another mineral. Pyrite, or a fool's gold, felt to be a good description.”
- kortex 5y ago
  Not to be confused with https://github.com/microsoft/pyright https://github.com/microsoft/pyright and dozens more smaller projects.

craigxyz 5y ago

Are you using Jitsi meet or the lib? I've been trying to work with the API to integrate into a solution and it hasn't been pretty.

Sean-Der 5y ago

I don't know Jitsi at all, but the things about Galene (and Pyrite) I have enjoyed. * Low resource requirements. You can serve lots of users off a Rasp Pi * Single binary + JSON Config. * Designed to be modified. Galene is API driven so you can ship your own custom UI. I co-ran a conference a while back and Galene let us give a custom experience easily. Users had no idea what we were using on the backend, and we customized it exactly to what we wanted. * Written in Go/Easy to understand. You can get into the guts of Galene's jitter buffer etc.. pretty easily. Great for learning and understanding the software you are running. * Maintainers are really accessible! Galene's developer runs a mailing list and you get bounce ideas of him and some other really smart people on it.

pthatcherg 5y ago

I was curious and looked through the code of Galene briefly and found the following, which may partially answer your question. For context, I am familiar with the Jitsi code and have written a calling server (and written about it: https://signal.org/blog/how-to-build-encrypted-group-calls/ https://signal.org/blog/how-to-build-encrypted-group-calls/). Galene appears to be less mature than Jitsi. For example, it uses REMB feedback messages from the client to calculate allowable bitrates rather than calculating the bitrates itself (as Jitsi and Signal's SFU do). Worse, it appears that what it does with that information is erroneous. I could be wrong, but it looks like the bitrate allocation code (see https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L334 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5...) only allocates the bitrate for one of the video streams, not all of them. Perhaps the author did not realize that there is one REMB sent back for all the video streams by WebRTC rather than one per stream (see, for example, here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc;l=514?q=Buildremb&ss=chromium%2Fchromium%2Fsrc https://source.chromium.org/chromium/chromium/src/+/main:thi...). Further, I find the spatial layer switching code to be strange. For examples, it doesn't go down a layer unless it's 150% over the estimated allowable bitrate, which gives a lot of opportunity for inducing latency. In short, I think Galene has a ways to go before it works as well as Jitsi (Videobridge), and thus Pyrite group calls are unlikely to work as well as Jitsi group calls (for 1:1 calls, I don't know; I didn't look into that). Oh, and just a reminder, the SFU we use for Signal group calls is also open source: https://github.com/signalapp/Signal-Calling-Service https://github.com/signalapp/Signal-Calling-Service.

jech 5y ago
Thanks for the review, pthatcherg. > For example, it uses REMB feedback messages from the client to calculate allowable bitrates rather than calculating the bitrates itself (as Jitsi and Signal's SFU do). I'm not sure what you are saying. Galene listens to REMB messages and computes its own bitrate, then combines the two informations. https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L317 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5... > I could be wrong, but it looks like the bitrate allocation code only allocates the bitrate for one of the video streams, not all of them The code you point at is not the bitrate allocation code, it's the code that chooses which scalable layer to assign to a given client. The code you're looking for is here: https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5846f4443e5464c4a/rtpconn/rtpconn.go#L893 https://github.com/jech/galene/blob/e8fbfcb9ba532f733405b1c5... > In short, I think Galene has a ways to go before it works as well as Jitsi (Videobridge) [...] the SFU we use for Signal group calls is also open source Jitsi VideoBridge is a great piece of software, no doubt about it. I'm sure that Signal's SFU is competently done too.