Chrome Android与Chrome Desktop的WebRTC编码解码兼容性问询

从你的测试结果来看，Chrome Android 和 Chrome Desktop（v64及以上版本）之间的WebRTC音视频通信并非完全可靠——虽然两者都官方支持getUserMedia、RTCPeerConnection和RTCDataChannel这套标准WebRTC接口，但实际互通时确实会出现你遇到的这类跨端收发异常问题，尤其是Chrome Desktop↔Chrome Android、Chrome Android互连的场景。

结合我处理过的类似开发者案例，这类问题通常和以下几个因素有关：

• 编码格式协商不匹配：Chrome Desktop和Android端的Chrome对音视频编码的默认优先级有差异。比如桌面端可能优先选择VP9编码（压缩效率更高），但部分中低端Android设备的硬件解码器对VP9支持不完善；音频方面，虽然OPUS是标准，但某些Android设备的音频硬件可能存在兼容性bug。你可以通过调用RTCPeerConnection.getStats()获取详细统计数据，查看双方最终协商出的编码格式是否一致，是否存在解码失败的统计项。
• 硬件编解码的兼容性bug：Chrome Android默认启用硬件加速来处理音视频编解码，这在大多数设备上没问题，但部分设备的硬件编解码器存在厂商定制的bug，无法正确解析桌面端发送的码流。你可以尝试在Chrome Android的chrome://flags中禁用#disable-accelerated-video-decoding和#disable-accelerated-video-encoding选项，改用软件编解码测试是否恢复正常。
• NAT穿越与ICE候选协商问题：Android设备的网络环境（比如移动网络的NAT类型更复杂）可能导致ICE候选收集不完整，或者STUN/TURN服务器的兼容性问题，进而导致媒体流无法建立传输通道。建议你检查ICE候选的交换日志，确认双方是否成功获取并交换了有效的连通候选（比如主机候选、中继候选）。
• 媒体权限与后台限制：Chrome Android对媒体权限的管控比桌面端更严格，比如应用退到后台时可能会限制摄像头/麦克风的访问，或者用户在权限申请时误操作导致媒体设备未正确初始化。确保Android端Chrome已获得相机和麦克风权限，且媒体流在创建过程中没有抛出错误。

针对这类问题，你可以尝试以下排查和修复方案：

1. 显式指定编码优先级：在RTCRtpSender.setParameters()中强制指定兼容性更好的编码格式，比如优先使用H.264（多数设备硬件支持更成熟），音频固定使用OPUS，减少协商过程中的不确定性。
2. 增加错误监听与日志收集：为RTCPeerConnection添加oniceconnectionstatechange、ontrack事件的错误处理，同时监听媒体流的onerror事件，捕捉具体的失败信息，帮助定位问题环节。
3. 利用WebRTC调试工具：桌面端通过chrome://webrtc-internals/查看详细的会话统计和错误日志；Android端可以通过Chrome远程调试功能连接到桌面Chrome，同样查看WebRTC内部的调试数据，精准定位编码、解码还是传输环节出了问题。

内容的提问来源于stack exchange，提问作者Laphaze