This repository is not the only project solving this problem. Several others build the WebRTC native libraries and publish the binaries, some covering platforms this one does not.

Worth knowing about for three reasons: to cross-check a build that is behaving oddly, to cover a platform we do not build, and to decide honestly whether maintaining our own pipeline still earns its keep.

Figures are a snapshot taken 2026-09-06 and will drift. "Last push" is the signal that matters — a WebRTC builder that has not moved in a year is tracking a Chromium milestone nobody ships.

The closest peers to this repository.

crow-misia/libwebrtc-bin is the most direct comparison. Its releases are versioned <milestone>.<branch>.x.y — the current one is 152.7977.0.0, the same branch this repository resolves to. If a build here fails and you need to know whether the branch itself is at fault, that is the fastest cross-check available.

shiguredo-webrtc-build has the widest platform coverage of anything listed here, including Jetson and Raspberry Pi. Its documentation is largely in Japanese.

stasel/WebRTC is the reference point should a native AppKit target ever be needed — it distributes the ObjC framework that our macOS .dylib lacks. WebRTCme does not need one today; see Platform layers.

Not builders exactly — they wrap WebRTC's C++ API in a flat C ABI so it can be called by P/Invoke, FFI or similar. The same problem WebRtcInterop/ in this repository solves; see Interop ABI for why we solve it ourselves rather than adopting one.

This is the project WebRtcInterop/ was originally started from in 2023 — WebRtcInterop/NOTICE still carries its MIT notice. Nothing of it survives in the current implementation, which was written from scratch against the ABI contract, but its header set remains the best available blueprint for the API shape a later slice should expose.

These build WebRTC as part of something else. Useful mainly as worked examples of build configuration.

These do not build Google's WebRTC at all — they reimplement the protocols. Listed because they are frequently mistaken for alternatives to a build, and because WebRTCme already depends on one.

An independent implementation sidesteps the whole build problem — no depot_tools, no 30 GB checkout, no patching. The trade-off is that it implements the protocols rather than shipping Google's media engine, so the audio processing, bandwidth estimation and codec integration are different code with different maturity.

Every gap described in Platform layers is a property of which GN target was built, not of who built it. A raw C++ webrtc target from any of these projects has the same missing H.264, because that comes from proprietary_codecs defaulting false.

The exceptions are the projects that build the sdk/ targets — the Apple distributions above, and the Android outputs of the cross-platform builders. Those carry the integration layer, which is what actually closes the gaps.

So the question "should we keep building our own?" is really two questions: whether we want control over the branch and the shared-library patch (which these mostly do not provide — they ship static libraries or platform frameworks), and whether we would rather consume the SDK targets than the raw core. The second is the more interesting one.

• Platform layers — what any given artifact actually contains
• Branch selection — how this repository picks a WebRTC version