12 ms·

Pyrite – open-source video conferencing

187 points by jvanveen 5y ago

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.
arsin 5y ago
rcarmo 5y ago
The most interesting thing for me is actually the galene server, but playing around with the demo server and looking at the documentation it seems to be a fair bit behind Jitsi in ease of use and deployment. (I built a one-shot template to deploy and run Jitsi on Azure - https://github.com/rcarmo/azure-ubuntu-jitsi https://github.com/rcarmo/azure-ubuntu-jitsi - and it's been trivial to maintain over the past two years, for a small group of friends and monthly "open sessions") I'm not enamored of the Pyrite UI (again, Jitsi seems simpler), but I'll keep an eye on both.
throwaway81523 5y ago
Besides this vs Jitsi, I wonder if there is a tldr about how Zoom managed to capture so much of this space.
- crubier 5y ago
  I think it's region and connection speed dependent, but for several years I noticed that meetings with zoom had wayyyy less problems with freezes, bad quality, audio drops and stuff when compared to all other tools.
  - salmo 5y ago
    This has been my experience, even now. I still prefer it to Teams and WebEx because of the reliability. I do like that Teams allows for a richer chat experience, but often just keep a Teams chat and Zoom call going when needed.
    - lucb1e 5y ago
      Then again, Teams is an outlier in terms of performance and reliability. Most things will compare positively with that.
- james_in_the_uk 5y ago
  I've assumed that control over the end point client native software allows them to focus on removing pain points. Codecs. NAT traversal etc. Once a critical mass of users, big corporates etc. found their solution easier, then they got the network effect.
- detaro 5y ago
  It was free and easy to get started with, and worked.
  - lucb1e 5y ago
    So like jitsi except not free as in freedom
goldbattle 5y ago
It would really help if the author had a list of "features" on the github project. It is a bit difficult to figure out what exact functionality the project supports. * https://github.com/garage44/pyrite/ https://github.com/garage44/pyrite/
- jech 5y ago
  Pyrite inherits most of Galene's features, which are listed at https://galene.org https://galene.org. (Galene's server has some extra features that are not used by Galene's native client yet, but were designed for third-party frontends, but I don't think Pyrite is using any of those yet.)
greazy 5y ago
Something that is desperately missing from video conferencing software is walkie-talkie-like interface and capabilities that allow for stop-start convos. This might seem silly but it would help tremendously for those in developing countries. Lots of our collaborators are in developing countries with terrible internet, so we end up resorting to video chat + phone call.
- c-smile 5y ago
  FreeConferenceCall[.com] allows to participate in meetings by phone and SMS. That's beside of typical video/chat conferencing capabilities. Client is pretty small ~20 Mb monolithic (a.k.a. portable) executable that can be loaded in seconds even on low bandwidth networks. If someone is interested, here https://terrainformatica.com/2022/02/19/freeconferencecall-and-sciter-js-project-development-notes/ https://terrainformatica.com/2022/02/19/freeconferencecall-a... I've explained how it was done (in 9 months).
  - greazy 5y ago
    Phone calling is part of the problem and does not solve the issue at hand. The central issue is that video conferencing software assumes face to face meetings. However if you use video conf for demonstrating anything it all goes to hell due to choppy video and compression. If you ever extend your software to have stop start system let me know. It will spread like wild fire on developing countries
- paulryanrogers 5y ago
  Push to talk can be nice though IME requires diligence and trust. I had a private Mumble server to chat with coworkers outside the company resources. It was OK-ish. Folks didn't really buy in to the always stay connected then push to talk or side rooms style. Slack seems to be trying to find a middle path with huddles.
ataylor32 5y ago
Not to be confused with https://github.com/microsoft/pyright https://github.com/microsoft/pyright
synergy20 5y ago
So Pyrite is a vue3 frontend to Galene the video conference backend. I do like go's easy of deployment. desktop it appears to be nice, on Android the UI is barely usable, is this a desktop-only UI so far?

187 points by jvanveen 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.

arsin 5y ago

rcarmo 5y ago

The most interesting thing for me is actually the galene server, but playing around with the demo server and looking at the documentation it seems to be a fair bit behind Jitsi in ease of use and deployment. (I built a one-shot template to deploy and run Jitsi on Azure - https://github.com/rcarmo/azure-ubuntu-jitsi https://github.com/rcarmo/azure-ubuntu-jitsi - and it's been trivial to maintain over the past two years, for a small group of friends and monthly "open sessions") I'm not enamored of the Pyrite UI (again, Jitsi seems simpler), but I'll keep an eye on both.

throwaway81523 5y ago

Besides this vs Jitsi, I wonder if there is a tldr about how Zoom managed to capture so much of this space.

crubier 5y ago
I think it's region and connection speed dependent, but for several years I noticed that meetings with zoom had wayyyy less problems with freezes, bad quality, audio drops and stuff when compared to all other tools.
- salmo 5y ago
  This has been my experience, even now. I still prefer it to Teams and WebEx because of the reliability. I do like that Teams allows for a richer chat experience, but often just keep a Teams chat and Zoom call going when needed.
  - lucb1e 5y ago
    Then again, Teams is an outlier in terms of performance and reliability. Most things will compare positively with that.
james_in_the_uk 5y ago
I've assumed that control over the end point client native software allows them to focus on removing pain points. Codecs. NAT traversal etc. Once a critical mass of users, big corporates etc. found their solution easier, then they got the network effect.
detaro 5y ago
It was free and easy to get started with, and worked.
- lucb1e 5y ago
  So like jitsi except not free as in freedom

goldbattle 5y ago

It would really help if the author had a list of "features" on the github project. It is a bit difficult to figure out what exact functionality the project supports. * https://github.com/garage44/pyrite/ https://github.com/garage44/pyrite/

jech 5y ago
Pyrite inherits most of Galene's features, which are listed at https://galene.org https://galene.org. (Galene's server has some extra features that are not used by Galene's native client yet, but were designed for third-party frontends, but I don't think Pyrite is using any of those yet.)

greazy 5y ago

Something that is desperately missing from video conferencing software is walkie-talkie-like interface and capabilities that allow for stop-start convos. This might seem silly but it would help tremendously for those in developing countries. Lots of our collaborators are in developing countries with terrible internet, so we end up resorting to video chat + phone call.

c-smile 5y ago
FreeConferenceCall[.com] allows to participate in meetings by phone and SMS. That's beside of typical video/chat conferencing capabilities. Client is pretty small ~20 Mb monolithic (a.k.a. portable) executable that can be loaded in seconds even on low bandwidth networks. If someone is interested, here https://terrainformatica.com/2022/02/19/freeconferencecall-and-sciter-js-project-development-notes/ https://terrainformatica.com/2022/02/19/freeconferencecall-a... I've explained how it was done (in 9 months).
- greazy 5y ago
  Phone calling is part of the problem and does not solve the issue at hand. The central issue is that video conferencing software assumes face to face meetings. However if you use video conf for demonstrating anything it all goes to hell due to choppy video and compression. If you ever extend your software to have stop start system let me know. It will spread like wild fire on developing countries
paulryanrogers 5y ago
Push to talk can be nice though IME requires diligence and trust. I had a private Mumble server to chat with coworkers outside the company resources. It was OK-ish. Folks didn't really buy in to the always stay connected then push to talk or side rooms style. Slack seems to be trying to find a middle path with huddles.

ataylor32 5y ago

Not to be confused with https://github.com/microsoft/pyright https://github.com/microsoft/pyright

synergy20 5y ago

So Pyrite is a vue3 frontend to Galene the video conference backend. I do like go's easy of deployment. desktop it appears to be nice, on Android the UI is barely usable, is this a desktop-only UI so far?