实验室实时视频传输项目历程

2012-7~2012-8 之前总结

之前总结：

7月底开始接手倩倩师姐做的项目部分，在实验室内部称为“图像组”。在实验室，每一届“图像组”只有1到2个人，基本都是一个人在干活，这一届就是我了。王菲号称去做图像算法部分，但实际工作时负责实验室报账等工作。技术上也就不指望了。说一下“图形组”这个称呼，虽然叫图像组，但实际上并没有研究出啥图像处理算法。我称之为“无线视频传输项目”。倩倩师姐解决了Linux下em28xx芯片驱动问题，后来我和她一起解决了传输一段时间后程序退出问题。这些在我的谷歌文档--“技术问题解决”中有介绍。

从7月底接手实时视频传输项目到现在已经有两个半月了。

7月底——8月10号：熟悉了视频传输项目相关程序。构建了方便的工作平台，包括编译库整理，网络文件系统NFS，大大方便了实验。

8月7号的时候老板让做火点的跟踪，也就是检测出火点后通过串口通信告诉ARM目标点，然后ARM控制另一个芯片来控制舵机。当时让“郎神”与我合作，他负责ARM部分。但郎基本不来实验室。所以这个放假前没做出来。

8月23号-9月22号  完成转台跟踪

在这段时间里，我做了：

(1)与林冰洋一起调通了3530与ARM串口通信，来控制舵机。我用简单的PI控制，使对火点有了较好的跟踪效果。

（2）将火点检测部分融入了RTSP流媒体程序部分。完成了相关图像格式转换。

（3）做了飞机上云台的支架部分。纯属机械部分。

9月22号~10月1号 调通硬件压缩

有师弟“朱”搭建了利用OMAP3530上的DSP硬件压缩视频功能，于是这段时间完成了与我的RTSP流媒体整合，使我的原系统采用硬件压缩。

技术路线：当时我考虑有两个方法，完成整合。（1）融合为一个程序。（2）采用IPC（进程通信）方式，交换采集到的图片和压缩后的图片。      我很快采用了第二种方法。该方法实现简单，可以快速完成程序改动与调试。同时也便于后面整个系统的扩展。

详细介绍：

IPC采用了共享存储方式。有三个共享内存块。一个用来传递采集到得图片，一个用来传递压缩后的图片；还有一个负责传递标志信号和压缩后图像的size变量。

遇到问题：

（1） 问题：硬件压缩程序运行一段时间后，自动关闭。

解决：在一块3530板上第一次运行时总会遇到这种问题，但后来再运行就不会再发生。We don't know thereason.

 10月9号-10月16号 调通硬件H264压缩,VGA（640*480）格式

在这一个星期中，老板很想做高清视频的传输。最开始他想做1080P（image_size:1920*1080）的视频无线传输。用了几天时间才让他明白，这个无法做到，而且对于我们的项目没有多大意义。后来老板终于降到了720P（1280*720）格式。

微软的摄像头经常出问题，影响了工作进展，但老板就很喜欢那个微软摄像头。隔了两天才买了罗技的摄像头。

我先将程序改为352*288，调通。老板紧逼高清，跟他说明图像处理需要时间长后，降到了VGA（640*480）格式。

问题:VGA格式的调通后发现图像质量与原图差距太大，解压缩后的图像严重模糊。而且压缩时间为60ms，时间太长。

解决：原硬件压缩程序设置的是30帧视频中只有1帧用帧内编码，其他29帧全用帧间编码方式。 设置只用帧内编码后解决。变量设置IVIDENC1_DynamicParams->intraFrameInterval设置为1。这样图像很清晰，每帧也只用27ms。

待解决问题：图像格式转换耗时。现在图像采集到得YUYV422格式，而压缩采用YUV420格式。转换时间至少为25ms。  思路：可以设置压缩格式为YUV422ILE格式去解决。

2012-10-17 OMAP3530硬件压缩支持YUV422格式

设置硬件压缩中 VIDENC1_Params->inputChromaFomat为 XDM_YUV_422IBE即可。