问题背景：
最近在SRS群里回答一些视频监控设备上云问题时，SRS开源作者让我写一篇文章介绍下视频监控摄像头的互联网化实践思路，很有幸毕业这几年工作的大体方向都跟这个有关系，本篇就抛砖引玉说下视频监控设备上云的一些实践和思考。
本篇文章核心内容大致分为下面几个部分，你可以选择感兴趣篇章阅读，如果你对视频监控行业比较陌生，可以看看以前这篇文章《从人类的第一次直播聊聊视频监控行业》：
为什么监控摄像头要上云？互联网化？
要上云怎么实践？有哪些大坑需要填？
未来这块还有哪些改进空间和期待？
视频监控互联网化改造的必要性：
视频监控从目前来看分为两个大的方向：一个是传统视频监控，一个是消费类视频监控。
前者其实很长一段时间跟大家关系都比较陌生，大家唯一能看到的就是挂在道路上的枪机、球机，一般都觉得这是震慑犯罪分子和维护公共安全，跟自己没有很大关系。但是随着这几年AI和移动互联网的发展，我们发现超市的摄像机能识别人脸还能识别VIP会员并进行刷脸支付，这是摄像头和AI结合的案例；幼儿园的摄像头能在手机上查看自家小孩在学校的学习情况和老师教育教学情况，这是摄像头和直播技术在教育行业的落地；到蜂巢取快递也是用摄像头一扫二维码就直接出货拿走不用快递员的再次确认，这是摄像头利用图像二维码识别技术在物流行业的一次成功实践，可以说摄像头已经从传统的震慑犯罪分子和社会公共安全领域拓展到和对传统行业的改造上，这是最近几年视频监控行业快速发展的核心动力，已经从传统的安防行业拓展到智慧城市，智能家居，智能物流各行各业。同时也从单一的音视频技术拓展到和AI、5G、大数据结合越来越紧密的
另外消费类视频监控在传统视频监控的基础上也发展起来，这部分主要面向的是我们消费者是To C业务。传统视频监控面向的主要是政府，企业等To B业务。现在很多家庭都用摄像头实现远程看家，远程开门，远程陪伴老人等，这部分属于新兴业务，量不大但是发展很迅速。像海康的萤石，360的小蚁等都属于这个范围。当然消费类视频监控的产品形态也不仅仅是摄像头，也包含智能音箱、智能门锁、电子猫眼、儿童手表等。
前者传统视频监控一般都是在局域网和视频专网里面，后者消费类视频监控一般都是要放到公网上进行。这几年随着各种技术的交叉发展，传统视频监控改造成互联网的需求越来越多，我总结了下面几个原因：
1. 移动互联网的发展彻底改变了用户的使用习惯，现在人人都是一部手机，能在手机上办的事绝对不会在电脑上操作，更不会一天24小时待到监控室目不转睛的看着屏幕上的视频监控画面，那样效率太低，所以为了让大家能随时查看视频和发生报警通知，第一步要做的事情就是要把视频监控设备和互联网打通，让大家在APP，微信小程序随时关注相关信息；
2. 随着AI、5G技术的快速应用，视频监控要跟各行各业结合起来，不联网这些技术想落地很困难，想这种智慧城市类项目，第一步要做的事情就是消除信息孤岛，所以还是要把摄像头的能力开发到外网，只要开发到外网才有可能实现互联互通和万物互联，进一步提升社会运转效率；
3. 视频监控行业本身的需要，现在云技术大数据技术在视频监控行业应用越来越多，这些技术可以大大降低视频监控部署的难度，能把用户资源高效利用起来，降低成本，但是这些安防厂商的云基础设施又很弱，所以自己想降低成本就需要提供自己设备的通外网能力，使自己能在公有云上实现软件的自由部署和数据的自由流动，提升运营能力，减少重复劳动；
说了这么多就是想讲一个重点，视频监控不是以前的那个安防概念了，是改造各行各业的一把利器，设备上云互联网化是使自己成为一个高效工具的第一步，所以这件事不仅重要而且是大趋势，消费类就更不用说，是需要你产品一出生就需要自带的功能。
视频监控互联网化改造的实践：
1.谈怎么做之前，先说下目前这块现状？
很不幸，这块整个行业做的非常差，因为这个行业一直都是有自己特殊群体和场景的，最早以前还是模拟摄像头，后来完成数字化改造，还没冷下来，高清化、智能化这些新兴技术就来了，所以这个行业没有预期自己竟然能发展这么快包括龙头老大海康，更没想到视频监控和5G 、AI、云计算、大数据这些技术都能紧密结合起来。所以视频监控厂商在带领这个行业时，没有考虑到这些互联互通问题，所以选用的技术栈跟目前万物互联需要的技术都有不少差异，但是一个行业一旦成型，想把新技术新标准快速贯彻下去，就有阻力了。
A. 目前摄像头最重要的视频传输采用的RTSP RTP RTCP技术，但是这些技术都跟互联网特别是移动互联网的需求有偏差，因为类似APP、浏览器观看视频很少直接用这些协议和标准进行拉流和推流；
B. 视频观看这块采用的是基于一些插件化技术和自研的播放器，这跟目前的HTML5无插件播放严重不匹配的，不仅兼容难而且耗费人力、精力，特别对于Flash插件明年各大浏览器将彻底不支持了。
C. 视频编解码虽然采用了H.264、H.265编码，但是里面往往有自己的私有码流，其次音频编码格式很多还是G7xx系列，都面临标准化适配和转码的问题。
D. 设备管理和会话这块，要么是私有协议要么是基于SIP的GB28181协议或者ONVIF协议，这些协议本身复杂也不是为视频监控类业务专门开发的，所以问题非常多。
E. 安全这块非常弱，通外网的协议基本不支持，这些都是让人头痛的地方。
2. 那么到底怎么实践？
首先哪里有需求，哪里就有发展，视频监控互联网化长期看是个趋势和必然需求，未来应该会在一些行业标准制定上或者摄像头自带功能能会有所突破，但是基于当下还是要实际问题实际解决，我基本总结了下面几种思路：
消费类视频监控
这类摄像头目前基本都是私有协议，所以你买回去摄像头一般再装一个他们家的APP就可以观看了，因为这类视频监控就你自己用，设备提供商可以提供端到端的技术实践。一般他们都有云服务，这类摄像头里边都是私有协议也不涉及开放和对接，所以这种情况技术比较容易实现，不是我们讲解重点，涉及核心技术基本下面三点：
a. P2P相关技术，同一个wifi和局域网进行打洞，实现APP和摄像头的直接互联；
b. 私有协议传输技术；
c. 云服务实现P2P打洞失败情况下流媒体的转分发和操作控制；
传统视频监控
这类设备比较复杂、功能比较多，设备厂商比较多，所以设备要上云，具体看你需要的功能有哪些，如果仅仅是观看视频类需求也就是跟码流直接相关需求，相对来说比较容易实现，但是你想充分使用设备所有的能力，那就比较复杂可选择性不多，首先我们看一个传统的视频监控设备如果要在外网对接成功，一般能对接设备那些能力：
A.设备的发现、注册、组织关系;
B.设备属性的获取，比如设备的厂商、型号、支持的编解码类型、分辨率、传输协议、设备的状态等信息；
C.设备属性的设置和远程控制，比如设备远程重启、定位、巡航，旋转等操作
D.设备的流媒体能力，这块包括直播，回放，下载、媒体的花式播放包括快进快退，倍速播放等；
E.设备事件的订阅和通知，这块包括一些人脸识别，视频遮挡，设备异常检测等基础事件的订阅和通知。
下图是我在Web上的一个调试demo，大家可以了解下一个摄像头的基本功能：
所以设备上云还是跟自己的业务有关系，到底是只接前端设备的音视频能力还是整个能力全部对接，需要你结合自己的业务需求。但是无论那种业务，前端设备上云基本下面三种方式：
[摄像头有固定外网地址但只对接媒体能力]
1. 如果前端设备有固定外网IP，当然这种情况比较少，因为外网IP现在是稀缺性资源，国内对IPV6落地速度明显慢于欧美国家，所以只适合特殊场景领域，随着IPV6发展，要是每个设备都有一个外网地址，那这件事变得就容易起来了。如果设备支持外网IP：仅仅对接设备的音视频能力，则用设备原生支持的拉流协议进行拉流和控制即可，一般设备都支持rtsp主动拉流同时支持rtp传输码流，这种你的基本开发工作量就是开发一个rtsp客户端，这部分能用的开源软件Live555或者FFmpeg，前者好处是兼容性做的非常棒，能适配各种前端情况对rtsp协议的实现情况即使不支持自己修改代码也容易，FFmpeg方案就是实现简单，但是兼容性不太好操作，毕竟Livee555已经开源一二十年了，而且只针对RTSP协议栈，实现比较优秀，当然你还可以选择自己开发。
[摄像头有固定外网地址对接设备所有能力]
2. 如果要对接整个设备能力，你可以选择前端设备支持的国标GB28181协议或者国际协议ONVIF，这两种设备接入协议行业设备一般都支持，你做好这两套协议的客户端直接对接设备即可。
[摄像头在局域网但只对接设备媒体能力]
3. 如果设备在局域网部署只有内网IP，这种情况还是分两种方法对接：
A. 只对接设备音视频能力同时设备支持推流协议如RTMP，现在摄像头有些可以支持RTMP原生推流，那就很简单你在外网部署一个RTMP收流服务器即可，然后收到RTMP码可以转协议和转封装通过其它如HLS-TS、HTTP-FLV分发出去，你可以参考这篇文章《在HTML5上开发音视频应用的五种思路》。
B. 只对接设备音视频能力但是设备本身不支持推流协议，需要你自己开发一个媒体流协议转换网关部署到设备侧，用RTSP向设备拉流然后转成RTMP推流到部署在公网的CDN或者RTMP收流服务器即可，当然只要把RTSP流拉上来，怎么分发都行，转成FLV用HTTP或者RTMP分发出去都可以。目前这块SRS开源服务器就支持，缺点就是在摄像头的用户侧都需要部署这个码流协议转换分发服务器。
[摄像头在局域网需要对接设备所有能力]
4. 不仅要对接设备流媒体能力还有其它能力则可以用GB28181接入网关，这个网关即支持你部署到设备侧内网也支持你部署到公网，让设备主动注册到公网。因为GB28181协议的机制支持设备主动注册，本质就是SIP RTP，我们把公网上的服务器信息和相关配置到设备界面，然后设备主动注册上来时就已经实现网络穿透了，这样我们下发信令就能到局域网的具体设备了，这样既解决了设备发现和注册，也支持了从外网操作设备，码流则让设备主动推流上来即可。
5. 如果海外项目不支持GB28181协议，但是设备支持国际协议ONVIF，则开发一个ONVIF接入网关，部署在设备侧，但是部署ONVIF的机器支持双网卡一个内网网卡用来和设备交互，一个外网网卡用来接收我们外网的一些操作请求。
对于上面说的这几种我花了两张图简单说明下：
将媒体协议转换网关、GB接入网关、ONVIF接入网关部署在用户侧的示意图：
GB接入网关部署在公网侧的示意图：
3. GB28181协议和ONVIF协议到底是什么？
对监控没有了解的人看到这两种协议很懵逼，以为是很高端的东西，其实并没有，下面我总结了几张PPT让大家熟悉下这两种协议，这是对接视频监控设备的核心：
协议标准：
协议优缺点：
协议本质和技术栈：
再看下摄像头在Web和移动端对接展示的效果，先用友商的展示吧：
Web端黄山景区直播：
家庭消费类 APP 端展示 ：
未来期望和想法：
视频监控业务互联网化改造的需求和项目会越来越多，但是要填的坑还很多，本质上还是视频监控这方面业务落后于移动互联网和AIoT的需求，没有想到相关的AI、5G、大数据云计算技术能对这块产生这么大的推动力，下面是我对这块的一些期望和看法：
1. 国标和ONVIF还是主要的对接和上云方式，这些协议会不断发布新版本和Feature适应当前需求，跟海康前同事聊了下，正在给公安一所体新需求和新标准；
2. 设备本身应该也会做出一些改变，无论从传输、信令控制、封装编解码都应该会考虑一些互联网传输和观看的相关需求，设备会原生支持一部分这种需求；
3. 国标基于SIP协议和RTP协议，但是SIP协议目前主要应用在分布式的P2P音视频会议和VOIP领域 ，但是目前视频监控业务应用在政府、公安、文教卫领域具有明显的方向性，一般从下级到上级，是明显的多人对一个设备的控制，设备和客户端不是对等的地位也是不一样的，所以用SIP协议来控制会话和利用拓展来操作设备比较复杂，其次目前国标协议对会话控制和码流传输缺乏明显的安全支撑，很多摄像头裸奔在互联网上很不安全，这两点估计是后面国标协议更新的主要方向。
4. 国标GB28181的编解码类型只支持H.264，但是不支持H.265，对视频的压缩和存储比较浪费，急需在编解码增加该功能。虽然ONVIF支持H.265但是各个版本的协议不兼容给对接带来很大困难，这两块也是吐槽比较多的地方，但是目前还看不到改进的希望，只能忍受这种缺陷和利用替代方案。
往期文章回顾:
周末活动回顾：视频质量主观评价、实时RTC和AV1
在HTML5上开发音视频应用的五种思路
音视频封装：MP4结构概述和分析工具
音视频解封装：MP4核心Box详解及H264&AAC打包方案
音视频基础知识-时间戳的理解
音视频封装格式：AAC音频基础和ADTS打包方案详解
从人类的第一次直播聊聊视频监控行业
音视频压缩：H264码流层次结构和NALU详解
音视频传输：RTP协议详解和H.264打包方案
音视频封装：FLV格式详解和打包H264、AAC方案（下）
音视频封装：FLV格式详解和打包H264、AAC方案（上）
音视频常见问题分析和解决：延时和抖动
今天就说这么多，祝您工作顺利！
