一、使用采集卡提供的pts
二、手动打pts
1.usb采集设备pts的问题
2.采集卡驱动,UVC/UAC,ffmpeg的关系
3.如何自己打pts
4.音视频同步调优
5.NTP等联网调时工具带来的不同步问题
一、使用采集卡提供的pts
我们用使用pc摄像头和使用pc麦克风声卡里的方法,用ffmpeg采集后会得到音视频的pts。
我们应该尽量用好这些pts,因为他们的时间间隔很精准,比如48000,每次采集2048,发现每帧间隔23ms;视频采集1080p25,每帧间隔40ms。
使用之前我们需要把他们同步到同一个时间戳,其中一个方法是:
dif = 格林威治时间 - 第一帧采集到的视频时间戳
然后以后每次pts = pts + dif。
V:
AVDictionary *options = NULL;
av_dict_set(&options, “video_size”, “1920x1080”, 0);
av_dict_set(&options, “framerate”, “30”, 0);
//以上参数如果不设置的话,ffmpeg就会用默认值,但默认值摄像头不一定支持
int re = avformat_open_input(&ic, “/dev/video0”, ifmt, &options);
A:
av_dict_set(&options, "sample_rate", "48000", 0); // 只能是48000不支持改动
av_dict_set(&options, "channels", "2", 0); // 无法改,不支持改动
long long GetCurTime()
{
struct timeval tv;
gettimeofday(&tv, NULL);
// ZlogInfo("second:%ld\n",tv.tv_sec); //秒
// ZlogInfo("millisecond:%ld\n",tv.tv_sec*1000 + tv.tv_usec/1000); //毫秒
// ZlogInfo("microsecond:%ld\n",tv.tv_sec*1000000 + tv.tv_usec); //微秒
long long temp_time = tv.tv_sec * 1000000 + tv.tv_usec;
return temp_time;
}
if(this->dif_PTS == 0) this->dif_PTS = GetCurTime() - read_pkt.pts;
read_pkt.pts = read_pkt.pts + this->dif_PTS;
二、手动打pts
1.usb采集设备pts的问题
decklink的采集卡,会把音视频的pts给好,并且是可靠的。但小的厂商就不一定了。我这里使了一个台湾和国内的厂商,一个是pci采集卡(sdi/hdmi采集转pci口),这个采集卡支持UVC和UAC协议,另一个是usb(hdmi转usb口)采集卡。这两个价格都在千元左右。
跟这两个采集卡的原厂技术沟通,pts存在以下问题
1:音频和视频的pts没有关系,没有共同的起点或相关的联系。
2.pts经过一夜测试后发现,有跳变的现象。
3.采集1080p30时,视频的pts,每帧之间只增加20ms,而不是33ms,其他分辨率无此问题。
因为这些设备的用户大多数不是开发者,所以这些问题都不会用到,对于开发者来说则需要原厂定制开发了。
2.采集卡驱动,UVC/UAC,ffmpeg的关系
在与原厂电话微信后,对usb的采集卡有初步的了解,对于音频来说,采集卡的驱动并不会提供pts给系统,因为对于音频来说,确定好采样率,声道数,位深,那么在播放端,它的采样数对应的播放时间是固定的,采集卡只有一个晶振在控制着采集频率,音频从采集卡采集到其提供给驱动,延时可以忽略。
视频采集卡的驱动也不会有pts,它的启动只会对上层提供类似于1,2,3…等视频的序号的标签,采集卡从采集到提供给驱动,可能会有几帧,如4帧延时。
那么我们用ffmpeg采集到的音视频,都含有pts,那么这些pts是什么呢。音频是1970年开始到现在的us,视频则是开机的时间us。他们都是UVC和UAC协议对采集卡驱动提供的音视频帧打的pts。
硬件厂商改一个问题,要改好几个版本,经常引入其他bug,看来天下程序员都一样。
3.如何自己打pts
那么我们该怎么自己打pts呢?
在两个线程里分别采集音视频:
av_read_frame()
我们把格林威治的PTS赋值给每次采集到的音视频数据。
A:
re = av_read_frame(ic_a, &read_pkt_a);
read_pkt_a.pts = GetCurTime();
V:
re = av_read_frame(ic, &read_pkt);
read_pkt.pts = GetCurTime();
ZlogInfo("dif:%ld\n", (shm_->GetCurTime() - LAST_PTS) / 1000);
LAST_PTS = shm_->GetCurTime();
视频每次从这个函数返回的时间间隔分别是:
//1080p25 39 40 39 40 39 40 39 40 39 40 39 40 ms
音频分别是:
//1080p25 41 0 42 0 42 0 41 0 41 0 42 0 ms
有时是
//1080p25 21 0 41 21 0 40 22 0 41 1 40 0 42 0 41 22 0 41 0 42 0 42 1 40 22 0 41 21 1 40
0并非没有间隔而是小于1ms,这里有精度损失。
可以看到间隔并不标准,因为av_read_frame()维护了一个缓存,他每次从采集卡拿到一阵或多帧音频或视频数据放入缓存,然后分包,返回一帧音频或视频数据,下次再调用直接去缓存里拿,如果缓存没有则阻塞住,直到采集卡提供了数据。
我们需要让他们的时间间隔相对均匀,那么每次的pts就和上次比较,如果少于一定时间则睡眠。
ZlogInfo("dif:%ld\n", (shm_->GetCurTime() - LAST_PTS) / 1000);
if((shm_->GetCurTime() - LAST_PTS) / 1000 < 10) usleep(10000);
pkt->pts = shm_->GetCurTime();
ZlogInfo("dif_last:%ld\n", (shm_->GetCurTime() - LAST_PTS) / 1000);
LAST_PTS = shm_->GetCurTime();
那么再次打印如下:
V:
//39 40 39 40 39 40 39 40 39 39 39 39 40 40
A:
//1080p25 31 12 30 10 32 10 31 11 31 10 32 11 30 10 32 10 32 10 30 10 31 11 31 10 31 10
4.音视频同步调优
因为采集视频到交给ffmpeg可能有几帧的缓存,因此每次的视频数据可以减去100ms左右,看看播出后的视频效果。
pkt->pts = shm_->GetCurTime() - 100000;
播放器的音视频同步策略一般都是按以音频为基准,音频是线性均匀的,那么音频的pts本身是没有意义的,两帧之间的间隔并不代表播放的时间间隔,它的意义主要是用于视频与他同步。
如果想要音频的间隔再均匀一些,可以调节以下睡眠的时间。
5.NTP等联网调时工具带来的不同步问题
pc每次开机联网后,系统自带NTP开始核对时间,并改变自身时间,那么你每次打的pts就会产生突变。NTP每次调剂的幅度可能在500ms左右,可以关闭它,或换小一点的工具,每次调解幅度在10ms左右的。