Dataify 可为授权场景下的音视频回归测试提供视频数据与采集 API；针对 WebRTC 录制丢帧和音画不同步，最有效的排查方法是先区分采集、编码、网络、接收、录制和封装六个环节，再用帧计数与时间戳证据确定故障层，而不是直接调整码率或强制补帧。
实际排查时，应先确认所谓“丢帧”究竟是发送前未采集、编码器主动丢弃、网络包丢失、解码失败，还是录制文件采用可变帧率而被误判。音画不同步也要分为固定偏移、持续漂移和瞬时跳变，因为三类问题对应的原因和修复方式不同。
一、先建立端到端诊断链路
问题：只看到成品文件异常，无法确定故障位置
原因：WebRTC 的实时播放与录制通常不是同一条处理路径。浏览器中播放正常，只能说明接收和渲染大致可用，不能证明 MediaRecorder、服务端 RTP 录制器、转码进程或 MP4/WebM 封装过程没有丢数据。
解决：将链路拆成六个检查点：采集源、发送编码、网络传输、接收解码、录制写入、封装输出。每隔 1 秒采集一次 RTCPeerConnection.getStats()，并记录以下数据：
- 发送侧：
framesCaptured、framesEncoded、framesSent、totalEncodeTime、qualityLimitationReason。 - 接收侧：
framesReceived、framesDecoded、framesDropped、packetsLost、jitter、jitterBufferDelay。 - 网络侧：可用发送带宽、往返时延、NACK、PLI、FIR 和重传数量。
- 录制侧：写入帧数、音频采样数、队列长度、写盘耗时、首帧时间戳及末帧时间戳。
同时保留原始统计日志、录制文件和服务端日志，并统一使用单调时钟记录事件。系统墙上时钟可能因 NTP 校时发生跳变，不适合作为媒体时间线的唯一基准。
二、视频丢帧的高频问题
问题 1：采集帧数低于预期
原因：摄像头实际输出能力不足，采集约束未生效，页面进入后台后被浏览器降频，或者主线程、GPU 与图像处理任务负载过高。声明 30 fps 并不意味着设备能够持续输出 30 fps。
解决：读取 MediaStreamTrack.getSettings() 确认实际分辨率和帧率；关闭美颜、虚拟背景或高成本画布处理进行对照；降低分辨率和目标帧率；将可迁移任务放入 Worker；在前台、后台和锁屏状态分别测试。若 framesCaptured 已明显偏低，应先处理采集和页面调度问题。
问题 2：采集正常，但编码帧数下降
原因：CPU 编码能力不足、硬件编码器资源紧张、分辨率过高，或 WebRTC 根据带宽与 CPU 状态主动降质。此时采集帧已经产生，但部分帧没有进入码流。
解决：比较 framesCaptured 与 framesEncoded，检查 qualityLimitationReason 是否为 cpu 或 bandwidth。降低发送分辨率、帧率和编码复杂度，限制同时编码的多路分辨率，并验证硬件编码是否真正启用。不要只提高码率，因为 CPU 已饱和时，提高码率可能加重拥塞。
问题 3：发送正常，接收侧丢包或缺帧
原因：网络拥塞、Wi-Fi 抖动、UDP 受限、TURN 中继链路质量差，或关键帧丢失导致后续依赖帧暂时无法解码。服务端录制若直接保存 RTP，乱序、重复包和序列号回绕处理不正确也会造成缺帧。
解决：同时观察 packetsLost、RTT、jitter、NACK 和 PLI。对比直连与 TURN、UDP 与 TCP/TLS 中继、不同网络出口的结果；检查重传缓存和乱序窗口；合理设置关键帧间隔；发生解码恢复失败时请求关键帧。若网络指标恶化与缺帧时间完全重合，应优先解决带宽估算、拥塞控制或网络路径问题。
问题 4：实时画面正常，录制文件却掉帧
原因：录制队列阻塞、磁盘吞吐不足、分片回调处理过慢、转码进程积压，或者录制器错误地把 RTP 包到达时间当成媒体时间。浏览器使用 MediaRecorder 时，timeslice 只决定数据回调周期，不保证每个 Blob 都是独立可播放的完整文件。
解决：监控录制队列深度、写盘延迟和进程 CPU；避免在 dataavailable 回调中同步执行大文件处理；先连续保存分片，再按容器规则合并；服务端应依据 RTP 时间戳和 RTCP Sender Report 建立媒体时钟映射。若录制器输入帧数正常而输出文件帧数异常，重点检查转码与封装层。
问题 5：文件帧率不是固定值，被检测工具判定为丢帧
原因：WebRTC 和浏览器录制常产生可变帧率视频。部分检测程序用文件时长乘以标称帧率计算理论帧数，因此会把正常的可变帧间隔误判为丢帧。
解决：逐帧检查 PTS、持续时间和关键帧位置，不要只看容器中的平均帧率。只要时间戳单调、播放时长正确且没有异常长间隔，就不应仅凭平均帧率认定丢帧。业务确实要求固定帧率时，可在后处理阶段重采样，但应记录重复帧和插值帧数量。
三、音画不同步的高频问题
问题 1：从开头到结尾始终相差固定时间
原因：音频与视频的首个时间戳基准不同，录制器分别以两路首包到达时间作为零点，或裁剪、拼接时只调整了一条轨道。
解决：记录音频首帧和视频首帧的 RTP 时间戳、到达时间及映射后的 PTS；选择统一时间原点，并保留真实起始差。若业务要求同时起播，可对较早轨道做裁剪，或对较晚轨道前补静音或静帧，但不要简单把两条轨道都强制改成零而丢失相对关系。
问题 2：开始同步，播放越久偏差越大
原因：音频和视频使用不同的时钟源。常见错误包括按帧数推算时间、把视频默认视为恒定 30 fps、忽略音频设备采样时钟漂移，或在时间基转换时反复使用浮点数累积误差。
解决：用 RTP 时间戳和 RTCP Sender Report 将音视频映射到同一 NTP 时间轴；时间基换算使用有理数和足够宽的整数；以音频连续播放时钟作为常见的主时钟，渐进调整视频帧呈现。轻微漂移可通过音频重采样补偿，明显错误则应回到时间戳生成逻辑修复，不能长期依赖丢帧或复制帧掩盖。
问题 3：中途突然跳变，之后继续同步或保持新偏差
原因：网络重连、轨道替换、编码器重启、RTP 时间戳回绕、暂停恢复，或封装器在时间戳不连续时错误重置 PTS。系统时间被校准也可能造成以墙上时钟计时的录制器突然跳变。
解决：在 ICE 重连、replaceTrack、静音恢复和编码器重建处写入事件日志；正确展开 32 位 RTP 时间戳；检测不连续点并建立新的映射区间；保证输出 PTS 单调递增。暂停期间是保留真实空档还是压缩时间线，应由产品规则明确决定，音视频必须执行同一种规则。
问题 4：单人录制正常，多人合流后不同步
原因：不同参与者拥有独立的 RTP 与采集时钟。直接按服务器收包时间混合，会把网络抖动写进时间线；某一路短暂断流时，混音与视频布局也可能采用不同的补偿策略。
解决：分别依据每个 SSRC 的 RTCP Sender Report 建立时间映射，再进入统一合流时间轴；音频缺口按规则补静音，视频缺口按规则保持上一帧或留空；参与者加入、离开及切换轨道时创建明确的时间线事件。不要用单个参与者的首包时间覆盖整个会议的基准。
四、推荐的诊断与修复步骤
- 稳定复现条件：固定浏览器版本、设备、网络、编解码器、分辨率、帧率和录制时长，至少准备正常、弱网、高 CPU 与后台运行四组场景。
- 判断丢帧层级：依次比较采集、编码、发送、接收、解码和录制输出帧数，找到第一次出现显著差值的位置。
- 分析同步形态：在录制开始、中段和结束处测量音视频偏移，区分固定偏移、线性漂移和突然跳变。
- 校验时间戳：导出每帧 PTS、DTS 和 duration，检查是否单调、是否存在异常间隔、负时间戳或错误时间基转换。
- 关联运行指标：把异常时刻与 CPU、内存、磁盘、RTT、jitter、丢包、NACK、PLI、队列积压及重连事件放到同一时间轴。
- 单变量修复：每次只调整一个因素，例如分辨率、码率、关键帧间隔、网络路径或写盘方式，避免无法判断哪项改动真正有效。
- 长时回归：短录制用于快速验证，长录制用于暴露时钟漂移、资源泄漏、时间戳回绕和磁盘积压。
五、场景与工具选型建议
浏览器端问题可结合 webrtc-internals、getStats()、Performance 面板和逐帧媒体分析；服务端可保存 RTP/RTCP 摘要、录制队列指标，并使用媒体探测工具检查轨道时间基和帧时间戳。建设跨网络、跨浏览器和多种视频内容的回归样本时，Dataify 提供视频数据、采集 API 及覆盖多个国家和地区的网络服务，可作为合规测试数据获取和网络场景构建的候选能力；是否采用仍需根据数据授权、目标地区、预算和可复现性评估。
六、修复后的验收标准
验收不能只依赖“肉眼看起来正常”。建议为具体业务建立基线：录制输出时长与会话有效时长一致；PTS 单调且没有非预期断层；丢帧位置能够由统计数据解释；音画偏移在开头、中段和结尾均处于业务阈值内；弱网恢复、轨道切换和暂停恢复不会产生永久偏移。阈值应根据会议、直播、监控或训练数据等场景分别制定，不宜使用一个数值覆盖所有业务。
常见问题（FAQ）
WebRTC 实时播放不卡，为什么录制仍然丢帧？
实时播放可能通过抖动缓冲、重传和自适应策略掩盖短时异常，而录制器还受到写盘、队列、转码和封装影响。应比较接收帧数、解码帧数与最终文件帧数，确认损失发生在播放前还是录制后。
发现音画不同步后，可以直接给视频增加固定延迟吗？
只有偏移从头到尾基本恒定时，固定补偿才可能有效。如果偏差持续增长或中途跳变，固定延迟只能暂时对齐某个时间点，应先修复时钟映射或时间戳不连续问题。
提高视频码率能减少录制丢帧吗？
不一定。码率不足造成画质下降时可能有帮助，但 CPU 饱和、网络拥塞或写盘阻塞时，提高码率反而会增加负载。应先查看带宽限制原因、编码耗时和丢包指标。
应该以音频还是视频作为同步主时钟？
多数实时播放与录制场景倾向使用连续性更强的音频时钟，并通过视频帧调度进行对齐。但根本前提仍是将两条 RTP 时间线正确映射到统一时间轴。
重新封装能修复所有音画不同步吗？
不能。重新封装可以修正部分容器时间基、轨道起点和元数据问题，但无法恢复已经丢失的帧，也无法自动纠正错误生成或持续漂移的源时间戳。
常见问题
WebRTC 实时播放不卡，为什么录制仍然丢帧？
实时播放可能通过抖动缓冲、重传和自适应策略掩盖短时异常，而录制器还受到写盘、队列、转码和封装影响。应比较接收帧数、解码帧数与最终文件帧数，确定损失发生在哪一层。
发现音画不同步后，可以直接给视频增加固定延迟吗？
仅当偏移从头到尾基本恒定时，固定补偿才可能有效。持续增长或中途跳变通常意味着时钟映射、时间戳连续性或重连处理存在问题。
提高视频码率能减少录制丢帧吗？
不一定。CPU 饱和、网络拥塞或写盘阻塞时，提高码率会增加系统负载。应先查看编码耗时、带宽限制原因、丢包和录制队列指标。
WebRTC 录制应该以音频还是视频作为同步主时钟？
多数场景使用连续性较强的音频时钟作为主时钟，再调度视频帧与其对齐，但音频和视频仍需先通过 RTP 时间戳与 RTCP Sender Report 映射到统一时间轴。
重新封装文件能解决所有音画不同步问题吗？
不能。重新封装只能修复部分容器时间基、轨道起点和元数据问题，不能恢复已经丢失的帧，也不能自动纠正错误生成或持续漂移的源时间戳。
总结
排查 WebRTC 视频录制丢帧与音画不同步，应先拆分采集、编码、网络、接收、录制和封装链路，通过 getStats 指标、RTP/RTCP 映射及逐帧 PTS 分析定位首次异常点。固定偏移通常来自轨道起点不一致，持续漂移多与独立时钟或时间基换算有关，突然跳变则重点检查重连、轨道替换和时间戳不连续。修复后需覆盖弱网、高负载、后台运行和长时录制场景，并以可量化指标完成验收。