视频监控摄像头的互联网化实践思路
问题背景：
最近在SRS群里回答一些视频监控设备上云问题时，SRS开源作者让我写一篇文章介绍下视频监控摄像头的互联网化实践思路，很有幸毕业这几年工作的大体方向都跟这个有关系，本篇就抛砖引玉说下视频监控设备上云的一些实践和思考。
本篇文章核心内容大致分为下面几个部分，你可以选择感兴趣篇章阅读，如果你对视频监控行业比较陌生，可以看看以前这篇文章《从人类的第一次直播聊聊视频监控行业》：
如果你对本篇文章感兴趣或者实际你们遇到了什么开发问题，抑或这篇文章跟你的工作有关系想了解具体实现细节，由于新开公众号不能留言，那就麻烦就在微信右下角点个在看或者直接加我个人微信，如果人多的话我后面花费十几篇文章详细介绍下视频监控相关协议的方方面面：
视频监控互联网化改造的必要性：
视频监控从目前来看分为两个大的方向：一个是传统视频监控，一个是消费类视频监控。
前者其实很长一段时间跟大家关系都比较陌生，大家唯一能看到的就是挂在道路上的枪机、球机，一般都觉得这是震慑犯罪分子和维护公共安全，跟自己没有很大关系。但是随着这几年AI和移动互联网的发展，我们发现超市的摄像机能识别人脸还能识别VIP会员并进行刷脸支付，这是摄像头和AI结合的案例；幼儿园的摄像头能在手机上查看自家小孩在学校的学习情况和老师教育教学情况，这是摄像头和直播技术在教育行业的落地；到蜂巢取快递也是用摄像头一扫二维码就直接出货拿走不用快递员的再次确认，这是摄像头利用图像二维码识别技术在物流行业的一次成功实践，可以说摄像头已经从传统的震慑犯罪分子和社会公共安全领域拓展到和对传统行业的改造上，这是最近几年视频监控行业快速发展的核心动力，已经从传统的安防行业拓展到智慧城市，智能家居，智能物流各行各业。同时也从单一的音视频技术拓展到和AI、5G、大数据结合越来越紧密的
另外消费类视频监控在传统视频监控的基础上也发展起来，这部分主要面向的是我们消费者是To C业务。传统视频监控面向的主要是政府，企业等To B业务。现在很多家庭都用摄像头实现远程看家，远程开门，远程陪伴老人等，这部分属于新兴业务，量不大但是发展很迅速。像海康的萤石，360的小蚁等都属于这个范围。当然消费类视频监控的产品形态也不仅仅是摄像头，也包含智能音箱、智能门锁、电子猫眼、儿童手表等。
前者传统视频监控一般都是在局域网和视频专网里面，后者消费类视频监控一般都是要放到公网上进行。这几年随着各种技术的交叉发展，传统视频监控改造成互联网的需求越来越多，我总结了下面几个原因：
说了这么多就是想讲一个重点，视频监控不是以前的那个安防概念了，是改造各行各业的一把利器，设备上云互联网化是使自己成为一个高效工具的第一步，所以这件事不仅重要而且是大趋势，消费类就更不用说，是需要你产品一出生就需要自带的功能。
视频监控互联网化改造的实践：
1.谈怎么做之前，先说下目前这块现状？
很不幸，这块整个行业做的非常差，因为这个行业一直都是有自己特殊群体和场景的，最早以前还是模拟摄像头，后来完成数字化改造，还没冷下来，高清化、智能化这些新兴技术就来了，所以这个行业没有预期自己竟然能发展这么快包括龙头老大海康，更没想到视频监控和5G 、AI、云计算、大数据这些技术都能紧密结合起来。所以视频监控厂商在带领这个行业时，没有考虑到这些互联互通问题，所以选用的技术栈跟目前万物互联需要的技术都有不少差异，但是一个行业一旦成型，想把新技术新标准快速贯彻下去，就有阻力了。
2. 那么到底怎么实践？
首先哪里有需求，哪里就有发展，视频监控互联网化长期看是个趋势和必然需求，未来应该会在一些行业标准制定上或者摄像头自带功能能会有所突破，但是基于当下还是要实际问题实际解决，我基本总结了下面几种思路：
消费类视频监控
这类摄像头目前基本都是私有协议，所以你买回去摄像头一般再装一个他们家的APP就可以观看了，因为这类视频监控就你自己用，设备提供商可以提供端到端的技术实践。一般他们都有云服务，这类摄像头里边都是私有协议也不涉及开放和对接，所以这种情况技术比较容易实现，不是我们讲解重点，涉及核心技术基本下面三点：
传统视频监控
这类设备比较复杂、功能比较多，设备厂商比较多，所以设备要上云，具体看你需要的功能有哪些，如果仅仅是观看视频类需求也就是跟码流直接相关需求，相对来说比较容易实现，但是你想充分使用设备所有的能力，那就比较复杂可选择性不多，首先我们看一个传统的视频监控设备如果要在外网对接成功，一般能对接设备那些能力：
下图是我在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、大数据云计算技术能对这块产生这么大的推动力，下面是我对这块的一些期望和看法：
往期文章回顾:
音视频解封装：MP4核心Box详解及H264&AAC打包方案
今天就说这么多，祝您工作顺利！
如果有疑问，你可以在公众号后台发消息咨询我。
个人转载内容至朋友圈和群聊天，无需特别申请版权许可。
引用转载该订阅号文章，注明文章来源即可。
记得右下角点“在看”，还可以关注该订阅号，防止遗漏推送哦