背景介绍
开发流媒体服务器时, 流媒体服务器对海康摄像头进行直播拉流时，针对视频，一般获取到的一个有效帧作为基准时间戳，
后续的时间戳在此基础上进行递增，但是发现海康的摄像头运行一段时间之后会出现当前的绝对时间戳小于基准时间戳的情况.
打印的部分日志如下:
[Date: 2016.9.14, Time: 16:24:54:914]
当前时间戳absoluteTimestamp(8) < 基准时间戳m_dbBaseVideoTime(24924990). Drop it.
[Date: 2016.9.14, Time: 16:24:54:961]
当前时间戳absoluteTimestamp(48) < 基准时间戳m_dbBaseVideoTime(24924990). Drop it.
[Date: 2016.9.14, Time: 16:24:55:23]
当前时间戳absoluteTimestamp(88) < 基准时间戳m_dbBaseVideoTime(24924990). Drop it.
[Date: 2016.9.14, Time: 16:24:55:39]
当前时间戳absoluteTimestamp(128) < 基准时间戳m_dbBaseVideoTime(24924990). Drop it.
[Date: 2016.9.14, Time: 16:24:55:70]
当前时间戳absoluteTimestamp(168) < 基准时间戳m_dbBaseVideoTime(24924990). Drop it.
分析可能是时间戳又重新开始计算了.
所以考虑是不是可以用流媒体服务器本机的时间作为视频和音频的时间戳.
采用系统时间戳作为视音频时间戳
C++代码如下:
// 用系统的时间作为时间戳
// 单位毫秒ms
inline INT64 GetCurrentTimeAsTS()
{
LARGE_INTEGER curTimeCount;
LARGE_INTEGER timeFreq;
QueryPerformanceFrequency(&timeFreq);
QueryPerformanceCounter(&curTimeCount);
return (INT64)(curTimeCount.QuadPart * 1000.0/ timeFreq.QuadPart) ;
}
设备信息
设备实际视频参数
设备实际音频参数
分析结果
用系统时间戳作为视音频的时间戳，效果很不好.
- 正常的相邻时间戳差值.
视频正常的相邻时间戳差值 为40ms 实际帧率25帧/s
音频正常的相邻时间戳差值 都在23ms附近 实际采样率44.1kHz
- 用系统时间戳作为时间戳时的分析结果
视频的相邻时间戳差值
音频的相邻时间戳差值
可以看出，用系统时间戳作为音视频时间戳时，视频和音频的相邻时间戳波动幅度很大，造成这种情况的主要原因是由于网络波动情况会导致数据包达到的时间会出现波动. 实际观看时会存在音频卡顿等现象.
结论是不适合用系统的时间戳作为视音频的时间戳，还是优先使用设备本身提供的时间戳.
