RTSP-Simple-Server中WebRTC AV1/HEVC在Android设备上的兼容性问题分析

问题背景

在RTSP-Simple-Server项目中，当使用WebRTC协议传输AV1或HEVC编码的视频流时，Android客户端会出现无法播放的问题。服务器日志显示"codecs not supported by client"的错误提示，但实际上这些Android设备是支持AV1解码的。

技术分析

经过深入分析，发现问题的根源在于WebRTC协商过程中的transceiver方向设置。当前RTSP-Simple-Server在创建WebRTC连接时，将transceiver方向设置为"sendrecv"(双向收发)，这会导致SDP协商时只包含设备同时支持编码和解码的编解码器。

对于Android设备而言，虽然它们支持AV1解码(播放)，但大多数设备并不支持AV1编码。因此当使用"sendrecv"方向时，AV1编解码器不会出现在SDP协商中，导致播放失败。

解决方案探讨

理论上，将transceiver方向改为"recvonly"(仅接收)可以解决这个问题，因为这样SDP协商时只需要考虑设备的解码能力。实际测试表明，修改后AV1流在Android设备上可以正常播放。

然而，项目维护者指出当前使用"sendrecv"方向是为了解决pion/webrtc库中的一个已知问题：在某些浏览器(特别是Firefox)中随机无法读取H264流的问题。这是一个临时的解决方案，待底层库的H264问题修复后，将会把方向改回"recvonly"。

技术启示

这个案例展示了WebRTC实现中的几个重要技术点：

1. SDP协商机制：编解码器支持列表与transceiver方向密切相关
2. 编解码器能力分离：设备可能支持解码但不支持编码同一编解码器
3. 兼容性权衡：有时需要为特定问题采用临时解决方案
4. 客户端多样性：不同平台和浏览器对WebRTC的实现存在差异

总结

RTSP-Simple-Server中WebRTC的AV1/HEVC在Android设备上的兼容性问题，本质上是由于当前采用的"sendrecv"方向与Android设备编解码能力不匹配导致的。虽然技术上可以通过修改为"recvonly"解决，但项目出于整体兼容性考虑暂时保留了当前实现。开发者在使用时需要注意这一限制，或者可以等待项目后续版本中底层问题的修复。