这里根据JTT1078-2016的文档进行个梳理.相当于排个优先级.很人多做事情没有优先级,总想一口吃个大胖子
先梳理业务分个优先级,再把问题列出来就成功一大半了是不是这么个意思.(我是这么做事情的哈,cuiyaonan2000@163.com).然后要多总结,回头看的话收获不小.
从业务功能上
业务是根本,很多半瓶不满,来回晃荡的就知道聊架构.应该从业务上出发,分各优先级在去弄实现方案.
首先映入眼帘的是关于终端的通信协议分为TCP和UDP.这个优先级最高
最基本的业务需求: 实时视频,回放视频,优先级最高
关于视频控制的需求:这个是调整视频质量和速度的关键点.这个的优先级是次高的
其它相关的需求::视频文件上传,云台控制,视频文件检索, 视频字幕叠加设置,视频报警(信号丢失,疲劳驾驶,打电话,抽烟,视频遮挡)
政府平台与企业平台之间的通信,这个优先级最低.
另外关于视频控制的这个需求包含的内容很多,也多涉及到一些视频的基本支持.这个要有点功底才能了解.主要的有如下几个:
实时流编码模式:固定码率CBR,可变码率VBR,平均码率ABR分辨率:QCIF,CIF,WCIF,D1,WD1,720P,1080P,关键帧的间隔,实时流目标帧率,实时流目标码率,字幕叠加,是否启用音频实时视频传输状态可以知道 丢包率视频编码:H264H265AVSSVAC音频编码:G721G722G721G723G728G729声道数2.02.15.0
从具体实施上终端层厂家终端协议的不统一,需要针对每个厂家的推流协议进行兼容.且相同版本的协议但是内容格式与含义不统一厂家终端协议的不统一会影响到视频的卡顿,与音频的同步.厂家终端的一次升级也会带来终端协议的推流的某些改变(暂未证实,但很有可能)老设备与新设备的兼容的问题解决会很复杂网络接收层
此网络接收层是集群部署,同时存在并发处理,热备问题待解决
1078协议要求的是同时支持TCP与UDP的数据推送.目前包括主流的的流服务都是支持TCP的.网络接收层目前仅做协议解析工作.后期还有安全,推流,转流,播放,等控制功能.
流媒体服务器
目前流媒体服务器是使用开源的流服务,此流服务肯定会有缺陷需要调整.例如视频卡顿,播放控制,转流存储,事件监控等流媒体服务器占用带宽,集群部署,热备功能等问题解决.这个我推荐2个Nginx-rtmp和SRS.(如果有其它的可以推荐给我cuiyaonan2000@163.com)
视频,音频问题
视频,音频问题主要是实现实时播放视频,减少卡顿或延迟.音频主要是要与视频进行同步播放.但是此问题的触发可能在多个地方,比如终端协议的不同或者错误造成了延迟,卡段音视频不同步.或者是流媒体服务器的配置影响.又或者网络接收层的程序效率不能实时播放或者同步(关于网络层与带宽暂时不考虑).
前端插件
前端插件的播放器可以做成简单的视频播放,但是如果需要提供截图,下载,暂定,缓存等功能.还需要对开源的videojs进行二次封装.
企业平台或者政府平台
如果要接入新的流媒体服务.则企业平台,政府平台需要梳理改动地方,并针对新的流服务方式进行新的控制于管理.如此各平台与流媒体服务之间肯定有业务数据上的交互.相互间的接口调用必不可少.
