关于直播视频平台与监控视频平台技术架构方案的一点小想法
- 2019 年 11 月 1 日
- 笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/eguid_1/article/details/83021107
截图服务在线演示demo：https://blog.csdn.net/eguid_1/article/details/82842904
项目维护地址：https://github.com/eguid/easyCV
前言
讲个大实话，直播平台复杂在直播端（也就是播放端），而监控平台复杂在接入端（前端设备或平台）。
至于技术难点，难者自知。
一、直播平台（想尽一切办法来降低延迟，从一开始你就不应该对hls抱有任何幻想） 1、直播房间管理 主播管理–[主播申请直播房间]–>房间管理–[房间绑定直播推流地址]–>分配流媒体直播地址（可能会有多个流媒体服务，房间id作为rtmp和flv播放名称，只提供rtmp和flv分发，直播场景不考虑hls）
2、流媒体服务（srs或nginx+rtmpmodule），定制需求（通过主播推流和用户播放回调事件展示实时数据，用户真实数量后台不做调整，前端随意,回调接口由web服务提供）
3、前端直播（web，pc，移动端，微信小程序） 主要是播放器（h5采用flv方案，原生随意），还有实时弹幕和评论，礼物等等。 直播这块主要难点在于cdn分发降低延迟，其他没有难点。 小程序这块微信有提供单独的liveplayer播放器API，支持rtmp和flv，直接用就可以。 pc端想怎么搞怎么搞，就算你想自己解码然后播放又有什么不可以呢？ web端主要还是H5为主（flv，兼容低版本ie的话，可以上flash播放器），毕竟直播还是年轻人看的多，老年人应该会选择看电视吧~~maybe。
二、监控视频平台（视频接入复杂度较高，依然不考虑hls） 监控平台复杂度体现在接入复杂，接入协议多，私有协议满天飞，gb28181，177平台，sip，各种设备对接和监控系统对接，音视频裸码流，rtsp，rtmp，rtmp，hls，录像文件等等。
1、视频接入服务 需要一个统一接入服务（必须确定接入的每台设备的接入信息和接入方式（大而全，支持协议足够多，支持各种厂商私有码流，吃力而不讨好），流媒体服务会通过回调方式让本服务进行拉流并推流到流媒体服务）。
2、流媒体服务 首选srs或nginx+rtmpmodule，定制需求（即时转流，通过用户调用方式触发回调接入服务进行实时推流到流媒体服务） 既然是即时转流，那么延迟肯定比直播平台延迟要大，用户体验一般般；想要更好的用户体验就需要不停的从前端设备拉流推流到流媒体服务，后者本质上跟直播没区别。
3、监控视频直播（web，pc，移动端，微信小程序） 这块跟直播平台没啥区别，只不过不需要弹幕什么的了，前端比较简单，只要能看视频就行。 小程序这块微信有提供单独的liveplayer播放器API，支持rtmp和flv，直接用就可以。 pc端想怎么搞怎么搞，就算你想自己解码然后播放又有什么不可以呢？
三、关于两种平台推流（接入）的异同 1、监控平台虽然不需要主动推流，但实际情况更加扑朔迷离，各种私有协议花样百出应接不暇，没有标准接入协议真的很难搞。 谁知道明年会不会出个新的协议或者厂商设备换个型号私有头也跟着变，但是接入这块有个好处，能养很多NB程序猿，技术难度高，门槛高（最基础的你得熟悉rtsp，sip，ts，rtmp，flv，mpeg4/h264，g711，aac这些吧，至于用什么编程语言这都是后话了）。 2、直播平台一般可以移动端推流和pc端推流，用浏览器推流不知道脑袋是怎么想的，还是暂时远离webrtc这个坑吧，再过五六年或许可以。
