WebRTC 总体架构：一个嵌入式音视频系统由哪些部分组成？
内容提要
本文以Linux嵌入式设备接入原生libwebrtc为例，讲解一对一可视对讲的整体架构：信令服务器交换SDP与ICE候选，STUN/TURN解决NAT穿透与中继；板卡侧需适配摄像头、硬件编码器、声卡与显示，并遵守格式、时间戳和执行三项约定；媒体经RTP/SRTP传输，拥塞控制与Pacing协同调节码率；音频经APM做AEC、NS、AGC，NetEq协调播放节奏；最后给出延迟拆解与分阶段验证方法。
延伸解读
嵌入式接入的关键：适配层三项约定
文章强调板卡适配层必须守住数据、时间、执行三项约定。数据约定涉及像素格式、内存布局和缓冲区生命周期，错误可能导致偶发花屏；时间约定要求采集时间戳真实反映曝光或采集时刻，不能随意用出队时间替代；执行约定要求动态码率、关键帧请求等控制指令有明确落地行为。这三项是嵌入式集成时最易被忽视却直接影响通话质量的环节。
拥塞控制与Pacing：判断与动作的分工
文章指出带宽估计负责判断当前可用速率，拥塞控制据此调整发送目标和节奏。编码器调整未来产生的数据量，Pacer安排已产生报文的发送时机，两者必须配合。若媒体持续产生2 Mb/s而链路只能消耗1 Mb/s，仅靠Pacer平滑发送无法消除积压，还需编码器降低产出或明确丢弃策略。这解释了为何单独优化某一环节不足以解决弱网问题。
音频AEC的参考信号为何不能随意选取
AEC需要知道本机正在播放什么，参考应来自准备送往扬声器的播放PCM，而非收到的压缩包或麦克风数据副本。文章以Native路径为例，混音结果先送APM反向流处理，再重采样输出。实际板卡还需核对硬件混音是否在参考点后加入提示音、音量变化和录放缓冲延迟，这些都会破坏参考与真实播放的关系，导致开启AEC后仍有回声。
延迟拆解：网络只是其中一段
文章将端到端延迟拆为采集前处理、编码发送准备、网络传输、接收恢复调度、解码呈现五部分，并强调不能简单用RTT/2替代单向媒体延迟。采集接口可能吐出队列中的旧帧，硬件编码快但内部缓冲仍可能积压。测量时应选择互不重叠的起止点跟踪同一帧，跨设备时间戳相减前需建立可信时钟对应关系，否则音画同步分析会失真。
Q&A
WebRTC 在一对一可视对讲中，信令服务器具体负责交换哪些信息？
信令服务器负责交换 SDP Offer/Answer 和 ICE candidate。SDP 描述会话的媒体类型、编码格式、方向和安全参数；ICE candidate 描述可能的通信地址和端口。这些信息由应用通过 WebSocket、HTTP 等通道传递，用于建立连接。
STUN 和 TURN 在 WebRTC 中分别解决什么问题？
STUN 用于发现设备的公网映射地址，帮助生成 ICE 候选；TURN 提供中继地址，当直连受限时媒体经 TURN 服务器转发。ICE 则组织候选收集、连通性检查和路径选择。
嵌入式板卡接入 libwebrtc 时，适配层需要遵守哪三个关键约定？
一是数据约定：确保像素格式、内存布局、缓冲区生命周期正确；二是时间约定：采集时间戳要准确随帧传递，不能随意使用出队时间；三是执行约定：动态码率、关键帧请求等控制命令必须有明确的落地行为。
WebRTC 的拥塞控制中，带宽估计和 Pacing 分别起什么作用？
带宽估计根据网络反馈判断当前可用带宽；拥塞控制据此调整发送目标和节奏。Pacing 负责将已编码的报文按合适节奏发送，避免突发流量冲击网络，但它不会改变编码帧的大小。
音频处理中的 AEC 为什么需要参考播放 PCM？
AEC 需要消除本机扬声器播放的声音被麦克风采集形成的回声，因此必须知道本机正在播放什么。参考信号应来自送往扬声器的播放 PCM，而不是网络收到的压缩包或麦克风数据。
NetEq 在音频接收链路中主要解决什么问题？
NetEq 协调网络到包节奏与声卡播放节奏，通过缓冲、解码调度和时间尺度调整，将不稳定的网络音频转换为连续播放的 PCM，减轻中断和延迟。
端到端延迟可以拆分为哪几个部分？
可拆分为采集与前处理、编码与发送准备、网络传输、接收恢复与调度、解码与呈现五部分。测量时应选择互不重叠的起止点，跟踪同一帧或同一段音频。
