pion/webrtc leans on fourteen sibling modules, and the import path carries the major

The import path carries the major version, so an upgrade touches every file

The usage section does not open with an install command, it opens with a rule: Go modules are mandatory, you must set the module mode variable yourself, and you must write the major version into the import path. That is why the module is declared as github.com/pion/webrtc/v4 rather than github.com/pion/webrtc. The consequence is mechanical and unavoidable: the v4 suffix appears in every file that imports the library, in every package of your own project, and a move from v3 to v4 is not a dependency bump but a rewrite of the import block. The README anticipates this by pointing readers who cannot upgrade yet at the tags for the latest v3 release, and it says breaking changes are described in the release notes wiki page. If your codebase is large, budget for that mechanical pass rather than discovering it during the upgrade.

export GO111MODULE=on

The module header itself is two lines, and the second one is the toolchain floor:

module github.com/pion/webrtc/v4

go 1.24.0

Sixteen required modules, each at its own major version

The dependency list is the clearest statement of what this library actually is. Fourteen of the direct requirements come from the Pion organisation and split the protocol across separate repositories: datachannel, dtls at v3, ice at v4, interceptor, logging, randutil, rtcp, rtp, sctp, sdp at v3, srtp at v3, stun at v4, transport at v5 and turn at v5. Three requirements are external: sclevine/agouti, stretchr/testify and golang.org/x/net. Because the majors are staggered, there is no single version of Pion you can reason about; a security fix in DTLS and a feature in RTP arrive through different repositories at different cadences, and your build resolves all seventeen direct requirements together. Read go.mod as the upgrade surface before you read the feature list.

Pure Go is the headline, and getUserMedia is the exception that needs Cgo

One of the strongest claims in the README is that there is no Cgo usage, followed by a platform list that covers Windows, macOS, Linux, FreeBSD, iOS, Android and WebAssembly, across 386, amd64, arm, mips and ppc64. That claim is what lets a Go service compile into a WebAssembly target or run on a phone without a cross toolchain. Then the media section lists a getUserMedia implementation, and marks it as requiring Cgo. So the portability story holds for everything that receives media over the network, and a boundary exists where the library has to reach a capture device. If you are deploying to a platform where Cgo compilation is unacceptable, that entry in the feature list is the one to check against your requirements before you design around it.

A Go library that also carries a private package.json for browser work

The repository root contains a package.json that has nothing to do with distributing a JavaScript artefact. It is marked private, its single devDependency is @roamhq/wrtc, and its one runtime dependency is a request library pinned to an exact patch version rather than a range. The packageManager field pins yarn to a specific release with a hash. What this tells you is that the package.json is private tooling, not a published JavaScript package.

The examples directory is the widest description of the API you will find

The top-level files are the specification surface: datachannel.go and its siblings, dtlstransport.go, bundlepolicy.go, icecandidateinit.go, configuration.go, plus parallel files carrying a _js suffix for browser builds. The examples directory then shows how those files compose. There are several data channel examples, split between the simple case, flow control, detaching channels, and a create-time variant, plus one named for WHIP and WHEP style signalling. Connectivity examples cover a TCP-only path, a single-port variant, an ICE proxy and an ICE restart. Media examples cover playing files from disk, with variants for forward error correction, playlist control and renegotiation, plus simulcast and bandwidth estimation from disk, and the ORTC and insertable-streams paths. If you are evaluating whether a case is supported, this directory answers it faster than the prose does.

Security is two named cipher lists, and congestion control sits in an interceptor

The security section is specific enough to be checkable: DTLS v1.2 with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SRTP with SRTP_AEAD_AES_256_GCM and SRTP_AES128_CM_HMAC_SHA1_80, and hardware acceleration available for the GCM suites. Everything below the encryption layer is delegated to sibling modules rather than implemented here: NACK, sender and receiver reports and transport wide congestion control feedback link to pion/interceptor, while bandwidth estimation has an example in this repository and SettingEngine is documented in the webrtc/v4 GoDoc. So the cryptography is one code path with an enumerated set of suites, and the adaptive behaviour on a lossy link is something you pull in as a dependency and configure.

The README timings were measured on a dated laptop and are not a benchmark

Under the portability section the README publishes build and test timings, and it is careful about their provenance: the numbers were generated on an Intel Core i5-2520M at 2.50GHz, with building examples/play-from-disk reported at 0.66s user and 0.20s system, and the entire test suite at 25.60s user and 9.40s system across 1:16.69 total. That machine is a decade old, and the figures describe the project as it stood when they were taken, not your build. The tool offered for real measurement is separate: rtsp-bench is provided for performance work. Read the published figures as evidence that the test suite runs in about a minute rather than as a performance claim, and measure your own numbers if your use case depends on throughput.

Editorial conclusion

Pion fits a Go service that has to be a WebRTC endpoint rather than a browser: signalling servers, recording pipelines, gateways and test harnesses, where owning the whole stack including ICE, DTLS, SRTP and SDP is the point. Before you commit, read go.mod rather than the feature list, because your upgrade surface is fourteen Pion modules whose major versions move independently. Check that nothing you need is the getUserMedia path, which requires Cgo and contradicts the pure Go headline. And treat the README timings as a historical measurement from a dated Intel Core i5-2520M machine, not as a benchmark. The default branch was last pushed on 2026-11-02.

Frequently asked questions

Official sources

1. License: MIT
2. pion/webrtc on GitHub
3. Project website
4. README
5. Releases