Top WebRTC open source media servers on github for 2024

Technology
Share 0
Tweet 0
Share 0
Share0
Tweet0
Share0
January 1, 2024

What are the WebRTC open source media servers in 2024, and which ones are the best, based on github stars.

This one is one of those sensitive articles which many people later complain about. So I’ll start it with a few disclaimers:

  • Different tools are suitable for different use cases. This means that a WebRTC media server here that is low on the popularity list might be the best fit for your requirements
  • It was enjoyable to look it up, so I just had to write this down
  • I love you all – I truly do. Please don’t be mad at me
  • That said, I am expecting a sarcastic enough meme by Iñaki. One that I can proudly add to this article – just below this bullet 😉

Table of contents

The WebRTC open source ecosystem

WebRTC is free. At least the part of it being an open standard with a commercial grade open source implementation that is available and embedded across all modern browsers.

This has garnered a nice developer ecosystem around it, part of which is open source in its nature. A simple search for “webrtc” on github returns over 32k results.

There are a lot of different avenues to WebRTC projects on github. The main ones that come to the top of my head include:

  • Media servers
  • Signaling servers and frameworks
  • WebRTC implementations in different languages
  • Samples and experiments
  • Applications written on top of WebRTC
  • …

For this specific article, I want to focus on media servers.

My “top 4” WebRTC open source media servers

There are quite a few WebRTC media servers, many of which are open source. That said, most aren’t widely known or got to the point of being interesting enough for me to take notice (I usually take notice when someone tells me he is using it for something that goes to commercial use).

Throughout the years, the list of the popular WebRTC media servers hasn’t changed that much. I’ve been using this diagram for two years now, and it probably still holds true:

Due to this, my “top 4” is simply the WebRTC open source media servers above that are still relevant. And to make sure people don’t bash me on minor issues, I’ll be presenting my these in their dictionary order: Janus, Jitsi, mediasoup and Pion

Using github for our WebRTC popularity contest

How do you even begin deciding which WebRTC open source media server project is the most commonly used out there?

One approach is to count the stars. Github starts. Luckily, all the projects I was interested in have github repos. Philipp Hancke directed me to GitHub Star History, which after a bit of fooling around with, got me this nice initial chart:

Based on people who placed a star on these github projects, we can see that mediasoup is chugging along, last in the packet. It is followed by Janus. Then there’s Pion and Jitsi Meet is ahead of the pack.

Each of these projects started at a different point in time. Pion was last to the party, which means the other projects had a headstart on it. Aligning them all on the point in time they were added to github, produces this chart:

Initial immediate thoughts here?

  • mediasoup is the slowest growing media server
  • Janus is growing at a steady, albeit slow pace
  • Jitsi changed its trajectory during the pandemic and growing faster ever since
  • Pion is the fastest growing project here, keeping at Jitsi’s recent pace to stardom

Let’s do a quick deep dive into each one of these.

Janus

Janus is one of the oldest WebRTC media servers. It is written in C, which might be the reason for its limited adoption – most developers these days won’t know how to write a hello world application in C – let alone figure out its memory use concepts (where you have to explicitly free what you allocate).

What Janus has going for it is a company. Meetecho, the maintainer of Janus, offers paid support and development services around Janus. Something other open source WebRTC media servers lack.

The trajectory of Janus is unlikely to change. It is versatile, has a community around it and support services.

Jitsi Meet

Jitsi Meet is likely the oldest of WebRTC media servers. Started by Bluejimp, who were acquired by Atlassian and then 8×8.

While Jitsi doesn’t offer any direct support and development services for Jitsi, it does offer JaaS – a managed Jitsi service for developers.

Jitsi is written in Java and has a React UI implementation.

One reason for its meteoric rise is the pandemic. Jitsi is the only open source solution that came fully built and optimized for group calls. From the get go, their mission was to build an open source Google Hangouts (that’s Google Meet today). And they succeeded.

By narrowing their applicability to a specific use case, they opened up their viability as a solution to a larger target audience – way beyond that of developers building applications.

This unfair advantage places them here as a top dog. This doesn’t mean that they are suitable for everyone – quite the opposite. They are suitable for those building Google Meet-like experiences. For things that are beyond this use case, shop around the other media servers first. But for a Google Meet-like service? Start from Jitsi Meet.

Mediasoup

Mediasoup is an open source WebRTC media server exposed as Node.js and Rust libraries. It is designed for high performance, with the unique concept of having the application built right inside the same Node.js or Rust process.

The challenge with mediasoup is its inability to offer official support and development services. Here, the reason is simple – the main creators and contributors work as developers at Miro today.

This challenge is probably what led to the slow growth of mediasoup in the github popularity contest.

That said, if you go and look at many large scale group calling deployments, they use mediasoup…

Pion

Pion is last to the scene, but fast growing compared to the others. There are 3 reasons why:

  1. Pion is written in Go language. For some reason, Go has its fandom of developers who love the language. This makes Pion their Go-to (pun intended) open source project
  2. Pion is general purpose. It is used to build both clients and servers. There are multiple media server implementations written on top of Pion, but in general, the fact that you can build more with it garners immediately more stars to the project
  3. Sean DuBois. The person who started Pion has a huge and infectious personality that helped push Pion forward. Other open source projects have their own unique personas, but whoever had the chance to speak with Sean directly will understand what I am saying here

As Pion’s popularity grows, so are the number of commercial services cropping up that use Pion. 

The best WebRTC open source media server

None.

All.

It depends.

For managers, my suggestion is almost always to let their developers experiment and pick and choose the open source WebRTC media server that they see fit. There are differences across these alternatives, but at the end of the day, if anyone tries to force a developer to use something he doesn’t think is the right solution – said developer will make sure to explain to the one forcing him why the decision made is the wrong one. In other words, you don’t want to go against your developers.

For developers, I find myself suggesting different media servers depending on their use case, requirements and even company DNA.

So in short, there’s no best WebRTC open source media server. There are several alternatives that are great – you just need to pick the one that is best for you 😀

 Previous
Next

You may also like

Comment​

Your email address will not be published. Required fields are marked

    1. Both are true I guess.

      Mediasoup is Node.js (and seems more recently also Rust) with C++ bindings and implementation of the low level networking stuff.

      From what I know, most would start from the higher level abstractions of Node.js than use the C++ part directly.

      Reply

  2. I personally used Kurento and Janus for large scale deployments, with Kurento having serious production issues, the server had to be restarted several times a month, on the other hand I really liked their plugin architecture, with ready made plugins, for example for OpenCV integration. Janus proved to be a stable and reliable solution for large scale deployments running for months without any hiccups. I've played with Mediasoup and like its npm module approach very much, however it feels as if it lacks some of the latest innovations in the space, like WHIP/WHEP. Currently I'm working with the proprietary Red5 streaming server, which I would say is in many way ahead of the competition, especially both in latest features and if you're seeking a paid support. I'm still very curious about Jitsi, having come back to Java development as my main tool, especially how much it would be possible to go beyond its narrowed use case, what I'm not very fond of is their use of XMPP for signalling, which complicates easily swapping it for another media server without changes on the front end. What I see as more and more interesting in the streaming space is utilising the technology for VR streaming and remote robotics, combining it with computer vision applications.

    In general when building a new streaming architecture now i would make it media server agnostic, have done this before and the change between Kurento and Janus was basically a smooth ride as the only thing changing was the media server adapter in the signalling microservice, even was able to use both at the same time for A/B testing scenarios in production.

    Reply

    1. Thanks David

      I think that making an architecture media server agnostic is wishful thinking in the long run.

      Different media servers tend to focus and optimize on different things. If you generalize and abstract the architecture you end up losing a lot of the optimizations that might be crucial to media quality of your use case.

      Reply

  3. 'It depends' is the best answer. Developers are trying to build so many different applications, one solution can't cover them all! Finding something that matches how you think about the problem is the fastest way to success.

    I love that the general attitude in the WebRTC server space is moving towards that. I would like to see that sentiment start happening for clients also.

    These are some projects I am really excited about it. I don't know where they will go, but I believe they will enable things that couldn't be done before!

    —-

    https://github.com/sepfy/libpeer – Client that with all libs can take ~512k of memory! I have only used it briefly, but I am hoping this is what cracks Embedded+WebRTC.

    https://github.com/paullouisageneau/libdatachannel – A WebRTC Client/Server in C++ that is very easy to build (CMake and will build all deps for you). This library was the only reason WebRTC support made it into https://obsproject.com/

    https://github.com/elixir-webrtc/ex_webrtc – WebRTC server in Elixir. I don't fully understand the ecosystem, but I have always been fascinated by Erlang. I always see people talk about Ericsson and WhatsApp with it. I also love seeing how much the developers care about spec compliance. I have learned a lot by watching them!

    https://github.com/algesten/str0m – Sans I/O Rust implementation. Love the idea to put the networking outside the library itself. Lets you do some interesting things. Pion had to add this as an after thought, and has some rough edges. I also would love to see a future with more Rust. Writing secure code is hard, writing secure networking and media code is next level! Exploits in media code are happening today https://en.wikipedia.org/wiki/Jeff_Bezos_phone_hacking_incident

    Reply

  5. I'm curious on what media server would serve best, If I just want to stream webcam video and audio data from browser and stream to server and record it there for further processing, I'm having issues with some outdated node-wrtc lib.

    Reply

      1. Thanks!

        May I know why official libwebrtc isn't mentioned? Does it have difficult learning curve or it's easier to start with one's you mentioned?

        I read your "don't expect google to be your outsourcing vendor" and it was a nice read. For my simple use case, maybe at max what I would need in future is to have many to one connections where I'm processing audio/video from multiple users/browsers on one server. Do I have to worry about small details on what I choose?

        Janus seems like a good options, so if I work with libwebrtc directly I would have to keep an eye on what's going on and if I'm using some other lib like Pion or Janus people would incorporate the changes by themselves and I don't have to worry about braking anything as I can get support(again it's subject).

        Also it would be nice if you can point me to good resource on datachannels, some libs like node-datachannel seem to have binding for it and seems confusing.

        Reply

        1. libwebrtc is mostly a client-side open source media engine from my point of view. You can use it to develop media servers, but it takes more effort and isn't a common approach these days.

          No matter what you choose you will need to work about breaking things. It is the nature of software development and a bigger one in WebRTC, where things evolve and break all the time.

          Janus is a good place to start here and one that many have used for years with success.

          Reply
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}