[webrtc] Add a new port

[bc-lee]

• Changes comply with the maintainer guide.
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Fixes #6205
Fixes #12134
Fixes #22646

Summary

This PR adds a new webrtc port.

The port builds upstream WebRTC with its native GN-based build system, unbundles most third-party dependencies to existing vcpkg ports, and installs a consumable webrtc::webrtc CMake package.

Because WebRTC is a large Chromium-related project with a non-trivial source layout and build graph, this port intentionally takes a synthetic-tree approach for a number of third_party and build-integration pieces instead of trying to maintain a separate non-GN build system.

What is WebRTC?

WebRTC is a free and open project that provides real-time communication capabilities for audio, video, and data exchange.

People sometimes call the native C++ codebase libwebrtc to distinguish it from the browser WebRTC API, but upstream itself uses the webrtc name for the project and source tree.

Design decisions

Use GN

GN is the native build system for Chromium-related projects.

Unlike some related projects such as V8 or Skia, WebRTC does not have a maintained alternative build system such as CMake. Also, the source tree is large enough that maintaining a separate build description in vcpkg would be unrealistic and high-maintenance.

For that reason, this port builds WebRTC with GN directly.

Synthetic third_party tree

To build WebRTC, upstream expects a large set of related source trees, especially under Chromium third_party layout.

In practice, for vcpkg packaging we do not need most of that tree:

• we are packaging the library, not upstream tests/tools/examples
• many bundled third-party dependencies already exist as vcpkg ports
• several optional components can be disabled entirely

This port therefore unbundles most dependencies and synthesizes the minimum GN-visible tree surface needed to keep the upstream build working while using vcpkg-provided dependencies.

That is the main reason this port looks more complex than a typical CMake port.

To maintain the synthetic third_party tree, I also added small Python helper scripts and tests for them.

Dependency model

This port uses vcpkg ports for major third-party dependencies such as:

• abseil
• openssl
• libsrtp
• opus
• libvpx
• libyuv
• aom
• jsoncpp
• pffft

Unsupported or unneeded optional pieces are disabled through GN args and patches rather than being left to accidental host discovery.

H.264 support

H.264 support is intentionally deferred for now.

Although H.264 is one of the most commonly used video codecs, enabling it in WebRTC requires deeper integration work around openh264 and ffmpeg, and would need more invasive tree patching than the current port.

There is also a licensing concern: H.264 is patent-encumbered, and using OpenH264 from source does not automatically give downstream users the same protection Cisco provides for their distributed binaries.

For now, I prefer to leave H.264 unsupported until there is a cleaner technical and policy story for it.

Supported triplets

The current supports set in ports/webrtc/vcpkg.json is:

• Windows:
  • x86-windows
  • x64-windows
  • arm64-windows
  • and corresponding -static / -static-md variants as supported by the port metadata
• Linux:
  • x64-linux
  • arm64-linux
• macOS:
  • x64-osx
  • arm64-osx

These triplets are supported by the port, but the validation depth is not identical across them.

Current validation I ran during bring-up includes:

• x64-linux
• arm64-linux
• x64-windows
• x64-windows-static-md
• arm64-osx

I also added support for arm64-windows, but I have not personally validated that triplet on real hardware.

Explicitly deferred

For now, this port explicitly does not support mobile targets.

I want to make the first desktop/server port solid before expanding further.

Android is especially non-trivial because upstream WebRTC ships Java sources that are not just a thin wrapper layer. Some important functionality, including parts of media codec integration, depends on that Android-side Java stack. That makes Android support significantly more involved than just enabling another GN target.

Validation

To make review easier, I also included a small sample consumer project for the port:

https://github.com/bc-lee/vcpkg-webrtc-sample

I used that sample during bring-up to validate package consumption in addition to direct vcpkg install testing.

Notes

This is still an early draft of the port.

Because the project is large and the packaging strategy is more involved than usual, I would like feedback from both maintainers and real users before treating the current shape as final. CI coverage and wider triplet usage will probably expose additional cleanup opportunities.

[bc-lee]

So far, I’ve fixed all CI issues, including the Linux audio backend ones.

Apparently, I’ve ended up with the largest port in the tree by text line count:

lines    files    port
4245     30       webrtc
4146     19       nettle
3015     18       llvm
2852     18       ffmpeg
2528     38       qt5-base
2468     7        winpcap
2388     32       qtbase
2228     4        dbow3
2107     37       vtk
2003     3        google-cloud-cpp
1944     6        openni2
1828     11       vcpkg-make
1817     24       opencv3
1803     22       opencv4
1775     10       aws-sdk-cpp

[Copilot]

Pull request overview

Adds a new webrtc port to vcpkg that builds upstream WebRTC via GN/Ninja, synthesizes a minimal Chromium-style third_party surface to unbundle dependencies to existing vcpkg ports, and installs a consumable webrtc::webrtc CMake package.

Changes:

• Introduces ports/webrtc with portfile, manifest, generated GN helper scripts/tests, and CMake package config.
• Adds a set of upstream/build patches to make GN-based builds work across supported triplets and to unbundle/disable optional components.
• Updates the version database (baseline + new versions entry) for the new port.

Reviewed changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
versions/w-/webrtc.json	Adds the version entry for the new webrtc port.
versions/baseline.json	Adds webrtc to the baseline registry.
ports/webrtc/vcpkg.json	Defines the new port metadata, dependencies, and Linux audio backend features.
ports/webrtc/portfile.cmake	Implements GN/Ninja build, synthetic-tree generation, and install logic.
ports/webrtc/source-manifest.cmake	Pins upstream WebRTC + auxiliary repos (build/buildtools/rnnoise).
ports/webrtc/webrtcConfig.cmake.in	Provides the exported webrtc::webrtc CMake package/target.
ports/webrtc/package-remove-paths.txt	Lists header subtrees pruned from the installed include tree.
ports/webrtc/absl-labels.txt	Manifest of Abseil GN labels to synthesize against CMake-exported Abseil libs.
ports/webrtc/generate_external_absl.py	Generates a synthetic third_party/abseil-cpp GN tree and CMake target lists.
ports/webrtc/generate_external_absl_test.py	Unit tests for the Abseil GN tree generator.
ports/webrtc/generate_external_third_party.py	Generates synthetic GN-visible trees for multiple third_party deps.
ports/webrtc/generate_external_third_party_test.py	Unit tests for the generic third-party tree generator.
ports/webrtc/webrtc-0001-disable-perfetto-when-off.patch	Adjusts Perfetto linkage/config behavior based on build flags.
ports/webrtc/webrtc-0002-export-enable-media-with-defaults.patch	Exports additional GN targets needed for consumption.
ports/webrtc/webrtc-0003-fix-rtp-config-optional.patch	Fixes optional/std::optional usage for MSVC compatibility.
ports/webrtc/webrtc-0004-use-upstream-rnnoise.patch	Switches to upstream rnnoise implementation model and integration approach.
ports/webrtc/webrtc-0005-use-external-openssl.patch	Enables external OpenSSL library path wiring for GN builds.
ports/webrtc/webrtc-0006-make-dav1d-decoder-deps-conditional.patch	Makes dav1d-related deps conditional on a GN arg.
ports/webrtc/webrtc-0007-fix-rtp-packet-info-eq-for-msvc.patch	Replaces defaulted operator== to support MSVC configurations lacking it.
ports/webrtc/webrtc-0008-fix-audio-device-core-win-goto-scope.patch	Fixes MSVC goto/scope issues and variable initialization in Windows audio device code.
ports/webrtc/webrtc-0009-fix-avx2-intrinsics-for-msvc.patch	Fixes AVX2 intrinsic code that relies on non-MSVC vector element access.
ports/webrtc/webrtc-0010-disable-arm-denormal-disabler-for-msvc.patch	Avoids ARM denormal disabler paths for MSVC where unsupported.
ports/webrtc/webrtc-0011-make-linux-audio-backends-optional.patch	Makes ALSA/PulseAudio backends optional and controlled via GN args.
ports/webrtc/rnnoise-0001-fix-neon-reinterpret-for-msvc.patch	Adjusts NEON reinterpret usage for MSVC compatibility in rnnoise.
ports/webrtc/build-0001-drop-module-deps-from-toolchain-invocations.patch	Removes module deps from tool invocations and disables module tool commands.
ports/webrtc/build-0002-fix-apple-arflags-usage.patch	Fixes Apple ar/libtool flag usage in toolchain definitions.
ports/webrtc/build-0003-disable-fno-lifetime-dse.patch	Drops a compiler flag that may be risky/undesired for this packaging context.
ports/webrtc/build-0004-disable-sanitize-c-array-bounds.patch	Disables array-bounds sanitizer flags in build toolchain config.
ports/webrtc/build-0005-disable-sanitize-return.patch	Disables return sanitizer flags in build toolchain config.
ports/webrtc/build-0006-skip-local-vs-debugger-copy.patch	Avoids copying Windows debugger DLLs when using a local toolchain setup.
ports/webrtc/build-0007-fix-windows-pdb-commands.patch	Fixes MSVC PDB command-line handling in GN toolchain templates.
ports/webrtc/build-0008-disable-crel-on-linux-arm64.patch	Disables --crel assembler flags (currently unconditionally).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

INTERFACE_LINK_OPTIONS and INTERFACE_COMPILE_DEFINITIONS embed generator expressions that contain semicolons inside the expression body (e.g. $<$<PLATFORM_ID:Darwin>:...;...> and $<$<PLATFORM_ID:Windows>:...;...>). CMake treats semicolons as list separators at configure time, so these expressions will be split into multiple list items and become syntactically invalid (dangling > fragments) and/or apply definitions unconditionally. Please rewrite these as multiple generator expressions without semicolons, or escape internal separators with $<SEMICOLON>, so the platform-conditional definitions/options evaluate correctly.

[Copilot]

asm_obj_extension is set based on is_win, but it is never referenced later in the nasm_assemble template. This makes the template misleading and can mask Windows-specific object naming requirements.

Suggested change

	if (is_win) {
	asm_obj_extension = "obj"
	} else {
	asm_obj_extension = "o"
	}

[Copilot]

The NASM template hard-codes .o for assembled object outputs. On Windows this should generally use .obj (or at least consistently use asm_obj_extension) to avoid toolchain/linker incompatibilities when consuming these objects.

Suggested change

	outputs = [ "$target_out_dir/$source_set_name/{{source_name_part}}.o" ]
	outputs = [ "$target_out_dir/$source_set_name/{{source_name_part}}.${asm_obj_extension}" ]

[BillyONeal]

Honestly when I started reviewing this I saw the 4k lines and thought I would hate it but most of this looks reasonable. I made some nitpick comments but by and large this is probably mergable.

I also included a small sample consumer project for the port

Thank you for the demonstration! It helps a lot on justifying adding a 4k lines thing.

Some thoughts:

• Being not normally Python programmers, I fear adding these big python scripts that we aren't really going to truly understand. I'm willing to take it mostly "on faith" given passing tests that they do what is expected, but I would appreciate if we could get others to confirm their sanity.
• This is adding yet another thing that is "sucked out" of chromium and needs vcpkg_from_git and is thus not asset cachable. However, unlike most of the other ports like angle it seems like this might use a substantial fraction of a chromium tree. Would it make sense to try to use https://github.com/chromium/chromium + vcpkg_from_github to allow those things to be cached? (To be clear, I'm just asking, I have not investigated if this would be a good idea.)
• What impact does this have on those other chromium children like angle, dawn, etc.?

[BillyONeal]

This seems to explicitly revert something upstream explicitly thoughtfully considered and added. Can you explain?

Ditto the next several patches.

[BillyONeal]

Is this submitted upstream? It's kind of a lot of edited product code which makes it borderline under https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#patching

[BillyONeal]

Why do you need this change? I'm nervous about it because it explicitly does silent bad code if the members update in the future.

[bc-lee]

I checked whether we could drop this patch and rebuilt webrtc:x64-windows without it.

With MSVC 19.44.35224 (VS 2022 Community, toolset 14.44.35207), the build fails in api/rtp_packet_info.cc on upstream’s defaulted free operator==:

../src/5931ef8cc1-5a7e580849.clean/api/rtp_packet_info.cc(77): error C2610: 'bool webrtc::operator ==(const webrtc::RtpPacketInfo &,const webrtc::RtpPacketInfo &)': is not a special member function or comparison operator which can be defaulted`

So this patch is still needed for our current Windows/MSVC build.

[BillyONeal]

Can you minimize the patch by not including this whitespace change?

[BillyONeal]

This is a big patch but because it's just moving lines that are already in the file to the top of their block I think it's acceptable.

[BillyONeal]

The original casts seem almost certainly incorrect and maybe the real reason they went through void* first is to fix a const problem?

[BillyONeal]

Where did these blobs of code come from?

[BillyONeal]

Suggested change

	args.push_back(const_cast<char*>("{tool_path}"));
	char tool_path_buffer[] = "{tool_path}";
	args.push_back(tool_path_buffer);

It's not safe to make a literal mutable.

[BillyONeal]

That's true but I'm not sure the comment is meaningful. After all it would also trigger for e.g. arm64-windows, or any custom triplet where VCPKG_CRT_LINKAGE is set to dynamic.

[BillyONeal]

Instead of making up a custom format and then trying to parse that out, why don't we just record this in the "exploded" form to begin with?

[dg0yt]

Isn't this something the skia port handles with declare_external_from_git/get_externals(${required_externals})?

[dg0yt]

The CMake config and targets shall be prefixed as unofficial.

I wish we could share more helper functions between the gn-based ports.

[dg0yt]

Isn't this something the skia port handles with declare_external_from_git/get_externals(${required_externals})?

[dg0yt]

I really dislike this being in a different file. There is no need to add variables for a single use.

[dg0yt]

This doesn't need to be included explicitly - having a dependency on that port is sufficient for the effect.

[dg0yt]

Do not use REQUIRED with find_dependency.

[bc-lee]

Thanks for the review!

Since this is a large patch set and I’ve been working on it for almost four weeks, some patch and compiler-flag comments still need cleanup. I also want to make sure each patch has a correct explanation and is revalidated, at least on x64-windows, x64-linux, and arm64-osx. After that, I’ll update the PR with cleaned-up comments and refreshed patches where needed.

[bc-lee]

• This is adding yet another thing that is "sucked out" of chromium and needs vcpkg_from_git and is thus not asset cachable. However, unlike most of the other ports like angle it seems like this might use a substantial fraction of a chromium tree. Would it make sense to try to use https://github.com/chromium/chromium + vcpkg_from_github to allow those things to be cached? (To be clear, I'm just asking, I have not investigated if this would be a good idea.)

I’m not a fan of googlesource.com (Gitiles), since its archive handling is not especially stable, but for WebRTC we do not really have a better option.

The GitHub archive for chromium/chromium is about 1.4 GB, and it does not give us a usable third_party/webrtc source tree anyway.

By comparison, downloads/webrtc-aa217206b9ce8b929dc56d112d670a5931ef8cc1.tar.gz is only about 40 MB after fetching the WebRTC history and archiving the needed revision. A local clone of WebRTC has a .git directory of roughly 500 MB. There is very little reason to choose the GitHub Chromium archive for this.

• What impact does this have on those other chromium children like angle, dawn, etc.?

Among the other Chromium-based projects in vcpkg, skia is the main one that also makes heavy use of gn and a large set of third-party dependencies. Some smaller pieces, such as dependency and external-resolution utilities, could probably be shared if we do that carefully. However, skia itself is already quite complex, so while developing the WebRTC port I did not want to modify that part of the tree without a clearer plan. That is why I kept the WebRTC implementation separate for now.

I think there is room to share some code in the future, but because vcpkg is intentionally modular, I am not yet sure what the right abstraction would be without risking breakage or weakening that modularity. For now, I would prefer to keep the code separate.

For the other libraries that use CMake as their native build system in vcpkg, such as dawn and angle, this PR should not affect their current build flow directly.

[bc-lee]

Note: I’ve made the local changes and submitted them to CI, but I don’t have time to add detailed review replies right now since it’s morning in my time zone and I need to get ready for work. I’ll follow up later today (or tomorrow) with comment-by-comment responses.