非对等WebRTC架构核心要点：采集端→SFU→浏览器
内容提要
本文介绍监控与工业相机网页低延时预览的非对等WebRTC架构：自研采集端推流、SFU中转、浏览器拉流。采集端需选用H.264无B帧，做好RTP分片与transport-cc带宽估计，合理设置IDR间隔；SFU透传RTP与RTCP；浏览器仅能提示缓冲，依赖getStats监控质量。内网设备不建议P2P直连，优先SFU中转。
延伸解读
非对等架构的独特挑战
与浏览器间对等通话不同，采集端自研、浏览器黑盒的非对等架构中，编码协商、RTP时间戳生成、带宽估计反馈等环节都需采集端主动适配浏览器能力。例如，采集端必须在浏览器支持的编码列表内选择，且需正确填写SDP的profile-level-id并声明no-bframe，否则可能导致花屏或延迟飙升。这种不对称性要求采集端承担更多兼容性责任。
采集端：延迟与稳定的主战场
文章强调，低延迟和弱网表现主要由采集端决定。关键配置包括：关闭B帧和lookahead以消除编码预读延迟；开启transport-cc并解析反馈以实现带宽自适应；做好RTP分片（FU-A）避免超MTU丢包；合理设置IDR间隔（1-2秒）并在丢包时主动输出IDR。此外，需定时发送RTCP SR报告，否则浏览器会判定流死亡。这些细节直接影响最终观看体验。
浏览器端：有限控制与监控
浏览器端的jitterbuffer、带宽估计和丢包恢复均为黑盒逻辑，JS只能通过jitterBufferDelayHint提供缓冲提示，无法强制低延迟。真正降延迟需靠采集端优化。浏览器端应使用playsinline和直接video硬件渲染，避免canvas二次绘制；通过getStats监控jitterBufferDelay、丢包率等指标；并监听ICE状态实现指数退避重连。Safari兼容性需单独测试。
部署与避坑要点
内网采集设备不建议与浏览器P2P直连，因NAT穿透成功率低，应优先使用SFU中转。采集端主动连接SFU，浏览器到SFU需STUN，企业内网可备TURN。避坑清单包括：禁止编码器开启B帧、忽略transport-cc、RTP不分片、过度依赖jitterBufferDelayHint，以及7×24运行设备缺少内存泄漏检测。遵循这些建议可提升系统稳定性。
Q&A
非对等WebRTC架构中，采集端和浏览器分别扮演什么角色？
采集端是自研程序，负责采集、编码、RTP打包和推流；浏览器是黑盒接收方，仅作为Subscriber拉流播放，不发送视频。
为什么内网设备不建议直接P2P连接浏览器？
内网设备NAT穿透成功率低，优先使用SFU中转，避免直连失败。
采集端编码器应该如何配置以降低延迟并避免兼容问题？
选用H.264 Constrained High，关闭B帧，lookahead=0，优先硬件编码，IDR间隔1-2秒，丢包时主动输出IDR。
为什么采集端必须开启transport-cc？
transport-cc是带宽估计的基础，浏览器通过RTCP反馈带宽信息，采集端据此动态调整码率，否则带宽自适应失效，网络变差会丢包花屏。
在单向观看场景下，NACK和FEC应该如何取舍？
追求最低延迟：关闭NACK，开启ULPFEC；网络好优先画质：开启NACK+少量FEC。
浏览器端如何监控WebRTC播放质量？
通过getStats读取jitterBufferDelay、接收帧率、丢弃帧、RTT、丢包率等指标。
无音频场景下，采集端应该如何处理音频轨道？
现代浏览器直接只推送video轨道；老旧浏览器可生成静音Opus虚拟音频轨道维持媒体时钟。
