C++调用WebRTC实现实时音视频通信方法

需自行编译WebRTC C++库，严格使用GN/Ninja构建链；初始化PeerConnectionFactory时须传入有效NetworkManager和PortAllocator；音视频Track必须在正确线程创建并操作；ICE连通需显式配置STUN/TURN服务器。

怎么开始用 WebRTC C++ 原生库跑通第一个音视频通话

WebRTC C++ 库不是装个头文件就能调 PeerConnection 的——它没有稳定 ABI，不提供预编译二进制，必须自己编译。官方只保证 Ninja + GN + Chromium 构建链能跑通，其他构建系统（CMake、Bazel）要么靠社区补丁，要么掉坑里。

实操建议：

• 直接 clone webrtc/src 仓库，用 fetch --nohooks webrtc 拉代码，再 gclient sync 补全依赖
• 必须用 gn gen out/Default --args='is_debug=false is_component_build=false target_cpu="x64"' 生成构建目录；target_os 要显式设为 "win" / "mac" / "linux"，否则 Linux 下可能漏 libX11
• 别碰 webrtc.lib（Windows）或 libwebrtc.a（Linux/macOS）直接链接——它依赖大量未导出符号，得连同 out/Default/obj/webrtc 下的中间静态库一起链接，顺序不能错

为什么 CreatePeerConnection 总返回空指针

根本原因：没初始化 PeerConnectionFactoryInterface，或者初始化时传了空的 NetworkManager / PacketRouter。WebRTC C++ 层不自动创建底层网络栈，所有依赖都得手动 new 出来并传入。

常见错误现象：

• 调用 factory->CreatePeerConnection(...) 返回 nullptr，但没报错日志
• 日志里出现 Failed to initialize network manager 或 Cannot create peer connection without valid network manager

实操建议：

• 先调 rtc::InitializeSSL()（即使不用 DTLS，也得初始化 OpenSSL/BoringSSL）
• 用 std::unique_ptr nm(new cricket::FakeNetworkManager()) 快速验证逻辑（生产环境换 BasicNetworkManager）
• PeerConnectionFactoryInterface::Create 第二个参数必须是非空 cricket::PortAllocatorFactoryInterface*，哪怕只是 new cricket::BasicPortAllocatorFactory()

音视频 track 怎么塞进 PeerConnection 不崩溃

崩溃主因是线程错乱：AudioTrackInterface 和 VideoTrackInterface 必须在 WorkerThread 上创建，且所有 addTrack/removeTrack 调用必须在 SignalingThread 上执行。WebRTC C++ 不做线程保护，越界访问直接 SIGSEGV。

使用场景：

• 本地采集：用 AudioDeviceModule + VideoCaptureModule 拿原始帧，再喂给 AudioSourceInterface / VideoSourceInterface
• 自定义源：继承 AudioTrackSource 或 VideoTrackSource，重写 OnData / OnFrame，但注意 buffer 生命周期——WebRTC 不拷贝数据，你得确保内存不提前释放

实操建议：

• 别用 MediaStreamTrack::CreateAudioTrack 直接传裸指针，改用 AudioTrackInterface::Create(..., std::make_unique())
• addTrack 前检查 pc->signaling_state() == PeerConnectionInterface::kStable，否则会触发断言
• Linux 下若用 V4L2 采集，记得在 VideoCaptureModule::Create 里传 cricket::VideoCapturer::Options{.device_id = "/dev/video0"}，否则默认找 X11 屏幕捕获

ICE 连接失败但 SDP 交换看着完全正常

SDP 对得上 ≠ 能通。WebRTC C++ 默认不启用 STUN/TURN，PeerConnection 创建时若没配 PeerConnectionInterface::IceServers，就只走 host candidate，内网都可能不通（尤其 Docker 容器、NAT 后设备）。

性能与兼容性影响：

• 没 STUN：host candidate 只暴露内网 IP，跨子网必 fail
• 没 TURN：对称 NAT 场景下，即使有公网 IP 也无法穿透
• Linux 下若没装 libsrtp，DTLS 握手会静默失败，日志只显示 ICE failed，无具体原因

实操建议：

• 至少加一个公共 STUN：{.urls = {"stun:stun.l.google.com:19302"}}，验证基础连通性
• 检查 pc->ice_gathering_state() 是否到 kComplete，没到说明 candidate 没收全——可能是 SetConfiguration 漏了 bundle_policy 或 rtcp_mux_policy
• 开启详细日志：rtc::LogMessage::LogToDebug(rtc::LS_INFO)，搜 candidate: 看是否真生成了 srflx/relay candidate

真正麻烦的是线程模型和生命周期管理——PeerConnection、MediaStream、Track 全部非线程安全，析构顺序错了，哪怕只差一行 delete，core dump 就在那儿等你。