Recent discussions with several parties, make me realise that the first steps to master webrtc are not yet documented enough. Once, as a challenge, I asked a master student doing his graduation project with us to try to recompile and example provided with libwebrtc separately from the compilation of libwebrtc itself. Basically to make a project with the same example source code but that would link against the pre-compiled library. 5 months later, it was still not successful. Thanks to our internal tool that I shared then, we eventually did it in two weeks. This post is about the usual ordeal people have to go through to understand the state of affair, and of course how CoSMo can shield you from that.

libwebrtc from webrtc.org

libwebrtc, the Implementation behind Chrome, Firefox, Safari, Edge and many other’s WebRTC API, is the de facto standard implementation for WebRTC compliant clients.

Unfortunately, libwebrtc is one of a kind. Designed to be fully integrated in the chromium build and test process, it includes some feature that help 1,000 developper strong team remaining agile, but that goes on the way of the usual practice for smaller teams:

• no design document,
• no backward compatibility,
• no stable release, only sync’ed release,
• specific (undocumented) build tool chain,
• build tool design that requires everything to be build in one pass,
• 200 commits a week
• no assurance of commit stability
• lack of updated examples except for those which are shipped along

As a result, the usual experience with libwebrtc goes like this:

1. 1. The golden path [3 ~ 5 days]
      1. go to webrtc.org,
      2. figure out the exact development environement needed (esp on windows),
      3. get the code sync’ed for a specific revision,
      4. compile it,
      5. test with appRTC or peerconnection_client.
   2. Emancipation: try to compile your own project and link against libwebrtc [weeks]
      1. Simplest way: take out the source code of peerconnection_user and try to compile it separately
      2. Deal with include paths,
      3. Deal with C++ standard (98,11,14, 17),
      4. Deal with C++ standard implementation lib mismatch,
      5. Deal with missing preprocessor definitions (WEBRTC_WIN, WEBRTC_POSIX, …),
      6. Deal with missing JSON symbols,
      7. Eventually succeed in barely reproducing something that was already working.
   3. Starting to deviate from the golden path: the quest for GN GEN args
      1. Try to make your own capturer, needs rtti,
      2. add support for H264,
      3. add support for ccache,
      4. add cupport for cross-compilation (ios, android),

all of the above, and some more, deviate from the official build, but has existing, undocumented flags for them.

1. 2. Alone in deep water
      1. Any modification to the C++ code,
      2. Changing external libs (OpenSSL, libsrtp, …),
      3. Adding a new codec,
      4. Compiling for an unsupported platform (win32 for IE plugin, …),
      5. Compiling the C++ API for arm64 (for Qt, …),
      6. …

All of the above are quite reasonable things to do, but still excrutiating hard to do in libwebrtc.

1. 2. the final blow: the ever recurring 6 weeks deadline

Once all of this has been figured out, you have a version of your app linkind against libwebrtc (or yo ugave up already). And then, chrome releases a new version, which breaks backward compatibility, which makes your app basically unusable … Since libwebrtc is not a simple single git repository, but an aggregated collection of them, rebasing is not an option.

In a less critical scenario, nothing breaks, but you do not benefit from the bug fixes, improvements and new features the 20+ companies, including 120 google engineers, added to the source code since last release.

CoSMo Tools for easier webrtc

libwebrtc packages

We provide pre-compiled, packaged versions of libwebrtc, so you can focus on your app.

• All the operating systems supported by webrtc.org are supported,
• All libraries needed in addition of libwebrtc are packaged along,
• CMake configuration files are provided to deal with compatibility:
  • check your compiler and build tool for compability,
  • set up all include and lib paths,
  • set compiler flags,
  • set preprocessor Definitions,
  • …
• The builds are tested first using the google’s own unit test suite,
• Then additionnal battery of tests which compile full applications are run,
• Finally, we run those application against web app in browsers for interoperability tests thanks to KITE,

Advanced packages and tools

We provide customized builds of libwebrtc with different options, e.g.

• Real end-to-end encryption (a.k.a. double encryption),
• Watermarking,
• G.729, H.265, AV1,
• Custom Crypto (custom OpenSSL and libsrtp),
• …,

We provide bindings and wrappers for webrtc into popular client libraries to make it even easier for you to use libwebrtc. not need to understand threading models, or COM models. Moreover, an update of libwebrtc itself would be transparent to the wrappers.

• Qt wrappers, desktop and mobile,
• Electron builds,
• React Native,
• IE 11 plugin,
• …,

Full white label apps and single server Systems

We maintain a suite of white labels apps that work either p2p or with an SFU, with a given signalling server. It feeds our test suite, and is the perfect starting point for Proof-of-concepts.

• appRTC, p2p connection, web app + native app desktop and mobile,
• Janus Video Room, SFU connections, web app + Electron + Qt app + Mod. OBS-Studio,
• Meedoze, SFU connection, web app + Electron + native all platforms + Qt app + Mod. OBS-Studio,
• Jitsi, SFU connection, web app + Electron + react-native ios and android,
• …

Do not hesitate to contact us for help and pricing!