使用Kurento v6.6.1录制Android原生端视频损坏问题技术问询

针对你遇到的Android端录制视频帧集中在开头几秒的问题，结合Kurento 6.6.1和Nubomedia webrtcpeer的技术栈，我整理了几个核心排查方向和解决方案：

可能的原因及对应修复方案 #

1. 老旧LibJingle版本的时间戳同步缺陷 #

你使用的LibJingle v11139是2015年底的版本，这个版本在Android多硬件平台上存在媒体时钟与系统时钟不同步的问题，导致发送的RTP视频帧时间戳不连续或起始值异常，Kurento的RecorderEndpoint会错误地将这些帧映射到同一个时间窗口。

解决办法：

• 优先升级WebRTC依赖：替换Nubomedia webrtcpeer为官方维护的WebRTC Android SDK（比如最新稳定分支），新版本修复了大量Android平台的时钟同步和时间戳生成问题。
• 若无法升级，手动校验时间戳：在Android端的视频捕获回调中，检查VideoFrame的timestampNs字段，确保每帧的时间戳是基于单调递增的媒体时钟生成的，避免使用系统时钟（System.currentTimeMillis()）来生成时间戳。

2. Kurento RecorderEndpoint的时间戳解析逻辑问题 #

Kurento 6.6.1的RecorderEndpoint在处理非标准RTP时间戳时，可能会默认使用系统时间来构建视频时间轴，而非流本身的时间戳，导致Android端的帧被压缩到开头。

解决办法：

• 调整Recorder配置：创建RecorderEndpoint时，确保启用基于流时间戳的录制模式。如果使用Java客户端，可以尝试设置useAbsoluteTime(false)（具体参数以Kurento 6.6.1的API为准），让Kurento直接使用RTP流中的时间戳来计算帧的播放位置。
• 检查媒体配置：确认录制的MP4容器是否启用了时间戳同步，避免因容器格式的元数据错误导致播放时时间轴异常。

3. Android硬件编码器的时间戳异常 #

部分Android设备的硬件H.264编码器会生成不符合标准的时间戳（比如重复、间隔过大/过小），Kurento无法正确识别帧的时间间隔，最终导致所有帧挤在开头。

解决办法：

• 强制使用软件编码器：在Android端初始化PeerConnectionFactory时，添加配置mediaCodecHwAcceleration=false，切换到软件编码模式，软件编码器生成的时间戳更规范，兼容性更好。
• 手动校准时间戳：在视频捕获的onCapturedFrame回调中，手动计算每帧的时间间隔（比如25fps对应每帧间隔40ms），调整VideoFrame的timestampNs值，确保时间戳连续且符合帧率要求。

4. 音频编码格式不匹配导致的同步问题 #

Android端使用Opus音频编码，而Web端使用AAC，Kurento在同步音视频流时，可能因两种编码的时间戳基准不同，错误地压缩了视频时间轴。

解决办法：

• 统一音频编码：将Android端的音频编码改为AAC，与Web端保持一致，减少Kurento在同步音视频时的时间戳解析差异。
• 添加同步组件：在Kurento媒体管道中引入SyncMediaPipeline，强制对齐音视频流的时间戳基准，确保两者的时间轴同步。

验证排查步骤 #

1. 抓包分析RTP流：用Wireshark捕获Android端发送到Kurento的RTP视频流，检查每帧的时间戳是否连续递增，间隔是否与设置的帧率匹配（比如25fps对应每帧时间戳间隔约40ms）。
2. 查看Kurento日志：检查Kurento的RecorderEndpoint相关日志，是否有时间戳异常的警告或错误信息，这能直接定位问题根源。
3. 排除网络影响：在稳定的网络环境下测试，排除因网络抖动导致的RTP帧丢失或乱序，进而引发的时间轴异常。

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