webrtc在民用安防行业中的应用

Posted 2022-05-07 Stoneshen1211

转载一篇关于webrtc的文章。
文章链接：
https://zhuanlan.zhihu.com/p/36507637

文章目录

• 相似点
• 痛点
• • 1. P2P
  • 2、回声消除
  • 3、网页客户端
• 优点
• • 1. P2P
  • 2、回声消除
  • 3、chrome浏览器免插件访问音视频
• 难点
• • 1. 设计场景差异
  • 2、部分优秀功能不适用
  • 3、资源投入大
  • 4、webrtc不支持h265编解码
  • 5、对嵌入式不友好
• 解决方案
• 结语

相似点

webrtc是互联网行业中流媒体技术的集大成者，涵盖了音视频采集、媒体处理、编码、p2p、网络发送到网络接收、解码。普遍用于直播、音视频聊天、视频会议，可以让没有音视频开发经验的人也可以轻松开发音视频通讯软件。

传统安防视频监控行业也是基于音视频流媒体技术做开发。在设备端，芯片负责音视频采集和编码，嵌入式上层应用模块根据通讯协议进行网络传输，客户端（PC、移动端）中有netsdk网络接收、playsdk做解码显示。

痛点

安防行业在逐渐向民用发展，随着移动互联网的到来网络环境也由局域网转向窄带公网。这几年逐渐遇到如下痛点：

1. P2P

传统方式下，先走P2P，P2P不成功再走转发。这是串行的方式，等转发出图要过5、6秒。P2P大都用UDP。UDP容易丢包且乱序，从而导致图像卡顿流畅性差。传统P2P用户体验非常差，用户投诉很多，不得已，很多安防厂家只能走纯服务器转发的方式，但云服务器的费用是笔巨大的开支。以某安防公司为例，它一年生产1000万台家用摄像头。假设千分之一的设备同时在线，设备的平均码率是1Mbps，云服务器费用按50Mbps 10W元/年，每年新增的设备转发费用是10000000/1000/50*10W元=2000W元，这还不包括体量更庞大的存量设备。每年在原来基础上再增加2000W费用，一年辛苦赚的血汗钱都交给个云服务公司了

2、回声消除

回声是因为语音对讲时，声音一边在播放一边在采集，采集时会把播放的声音又采回去。在PC电脑时代，用的是耳机+麦克风，麦克风能采集到的耳机播放的声音很小，所以回声的问题不明显。而到了移动互联时代，手机端扬声器大都是外置的，回声就很大。

3、网页客户端

嵌入式设备和视频综合管理平台都支持B/S架构。B/S架构下观看视频是基于微软的ocx控件，但ocx越来越被人诟病：1、要安装浏览器插件，调整浏览器安全级别，并允许active x控件弹出。2、ocx控件只能在windows环境下使用。3、最新的chrome、firefox版本不允许安装ocx，连微软新出的浏览器edge都不再支持ocx，IE的市场占用率逐年下降。也有人用HLS在网页上观看视频，但HLS的文件特性导致它不够实时，不适用于实时预览。特别是球机或带云台功能的摇头机，用户点一下方向键，要过5、6秒画面才有反应，体验极差。

优点

安防业的这些痛点，正是webrtc擅长的。

1. P2P

Webrtc中的p2p支持3种网络连接方式，局域网内直连、公网穿透、公网转发。采用ICE框架，这3中网络连接是并发进行的。打个比方就是一条河上同时搭三座桥，哪条桥先搭好就直接通行。等优先级高的桥搭好就把优先级低的桥拆除（优先级： 直连>穿透>转发），并改用优先级高的桥来通行。这样可以保证即使穿透不成功的情况下走转发，也能在1秒内出图。每种方式会尝试15秒，如果15秒内没有联通，就自动放弃。

Webrtc的UDP传输中，接收端的jitter buffer会做UDP包的乱序重组。在某时间阀值内发现一直没等到某序号的包，就通过RTCP通知发送端重传该序号的包。另外，发送端会根据发送的码率做适度的流控。做了丢包重传、乱序重组、流控的UDP有着不弱于TCP的传输效果，而且在窄带公网（wifi、4G）下，UDP的传输效果优于TCP。

实践证明，webrtc下基于UDP的p2p，具有出图快、实时、流畅的优点。

P2P的过程如下：

由客户端主动发起连接，两端生成各自的sdp和candidate(公网映射地址和转发地址需借助stun和turn服务)。由信令服务交换双方的sdp和candidate。Sdp协商成功后，就通过candidate并发的尝试连接

NAT类型：1、完全圆锥型(FullConeNAT) 2、地址限制圆锥型（Address Restricted Cone NAT） 3、端口限制圆锥型(Port Restricted Cone NAT) 4、对称型（Symmetric NAT）。 理论上3跟4、4跟4不能穿透。在国内普通家用wifi是NAT 3，移动4G是4，不能穿透。遗憾的是，在国内，4G网络是对称型，普通家用网络是端口限制圆锥型，两者不能相通。

2、回声消除

webrtc的前身是GIPS，GIPS是回声消除方面的权威。

3、chrome浏览器免插件访问音视频

webrtc跟chrome代码同源(chromium)，所以chrome对webrtc的支持是顺理成章的事情，firefox、edge、safari也都支持webrtc且会支持得越来越好。Webrtc给javascripe提供了接口调用。

后续webrtc会跟tensenflow结合，开发人员调用几个js接口，就可以在chrome上看实时音视频，并做人脸识别等功能。

另外webrtc的跨平台做得非常好，基本上在windows上跑通后，在linux、嵌入式、移动端上只要makefile一下就能正常运行了。嵌入式下出现的问题，都可以在windows上模拟出来（windows的visual stdio是宇宙第一IDE，对于问题定位调试和压力测试非常方便）

难点

1. 设计场景差异

webrtc是为一对一的双向音视频通讯而设计，webrtc的demo（peerconnection）就是一个类似QQ视频聊天的软件。而安防监控是一对多（多客户端）、多对多的（DVR、NVR多通道），视频传输是单向的（只有设备到客户端），语音可以是单向也可以双向（对讲）。要支持多对多，需要对代码进行改造。

2、部分优秀功能不适用

如带宽自适应，检测到带宽小时，自动降低帧率、码率、分辨率。但摄像头可能多个客户端在同时观看，摄像头本身可能还在TF卡本地录像，不能因某个客户端网络不好而影响到其他客户端或录像的图像质量。对多的场景下，带宽自适应不适用，或者说改造难度非常大（要么对不同的客户端编码多份码流，但这对芯片的cpu和内存要求非常高）。再一个功能是，当客户端解码出错时会要求以当前正常解码的帧为参考帧，让设备端重新编码，而不是强制I帧更加大网络拥堵。这功能在对多的场景下还是不太实用，而且要求编码时带帧ID（vp8、vp9支持，h264不支持帧ID）

3、资源投入大

涉及范围广，webrtc对安防业的改造，涉及到嵌入式设备端、PC端、移动端、服务器端、网页端，需要多部门协同。Webrtc本省代码量也大。这些需要公司大量的资源投入

4、webrtc不支持h265编解码

安防厂家越来越多使用h265，因为同等画质下码率是h264的一半。意味着网络传输只需更少的带宽，同样的硬盘容量存储时间更长。但h265专利收费，webrtc不支持h265解码。另外，google有推出自己的开源编解码器vp9跟h265竞争，但vp9不被安防芯片支持。

5、对嵌入式不友好

webrtc对PC和移动端的支持已经很好，但在嵌入式端的进展不理想。没有嵌入式，就没有硬件产品。Google的那帮白胡子老头工程师估计都已财务自由，写代码更多出于自身兴趣，偏重于算法理论，对产品化和工程实践关注较少。Webrtc中很多算法对cpu要求很高，而嵌入式芯片性能大多比较差。如用于流媒体传输的SRTP用到AES加密算法（个人觉得只对I帧的部分数据加密足矣），海思3516C下，加密的情况下客户端预览两路2Mbps的码流，设备端cpu占用达到80%，在不做加密的情况下只占40%。AES加密算法，webrtc有对X86和nenon的汇编优化，但没有嵌入式汇编优化。其他如回声消除、带宽自适应算法都需要大量计算。webrtc中存在不少流媒体数据(rtp包)的内存拷贝。再一个webrtc用ninja编译，而嵌入式下没相应的gn工具, 需要手写makefile， ninja是个坑人的玩意。另外对嵌入式下sleep的精确度考虑不足（嵌入式下sleep的精度很多是10-15毫秒， PC和移动端是1毫秒），易导致延时

解决方案

webrtc花了大量精力来实现音视频采集、编解码，但这些功能对于安防行业是鸡肋。安防芯片和客户端有成熟的h264、h265编解码方案，包括硬软编解码。应把首尾两端的采集编解码裁剪，保留中间流程，采集和编解码模块平台差异性很大，这些模块裁剪后也利于跨平台移植。可根据ninja文件中对各平台下的宏定义、需包含的文件、依赖的库，来制作windows vs2015工程和linux makefile文件。有了linux makefile文件，再来写嵌入式下的makefile和android下的Android.mk就比较容易。

通过建立多个peerconnection对象来支持多客户端。通过多次AddStream来支持多通道（dvr、nvr），由stream_lable来标识不同的通道。

依据peerconnection demo（需熟悉win32底层GUI编程），来制作两个库，设备端的和客户端的。设备端：把采集和编码模块裁剪，改成由外部传入一帧帧的264数据，视频改成只发送不接收。客户端：把解码模块裁剪，改成接收到一帧h264后回调出去，外部playsdk解码，视屏改成只接收不发送。

对于webrtc的应用，可以循序渐进。先从p2p着手，不做SRTP(为安全考虑，可对I帧的部分数据加密)，把回声消除和带宽自适应等cpu占用高的功能先屏蔽掉。自定义媒体格式以支持265，客户端用自己的playsdk来解码。Chrome的支持可以先从服务器、边缘端（性能强的nvr，海思3531、3536）先支持，IPC端可以等新的性能更强的支持nenon的芯片方案（现有的3516C勉强也可以支持，路数少一点，码率小一点）。可做成自适应，根据客户端的uuid判断客户端类型。如果是chrome，就做SRTP。否则不做SRTP，由自己的playsdk解码。

结语

传统行业在拥抱互联网时要有针对性有选择的吸收。互联网在改造传统行业时应充分了解该行业的背景，与该行业的实际相结合。只有这样，两者才能真正融合，碰撞出火花，产出一个有创新性的产品和服务。