播放/录制故障：录制丢帧及DTS非单调递增错误排查

核心错误原因 #

Application provided invalid non monotonically increasing dts to muxer in stream 0 这个错误明确指向音视频封装时，输入的解码时间戳（DTS）不是单调递增的——也就是后续帧的DTS比前面的帧小，违反了封装格式的时序要求，这是导致录制功能异常的直接原因。结合你的场景，问题大概率出在录制模块的时间戳管理逻辑上，且和播放场景的状态切换强相关。

可能存在的逻辑漏洞 #

• 录制启动/重启时的时间戳未正确初始化
  如果运动触发后是重新启动录制（而非暂停后恢复），但没有彻底清理之前的录制上下文，比如待机阶段可能已经在预录制，触发后新的录制时间戳没有从合理起点（比如0或当前系统时间）开始，反而沿用了旧的、已累积较大的时间戳，或者错误重置为更小的值，就会出现DTS不递增的情况。

• 播放与录制的时间戳逻辑混淆
  你的场景中播放和录制并行，如果录制模块错误复用了播放视频的DTS/PTS（比如试图做同步），当播放完成回到第一帧时，播放的时间戳会回退，进而导致录制的时间戳也跟着回退，被封装器判定为无效。播放和录制的时间线完全独立，绝对不能混用。

• 状态切换时的录制暂停/恢复逻辑有问题
  待机阶段（停留在第一帧）如果录制处于暂停状态，但时间戳计数器没有冻结，恢复录制时没有计算暂停的时长差，直接继续生成时间戳，就会出现后续帧的时间戳比暂停前最后一帧小的情况；或者切换状态时没有清空旧的时间戳缓存，新帧的时间戳被旧值覆盖，造成时序混乱。

• 自定义时间戳生成逻辑错误
  如果录制模块是自行生成时间戳（而非使用摄像头硬件提供的原生时间戳），在待机、触发、回到待机的状态循环中，时间戳生成没有保持连续递增。比如待机时时间戳一直在累加，触发后突然重置为0，导致封装器收到的帧时序颠倒。

排查与修复方向 #

• 隔离播放与录制的时间戳：确保录制模块只使用摄像头流自身的时间戳（优先用硬件提供的），完全独立于播放模块的时间线，避免任何形式的复用或同步。
• 检查状态切换时的录制上下文：运动触发时，如果是重启录制，要彻底销毁旧的录制器实例，重新初始化时间戳计数器；如果是恢复录制，要记录暂停时的最后一个时间戳，恢复时基于这个值继续递增（可加上暂停的时长）。
• 打印时间戳日志：在录制模块输出每帧的DTS/PTS值，重点观察运动触发前后、播放完成回到第一帧时的时间戳变化，定位到具体哪一步出现了时间戳回退或乱序。
• 验证摄像头流的原生时间戳：如果使用摄像头硬件时间戳，确认摄像头输出的帧时间戳本身是单调递增的，排除硬件驱动层面的问题。

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