大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE稳定放心使用
视频传输
传输系统
H.265编解码
高清视频
Boost:asio库
渲染
低时延
硬编码
流媒体服务器
video transmission
transmission system
H.265 codec
high-definition video
Boost:asio
render
low latency
hard-coded
streaming media server
随着封闭小区的开放,智慧社区的建立,视频监控将得到进一步的需求。视频监控目前正从以CIF、D1为主的标清时代进入以720P、1080P为主的高清时代。目前,H.264视频编解码标准仍占据了视频网络传输领域的80%左右份额[1]。但是随着摄像机的图像质量的提升,H.264视频编解码标准越来越不能满足高清视频传输的要求。
目前,谷歌的VP9和JCT-VC制定的H.265视频编解码标准[2],在视频编解码性能上均优于H.264编解码标准。Dumic等[3]研究对比了H.265和H.264在网络传输中压缩性能,证明了H.265针对高清视频压缩性能强于H.264。Grois,Dan等[4]进行了X264和X265压缩码率对比研究,可知X.265相对于X.264在码率节省方面有32.6%的提升。工业界实现视频编解码的方案主要分为2类,分别是硬编解码和软编解码方案。经市场调研可知,爱立信发布了第一个兼容H.265的视频解码器,华为海思、博通以及中兴和海康等企业陆续推出各自基于H.265标准的硬件设备[5]。软编解码主要有FFmpegH265和X265[6],这2种软编解码器针对H.265编解码功能进行相应的精简,保证编解码的时效性。针对高清视频网络传输带宽大、时延长等问题,采用基于H.265的硬编码和软解码的方案进行系统软硬件一体化设计。
1 高清视频采集编码
视频采集编码端采用华为海思Hi3516A处理器进行不同格式视频信号采集、H.265和H.264硬编码以及和客户端交互控制的功能应用程序设计,其中交互控制示意图如图 1所示。视频采集编码端主要完成视频采集编码及与客户端交互的功能开发设计,分别包括对一路高清视频数据采集编码、用户可自定义选择编码的格式、视频图像清晰度和自定义传输码率等。
采集编码端整体架构图如图 2所示。视频图像通过VI视频输入模块采集后,传送给系统控制模块VPSS,然后进入编码通道编码。论文中主要针对视频信号进行H.264和H.265编码。
1.1 视频采集
采集编码端的视频流硬件接口电路是通过外接HDMI接口采集。由于Hi3516A处理器视频接口有BT.656/601、BT.1120接口、数字相机接口和MIPI Rx(包含MIPI、LVDS、HiSPi)接口。论文方案设计中Hi3516A处理器中的视频捕获单元VICAP(video capture)通过BT.1120接口接受视频数据流。视频源由HDMI接口发出,分辨率是1 920×1 080(1 080P),结果驱动IC芯片SIL9135A转换为BT.1120格式视频数据送入Hi3516A处理器,压缩后经过千兆以太网发送出去。
视频采集线程应用程序设计主要包括初始化系统各模块参数、初始化MPP平台参数、打开物理通道及扩展通道、启动VPSS及绑定VPSS和VI以及开通过VI模块进行视频采集。其中,初始化系统参数过程中主要是获得输入图像大小信息,计算不同视频格式所需要视频缓冲块的大小并申请相应大小视频缓冲区。视频采集流程图如图 3所示。
1.2 视频编码
视频编码线程中,编码通道分别从各个配置好的通道中获取编码后的码流。在获取编码后码流的过程中,首先要针对相应的编码通道询问一帧码流中所包含数据包的数量。针对相应的数据包的个数,申请内存空间,然后才读取一帧编码后的码流数据,存储起来。程序设计最后要记得释放内存,避免内存空间被申请完,系统崩溃。视频通道编码线程如图 4所示。
1.3 线程交互
主程序中的交互线程(流程图如图 5所示),主要完成和客户端之间的交互,进行编码参数的更新和相应控制操作。由于编码参数的更新不是动态更新,所以每一次更新完参数后,都需要关闭系统,再次重新启动系统。
每次设备端接收到的数据分2类,一类是控制命令信息,另一类是包含视频编码参数的信息。系统通过设置私有通信协议完成信息传递。在交互线程中,首先为接受数据申请相应的内存。当系统接收到数据后,根据帧头数据内容对数据类型进行分类。如果是参数信息,则进行更新相应的参数操作,然后重新启动系统;如果是控制命令信息,则直接进行相应的命令操作。通过shell客户端打印出来识别效果图如图 6、7所示。
2 基于Boost:asio库的流媒体服务器
目前,大部分流媒体服务器基于RTSP传输协议,并采用了网络技术和流媒体技术结合方法进行开发设计[7]。但无论是开源还是商用的流媒体服务器,其通用性虽然较好,但是功能比较复杂,要完整实现其功能比较困难。如果方案需要的是一个完整功能的流媒体服务器,那就可以选择一个开源的或者是商用的流媒体服务器[8]。由于论文中系统仅需要传输一路H.264或H.265的直播流,所以根据系统需求进行设计专用流媒体服务器。论文采用C/S架构进行流媒体服务器设计,最后基于Boost:asio库实现异步服务器的开发设计,其中服务器分为面向连接和非面向连接2个部分。
流媒体服务器设计完成后,当进行发送视频码流和接收视频码流程序设计时,需要对H.264和H.265编解码的NAL层的码流结构进行分析。在编码线程完成编码工作后,将编码后的码流传送到发送线程。当服务器端发送线程接收到nalu数据包时首先应判断nalu包类型。判断数据包是否为sps,pps等类型的nalu包。如果是则添加相应帧头作为解码时的标志和码流调整中作为丢弃数据包的选择依据。其次,由于网络传输码流长度的限制,如果网络传输码流超过一定长度需要做拆分,系统中针对无线网络传输码流不得超过1 500 bytes的属性,进行设置。码流分析过程如图 8所示。码流发送通过shell客户端打印效果图如图 9所示。
3 客户端软件设计
论文中视频数据解码部分主要采用流式解码方式进行解码。由于解码器输出视频数据为YUV420格式,而图像显示一般为RGB格式[9]。但是高清视频的YUV格式数据到RGB格式数据转换需要占用较大计算机资源,同时高清视频的实时解码也占用较多的计算机资源,所以解码显示时间会很长[10]。因此论文终端显示方案选择DirectDraw技术实现高清视频的YUV格式数据渲染显示。显示流程图如图 10所示。
由于显示系统设计过程中省略了视频格式转换,充分利用了显卡资源,所以显示比较流畅,并且减少了显示延迟。
解码流程如图 11所示。系统针对输入的码流不同分为以下2种情况进行处理:首先,码流不足一帧视频数据,则需要继续输入码流进行解码;其次,当码流包括若干帧视频数据时,则需要在解码出一帧图像后反复调用解码函数进行解码剩余码流。解码过程中需要注意的一点是,在码流结束后,必须进入flush 模式清空解码器中的残留图像,直到解码器中没有残留图像为止。
4 测试结果
4.1 图像质量对比
因为峰值信噪比PSNR是目前图像质量评价的最常用指标,所以本小节验证在相同源图像画质传输下H.265视频编解的传输码率相对于H.264减半时的视频图像传输情况,比较H.265和H.264解码后图像的PSNR数值。
下面分3组情况进行实验,分别为1 080P视频图像、720P视频图像和480i视频图像在25 fps帧率下进行实验。
1) 针对1 080P视频图像经H.265和H.264编解码后图像质量对比 。
如图 12所示,参考图像经1 080P格式采集,(a)为在1 M码率条件下经H.265编解码后的图像,12(b)为在2 M码率条件下经H.264编解码后的图像。
人眼直观观察图 12(a)、(b)没有太多的差别,通过表 1可以判断2种码率情况下图像差别。
带宽 | PSNR-Y | PSNR-U | PSNR-V |
H.265(1 M) | 41.040 74 | 41.540 80 | 41.880 81 |
H.264(2 M) | 18.974 96 | 19.624 50 | 20.549 20 |
通过对比1 080P视频图像分别在1M码率下经H.265编解码和在2M码率下经H.264编解码后图像PSNR数值,可以看到图像质量差别很大。1 080P图像经H.265编解码后,虽然码率只有H.264传输码率的一半,但是图像质量远超过经H.264编解码后的图像质量。其中H.264编解码后图像质量与H.265编解码后图像质量差别这么大,主要原因是Hi3516A处理器中H.264编码模块对于1080P高清视频编解码的支持不好。
2) 针对720P视频经H.265和H.264编解码后图像质量对比。
如图 13所示,参考图像经720P格式采集,(a)为在0.5 M码率条件下经H.265编解码后的图像;(b)为在1 M码率条件下经H.264编解码后的图像。
通过对比表 2中720P视频图像分别在0.5 M传输码率下经H.265编解码和在1M码率下经H.264编解码后图像PSNR值,可以看到图像质量差别很小,PSNR值均在33左右。720P图像经H.265编解码后,虽然传输码率只有H.264码率的一半,但是图像质量和H.264基本相同。
带宽 | PSNR-Y | PSNR-U | PSNR-V |
H.265(0.5 M) | 33.17912 | 35.000 71 | 33.152 47 |
H.264(1 M) | 33.113 80 | 34.834 72 | 32.947 76 |
3) 针对480i视频图像经过H.265和H.264编解码后图像质量对比。
如图 14所示,参考图像经480i格式采集,(a)为在0.25 M码率条件下经H.265编解码后的图像;(b)为在0.5 M码率条件下经H.264编解码后的图像。
带宽 | PSNR-Y | PSNR-U | PSNR-V |
H.265(0.25 M) | 29.94754 | 31.26621 | 30.58239 |
H.264(0.5 M) | 30.32712 | 31.79496 | 30.99647 |
通过对比480i视频图像分别在0.25 M传输码率下经H.265编解码和在0.5 M码率下经H.264编解码后图像PSNR值,分析可知针对480i标清图像经过H.264编解码后的图像质量略微强于经过H.265编解码后图像质量。
通过以上实验总结可得,H.265视频编解码对于高清视频处理性能明显优于H.264视频编解码。
4.2 图像传输时延测试
针对网络传输情况下系统时延进行测试如表 4所示。经系统分析可知,视频传输延迟主要分为3个部分,编解码延迟、网络传输延迟和显示延迟[10]。实验针对视频数据经H.265编码,分别在高码率和低码率传输情况下进行了10组时延测试。实验中采用1 080P的视频采集格式的测试帧率为25,其中高码率指2 M和低码率指1 M。H.265编码下10组测试数据如表 4所示。
组别 | 高码率情况 | 组别 | 低码率情况 | ||||
编码前/s | 解码后/s | 时间差/s | 编码前/s | 解码后/s | 时间差/s | ||
组1 | 8.14 | 8.26 | 0.12 | 组6 | 03.53 | 03.75 | 0.22 |
组2 | 9.12 | 9.23 | 0.11 | 组7 | 14.49 | 14.79 | 0.30 |
组3 | 13.83 | 13.94 | 0.11 | 组8 | 27.74 | 28.01 | 0.27 |
组4 | 44.81 | 44.93 | 0.12 | 组9 | 34.76 | 34.99 | 0.23 |
组5 | 86.34 | 86.46 | 0.12 | 组10 | 59.74 | 60.03 | 0.27 |
由H.265编码条件下10组测试数据分析可知,高码率情况下,系统的时延平均在120 ms左右。当相同条件下采用1 M低码率传输时,相应的系统时延增加,平均在250 ms左右。
通过以上实验可知,传输系统在高码率情况下可以相对减少系统传输时延。主要原因是系统在低码率下编解码处理时延长于高码率下编解码处理时延。现场测试图如图 15所示。
5 结论
论文通过研究基于H.265高清视频网络传输系统,完成基于Hi3516A处理器硬编码和客户端软解码的一体化系统设计与实现。
1) H.265编解码相对于H.264编解码的一半码率的编解码情况下,解码后图像的PSNR值,在低清晰度480i情况下,H.264的编解码质量稍微优于H.265。
2) 在传输720P图像时,两者PSNR值基本相等。
3) 当传输高清晰度1080P图像时,H.264的编码性能相对于H.265大幅降低。实验表明,H.264的编解码性能在低清晰度视频传输情况下,性能优越,但是在高清视频编解码后图像质量下降很快。因此随着高清视频的普及,H.264将不能适应高清视频传输。
同时,论文通过实验针对高清1 080P视频格式视频经H.265编码,对比低码率和高码率两种情况下系统延迟,计算可得论文中系统的传输时延在高码率时为 120 ms左右,低码率时为250 ms左右,可以满足工程需要。实验证明本系统软硬件一体化设计性能良好,能够满足实时系统传输要求。目前,系统是在固定码率下进行试验,以后将在编码器自适应码率下进行试验对比。
[1] | 高丹丹, 王成. H.265引领视频新时代[J]. 科技创新导报, 2014(20): 231 |
[2] | 何海东, 董全武, 纪琳. H.265/HEVC、VP9、H.264编码算法比较及性能测试分析[J]. 广播与电视技术, 2014, 41(10): 47-52 |
[3] | DUMIĆ E, GRGIĆ S, FRANK D, et al. Subjective quality assessment of H.265 versus H.264 video coding for high-definition video systems[C]//Proceedings of the 13th International Conference on Telecommunications. Graz, Austria:IEEE, 2015:1-7. |
[4] | GROIS D, MARPE D, NGUYEN T, et al. Comparative assessment of H.265/MPEG-HEVC, VP9, and H.264/MPEG-AVC encoders for low-delay video applications[C]//Proceedings of the SPIE 9217, Applications of Digital Image Processing XXXVII. San Diego CA, United States:SPIE, 2014:92170Q. |
[5] | 杨东. 浅析H.265下的编解码新趋势[J]. 中国安防, 2015(6): 84-86 |
[6] | 张征. H.265开启安防新时代[J]. 中国公共安全, 2015(8): 116-118 |
[7] | RUPALWALA S S. ARM 11 based real-time video streaming server using RTSP protocol[C]//Proceedings of International Conference on Electrical, Electronics, Signals, Communication and Optimization. Visakhapatnam, India:IEEE, 2015:1-5. |
[8] | 赵进, 叶梧, 冯穗力. 基于RTP/RTCP的流媒体服务器技术研究[J]. 中国有线电视, 2004(1): 6-9 |
[9] | 李华. 网络视频监控系统客户端视音频软件的设计与实现[D]. 武汉:华中科技大学, 2007. |
[10] | 郭芳, 张家树. 基于H.265的安全高效的指数哥伦布编解码方案[J]. 计算机应用与软件, 2013, 30(10): 85-86 |
[11] | JI Qiujia, YU Hewei, CHEN Haihao. A smart android based remote monitoring system[C]//Proceedings of the 3rd International Conference on Technological Advances in Electrical, Electronics and Computer Engineering. Beirut, Lebanon:IEEE, 2015:181-184. |
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/186391.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...