libwebrtc packages Chromium's WebRTC stack as a DLL or shared object

This is a Chromium checkout with a wrapper around it

The repository description calls it a C++ wrapper for binary release, mainly used for flutter-webrtc desktop versions on Windows, Linux and embedded. The README title is more literal about the artefacts, naming them libwebrtc-{windows,linux}-{amd64,x86,armv7,arm64}.{dll,so}. So what the project produces is a shared library or DLL that wraps the WebRTC stack from the Chromium source tree, and the reason it exists is that the browser build of WebRTC is not a library anyone can link against directly. The supported platform list is checked off in the README: Windows on x86 and x64, Linux on x86 and x64, and embedded Linux on armv7 and arm64. The topics list is just three words, dll, so and webrtc, which is consistent with a project whose output is two binary formats. The primary consumer being flutter-webrtc tells you the target, which is a Flutter application that needs peer to peer media on desktop platforms where the standard Flutter webview route does not apply.

The note about which branch to compile is the first thing to read

There is a Note section in the README and it is short but load bearing. It says to use the webrtc-sdk/webrtc.git branch m144_release to compile. That is the single most important fact in the document for anyone building this, because the WebRTC source tree moves fast and the wrapper is tied to a specific branch layout. There is an interesting gap between the documentation and the release tags. The recent releases are libwebrtc.m150.7871.06 dated 2026-10-20, libwebrtc.m150.7871.05 from 2026-10-19 and libwebrtc.m150.7871.04 from 2026-10-09, so the published binaries track milestone 150 of the Chromium WebRTC branch while the note still names m144_release. The releases are frequent, with three in October 2026 alone, and the last push was on 2026-10-20, the same day as the newest tag. So the project is being rebuilt against a moving upstream, and the version you download is not necessarily the version the README describes.

Building starts with a gclient sync of a pinned WebRTC checkout

The build is a Chromium style checkout, and the first step is creating a working directory and entering it:

mkdir libwebrtc_build
cd libwebrtc_build

Then you write a .gclient file that points at the WebRTC repository on the m144_release branch, with the DEPS file and managed set to False, and the target_os set to win:

solutions = [
  {
    "name"        : 'src',
    "url"         : 'https://github.com/webrtc-sdk/webrtc.git@m144_release',
    "deps_file"   : 'DEPS',
    "managed"     : False,
    "custom_deps" : {
    },
    "custom_vars": {},
  },
]
target_os  = ['win']

After that a gclient sync fetches the source and its dependencies. This is the standard way WebRTC is built anywhere, and it is worth saying plainly that you are pulling a Chromium sized dependency tree. The alternative paths around it, such as a system WebRTC package, are not what this project provides, and the build scripts here assume the depot_tools workflow.

An audio patch and a BUILD.gn edit turn the source into a library

Two modifications turn the vanilla WebRTC source into libwebrtc. The first is a patch for the audio custom source, applied after cloning the wrapper repository:

git apply libwebrtc/patches/custom_audio_source_m144.patch 

The patch file name includes the m144 milestone, which is another reason the branch note matters. The second is a small edit to the WebRTC src/BUILD.gn file, adding libwebrtc to the group("default") target so that the ninja default build produces it:

-    deps = [ ":webrtc" ]
+    deps = [ ":webrtc","//libwebrtc", ]

That is a one line change with a large consequence, because it turns a target that was only reachable explicitly into part of every default build. The wrapper repository itself holds a BUILD.gn file, a conanfile.py and a .conan/ directory, include/ and src/ for the wrapper sources, a patches/ directory, an examples/ directory with a wx_loop_back_demo, a test/ directory and a format.sh script. The conanfile presence suggests the wrapper can also be consumed through Conan rather than only built by hand.

Windows and Linux builds differ mainly in the GN arguments

The platform sections are where the difference in tooling shows. On Windows you install Visual Studio Community 2022, and the GN step needs a few environment variables set for the toolchain, including DEPOT_TOOLS_WIN_TOOLCHAIN, GYP_MSVS_VERSION, GYP_GENERATORS set to ninja,msvs-ninja and GYP_MSVS_OVERRIDE_PATH pointing at the Community install. The gn gen call then sets target_os win, target_cpu x64, is_component_build false, is_clang true, is_debug true, rtc_use_h264 true, ffmpeg_branding Chrome, rtc_include_tests false, rtc_build_examples false and libwebrtc_desktop_capture true, with an ide of vs2022. The final step is a ninja build of the libwebrtc target. On Linux you go back to the .gclient step and change target_os to linux, then sync again, and the GN arguments differ, with a use_custom_libcxx false and rtc_enable_protobuf false alongside the shared rtc_use_h264 true. The ARCH variable covers x86, x64, arm and arm64, which is how the embedded targets are reached.

Desktop capture is a build flag, so screen sharing comes along with the library

One argument deserves attention because it is easy to miss and hard to undo later: libwebrtc_desktop_capture true on the Windows GN line. Desktop capture in a WebRTC build is the capability to grab the screen, and here it is compiled in rather than left out. On Linux the same set of flags does not include it. That asymmetry is a decision about the artefact rather than an oversight, and it means the Windows binaries carry screen capture code that a Linux build does not. For a product that ships these libraries to end users, that is a difference worth making deliberately rather than by inheritance, because a library that can capture the screen is a library whose threat surface is larger on the platform where it was enabled. The remaining flags are about trimming rather than adding, with rtc_include_tests and rtc_build_examples both false so the shipped library does not carry the test and example code.

Where libwebrtc is the wrong choice

Three situations argue against it. The first is a browser only product. If your application runs in a browser, the WebRTC implementation is already there, and shipping a Chromium derived native library adds tens of megabytes and a build you have to maintain for no functional gain. The second is a team that cannot carry the Chromium toolchain. This build needs depot_tools, gclient, GN and ninja, a full WebRTC source sync, a Visual Studio install on Windows, and a patch applied by hand, so the ongoing cost is maintaining a set of scripts that assume a specific upstream branch. That cost is real and it is paid on every upstream move, not once. The third is a project with a licence question. The repository carries a LICENSE file and a NOTICE file, and the WebRTC stack it wraps carries its own BSD style licence terms with the customary patent grant, but a Chromium derived binary distributed to end users raises attribution obligations that the repository does not spell out for you. The practical alternative for many teams is a WebRTC SDK that ships prebuilt binaries with a supported API surface, and the difference in approach is exactly this, one path compiles the browser engine yourself and pins it, the other accepts a vendor's build and its update cadence.

Editorial conclusion

Adopt libwebrtc when you are binding the native WebRTC stack into a desktop or embedded application and can accept a Chromium derived build, and use the browser WebRTC implementation directly if your target is only a browser. Verify first that the branch named in the note is the one you need, since the README points at m144_release while the published artefacts are tagged for a later milestone, and check the desktop capture flag because screen sharing is compiled in rather than left out.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. webrtc-sdk/libwebrtc on GitHub