zoukankan      html  css  js  c++  java
  • webrtc在民用安防行业中的应用

    相似点

    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解码。

    结语

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

  • 相关阅读:
    我的WCF之旅(1):创建一个简单的WCF程序
    网页设计中颜色的搭配
    CSS HACK:全面兼容IE6/IE7/IE8/FF的CSS HACK
    UVa 1326 Jurassic Remains
    UVa 10340 All in All
    UVa 673 Parentheses Balance
    UVa 442 Matrix Chain Multiplication
    UVa 10970 Big Chocolate
    UVa 679 Dropping Balls
    UVa 133 The Dole Queue
  • 原文地址:https://www.cnblogs.com/lidabo/p/14436828.html
Copyright © 2011-2022 走看看