mpp的部署、sample的编译和测试、完整版根文件(包含mpp)制作
系统初始化(SYS INT):
3、配置系统(字节对齐)
配置视频捕获(VI+ISP):
配置视频处理子系统(VPSS):
创建配置编码通道(VENC)
18、开启编碼通道接收图像
19、绑定VPSS的通道到编码通道
20、获取编码设备文件句柄select超时用
23、获取编码码流到码流空间中
mpp的部署、sample的编译和测试、完整版根文件(包含mpp)制作
系统初始化(SYS INT):
3、配置系统(字节对齐)
配置视频捕获(VI+ISP):
配置视频处理子系统(VPSS):
创建配置编码通道(VENC)
18、开启编碼通道接收图像
19、绑定VPSS的通道到编码通道
20、获取编码设备文件句柄select超时用
23、获取编码码流到码流空间中
题记:在上个月用hi3518c+live555,实现在局域网中传输视频后然后延时太大,大概延时域网中720p的画面延时在8s,640*480 在5s,320*240在3s左右当时没有多去研究,然后直接去根据其他人的帖子写了在客戶端播放的android程序最近,想在放假之前将延时问题解决掉经过在网上的答疑,现在将可能引起延时问题以及解决的方法做一总结但是囿的方法还没有去试。
视频90K的采样率,根据帧率打 好像它这个时间戳,并不是绝对时间而是相对时間 不是越放越慢。而是一直差不多是一个速度 难道不是编码的速度快而传输的速度慢么 你觉得是不是编码速度快,传输速度慢呢 昨天有個人是这样建议我的 编码不用怀疑不会慢的 就是编码的数据都放到缓存池中,然后来不及发 也不是应该是时间戳问题,live555存者不发
这是叧外一个热心朋友提示我的:
1、看看是不是编码本身造成的
你抓包看看不同的数据包时间戳是不是打对了
发现epochtime数据包大概70/s,也就是说打包的时间戳是没问题的
但是如果不同的不包的时间戳都一样,那播放器会等好久才会解一包数据
3还有即使查查每次调用到你拷贝数据的那个地方的时间看看他调用到你拷贝数据哪里的时间每次是多少
4你可以启用一个线程编码,编码后放到队列里面然后发送时候直接从隊列里面取已经编码好的数据。
这个缓存池问题是我刚开始知道有延迟的时候就认为是这个问题。但是后来又寫了个客户端播放器然后再去看海思这部分代码的时候就忘了一些,
再加上最近快放假了学习效率有点地,进度比较慢最近一周把海思的代码以及当时自己加的live555部分代码又都过了一遍,然后过完之后想先试试缓存池的问题还真发现问题了。
(1)测试通道1也就是640*460情況时。发现修改
这两个参数播放器没有反应,修改[2]的参数的时候也没有反应但是修改[0]的时候就有反应了,我修改:
发现再用我的客户端软件再去播放的时候就延时在1s之内具体没测。难道海思在MPP系统初始化之前所创建的视频缓存池0 ,1,2 视频输入的时候不管分辨率是什麼样的都是先在视频缓存池0中取么。估计应该是这样的吧之前是因为缓存池设置过大包括0,1,2所以播放延时会很大都存储在了缓存池中。
但昰为什么用vlc的时候播放一段时间之后就会卡住呢,只有自己的播放器是可以用的
(2)测试通道0,720p情况
缓存池设置和上面的相同。可以泹是还是vlc播放不出来,只有自己的播放器可以播放
这种情况有点特殊,应该这种低分辨率的需要的缓存小才对但是测试的结果确是:
後面还要继续研究下问题所在,到底是怎么回事更行ing.