企业官网建设流程全解析

1. 项目概述：为什么“媒体能力协商”是WebRTC稳定通话的隐形地基

你有没有遇到过这样的情况：两个设备明明都支持高清视频，但一打开视频通话，画面却自动降成360p，帧率卡在15fps，连对方眨眼都看不清？或者更糟——双方设备列表里明明都有H.264编码器，可连接建立后日志里却赫然写着no common codec found，直接黑屏失败。这不是网络问题，也不是信令故障，而是WebRTC最底层、最沉默却最关键的环节出了岔子：媒体能力协商（Media Capabilities Negotiation）。它不像SDP交换那样显眼，也不像ICE连通性检查那样有明确日志，但它决定了整个会话的“画质天花板”和“功能下限”。我带过的几个团队，在做跨终端兼容性优化时，80%以上的音视频异常最终都回溯到这个环节——不是协议没跑通，而是两边根本没谈拢“能干什么”。

这个标题里的“WebRTC源码研究（29）”，说明它是一系列深度源码剖析中的第29篇，意味着读者已经具备一定基础：知道PeerConnection是什么，能看懂SDP结构，甚至可能调试过信令流程。但“媒体能力协商”恰恰是很多开发者跳过的盲区——大家习惯把SDP当黑盒，copy-paste模板，改几行a=rtcp-fb就上线。可一旦遇到某款国产安卓平板死活播不出音频，或是某款新发布的MacBook Pro在Safari里无法启用硬件编码，这种“模板思维”立刻崩盘。真正的问题藏在RTCRtpTransceiver的setCodecPreferences()调用之后，在PeerConnection::CreateOffer()内部触发的MediaSessionDescriptionFactory::CreateMediaDescription()深处，在VideoEncoderFactory与AudioEncoderFactory的联合筛选逻辑里。它不暴露在API层，却主宰着每一帧数据的命运。

所以这篇内容不是教你怎么写一个Hello World的WebRTC应用，而是带你钻进Chromium 120+版本的WebRTC C++源码腹地，看清媒体能力从“设备声明”到“会话共识”的完整炼金术。你会明白：为什么Chrome默认禁用VP9而Firefox偏爱它；为什么iOS Safari至今不支持AV1；为什么同一个RTCPeerConnection实例，在createOffer()和createAnswer()时协商出的编解码器列表可能完全不同；以及最关键的一点——当你想强制启用某个编码器（比如让老旧Android设备也用H.264 baseline profile），该在源码哪一行打patch，又该规避哪些坑。这不仅是技术细节，更是构建高可用音视频系统的底层认知框架。

2. 媒体能力协商的整体设计与思路拆解

2.1 协商不是“选一个”，而是“建一张能力交集图”

很多人误以为媒体能力协商就是“客户端A说我要用H.264，客户端B说我也支持H.264，OK，成交”。这是对WebRTC设计哲学的根本性误解。真实过程远比这复杂：它不是简单的布尔匹配，而是一场多维度、分层次、带优先级的能力集合求交集运算。这个“集合”包含至少五个正交维度：

• 编解码器类型（Codec Type）：audio/video，这是最外层过滤。
• 具体编码器（Codec Name）：H264、VP8、VP9、AV1、OPUS、ISAC等，每个名称背后对应一套RFC标准。
• 编码参数（Codec Parameters）：H264的profile-level-id（如42e01f代表Baseline Profile Level 3.1）、VP9的profile（0/1/2）、OPUS的stereo和sprop-stereo等。这些参数决定了硬件是否能加速、网络能否承受。
• 传输能力（Transport Capability）：是否支持RTX重传、FEC前向纠错、NACK负反馈，这些依赖底层传输栈支持。
• RTP头扩展（RTP Header Extension）：如abs-send-time、transport-wide-cc-01，影响拥塞控制精度，但需要两端都声明支持才能启用。

WebRTC的协商引擎（核心在webrtc/sdk/objc/Framework/Classes/PeerConnection/RTCMediaConstraints.m和C++层的webrtc/media/engine/webrtc_media_engine.cc）会将这些维度全部展开，生成一张“能力矩阵”。例如，一个现代Chrome浏览器上报的能力可能包含：

• H264:profile-level-id=42e01f,level-asymmetry-allowed=1,packetization-mode=1
• VP9:profile=0,level=3.1,frame-rate=30
• AV1:profile=0,level=3.1,tier=0
• OPUS:stereo=1,sprop-stereo=1,maxplaybackrate=48000

而一台老款Android 7设备可能只上报：

• H264:profile-level-id=42001f,packetization-mode=0
• OPUS:stereo=0

协商引擎会逐项比对：profile-level-id=42e01fvs42001f——前者要求Baseline Level 3.1，后者仅支持Level 1.3，不匹配；packetization-mode=1vs0——前者支持分片打包，后者只支持单NALU，不匹配。最终交集只剩H264（降级到42001f）和OPUS（降级到stereo=0）。这个过程不是靠运气，而是由webrtc/media/base/media_constants.cc中预定义的严格兼容规则驱动。

提示：profile-level-id的十六进制值不是随意写的。它按ITU-T H.264 Annex A规则编码：前6位是Profile ID（42=Baseline,64=Main,6e=High），后18位是Level（001f=Level 1.3,e01f=Level 3.1）。源码里H264ProfileLevelId::IsSameProfile()函数会做位运算解析，而非字符串比较。

2.2 为什么必须分“Offer/Answer”两阶段？单次协商不行吗？

这是WebRTC区别于传统SIP的关键设计。很多初学者试图用createOffer()生成一个“全能SDP”，再发给对方，期望对方无脑接受。这在WebRTC里注定失败，因为Offer和Answer承载着完全不同的协商语义：

• Offer（发起方）：表达“我能提供什么”。它基于本地RTCPeerConnection的addTransceiver()配置、setCodecPreferences()显式设置、以及RTCRtpCapabilities的默认能力。注意，Offer不承诺“我一定会用”，只是亮出底牌。例如，你调用pc.addTransceiver('video', {direction: 'sendrecv'})，Chrome会把所有已知视频编码器都放进Offer，哪怕你实际只打算发一路1080p。

• Answer（应答方）：表达“我愿意接受并使用什么”。它必须是Offer中能力的子集，且要根据自身策略做裁剪。例如，Firefox收到含AV1的Offer，但其AV1解码器仅支持软件解码（CPU占用高），它可能主动剔除AV1，只保留VP9和H264，以保障用户体验。这个裁剪逻辑在webrtc/p2p/base/session_description.cc的JsepSessionDescription::Initialize()中执行。

这种分离设计解决了两个核心矛盾：

1. 异步能力发现：设备A在生成Offer时，可能还不知道设备B的实时负载（如GPU温度过高需降级编码），Answer阶段给了B动态决策的空间。
2. 策略隔离：企业级应用常需服务端策略干预（如禁止AV1以节省带宽）。服务端可在转发Answer前，安全地移除特定编码器，而不影响Offer的完整性。

我曾在一个跨国会议系统中踩过坑：前端工程师为追求画质，在Offer里硬编码了a=fmtp:100 profile-level-id=640032（High Profile Level 5.0），结果导致大量低端手机无法生成Answer，因为它们的H264解码器最高只支持Level 3.1。后来我们改为在Answer生成后，由信令服务器注入a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid，再由客户端SDK动态降级profile-level-id，问题才彻底解决。这印证了WebRTC的设计智慧：Offer是能力声明，Answer才是能力契约。

2.3 源码架构：从JS API到底层C++的四层穿透

要真正理解协商过程，必须看清WebRTC的分层架构。它不是单体代码，而是典型的“胶水层+引擎层+平台层”设计：

整个协商链路是：JS调用createOffer()→ JS Binding层转为C++PeerConnectionInterface::CreateOffer()→ Session层创建空JsepSessionDescription→ Media Engine层调用MediaSessionDescriptionFactory::CreateMediaDescription()，此时它会：

1. 从VideoEncoderFactory获取本地所有视频编码器能力（GetSupportedFormats()）
2. 从AudioEncoderFactory获取所有音频编码器能力
3. 解析远端Offer中的m=行，提取对方声明的能力
4. 对每个m=行，执行FindMatchingCodec()算法，计算交集
5. 按codec_preferences或默认优先级排序，生成Answer的m=行

这个过程里，FindMatchingCodec()是真正的“大脑”。它不在一个函数里完成，而是分散在webrtc/media/engine/webrtc_media_engine.cc的WebRtcMediaEngine::FindMatchingVideoCodec()和WebRtcMediaEngine::FindMatchingAudioCodec()中。它们会遍历所有候选编码器，对每个参数做精确匹配或向下兼容判断。例如，对H264的level-asymmetry-allowed，如果Offer设为1，Answer可设为0（允许不对称），但反之不行。

3. 核心细节解析与实操要点

3.1 编解码器能力的“三重来源”与优先级冲突

一个设备能支持哪些编解码器，并非铁板一块，而是来自三个动态叠加的来源，且存在明确的优先级覆盖关系。忽略这一点，是导致协商结果不符合预期的最常见原因。

第一重：平台原生能力（Lowest Priority）
这是最底层的基础，由操作系统和硬件决定。WebRTC在启动时会调用平台适配器扫描可用编解码器：

• Android：通过MediaCodecList查询video/avc、video/hevc等MIME类型，解析getCapabilitiesForType()返回的CodecCapabilities，提取profileLevels数组。
• iOS：调用VTCompressionSessionCreate()和VTDecompressionSessionCreate()，尝试创建不同kVTCompressionPropertyKey_ProfileLevel的会话，成功即表示支持。
• Windows：枚举DirectX Video Acceleration (DXVA) 或 Windows Media Foundation (WMF) 支持的GUID。

这部分能力写死在webrtc/sdk/android/src/jni/jni_generator.cc或webrtc/sdk/ios/src/ios_video_toolbox.mm中，生成VideoEncoderFactory::GetSupportedFormats()的初始列表。特点是：只读、不可控、但最真实。如果你的Android设备芯片不支持H265，这里永远不会有HEVC条目。

第二重：运行时配置（Medium Priority）
通过RTCPeerConnection构造时的configuration对象或setConfiguration()动态注入：

const pc = new RTCPeerConnection({ encodedInsertableStreams: true, // 启用E2EE bundlePolicy: "max-bundle", // 影响m=行合并 rtcpMuxPolicy: "require" // 强制RTCP复用 }); // 或运行时 pc.setConfiguration({ sdpSemantics: "unified-plan", // 必须，否则不走新协商流程 iceTransportPolicy: "relay" // 影响candidate类型 });

这些配置不直接添加编解码器，但会过滤掉不兼容的选项。例如，iceTransportPolicy: "relay"会使协商引擎自动剔除需要hostcandidate的编码器（某些旧版VP8实现）。

第三重：显式偏好设置（Highest Priority）
这是开发者可控的最强力手段，通过RTCRtpTransceiver.setCodecPreferences()或RTCPeerConnection.createOffer({offerToReceiveVideo: true})的voiceActivityDetection等参数指定：

const transceiver = pc.addTransceiver('video', { direction: 'sendrecv', streams: [stream] }); // 强制只用H264，且必须是Constrained Baseline transceiver.setCodecPreferences([ { mimeType: 'video/H264', clockRate: 90000, parameters: { 'profile-level-id': '42c01f', 'level-asymmetry-allowed': '1' } } ]);

这个调用会直接修改Transceiver内部的preferred_codecs_列表，覆盖所有其他来源。关键点在于：setCodecPreferences()必须在createOffer()之前调用，且对每个Transceiver独立生效。我曾见过团队在createOffer()后才调用它，结果协商完全不受影响——因为Offer生成时preferred_codecs_还是空的。

注意：setCodecPreferences()的参数是RTCRtpCodecCapability对象，其parameters字段必须是合法的SDP fmtp参数。profile-level-id值必须是6位十六进制字符串，且符合H.264 Annex A规范。传入'42e01f'（Level 3.1）给只支持Level 1.3的设备，会导致协商失败，而非自动降级。

3.2 SDP中的“隐性协商”：RTP头扩展与FEC的连锁反应

媒体能力协商不仅关乎编解码器，还深度耦合RTP传输层特性。一个常被忽视的细节是：RTP头扩展（Header Extension）和FEC（前向纠错）的启用，会反向影响编解码器的选择。这是因为它们共享同一套RTP payload type空间，且协商逻辑相互依赖。

以abs-send-time（绝对发送时间）为例，它在SDP中表示为：

a=extmap:1 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

这个extmap声明告诉对方：“我支持transport-wide CC扩展，ID为1”。但它的启用有两个前提：

1. 双方都声明了该extmap：如果Offer有a=extmap:1 ...，Answer里没有，此扩展即失效。
2. 所选编解码器必须支持该扩展：并非所有编码器都兼容transport-wide-cc-01。例如，VP8的RFC 7741明确支持，但某些定制H264封装可能未实现。

更复杂的是FEC。WebRTC支持两种FEC机制：

• ULPFEC（UDP-Lite FEC）：通过a=fmtp:126 apt=120;useinbandfec=1声明，其中apt=120指向基础编码器（如VP8 payload type 120）。
• FlexFEC（Flexible FEC）：通过a=rtpmap:127 flexfec-03/90000独立声明。

协商时，引擎会检查：如果Offer中VP8（pt=120）启用了useinbandfec=1，那么Answer中若选择VP8，就必须保持useinbandfec=1，否则FEC包无法解码。但如果Answer想选H264，而H264的FEC实现不成熟（Chrome 115前H264-FEC有严重丢包），引擎会主动放弃H264，降级回VP8，以保障FEC可用性。这个逻辑在webrtc/media/engine/webrtc_media_engine.cc的WebRtcMediaEngine::FindMatchingVideoCodec()中，通过codec.has_fec标志位控制。

实操中，我建议在高丢包网络（如4G）下，显式禁用FEC以换取更多编解码器选择空间：

// 创建Offer时禁用FEC const offerOptions = { offerToReceiveAudio: true, offerToReceiveVideo: true, voiceActivityDetection: false // 关键：禁用VAD，减少FEC依赖 }; pc.createOffer(offerOptions).then(offer => { // 手动移除SDP中的FEC相关行 offer.sdp = offer.sdp.replace(/a=fmtp:\d+.*useinbandfec=1/g, ''); offer.sdp = offer.sdp.replace(/a=rtpmap:\d+ flexfec-\d+/g, ''); return pc.setLocalDescription(offer); });

这招在某海外直播App中救了急：他们的CDN节点不支持FlexFEC，导致大量Android端黑屏。手动清理FEC后，协商自动切到VP8+ULPFEC，画质虽略降，但100%可用。

3.3 “动态降级”机制：当协商失败时的保底策略

WebRTC不会因一次协商失败就放弃。它内置了一套精妙的“动态降级（Dynamic Fallback）”机制，确保在极端情况下仍有基础通信能力。理解这套机制，是设计高鲁棒性系统的基石。

降级触发条件有三类：

• 硬性失败：Offer/Answer语法错误，如m=行缺失c=连接地址，或a=rtpmap参数格式错误。此时setLocalDescription()直接reject。
• 软性失败：能力交集为空，如Offer含AV1，Answer设备无AV1解码器。此时WebRTC不会报错，而是静默降级到下一个可用编解码器。
• 运行时失败：连接建立后，检测到编码器初始化失败（如VideoEncoder::InitEncode()返回WEBRTC_VIDEO_CODEC_ERR_PARAMETER）。此时触发OnEncoderError()回调，PeerConnection会尝试切换到fallback_encoder。

源码中，软性降级的核心逻辑在webrtc/media/engine/webrtc_media_engine.cc的WebRtcMediaEngine::FindMatchingVideoCodec()函数末尾：

// 如果首选编码器不匹配，尝试列表中下一个 for (size_t i = 0; i < supported_formats.size(); ++i) { const auto& format = supported_formats[i]; if (MatchCodec(format, remote_codec)) { return format; // 找到第一个匹配的即返回 } } // 全部不匹配？返回空，触发上层降级 return absl::nullopt;

注意，它返回的是第一个匹配的，而非最优的。这意味着supported_formats的顺序至关重要。Chrome的默认顺序是：VP8 > H264 > VP9 > AV1（视频），OPUS > ISAC > G722（音频）。所以即使AV1画质更好，只要VP8匹配，就绝不会选AV1。

要利用好降级，必须掌握两个技巧：

1. 控制supported_formats顺序：通过setCodecPreferences()显式排序。例如，强制H264优先于VP8：

   transceiver.setCodecPreferences([ { mimeType: 'video/H264', ... }, { mimeType: 'video/VP8', ... } ]);

2. 提供“兜底编码器”：在addTransceiver()时，为sendEncodings配置多个scaleResolutionDownBy，让编码器能在分辨率/帧率上动态缩放。例如：

   pc.addTransceiver('video', { sendEncodings: [ { scaleResolutionDownBy: 1 }, // 1080p { scaleResolutionDownBy: 2 }, // 540p { scaleResolutionDownBy: 4 } // 270p（保底） ] });

   当网络拥塞时，VideoStreamEncoder会自动切换到更低分辨率的编码路径，无需重新协商SDP。

我曾在一个教育App中部署此策略：主讲人用MacBook Pro开1080p，学生用千元安卓机，协商后自动降为270p@15fps，但语音始终流畅。用户感知是“画质一般”，而非“卡顿黑屏”，体验差距巨大。

4. 实操过程与核心环节实现

4.1 从零开始：在Chrome DevTools中追踪协商全过程

脱离调试工具谈源码是纸上谈兵。以下是在Chrome 120+中，实时监控媒体能力协商的完整步骤。这不是理论，而是我每天都在用的工作流。

第一步：开启WebRTC Internals面板

1. 访问chrome://webrtc-internals
2. 点击右上角“Start Recording”（录制图标）
3. 在你的WebRTC应用中触发createOffer()（如点击“开始通话”）

第二步：定位关键日志流
在webrtc-internals页面，你会看到多个Tab：

• PeerConnections：显示所有RTCPeerConnection实例，点击目标连接的pc_id。
• Stats：实时统计，但协商细节在此处不明显。
• Event Log：核心！这里记录了每一步SDP操作。查找关键词：
  • SetLocalDescription：本地Offer/Answer被设置
  • SetRemoteDescription：远端Offer/Answer被接收
  • NegotiationNeeded：触发协商事件
  • IceConnectionStateChange：ICE状态变化（常与协商并发）

第三步：深挖SDP内容与能力匹配
在Event Log中，找到SetLocalDescription事件，点击右侧的▶展开。你会看到完整的SDP文本。重点分析：

• m=video行后的a=rtpmap：列出所有候选编码器及其payload type（pt）
• a=fmtp行：每个编码器的具体参数，如a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
• a=rtcp-fb：反馈机制支持，如a=rtcp-fb:100 nack表示支持NACK

此时，切换到StatsTab，筛选outbound-rtp类型，找到对应trackId的统计项。关键字段：

• codecId：当前实际使用的编码器ID（如video-100）
• framesEncoded：已编码帧数，为0说明编码未启动
• keyFramesEncoded：关键帧数，若为0且framesEncoded>0，说明编码器卡在I帧

第四步：源码级断点验证
若需深入C++层，启动Chrome with debug flags：

# macOS open -a "Google Chrome" --args \ --remote-debugging-port=9222 \ --enable-logging=stderr \ --v=1 \ --vmodule=*/webrtc/media/engine/*=2,*/webrtc/p2p/base/*=2

然后访问chrome://version查看Command Line确认flag生效。在chrome://webrtc-internals的Event Log中，点击任意事件旁的Source链接，可跳转到Chromium源码对应的行（需提前下载源码并配置Source Map）。

我常用的一个断点位置是webrtc/media/engine/webrtc_media_engine.cc的WebRtcMediaEngine::FindMatchingVideoCodec()函数入口。当它被调用时，观察remote_codec（远端Offer中的编码器）和supported_formats（本地支持列表）的值，就能100%确认协商逻辑是否按预期执行。有一次，我发现supported_formats里H264的profile-level-id被错误解析为42001f（Level 1.3），而Offer要求42e01f（Level 3.1），但函数返回了absl::nullopt，证明降级未触发。追查发现是Android NDK版本过低，MediaCodecList返回的profileLevels数组被截断。升级NDK后问题解决。

4.2 修改源码：为老旧设备强制启用H264 Baseline

当标准协商无法满足业务需求时，修改WebRTC源码是终极方案。以下是在Chromium 120源码中，为Android平台强制启用H264 Baseline Profile的完整patch，已在某千万级教育App中稳定运行18个月。

问题场景：某款搭载联发科MT6735芯片的Android 5.1平板，MediaCodecList只报告profileLevels[0] = {profile=1, level=1}（Baseline Level 1），但实际硬件支持Level 3.1。Chrome默认信任MediaCodecList，导致协商时拒绝profile-level-id=42e01f的Offer。

解决方案：在webrtc/sdk/android/src/jni/android_video_encoder.cc中，绕过MediaCodecList的静态检查，动态注入Level 3.1支持。

Patch步骤：

1. 定位到AndroidVideoEncoder::GetSupportedFormats()函数（约第120行）
2. 在std::vector<VideoCodecInfo> formats;声明后，插入以下代码：

// 【新增】强制为MT6735芯片添加H264 Baseline Level 3.1支持 std::string device_model = GetDeviceModel(); // 需先实现GetDeviceModel() if (device_model == "MT6735") { VideoCodecInfo h264_baseline_31; h264_baseline_31.name = "H264"; h264_baseline_31.codec_type = kVideoCodecH264; h264_baseline_31.max_width = 1280; h264_baseline_31.max_height = 720; h264_baseline_31.max_fps = 30; // 关键：硬编码profile-level-id为42e01f h264_baseline_31.parameters["profile-level-id"] = "42e01f"; h264_baseline_31.parameters["level-asymmetry-allowed"] = "1"; h264_baseline_31.parameters["packetization-mode"] = "1"; formats.push_back(h264_baseline_31); }

3. 实现GetDeviceModel()（在同文件底部）：

std::string GetDeviceModel() { JNIEnv* env = AttachCurrentThread(); jclass build_class = env->FindClass("android/os/Build"); jfieldID model_id = env->GetStaticFieldID(build_class, "MODEL", "Ljava/lang/String;"); jstring model_jstr = (jstring) env->GetStaticObjectField(build_class, model_id); const char* model_cstr = env->GetStringUTFChars(model_jstr, nullptr); std::string model(model_cstr); env->ReleaseStringUTFChars(model_jstr, model_cstr); env->DeleteLocalRef(model_jstr); env->DeleteLocalRef(build_class); DetachCurrentThread(); return model; }

4. 重新编译WebRTC for Android（需完整GN构建环境）

效果验证：

• Patch前：Offer含a=fmtp:100 profile-level-id=42e01f，Answer中无H264条目，协商失败。
• Patch后：GetSupportedFormats()返回的formats列表包含profile-level-id=42e01f，FindMatchingVideoCodec()成功匹配，Answer中出现a=fmtp:100 profile-level-id=42e01f，1080p视频正常播放。

注意：此patch仅影响编码器能力声明，解码器仍需AndroidVideoDecoder同步patch。且必须严格限定设备型号，避免误伤其他芯片。我们通过Build.MODEL和Build.BOARD双重校验，确保精准命中。

4.3 构建自定义协商引擎：脱离SDP的轻量级方案

对于IoT设备或资源受限终端（如内存<128MB的嵌入式摄像头），标准WebRTC的SDP协商过于重量级。我们曾为某安防摄像头SDK开发了一个极简协商引擎，仅200行C++代码，完美替代createOffer/createAnswer。

设计原则：

• 去SDP化：不生成完整SDP，只交换核心能力哈希
• 二进制协议：用Protocol Buffers序列化，体积比文本SDP小80%
• 单次握手：Offer/Answer合并为一个NegotiateRequest消息

核心数据结构（Protobuf定义）：

message NegotiateRequest { string device_id = 1; // 设备唯一标识 repeated CodecPreference codecs = 2; // 编码器偏好列表 bool supports_fec = 3; // 是否支持FEC int32 max_bitrate_kbps = 4; // 最大码率 } message CodecPreference { enum CodecType { H264 = 0; VP8 = 1; OPUS = 2; } CodecType type = 1; uint32 profile_level_id = 2; // H264: 0x42e01f, VP8: 0 (无) uint32 clock_rate = 3; // 音频采样率 }

协商流程：

1. 摄像头端发送NegotiateRequest，含codecs=[{type:H264, profile_level_id:0x42e01f}]
2. 手机APP端收到后，遍历本地解码器能力表（预存于ROM）：

   struct DecoderCapability { CodecType type; uint32 min_profile_level_id; // 支持的最低Level uint32 max_profile_level_id; // 支持的最高Level }; static const DecoderCapability kDecoderCaps[] = { {H264, 0x42001f, 0x640032}, // 支持Baseline Level 1.3 到 High Level 5.0 };

3. 匹配逻辑：request.profile_level_id >= cap.min_profile_level_id && request.profile_level_id <= cap.max_profile_level_id
4. 若匹配，回复NegotiateResponse，含选定的codec和selected_profile_level_id
5. 双方据此配置RTP通道，跳过SDP解析

优势：

• 启动时间从1200ms降至180ms（免去SDP tokenizer）
• 内存占用从8MB降至1.2MB（无SDP字符串缓存）
• 兼容性更高：不依赖WebRTC版本，纯C++实现

我们在某款海思Hi3516DV300摄像头中部署此方案，与标准WebRTC手机端互通，延迟稳定在300ms内。这证明：理解协商本质，远比套用框架更重要。

5. 常见问题与排查技巧实录

5.1 “No common codecs”错误的七种根因与速查表

Failed to set remote offer: no common codecs是WebRTC协商失败最经典的报错。但它的背后，可能是七个完全不同的技术问题。以下是我在一线支持中整理的速查表，按发生频率排序：