这几天搞文件回放,视频格式是H264,音频是PCM,使用FFMPEG来读取音视频,然后用ffmpeg来解码显示,所有的一切还算顺利,但音视频同步花了我很多时间,总也搞不清楚为什么会差很多。音视频同步的原理当然是根据音频的pts来控制视频的播放,也就是说在视频解码一帧后,是否显示以及显示多长时间是通过该帧的PTS与同时正在播放的音频的PTS比较而来的,如果音频的PTS较大,则视频显示完毕准备下一帧的解码显示,否则等待。
本以为问题到这就算结束了,但程序运行的时候怎么发现机器这么慢呀,看了下CPU占用率,达到100%。很显然使用这个做等待是不行的了。
于是继续google,网上有说timesetevent什么的,我没有试。感觉麻烦了些。后来想到以前看过的一篇用WaitForSingleObject来做定时让某段代码执行的,于是试了试,一试之下立即发现效果明显,CPU占用率一下子回到了个位数。更改后的代码如下:
具体实现时遇到的问题:
问题一:没办法得到正在播放的音频帧的PTS,因为进行音频播放使用的DirectSound,而对于DirectSound我只能得到当前拷入DirectSound的缓存的帧的PTS,而无法得到正在播放的PTS,如果得不到正在播放的帧的PTS的话,那同步肯定是不可能的了。在网上找资料好象也没找到有用的,最后突然想到由于音频帧的大小与时间成正比,那么DirectSound的缓存中的数据所需要的播放时间就可以计算得出,再根据当前正在拷入的音频帧的PTS,就可以得到正在播放的帧的PTS,再用这个就可以正确同步视频帧的显示了。
问题二:根据上面的方法处理后还是出现不同步的现象,为什么这样我也是百思不得其解,后来才发现是等待机制有问题,原来我是用Sleep()来做等待的,但实际上Sleep()的误差很大的,网上有说有15MS,做音视频同步肯定是不行的了,经过不断的google,找到一份代码:
void MySleep(int interval)
{
LARGE_INTEGER litmp;
LONGLONG QPart1,QPart2;
double dfMinus, dfFreq, dfTim;
QueryPerformanceFrequency(&litmp);
dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
QueryPerformanceCounter(&litmp);
QPart1 = litmp.QuadPart;// 获得初始值
do
{
QueryPerformanceCounter(&litmp);
QPart2 = litmp.QuadPart;//获得中止值
dfMinus = (double)(QPart2-QPart1);
dfTim = dfMinus / dfFreq;// 获得对应的时间值,单位为秒
}while(dfTim<0.001 * interval);
}
}
可以达到精度比较高的等待,从效果看,也可以达到音视频同步。
本以为问题到这就算结束了,但程序运行的时候怎么发现机器这么慢呀,看了下CPU占用率,达到100%。很显然使用这个做等待是不行的了。
于是继续google,网上有说timesetevent什么的,我没有试。感觉麻烦了些。后来想到以前看过的一篇用WaitForSingleObject来做定时让某段代码执行的,于是试了试,一试之下立即发现效果明显,CPU占用率一下子回到了个位数。更改后的代码如下:
void MySleep(int interval)
{
HANDLE evt;
evt = CreateEvent(NULL, TRUE, FALSE, NULL);
WaitForSingleObject(evt, interval);
CloseHandle(evt);
}