[移动多媒体方向综合设计报告-2015.01.docxVIP

移动多媒体方向综合设计报告PC机Linux即时视频通信系统发送端的多线程优化一、摘要IP网视频对话发送端关键技术包括视频采集、视频编码、RTP打包发送等多个任务，这些任务所需的主要硬件资源并不相同，可以利用多线程将这些任务并行运行，以减小视频传输延迟。本课题研究利用Linux多线程实现多任务并行运行、减小任务间等待，并且在安装Linux的PC机上实现这一过程。二、多线程原理IP网视频对话发送端关键技术包括视频采集、视频编码、RTP打包发送等多个任务，其中，视频采集主要使用USB摄像头设备在应用层调用capture的API(call function)采集单帧图像，视频编码利用开源H.264编码库x.264对采集到的图像进行压缩编码，最后调用Linux socket将H.264压缩码流打包并通过PC网卡发送出去，这三个任务主要使用的硬件资源不同，因此，使用多线程并行运行可减小视频传输延迟。三、方案设计有两种多线程方案，一是以两个线程并行运行，将运行较费时的视频采集独立成一个线程运行，视频编码、RTP打包发送合并在一个线程；二是将视频采集、视频编码、RTP打包发送分别用一个线程运行。根据老师的建议，先运行两个线程，即使用方案一，在此基础上再进一步实现三个线程并行运行。本实验仅实现两个线程的多线程，对于三个线程的使用将在第五部分结果和讨论中进行讨论。由于线程与同进程的其他线程共享除栈以外的其他地址空间，包括了代码段、数据段、全局变量、堆段等，因此，将采集到的图像数据作为线程间的公共数据，在线程中通过指针对其直接修改及访问。对于图像公共数据，为了保证下一次获取的图像数据覆盖原来之前，原图像已完成H.264的压缩编码处理，因此必须采取措施对数据进行保护。本实验使用了两种方法实现：1.对图像数据加锁。2.设置同步点方法。3.1 方法一图像数据加锁为了使数据处理更快，实验使用了三个图像数据空间，x264_picture_t pic_in1,pic_in2,pic_in3;每个图像数据都带有一个mutex互斥锁、一个condition条件变量以及其他的标志符，以保护数据和判断数据是否已处理完毕。数据结构如下：TypedefstructpicIn{ x264_picture_t *pic_in;//图像指针pthread_mutex_tpic_mutex; //互斥锁pthread_cond_tpic_cond; //条件变量int flag;//处理完成标志，采集结束置1,编码结束置0 unsigned char frmrate;//帧率intframesize; //图像帧大小}picIn;其中，x264_picture_t *pic_in;为指向图像数据的指针。并定义了一个该数据结构的数组，数组元素的pic_in指针分别指向了三个图像数据空间。structpicInpic_in_array[3];pic_in_array[0].pic_in=pic_in1;pic_in_array[1].pic_in=pic_in2;pic_in_array[2].pic_in=pic_in3;线程一和线程二的流程图如下：图3.1.1 线程一，获取摄像头图像流程图图3.1.1 线程二，H.264压缩编码和网络发送流程图该方法由于使用了三个带锁和条件变量的图像数据，效率较低，处理较慢。下面使用设置同步点的方法，提高了效率。3.2 方法二设置同步点方法使用老师提供的TI的设置同步点的函数，强制对线程一和线程二进行同步，即在线程一和线程二分别设置同步点，当任一线程到达同步点时，等待另一线程到达同步点，然后再进行各自操作。实验使用了两个图像数据空间，两个线程各处理一个图像，当线程均到达同步点后，交换图像指针，因此，不必给图像数据加锁，从而提高了效率。从实验结果看，该方法优于方法一，因而附录2只贴出此方法的主要代码。线程一和线程二的流程图如下：图3.2.1 线程一的流程图图3.2.2 线程二的流程图四、结果分析实验以对比了三组图像大小和比特率分别为640*480和786kb/s、960*720和1200kb/s及1280*720和1982kb/s的图片格式，并且保持摄像头录像的区域相对一致，以减小其他干扰。4.1每帧的平均处理时间在进入获取摄像头图像的循环之前，获取系统时间作为初始时间，每帧处理和显示完毕后，再次获取系统时间作为一帧的处理结束时间，每100帧打印一次，得到每100帧的处理时间。并可由此计算出单帧的平均处理时间。每帧平均处理时间计算：由于开始时存在调整摄像头等因素的干扰，所以最初的若干帧存在误差，计算时忽略前200帧，以第1200减去第200帧的时间得到1000帧的总处理时间，除以1000