Screego项目中WebRTC编解码器偏好设置问题的分析与解决

在Screego项目的实际使用中，部分Chrome浏览器版本（如131.0）会出现一个与视频编解码器相关的技术问题。当用户将首选编解码器设置为VP9时，控制台会抛出"Invalid codec with name 'H264'"的错误提示，导致屏幕共享功能无法正常工作。

问题现象分析

该问题的核心表现是：在RTCRtpTransceiver接口执行setCodecPreferences方法时，系统无法识别H264编解码器。通过错误堆栈可以定位到问题发生在WebRTC的编解码器偏好设置环节。值得注意的是，这个问题具有版本特异性：

• Chrome 131.0版本会出现此问题
• Chrome 120.0及Edge 134.0版本则表现正常

技术背景

WebRTC规范中定义了RTCRtpSender和RTCRtpReceiver两个关键接口，它们分别负责媒体流的发送和接收端能力协商。其中：

• RTCRtpSender.getCapabilities() 返回发送端支持的编解码器能力
• RTCRtpReceiver.getCapabilities() 返回接收端支持的编解码器能力

在早期的WebRTC实现中，这两个接口返回的能力集通常是相同的。但随着规范的演进和浏览器实现的差异，某些情况下可能会出现发送端和接收端能力不一致的情况。

问题根源

经过深入分析，发现问题源于代码中错误地使用了RTCRtpSender.getCapabilities()来获取编解码器能力。在Chrome 131.0版本中，发送端能力集可能不包含接收端实际支持的编解码器，特别是当涉及到H264和VP9这类复杂编解码器时。

正确的做法应该是使用RTCRtpReceiver.getCapabilities()，因为：

1. 接收端能力集通常更全面
2. 编解码器偏好设置最终影响的是接收端的解码能力
3. 符合WebRTC规范的最新演进方向

解决方案

将原有代码从：

RTCRtpSender.getCapabilities('video')?.codecs.forEach((codec) =>...

修改为：

RTCRtpReceiver.getCapabilities('video')?.codecs.forEach((codec) =>...

这一修改确保了编解码器偏好设置基于接收端的能力，避免了因发送端能力限制导致的问题。修改后：

• 错误提示消失
• VP9编解码器可以正常使用
• 屏幕共享功能恢复

兼容性考虑

虽然这个问题在特定Chrome版本中表现明显，但采用RTCRtpReceiver的方案具有更好的向前兼容性。它能够适应：

• 不同浏览器版本的能力差异
• 发送端和接收端能力不对称的场景
• 未来可能新增的编解码器支持

总结

这个案例展示了WebRTC实现中一个典型的兼容性问题。开发者在使用较新的WebRTC特性时，应当注意：

1. 浏览器版本差异可能导致API行为变化
2. 发送端和接收端能力协商需要区分对待
3. 规范演进过程中最佳实践可能发生变化

通过这个问题的解决，不仅修复了特定版本的兼容性问题，也为Screego项目建立了更健壮的编解码器协商机制，为后续功能扩展打下了良好基础。