iOS-to-iOS WebRTC加密通话视频无显示问题排查求助

核心排查方向 #

结合现有测试结果（加解密日志正常、音频播放正常、注释加密代码后视频恢复），问题大概率出在iOS端加解密器对视频帧的非内容性处理异常，以下是具体分析：

1. 视频帧元数据损坏 #

iOS端的FrameEncryptorInterface/FrameDecryptorInterface在处理视频帧时，可能误修改了帧的元数据（宽高、旋转角度、时间戳、像素格式）。虽然加解密后的像素字节一致，但元数据错误会导致渲染组件无法正确解析帧：

• 对比加密前后RTCVideoFrame的width/height/rotation/timeStampNs参数，确保解密后完全还原原始值。
• 检查解密后的pixelFormat是否与原始帧一致，比如是否误将kCVPixelFormatType_420YpCbCr8BiPlanarFullRange改为其他不兼容格式。

2. 视频帧字节长度对齐错误 #

WebRTC对YUV等格式的视频帧有严格的字节长度对齐要求，加密解密过程中可能破坏了这一规则：

• 验证解密后视频帧的总字节数、Y/U/V三个平面的字节数是否与原始帧完全匹配（比如Y平面字节数=宽×高，U/V平面=宽×高/4）。
• 排查加密时是否额外添加了IV、校验位等字节，但解密后未完全移除，导致帧数据长度超出预期。

3. 视频缓冲区处理逻辑异常 #

iOS端解密器返回的视频缓冲区可能存在内存管理或拷贝逻辑错误，导致渲染时无法获取有效数据：

• 检查解密后是否正确调用了RTCVideoBuffer的拷贝方法（如copy），而非直接返回原始缓冲区的引用（可能被提前释放）。
• 确认解密后的缓冲区isMutable属性是否符合WebRTC渲染管线的要求，避免因不可写导致帧被丢弃。

4. 首帧处理时序错位 #

iOS-iOS场景下，视频首帧的解密时机可能晚于渲染组件的初始化：

• 梳理日志中首帧加密、解密、渲染的时间线，确认解密后的首帧是否及时传递给渲染组件。
• 检查是否存在首帧被加解密器拦截但未正确转发的情况，导致渲染端一直处于等待状态。

5. 字节序隐性差异 #

虽然整体字节数组对比一致，但iOS端加解密实现可能在视频帧头部的字节序处理上存在隐性问题：

• 逐字节对比原始视频帧头部（前100字节）与iOS-iOS解密后的头部，确认完全一致（Android-iOS场景下WebView的JS处理可能自动兼容了字节序差异）。

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