低时延条件下高速公路视频监控系统web无插件播放方案设计

张百里

【摘要】近几年，随着高速公路事业向高质量发展要求提出，对高清视频监控系统需求也更加强烈。本方案分析了高速公路视频监控系统产生延时的原因和各种视频播放方案的优缺点，取长补短、融合创新，设计了低延时无插件条件下高速公路视频监控方案web播放方案。该方案已应用在安徽省交通控股集团有限公司视频监控平台，为高速公路营运、养护、交管等提供了很好的视频监控服务。

【关键词】视频监控、低延时、无插件

引言

视频监控系统是高速公路三大系统之一，随着我国高速公路事业的发展，视频监控系统经历模拟、数模混合及数字等技术变迁，视频清晰度也由标清向高清发展。近几年，随着高速公路全程监控和视频上云等重大工程建设完成，高速公路视频监控已覆盖道路沿线、隧道、收费站、服务区等路网区域，为高速公路营运、养护及交管等方面的管理提供了更好的服务。随着高速公路事业向高质量发展以及信息技术不断迭代发展，人们对高速公路视频监控系统也提出了新的要求，比如点播视频要快、不需要安装客户端、web播放不需要安装插件等。

本文分析了高速公路视频监控系统各个环节产生延迟的原因和传统视频直播方案的优缺点，并以此为基础，取长补短，融合传统安防实时视频协议RTSP、主流网络直播协议RTMP和新兴技术潮流网页及时通信协议WebRTC的优点，设计开发了高可靠、高便捷、高性价比的低时延无插件条件下高速公路视频监控系统WEB播放方案。

1.视频监控系统延时分析

在整个视频监控系统中，从视频采集、前处理(编码)、传输、到接收和播放的各个环节都有可能会产生延时，各个节点延时累加在一起就构成了视频监控系统的整体延时。如下图所示：

图-1媒体数据传输流程

1.1编解码

音视频编码的主要目的是压缩，减少网络传输的数据量，下面我们看看常见的编码方案对延迟的影响。

首先是音频编码方案对延时的影响，从表-1中可以看到不同的音频编码方案引入的延时差距还是很大的，延时最大的是HEAAC,最小的是G711。

表-1常见音频格式编码延时

我们再来看看视频编码方案对延时的影响，H.264是目前广泛应用的视频编码标准。所有H264编码方案都会产生I帧和P帧，有些方案还会产生B帧。B帧会参考未来的数据，当编码帧率为25帧每秒，一个B帧将引入40ms的额外延迟。

因此采集端我们选择支持音频编码G711A，视频编码H264的设备，且H264支持无B帧编码方案，尽量降低采集端带来的时延。

1.2网络传输

音视频数据传输所用时间受到运营商、物理距离、基础设施、传输协议以及转发处理次数等诸多因素影响，因此传输过程不可避免的会产生延时。数据在网络上的传输距离越短、环境越简单，传输时延则越小。下表给出了数据在光纤中传输的理论时间(实际场景要比这个大很多)

表-2传输距离与时间

1.3缓冲数据

由于网络抖动，系统一般会缓存媒体数据，假定视频FPS为25，则缓存中每滞留25帧视频数据，视频延时就增大1000ms。

尤其当传输使用TCP协议时，网络抖动会产生“累积延迟”。

TCP传输数据失败时，会缓存数据，等待网络条件好的时候再重新发送。这样就必然增加了延迟，如果网络波动较大，那么缓存反而是有害的，所以一般来说都会将推流端的缓存设置到尽可能的小。

本设计方案在尽量降低系统时延的基础上，亦兼顾视频质量。可根据用户个人倾向，通过灵活配置缓存大小，平衡视频时延和质量。

1.4客户端处理

客户端的主要处理流程为“接收数据—解码数据—视频渲染”，接收数据对延时的影响主要体现在接收缓存，此处不累述。解码延时主要与解码器性能、系统配置有关，从几毫秒到几十毫秒不等；视频渲染则主要与硬件配置有关，一般十几到几十毫秒不等。

2.方案设计

2.1设计目标

下图是ITU-TG.114国际标准，显示了延时对主观质量的影响

图-2用户体验度与延时关系

图中横轴坐标是延时大小，单位ms。纵轴坐标是用户的体验度。

由上图可知，ITU-TG.114国际标准规定，当延时达到150毫秒的时候，用户体验度开始下降，当达到400毫秒的时候，用户的感受开始无法容忍。

因此，在考虑用户体验、便捷性、图像质量等因素综合影响下，我们的设计目标是将视频播放平台延时限制在400ms以内。

2.2设计原则

2.2.1可靠性与先进性原则

视频监控系统是高速公路三大核心系统之一，承载高速公路营运、养护、交管等管理需求，所选技术要稳定、可靠性且紧跟当今技术发展步伐。

2.2.2经济性原则

安徽省高速公路已快速发展建设了几十年，路网内已安装不同品牌型号上万路视频监控摄像机。方案设计要充分考虑不同时期不同型号的原有设备，非必要不新增或更换设备。

2.2.3便捷性原则

当今社会已步入移动互联时代，人们已经习惯移动互联生活，传统的完全基于视频客户端的监控方式已无法满足用户随时随地的移动式办公需求，因此方案设计要能够支持电脑端的浏览器访问和移动端的APP访问。

2.3方案设计

图-3    核心架构设计

如上图所示，web客户端通过WebRTC协议向流媒体模块请求音视频流；服务收到请求后，媒体接入单元通过RTSP协议从前端设备拉取音视频流，编解码单元和媒体转发单元对原始流进行二次处理，最终形成WebRTC流，推送给客户端。

2.3.1媒体接入单元

依据前述设计原则，设备接入端要能够利旧已有设备，同时满足未来新设备的持续加入，且要满足设计的初衷——低延时要求，媒体接入单元采用RTSP协议。

同时，考虑到设备接入端是数据源，源数据的质量直接影响后续存储和转发数据的质量，所以在良好的集团内网环境下，我们进一步选择RTSPoverTCP，即选择可靠的TCP协议作为RTSP底层媒体数据的传输协议。

2.3.2媒体编解码单元

媒体编解码单元根据业务需求，负责编解码音视数据。经过调研，我们选择FFmpeg开源库作为音视频处理的核心技术库。

FFmpeg 是一个集录制、转换、音/视频编解码功能为一体的完整的音视频开源解决方案，它是从事音视频行业的必备工具，采用LGPL或GPL开源许可证，完全不用担心商业纠纷问题。

2.3.3媒体推送单元

根据2.5章节直播协议的比对，媒体转发单元选择兼顾低延时和web支持(无需插件)的WebRTC协议。同时还可以利用WebRTC抗丢包来优化最后一公里的观看体验。

2.4时延优化

2.4.1采集端优化

采集端选择支持音频编码G711A，视频编码H264的设备，且H264

支持无B帧编码方案，尽量降低采集端带来的时延。

2.4.2数据接收&&处理优化

采用RTSP协议接收媒体流，本身具有很高的实时性，需要注意编解码单元应能够及时高效的处理接收的媒体数据，防止数据阻塞性延迟。这要求数据接收、编解码处理以及数据推送应能够异步多线程处理，彼此互不影响和阻塞。

2.4.3推流优化

播放端从服务端拉取流数据，只有拿到I帧才能开始解码播放，如果一开始拿不到I帧，解码器只有等待，等待的时候会出现黑屏，等待的最大时长是一个GOP(包含I帧、P帧的一组图片)的长度，一般1-2秒。为了防止上述黑屏的出现，服务端需要缓存前一个GOP，进而导致1-2秒的延迟。

优化：

推流的时候确保推送的第一帧就是I帧，这样就无需为了避免客户端黑屏而缓存一个GOP的数据，进而消除了这部分延迟。

2.4.4部署优化

根据2.3章节分析，数据在网络上的传输距离越短、环境越简单传输延时越小，所以方案设计时考虑将流媒体服务就近部署在各个收费站内，减少数据接收、推送时延。

3.系统实现

该系统融合传统安防协议RTSP与新兴视频直播协议WebRTC等技术，完成了安徽交控集团高速公路视频监控系统低时延条件下web无插件播放，具备视频点播、存储录像、实时视频转发、录像回放及控制、云台控制等功能，提升了安徽交控集团高速公路营运管理水平和效率。

图-4系统登陆界面

图-5 系统地图展示界面

图-6 系统视频轮播界面

图-7 系统点播界面

结束语：

“安徽交控集团视频监控平台”融合传统、主流、和新兴视频直播方案，博众家之所长，即达到了传统安防监控方案RTSP的实时性，也保证了主流直播方案RTMP的稳定性，同时具有了新兴技术方案WebRTC的便捷性，有效的解决了视频监控行业存在的实时性、稳定性、便捷性难以共存的尴尬局面，实现了安徽交控集团借助视频监控平台为人民提高质量、高安全服务的愿景。

参考文献：

[1]李超.WebRTC音视频实时互动技术原理、实战与源码分析[M].北京:机械工业出版社,2021

[2]常智明,张浩,郭丽,张帅丛.低延时流媒体多端分发平台的设计与实现[J]广播与电视技术,2020,47(8):46-47

[3] 刘伟琪.网络视频监控技术发展现状与展望[J].无线互联科技, 2016(14):37-38