音视频，这个词最近在各种技术讨论、自媒体运营、远程协作甚至家庭娱乐场景里反复出现，不是作为某个具体功能的附属词，而是直接以独立名词身份被高频提及——比如“这个项目要打通音视频”，“音视频延迟压不下去”，“音视频同步老出问题”，“音视频采集链路得重做”。它不再只是“播放器里能听能看”的模糊概念，而是一整套涉及信号采集、编码压缩、网络传输、解码渲染、时序同步、设备适配、资源调度的系统工程。我做音视频相关项目十多年，从早期用VLC硬改源码跑RTSP流，到后来搭WebRTC集群支撑万人级在线课堂，再到最近帮制造业客户把4K红外热成像视频+语音对讲嵌入工业平板——所有这些，底层绕不开的都是“音视频”这三个字背后的真实约束：带宽不是无限的，设备不是理想的，人眼和人耳对卡顿、不同步、失真极其敏感，而开发者的调试工具却常常只显示“播放失败”四个字。这篇文章不讲抽象理论，也不堆砌协议标准，就拿一个真实可复现的轻量级音视频双向通信场景切入：在局域网内，用一台笔记本当发送端（摄像头+麦克风），另一台设备（树莓派/安卓平板/另一台PC）当接收端，实现低延迟（目标≤300ms）、可调分辨率（支持480p/720p/1080p三级切换）、音频同步稳定、断线自动重连的端到端通路。我会从设计思路怎么定、每个环节为什么这么选、实操中哪些参数不能乱动、哪些日志要看、哪些现象说明哪一层出了问题，全部摊开讲。适合刚接触音视频开发的工程师、想自己搭远程监控系统的创客、需要嵌入音视频能力的产品经理，以及被“音视频”三个字反复折磨却找不到突破口的运维同学。你不需要会写编解码器，但得知道H.264的profile选baseline还是main会影响什么；你不用懂RTP时间戳计算，但得明白为什么接收端一卡，十有八九是抖动缓冲区（Jitter Buffer）没配对；你可能没碰过WebRTC的SDP交换，但得清楚offer/answer里哪几行改了会导致黑屏而不是无声。下面我们就从最根本的问题开始：为什么同样叫“传音视频”，用微信视频通话、用OBS推流、用FFmpeg拉流、用自研SDK做远程医疗会用完全不同的技术路径？答案不在代码里，而在需求定义的第一行。

1. 音视频系统整体设计与思路拆解

1.1 为什么不能“一套方案打天下”：从场景倒推架构选型

很多人一上来就想找“最好的音视频框架”，结果试了WebRTC、SRS、Janus、GStreamer、FFmpeg pipeline，最后发现要么编译不过，要么延迟高得没法用，要么移动端兼容性差，要么文档里写的“低延迟”在自己网络环境下根本达不到。问题不在于工具不行，而在于没先问清楚：你要解决什么问题？这个问题的边界在哪里？我见过太多团队花三个月搭完WebRTC信令服务器，结果发现客户现场全是NAT穿透失败的老旧路由器，最后全换成RTMP+HTTP-FLV方案；也见过用FFmpeg硬编码H.265的项目，上线后发现80%的安卓机根本不支持HEVC硬解，画面全绿。所以设计第一步，永远是反向拆解场景约束：

• 实时性要求 ：是“说话要立刻听到”（≤300ms），还是“直播可接受2秒延迟”（≤2s），或是“点播只要能播就行”（≤10s）？实时性越强，对传输协议、缓冲策略、编解码复杂度的要求就越苛刻。比如300ms目标，TCP基本出局（重传机制天然引入不确定延迟），必须上UDP类协议（RTP/QUIC），且要启用前向纠错（FEC）或丢包重传（NACK），而2秒延迟下，用HLS切片+CDN分发反而更稳。

• 终端覆盖范围 ：是否必须支持iOS/Android/Web三端？有没有老旧设备（如Android 5.x、iOS 10）？是否涉及嵌入式设备（ARM32、无GPU）？这直接决定编解码器选择：H.264 baseline profile几乎通吃所有设备，H.265虽省带宽但软解CPU吃紧，AV1目前仅Chrome/Firefox/部分新安卓机支持，Web端用WebAssembly软解AV1帧率常卡在10fps以下。

• 网络环境确定性 ：是可控局域网（企业内网/工厂车间），还是公网弱网（4G移动场景/农村宽带）？局域网下可大胆用高码率+无FEC，公网则必须做自适应码率（ABR）、动态关键帧间隔、多路冗余传输。我们这次定位的是局域网场景，所以设计上可以砍掉ABR模块、关闭FEC、固定I帧间隔为关键帧，大幅降低实现复杂度。

• 功能边界清晰度 ：只需要单向视频流？还是双向音视频？是否要支持屏幕共享、录制、美颜、降噪？功能越多，模块耦合越深，调试难度指数上升。本次明确只做双向音视频（即A发视频B收+B发音频A收，或双工），不加滤镜、不录本地、不转推第三方，确保主干链路干净可测。

基于这四条，我们最终选定“轻量级WebRTC直连”方案，而非SRS转发或FFmpeg拉流。理由很实在：WebRTC原生支持NAT穿透（STUN/TURN）、内置Jitter Buffer和PLC（丢包补偿）、音频自动同步（A/V sync via RTP timestamp + NTP clock）、跨平台成熟（Chrome/Firefox/Edge/Safari 15+ / Android WebView / iOS WKWebView均支持），且最新版libwebrtc已支持硬件加速编解码（Intel QSV/NVIDIA NVENC/Apple VideoToolbox）。更重要的是，它不依赖中心化服务器——两台设备在同一个局域网内，连上同一WiFi，用一个简单的信令交换页（HTML+WebSocket）就能完成offer/answer交换，连STUN服务器都可省（局域网IP直连）。对比FFmpeg方案：需手动管理RTP包拼接、自己写Jitter Buffer、音频视频时间戳对齐要算PTS/DTS差值、丢包全靠重传无补偿，调试时抓包看到满屏UDP丢包根本不知道该修哪一层。WebRTC把这些问题封装进C++ SDK里，我们只管喂数据、取数据，中间链路交给它。

1.2 架构分层：为什么必须严格区分采集、编码、传输、解码、渲染五层

很多初学者试图“一步到位”：用OpenCV读摄像头→FFmpeg编码→sendto()发UDP→recvfrom()收UDP→FFmpeg解码→SDL渲染。表面看流程完整，实际一跑就崩。原因在于音视频处理是典型的“生产者-消费者”流水线，每一层都有自己的节奏和瓶颈，强行耦合会导致：

• 采集层被编码拖慢 ：摄像头输出30fps原始YUV帧，但编码器因CPU忙每秒只处理20帧，采集缓冲区溢出，新帧覆盖旧帧，画面跳变；
• 传输层被解码卡住 ：网络收到100个RTP包，但解码器一秒只解15帧，接收缓冲区堆积，延迟飙升；
• 渲染层被音频拖累 ：音频播放器要求每20ms喂一次PCM数据，但视频渲染卡在GPU队列，主线程阻塞，音频缓冲区饿死，出现爆音。

所以必须分层隔离，用环形缓冲区（Ring Buffer）或消息队列（如libuv pipe）解耦。我们采用标准五层模型：

1. 采集层（Capture） ：负责从设备获取原始音视频帧。视频用MediaDevices.getUserMedia（浏览器）或AVFoundation/Camera2（移动端）；音频用Web Audio API或AudioRecord。关键约束：帧率锁定（如30fps）、分辨率预设（如1280×720）、格式统一（YUV420P for video, PCM signed 16-bit little-endian for audio）。

2. 编码层（Encode） ：将原始帧压缩为比特流。浏览器端走MediaStreamTrack.getSettings().width/height触发硬件编码；移动端调用MediaCodec（Android）或VideoToolbox（iOS）。核心参数：bitrate（码率）、keyFrameInterval（关键帧间隔）、profile（档次）、level（级别）。例如H.264 baseline@3.1支持最大分辨率为1280×720@30fps，超此范围强制降级。

3. 传输层（Transport） ：将编码后的NALU（视频）或Opus帧（音频）打包成RTP包，添加序列号、时间戳、SSRC，通过UDP发送。WebRTC内部自动处理：RTP头生成、NACK请求、FEC包生成、带宽估计算法（GCC）、拥塞控制（PacedSender）。我们只需配置 RTCRtpEncodingParameters 控制最大码率和降级策略。

4. 解码层（Decode） ：接收RTP包，校验校验和，重组NALU，送入解码器。WebRTC自动管理解码器实例、错误隐藏（Error Concealment）、帧间依赖修复（如B帧丢失时跳过）。关键指标：解码耗时（decode time）、输出帧率（output fps）、丢帧数（dropped frames）。

5. 渲染层（Render） ：将解码后的YUV/RGB帧和PCM音频送显卡/声卡。浏览器用

这五层不是理论摆设。我在调试一个医疗内窥镜项目时，发现画面卡顿但音频正常，抓包看RTP包全到，解码日志显示“decode time > 50ms”，立刻定位到解码层：客户用的国产ARM芯片未启用VideoToolbox硬解，全靠CPU软解H.265，一帧解30ms必然卡。换回H.264 baseline后，decode time压到8ms，问题消失。分层思维，就是把“哪里出问题”变成“哪一层出问题”，极大缩短排查路径。

1.3 方案取舍：为什么放弃RTMP/HTTP-FLV，坚持WebRTC直连

市面上常见方案还有RTMP（Adobe开源，Nginx-rtmp-module支持）、HTTP-FLV（Bilibili主推）、SRT（Haivision开源，广电常用）。它们各有优势，但在此场景下均被排除：

• RTMP ：基于TCP，天然抗丢包，但重传机制导致延迟不可控（弱网下动辄2~5秒），且不支持端到端加密（需额外加TLS），信令交互复杂（需Flash Policy Server或WebSocket伪装）。我们测试过：局域网千兆环境，RTMP延迟实测1.2秒；而WebRTC直连稳定在180~220ms。

• HTTP-FLV ：利用HTTP长连接规避TCP队头阻塞，延迟比RTMP低（约800ms），但仍是TCP协议，无法做到真正的实时互动；且FLV容器格式不支持现代编码（如AV1、VP9），扩展性差。某教育客户曾用HTTP-FLV做双师课堂，学生提问后老师要等近1秒才收到，互动感极差。

• SRT ：专为互联网传输优化，支持前向纠错、动态带宽调整，延迟可压至300ms以内，但生态薄弱：浏览器无原生支持（需WebAssembly移植，性能打折），移动端SDK成熟度低，调试工具链不完善（Wireshark无SRT解析插件）。我们曾尝试用SRT替代WebRTC，结果在iOS上因TLS握手失败导致连接超时，查了三天才发现SRT库默认启用DTLS 1.2，而客户iOS设备只支持DTLS 1.0。

WebRTC的胜出，不是因为它“最好”，而是它在“局域网低延迟双向通信”这个狭窄赛道上，做到了 开箱即用、跨端一致、调试友好、社区活跃 。它的规范由IETF和W3C联合制定，Chrome源码公开，libwebrtc每日CI构建，遇到问题搜GitHub issue基本能找到同类case。相比之下，RTMP/SRT的issue页面常年沉寂，文档更新滞后于代码。技术选型的本质，是选“谁帮你扛住了大部分脏活累活”，而不是选“理论上参数最漂亮的那个”。

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

2.1 采集层：设备权限、格式协商与帧率锁定的实操陷阱

采集是音视频链路的源头，看似简单，实则暗坑最多。浏览器环境下， navigator.mediaDevices.getUserMedia({video: true, audio: true}) 一行代码背后，藏着至少五个关键决策点：

• 设备选择 ： getUserMedia 默认用系统首选设备，但用户可能插了多个USB摄像头或蓝牙耳机。必须提供设备枚举接口：

  navigator.mediaDevices.enumerateDevices()
    .then(devices => {
      const videoDevices = devices.filter(d => d.kind === 'videoinput');
      const audioDevices = devices.filter(d => d.kind === 'audioinput');
      // 渲染下拉菜单供用户选择
    });
  

  实测发现：某些会议摄像头（如Logitech C920）在enumerate时返回两个设备ID（一个标“default”，一个标具体型号），选错ID会导致采集失败。经验：优先选 label 含厂商名的设备，避免用 deviceId 为"undefined"的默认项。

• 分辨率与帧率协商 ： constraints 参数不是“我要1080p”，而是“我期望1080p，但可接受降级”。正确写法：

  const constraints = {
    video: {
      width: { ideal: 1280, max: 1920 },
      height: { ideal: 720, max: 1080 },
      frameRate: { ideal: 30, max: 30 }
    }
  };
  

  关键点： ideal 表示目标值， max 表示上限， min 表示下限。若设 frameRate: {exact: 30} ，而摄像头物理不支持30fps（如某些USB2.0摄像头只支持15fps），则 getUserMedia 直接reject。我们线上项目曾因此导致30%安卓机采集失败——因为厂商固件把 exact 解析为硬性要求，而非协商。

• 格式强制统一 ：不同设备输出格式各异（NV12/YUY2/I420），WebRTC内部编码器通常只支持I420（YUV420P）。若采集输出非I420，浏览器会自动转换，但消耗CPU。可在 getCapabilities() 中检查：

  const track = stream.getVideoTracks()[0];
  const capabilities = track.getCapabilities();
  console.log(capabilities.frameRate); // 实际支持的帧率范围
  console.log(capabilities.width);     // 实际支持的宽度范围
  

  若 capabilities 为空，说明设备不支持MediaStreamTrack API（老旧IE/Edge Legacy），需降级到 <video> 标签+ srcObject 方案。

• 自动增益控制（AGC）与噪声抑制（NS） ：音频采集默认开启AGC和NS，对语音通话友好，但对音乐、仪器音采集会失真。关闭方式：

  const audioConstraints = {
    autoGainControl: false,
    noiseSuppression: false,
    echoCancellation: true // 回声消除必须开，否则双向通话啸叫
  };
  

  注意： echoCancellation 在部分安卓WebView中无效，需额外集成WebRTC AECM模块。

• 采集性能监控 ：不能只看 track.readyState ，要监听 onended 和 onmute 事件：

  track.onended = () => console.warn('Video track ended unexpectedly');
  track.onmute = () => console.warn('Video track muted by system');
  

  我们曾遇到华为Mate系列手机在后台切回前台时，摄像头自动 onmute ，但 readyState 仍为 live ，导致画面黑屏却无报错。解决方案：定时检查 track.enabled 和 track.muted 状态，异常时主动 track.stop() 再 getUserMedia 重连。

提示：采集层最大的坑是“静默失败”——没有报错，但数据流为空。务必在 ondataavailable 或 onframe 回调中打印首帧时间戳和尺寸，确认数据真实到达。

2.2 编码层：码率、关键帧、档次选择的硬核参数逻辑

编码是带宽与质量的平衡术。H.264/H.265的参数不是随便填的数字，每个都对应硬件能力与网络约束：

• 码率（bitrate）设定逻辑 ：不是“越高越好”。局域网千兆环境，1080p视频合理码率区间为2~4Mbps。计算依据：

  • 原始YUV帧大小：1920×1080×1.5（YUV420P）= 3.1MB/frame
  • 30fps → 93MB/s原始带宽
  • H.264压缩比典型值：50:1 → 93MB/s ÷ 50 ≈ 1.86MB/s ≈ 15Mbps
  • 但这是理论峰值，实际需留余量（运动剧烈场景码率飙升），且要考虑音频（Opus 64kbps）和RTP包头（12字节/包 × 50包/s ≈ 4.8kbps）。最终我们定1080p档位为3Mbps，720p为1.5Mbps，480p为800kbps。

• 关键帧间隔（keyFrameInterval） ：影响随机访问和恢复能力。设为0表示“按GOP长度自动”，但WebRTC推荐显式设置：

  const encodings = [{
    rid: 'h',
    maxBitrate: 3000000,
    scaleResolutionDownBy: 1.0, // 不缩放
    keyFrameInterval: 3000 // 毫秒，即每3秒一个I帧
  }];
  

  为什么是3000？因为I帧比P/B帧大5~10倍，太密浪费带宽，太疏导致丢包后长时间黑屏。实测3秒是平衡点：丢一个I帧，最多3秒黑屏；网络波动时，3秒内足够恢复。

• 档次（profile）与级别（level）匹配 ：H.264 profile决定编码工具集，level决定分辨率/帧率上限。常见组合：

  Profile	Level	Max Resolution	Max Frame Rate	兼容性
  Baseline	3.0	720×480@30fps	30fps	★★★★★（所有设备）
  Main	3.1	1280×720@30fps	30fps	★★★★☆（iOS 8+/Android 4.4+）
  High	4.0	1920×1080@30fps	30fps	★★★☆☆（仅新设备）

  我们选Baseline@3.0，牺牲一点压缩率（同码率下画质略逊Main），换取100%设备兼容。某次升级到Main@3.1后，发现三星Galaxy J系列（Exynos芯片）解码失败，查文档才发现其VideoCore解码器仅支持Baseline。

• 硬件加速强制启用 ：浏览器默认优先用硬件编码，但需确认：

  const pc = new RTCPeerConnection({ 
    encodedInsertableStreams: true // 启用WebCodecs API，可接管编码
  });
  

  更可靠的方式是检查 RTCRtpSender.getCapabilities('video') 返回的 encodings 是否含 hardwareAccelerated: true 字段。若为false，说明fallback到软编，此时需降码率保流畅。

• 音频编码选Opus而非AAC ：Opus在64~128kbps下语音质量远超AAC-LC，且支持动态码率（从6kbps窄带语音到510kbps全频响音乐），WebRTC默认启用。关键参数：

  const audioEncodings = [{
    maxBitrate: 64000,
    ptime: 20, // packet time，20ms一包，匹配人耳听觉暂留
    sdpFmtpLine: 'stereo=1;usedtx=1;useinbandfec=1' // 启用立体声、DTX静音检测、FEC前向纠错
  }];
  

  usedtx=1 让静音时不发包，节省50%带宽； useinbandfec=1 在丢包率<15%时几乎无感知。

2.3 传输层：RTP包结构、NACK机制与带宽估计算法的实战解读

传输层是WebRTC的“黑盒”，但理解其行为才能调优：

• RTP包基础结构 ：每个RTP包12字节固定头，含：

  • sequence number ：包序号，用于检测丢包（连续+1为正常，跳变即丢）
  • timestamp ：采样时钟时间戳，视频用90kHz时钟，音频用48kHz， 同一媒体流内单调递增
  • SSRC ：流标识符，同一会话中唯一，用于区分音视频流
  • payload type ：编码类型标识（如126=H.264，111=Opus）

  抓包时Wireshark过滤 rtp && rtp.p_type == 126 可单独看视频包。实测发现：若 timestamp 非单调（如跳变-100000），说明采集层时钟紊乱，需检查设备驱动。

• NACK（Negative ACKnowledgement）机制 ：接收端发现丢包（sequence number跳变），立即发NACK包请求重传。WebRTC默认启用，但需注意：

  • NACK只对最近20个包有效（RFC 4585），超时未重传则放弃
  • 重传包用相同sequence number，但timestamp不变，避免解码器误判为新帧
  • 局域网下NACK成功率>95%，公网弱网需配合FEC

• 带宽估计（BWE）与拥塞控制 ：WebRTC用Google Congestion Control (GCC) 算法，核心是：

  1. 发送端按当前估计带宽发包
  2. 接收端统计包到达时间差（inter-arrival jitter），计算网络排队延迟
  3. 若排队延迟持续上升，判定拥塞，通知发送端降码率
  4. 发送端按 remb 或 transport-cc 反馈调整

  调试时看 RTCPeerConnection.getStats() 中的 outbound-rtp 条目：

  • bytesSent / timestamp → 实际发送码率
  • jitter → 接收端抖动（ms），>30ms需关注
  • packetsLost → 丢包数，局域网应≈0

  曾有个项目在企业内网部署， jitter 高达80ms，查原因是交换机QoS策略将UDP包优先级设为最低。关掉QoS后 jitter 降至5ms。

• MTU与PMTU发现 ：UDP包过大（>1500字节）会被IP层分片，任一片丢失则整包失效。WebRTC默认MTU为1200字节（预留200字节给IP/UDP头），可通过 RTCPeerConnection.setConfiguration({iceTransportPolicy: 'relay'}) 强制走TURN中继规避分片，但增加延迟。局域网直连无需此操作。

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

3.1 信令交换：用WebSocket实现极简offer/answer交换

WebRTC需要信令服务器交换SDP（Session Description Protocol）和ICE候选地址。我们用Node.js+WebSocket搭最小信令服务：

// server.js
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws, req) => {
  ws.id = Date.now() + Math.random().toString(36).substr(2, 9);
  console.log(`Client ${ws.id} connected`);

  ws.on('message', (data) => {
    const msg = JSON.parse(data.toString());
    // 广播给其他客户端，除自己
    wss.clients.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify({
          from: ws.id,
          type: msg.type,
          data: msg.data
        }));
      }
    });
  });
});

前端信令逻辑：

// signaller.js
let socket;
function connectSignaller() {
  socket = new WebSocket('ws://localhost:8080');
  socket.onmessage = (event) => {
    const msg = JSON.parse(event.data);
    if (msg.from === localId) return; // 忽略自己发的消息
    switch (msg.type) {
      case 'offer':
        pc.setRemoteDescription(new RTCSessionDescription(msg.data));
        createAnswer();
        break;
      case 'answer':
        pc.setRemoteDescription(new RTCSessionDescription(msg.data));
        break;
      case 'candidate':
        pc.addIceCandidate(new RTCIceCandidate(msg.data));
        break;
    }
  };
}

async function createOffer() {
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  socket.send(JSON.stringify({
    type: 'offer',
    data: offer
  }));
}

关键细节：

• ICE候选过滤 ：局域网下，只保留host候选（192.168.x.x），忽略srflx（STUN）和relay（TURN）候选，减少连接建立时间。可通过 RTCPeerConnection.getConfiguration().iceTransportPolicy = 'relay' 强制，但没必要。
• SDP munging（篡改） ：有时需修改SDP以适配老旧设备。例如，Android 5.0不支持 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level ，需在 pc.onnegotiationneeded 中移除该行。
• 连接超时控制 ： RTCPeerConnection 无内置超时，需手动：

  const timeout = setTimeout(() => {
    if (pc.connectionState !== 'connected') {
      pc.close();
      alert('Connection timeout');
    }
  }, 10000);
  pc.onconnectionstatechange = () => {
    if (pc.connectionState === 'connected') clearTimeout(timeout);
  };
  

3.2 编码参数注入：通过RTCRtpEncodingParameters动态控制码率

WebRTC允许运行时调整编码参数，实现自适应：

const sender = pc.getSenders().find(s => s.track?.kind === 'video');
const params = sender.getParameters();
params.encodings[0].maxBitrate = 1500000; // 切换到720p档位
sender.setParameters(params);

但要注意：

• setParameters 是异步操作，需await其Promise
• 某些浏览器（Safari）不支持动态修改，需重建sender
• 修改后需等待 RTCRtpSender.ontrack 事件确认生效

我们封装了一个码率控制器：

class BitrateController {
  constructor(sender) {
    this.sender = sender;
    this.levels = [
      { name: '480p', bitrate: 800000, width: 640, height: 480 },
      { name: '720p', bitrate: 1500000, width: 1280, height: 720 },
      { name: '1080p', bitrate: 3000000, width: 1920, height: 1080 }
    ];
  }

  async setLevel(levelName) {
    const level = this.levels.find(l => l.name === levelName);
    if (!level) return;
    
    const params = this.sender.getParameters();
    params.encodings[0].maxBitrate = level.bitrate;
    params.encodings[0].scaleResolutionDownBy = 
      level.width / 1920; // 按比例缩放
    await this.sender.setParameters(params);
  }
}

3.3 渲染层同步：用requestVideoFrameCallback精准控制渲染时机

传统 <video> 标签渲染有延迟且不可控。Chrome 94+支持 requestVideoFrameCallback ，可精确到帧：

let lastTime = 0;
videoEl.requestVideoFrameCallback((now, metadata) => {
  // now: 当前帧渲染时间戳（DOMHighResTimeStamp）
  // metadata: {receiveTime, decodeTime, presentationTime}
  const delta = now - lastTime;
  if (delta > 1000/30 * 1.2) { // 超过30fps的120%
    console.warn(`Frame drop detected: ${delta.toFixed(1)}ms`);
  }
  lastTime = now;
  
  // 手动控制渲染节奏
  if (shouldRenderFrame()) {
    renderFrame(metadata);
  }
});

metadata.presentationTime 是WebRTC内部计算的“理想渲染时间”，与音频播放时间对齐。我们用它做A/V同步校准：

// 获取音频播放时间
const audioContext = new (window.AudioContext || window.webkitAudioContext)();
const audioTime = audioContext.currentTime;

// 计算音画偏差
const avDiff = audioTime - metadata.presentationTime;
if (Math.abs(avDiff) > 0.05) { // >50ms偏差
  // 调整视频播放速率
  videoEl.playbackRate = 1 + (avDiff > 0 ? -0.01 : 0.01);
}

3.4 断线重连：基于iceConnectionState的自动恢复策略

WebRTC的 iceConnectionState 有 new / checking / connected / failed / disconnected / closed 六种状态。 disconnected 不等于断开，可能是瞬时抖动：

pc.oniceconnectionstatechange = () => {
  switch (pc.iceConnectionState) {
    case 'disconnected':
      // 启动重连计时器，3秒内恢复则忽略
      if (!reconnectTimer) {
        reconnectTimer = setTimeout(() => {
          console.log('Reconnecting...');
          pc.restartIce(); // 重新收集ICE候选
        }, 3000);
      }
      break;
    case 'connected':
      clearTimeout(reconnectTimer);
      reconnectTimer = null;
      break;
    case 'failed':
      // 彻底失败，清理资源
      pc.close();
      initNewConnection();
      break;
  }
};

关键点： restartIce() 不重建连接，只刷新候选地址，比 createOffer 快得多。

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

4.1 黑屏但有声音：五层定位法实战

这是最高频问题。按五层顺序快速排查：

层级	检查点	工具/命令	典型现象	解决方案
采集	track.readyState 是否 live ？ track.muted 是否 true ？	浏览器控制台	readyState 为 ended	重启 getUserMedia
编码	RTCPeerConnection.getStats() 中 outbound-rtp 的 bytesSent 是否增长？	pc.getStats()	bytesSent 为0	检查 sender.replaceTrack() 是否执行
传输	Wireshark抓包， rtp && rtp.p_type==126 是否有包？	Wireshark	有包但 sequence number 跳变	检查防火墙UDP端口
解码	inbound-rtp 的 framesDecoded 是否增长？	pc.getStats()	framesDecoded 为0	检查SDP中 profile-level-id 是否匹配设备
渲染	<video> 元素 videoWidth / videoHeight 是否为0？	DOM inspector	videoWidth=0	检查 srcObject 是否赋值， autoplay 是否启用

某次客户现场黑屏，按表排查发现 framesDecoded 为0，但 bytesSent 正常。导出SDP发现 a=fmtp:126 profile-level-id=42e01f ，而客户设备只支持 42c01f （Baseline@3.0 vs Baseline@3.1）。手动修改SDP后恢复。

4.2 音画不同步：从时间戳到渲染的全链路校验

同步问题分两类： 系统级不同步 （全局偏移）和 抖动不同步 （忽快忽慢）。

• 系统级偏移 ：用 chrome://webrtc-internals 看 audio playout delay 和 video render delay 曲线，若两者差值稳定在>100ms，则是采集时钟偏差。解决方案：在 RTCPeerConnection 创建时指定 voiceActivityDetection: false 禁用VAD，或强制音频采集用 sampleRate: 48000 （视频时钟常用90kHz，48k更易对齐）。

• 抖动不同步 ：表现为“说话嘴型对不上”。抓包看RTP timestamp是否均匀递增。若 timestamp 增量忽大忽小（如应+2700却+5400），说明采集层帧率不稳。解决方案