详细描述
云存录像回放时间异常，包括但不限于以下情况：
音视频不同步。
前30秒只有音频，从第30秒开始有音频和视频，音视频之间相差30秒（或类似问题）。
视频回放时播放速度时快时慢。
实际录像时长为1分钟，回放时画面只显示了一瞬间，播放器闪退。
实际录像时长为1分钟，播放器进度条显示时长为16小时，且画面卡住不动。
实际录像时长为1分钟，播放器进度条显示时长远超1分钟，且无画面或无声音或即无画面也无声音。n部分播放器对于这类情况的处理也不同，最终实际的播放效果也不同，上述现象仅供参考。
原因分析
以上几种问题或类似问题都是音视频帧时间戳异常导致的。云存视频回放严格依赖时间戳，因此在推送音视频帧时务必保证时间戳正确。
下面进行逐个分析：
音视频不同步。n通常来说音视频帧的时间戳是这一帧采集的时刻，一般硬件编码器都带有时间戳，这个时间戳建议直接从编码器取出。如果编码器不带时间戳在手动添加时间戳时请尽量保证时间戳准确。
手动添加时间戳常见错误是没有考虑误差积累，特别是音频有重采样、格式转换等操作，视频有改变帧率等操作更容易引入误差，导致音视频帧的时间戳误差越来越大。
例如视频帧率是 30fps，每帧之间相差33.333……毫秒，整除为33毫秒，不进行误差补偿的时间戳为 0,33,66,99,132,165,198，补偿后为 0,33,66,100,133,166,200。
另一种情形是硬件编码的时间戳从初始化的那一刻开始计时，例如音频编码器在第0秒初始化，视频编码器在第3秒初始化，两个编码器的时间戳都是从0开始计时，两个编码器的时间戳虽然都从0开始计时，但因为初始化时间不同使拿到的音视频时间戳就始终相差3秒，导致音视频不同步。
前30秒只有音频，从第30秒开始有音频和视频，音视频之间相差30秒（或类似问题）。n同样属于音视频不同步问题，见上文。
视频回放时播放速度时快时慢。n为了光线不足时的画质，部分芯片在夜间或黑暗环境下会延长曝光时间来提升画面亮度，因此导致帧率降低。这种情况往往是手动计算帧率导致的。
例如明亮环境下默认20fps，黑暗环境下降低为 10fps，但时间戳仍然按20fps计算。n如下所示，假设在第5帧处帧率由20fps变为10fps，则：正常时间戳 0,50,100,150,200,300,400,500,600,700异常时间戳 0,50,100,150,200,250,300,350,400,450
最终的效果就是明亮环境下画面正常，黑暗环境下画面速度为正常的2倍。如果芯片的 ISP 算法会改变帧率，建议直接从编码器获取时间戳，如需手动计算时间戳请按实际帧率计算，或者在向 SDK 推送视频帧时直接从系统获取毫秒级时间戳。
实际录像时长为1分钟，回放时画面只显示了一瞬间，播放器闪退。n音视频帧的时间戳填写错误，典型情况就是误将时间戳填写为帧序号。
假设帧率为20fps：正常时间戳 0,50,100,150,200,300,400,500,600,700异常时间戳 0,1,2,3,4,5,6,7,8,9
播放的效果为画面以正常速度的50倍进行快放，即1分钟的视频仅用1秒左右就播放完了，给人的感觉就是画面只显示了一瞬间，播放器闪退。
实际录像时长为1分钟，播放器进度条显示时长为16小时，且画面卡住不动。nSDK 接收的音视频帧时间戳单位是毫秒，造成这种情况是误将时间戳填成了微秒，使得1分钟的录像变为了16小时，画面其实并没有真正卡住，而是以相当于千分之一的速度慢放。
实际录像时长为1分钟，播放器进度条显示时长远超1分钟，且无画面或无声音或即无画面也无声音。n这种情况是音视频使用了不同的时间戳导致的。例如音频的时间戳从0开始计时，视频的时间戳从当前 UTC 事件开始计时，两者相差的时间非常大，使得播放器的进度条显示的时间异常以及播放异常。nSDK 要求必须填写音视频帧的时间戳，但不对时间戳的参考时间做强制要求，用户可以根据自己的实际情况填写。例如长供电设备的时间戳可以使用精确到毫秒的 UTC 时间，断电设备的时间戳可以从0开始计时，或者也可以使用其他值同时作为音视频时间戳的基准。总之音频和视频一定要使用相同的参考时间或相同的时间源，不要各自用各自独立的时间源。
解决方法
保证音视频时间戳准确无误（手动计算时间戳时考虑误差、可变帧率等情况），保证音视频时间戳采用相同的参考时间或相同的时间源（例如编码器时钟、RTC 时钟、UTC 时钟、1毫秒 tick 时钟等）。
