您好,欢迎访问三七文档
当前位置:首页 > 电子/通信 > 综合/其它 > 移动多媒体方向综合设计报告-201501
移动多媒体方向综合设计报告PC机Linux即时视频通信系统发送端的多线程优化一、摘要IP网视频对话发送端关键技术包括视频采集、视频编码、RTP打包发送等多个任务,这些任务所需的主要硬件资源并不相同,可以利用多线程将这些任务并行运行,以减小视频传输延迟。本课题研究利用Linux多线程实现多任务并行运行、减小任务间等待,并且在安装Linux的PC机上实现这一过程。二、多线程原理IP网视频对话发送端关键技术包括视频采集、视频编码、RTP打包发送等多个任务,其中,视频采集主要使用USB摄像头设备在应用层调用capture的API(callfunction)采集单帧图像,视频编码利用开源H.264编码库x.264对采集到的图像进行压缩编码,最后调用Linuxsocket将H.264压缩码流打包并通过PC网卡发送出去,这三个任务主要使用的硬件资源不同,因此,使用多线程并行运行可减小视频传输延迟。三、方案设计有两种多线程方案,一是以两个线程并行运行,将运行较费时的视频采集独立成一个线程运行,视频编码、RTP打包发送合并在一个线程;二是将视频采集、视频编码、RTP打包发送分别用一个线程运行。根据老师的建议,先运行两个线程,即使用方案一,在此基础上再进一步实现三个线程并行运行。本实验仅实现两个线程的多线程,对于三个线程的使用将在第五部分结果和讨论中进行讨论。由于线程与同进程的其他线程共享除栈以外的其他地址空间,包括了代码段、数据段、全局变量、堆段等,因此,将采集到的图像数据作为线程间的公共数据,在线程中通过指针对其直接修改及访问。对于图像公共数据,为了保证下一次获取的图像数据覆盖原来之前,原图像已完成H.264的压缩编码处理,因此必须采取措施对数据进行保护。本实验使用了两种方法实现:1.对图像数据加锁。2.设置同步点方法。3.1方法一图像数据加锁为了使数据处理更快,实验使用了三个图像数据空间,x264_picture_tpic_in1,pic_in2,pic_in3;每个图像数据都带有一个mutex互斥锁、一个condition条件变量以及其他的标志符,以保护数据和判断数据是否已处理完毕。数据结构如下:TypedefstructpicIn{x264_picture_t*pic_in;//图像指针pthread_mutex_tpic_mutex;//互斥锁pthread_cond_tpic_cond;//条件变量intflag;//处理完成标志,采集结束置1,编码结束置0unsignedcharfrmrate;//帧率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得到每帧的平均处理时间。完整的每100帧处理时间表在附录1显示。方法图片格式每帧平均处理时间ms方法一640*48043.50561960*720101.76421280*720101.3051方法二640*48033.4715960*720101.27561280*720101.1656单线程640*48033.50281960*720101.3821280*720101.3756表4.1.1不同方法的每帧平均处理时间表由表可以看出,图片格式较小时,多线程效率较单线程差,图片格式较大时,多线程效率较单线程好,这是由于数据大时,线程二中H.264压缩编码需要的时间长,增加了单线程顺序执行时间,而对于并发运行的并无多大影响。此外,方法一整体上效率比方法二差,大概是方法一使用资源较多,加锁后使得图像获取和处理的时间变长。以图像大小为640*480,压缩比特率786kb/s为例,比较了从摄像头获取一帧图像的时间,即函数uvcGrab()的执行时间,可以看出,方法一在获取单帧图像的时间远大于其他方法,使得效率降低。方法uvcGrab()执行时间ms方法一51方法二32单线程22表4.1.2不同方法的uvcGrab()执行时间4.2平均时延启动手机秒表程序后将手机置于摄像头前,录制秒表时间,可以在本地回环看到接受的时间,从而计算出时延。如下图:图4.2.1发送和接收时间(上为发送,下为接收)由此可计算出不同方法的大致平均时延。方法图片格式平均时延时间0.01s方法一640*48015960*720321280*72034方法二640*48010960*720311280*72030单线程640*48010960*720341280*72035表4.2.1不同方法的大致平均时延由此可见,图像较大时,多线程可以减小视频传输的时延,且方法二比方法一效果更明显。4.3多线程与单线程的细节对比由于方法一的效率不高,此处仅以方法二做为多线程对比,并且图像大小为1280*720,压缩率为1982kb/s,压缩质量为最高。编码和发送的平均时间ms获取一帧图像平均时间ms单线程0.93634585.88613多线程0.863087100.932使用多线程后,从摄像头获取一帧图像的时间增加了,编码和发送的时间减少了,但多线程为并发运行,总时间取决于较慢的线程,即线程一,线程一循环一次的时间为100.9217ms。单线程为顺序执行,循环一次的时间为100.9221ms。由于两个线程执行时间悬殊,整体上看,单线程与多线程的效果差别不大。但如果提高获取一帧图像的时间或当压缩编码速率较低时,多线程便能表现出优势。五、结论和讨论5.1结论当视频图像较大时,多线程在每帧平均处理时间和时延上都比单线程的少,整体效果比较好。但对于视频图像较小时,多线程显示不出优势,但考虑实际情况,即时视频通信系统使用的是大图像,因而,实际应用中,还是可以使用多线程来减小视频传输延迟的。5.2三个线程讨论从“4.3多线程与单线程的细节对比”中可以看到,程序运行的主要时间是在获取视频图像上,压缩编码和发送所占用的时间远远小于获取时间,因为,将发送独立出来作为第三个线程完全没有必要。要想进一步优化,则应该考虑如何减少多线程中获取图像的时间,如果能将多线程中获取图像的时间减少至单线程获取图像时间,那么,多线程优势就更加明显。六、心得通过这个课程设计,学习了多线程的使用,了解使用多线程的意义,并用两种方法实现即时视频通信系统发送端的多线程优化。其中,方法一是自己思考的结果,由于欠考虑加锁带来的时延,实现效果欠佳。方法二是按老师的建议,使用TI的设置同步点的方法,得到了较好的结果。通过实践,我了解到不同方法实现的多线程的效果是不一样的,在实际中,应该考虑不同方法产生的效果,选择合适的。七、参考文献[1]徐程.Linux环境C程序设计.北京:清华大学出版社,2014[2]杨宗德吕光宏刘雍.Linux高级程序设计.北京:人民邮电出版社,2012.11附录一每100帧处理时间表100200300400500600700800900100011001200每帧平均时间平均比特率kb/s方法一640*4808900.61414311.3819508.8523379.3326907.0830441.6833966.1238324.5342689.6947176.4752372.9357816.994350.5609787.51960*72012234.5922333.3932429.2242529.1152828.9763028.7573125.5383301.0593600.78103902.5114000.2124097.610176.41721184.711280*72012182.2622382.3932627.3742848.6452952.5863043.2373144.5383238.1793396.6103499113594123687.510130.50662001.67方法二640*4806310.26610368.0513712.1117060.4420407.5323756.2327103.3130447.433827.3837144.0940490.2643839.553347.15787.51960*72012235.4422334.84324294262952728.6462828.673022.7383228.8593319.63103417.9113519.2123610.410127.55771204.081280*72012146.5322343.7832434.1342538.3252733.162833.8572930.4983022.3393224.76103316.6113417.6123509.410116.56432039.83单线程640*4805321.6688663.66412008.7615355.5418705.9822054.1425402.1628784.4732130.435502.0738819.4442166.483350.2812785.44960*72012197.1822394.3332593.3142789.452887.163087.7873187.2483284.3593384.25103585.2113677.2123776.310138.19581194.231280*72012244.522341.2732434.7842536.1852632.0962825.6373026.8583119.7493324.27103517.8113622.6123716.910137.55862053.1
本文标题:移动多媒体方向综合设计报告-201501
链接地址:https://www.777doc.com/doc-2237611 .html