本文共 1381 字，大约阅读时间需要 4 分钟。

序言

           这里根据JTT1078-2016的文档进行个梳理.相当于排个优先级.很人多做事情没有优先级,总想一口吃个大胖子

           先梳理业务分个优先级,再把问题列出来就成功一大半了是不是这么个意思.(我是这么做事情的哈,cuiyaonan2000@163.com).然后要多总结,回头看的话收获不小.

从业务功能上

     业务是根本,很多半瓶不满,来回晃荡的就知道聊架构.应该从业务上出发,分各优先级在去弄实现方案.

1. 首先映入眼帘的是关于终端的通信协议分为TCP和UDP.这个优先级最高

2. 最基本的业务需求:  实时视频,回放视频,优先级最高

3. 关于视频控制的需求:这个是调整视频质量和速度的关键点.这个的优先级是次高的

4. 其它相关的需求::视频文件上传,云台控制,视频文件检索, 视频字幕叠加设置,视频报警(信号丢失,疲劳驾驶,打电话,抽烟,视频遮挡)

5. 政府平台与企业平台之间的通信,这个优先级最低.

      另外关于视频控制的这个需求包含的内容很多,也多涉及到一些视频的基本支持.这个要有点功底才能了解.主要的有如下几个:

1.  实时流编码模式:固定码率CBR,可变码率VBR,平均码率ABR
2. 分辨率:QCIF,CIF,WCIF,D1,WD1,720P,1080P,
3. 关键帧的间隔,实时流目标帧率,实时流目标码率,字幕叠加,是否启用音频
4. 实时视频传输状态可以知道    丢包率
5. 视频编码:H264 H265 AVS SVAC
6. 音频编码:G721 G722 G721 G723 G728 G729
7. 声道数 2.0 2.1 5.0

从具体实施上

终端层

1. 厂家终端协议的不统一,需要针对每个厂家的推流协议进行兼容.且相同版本的协议但是内容格式与含义不统一
2. 厂家终端协议的不统一会影响到视频的卡顿,与音频的同步.
3. 厂家终端的一次升级也会带来终端协议的推流的某些改变(暂未证实,但很有可能)
4. 老设备与新设备的兼容的问题解决会很复杂

网络接收层

         此网络接收层是集群部署,同时存在并发处理,热备问题待解决

        1078协议要求的是同时支持TCP与UDP的数据推送.目前包括主流的的流服务都是支持TCP的.网络接收层目前仅做协议解析工作.后期还有安全,推流,转流,播放,等控制功能.

流媒体服务器

        目前流媒体服务器是使用开源的流服务,此流服务肯定会有缺陷需要调整.例如视频卡顿,播放控制,转流存储,事件监控等流媒体服务器占用带宽,集群部署,热备功能等问题解决.这个我推荐2个Nginx-rtmp和SRS.(如果有其它的可以推荐给我cuiyaonan2000@163.com)

视频,音频问题

         视频,音频问题主要是实现 实时播放视频,减少卡顿或延迟.音频主要是要与视频进行同步播放.但是此问题的触发可能在多个地方,比如终端协议的不同或者错误造成了延迟,卡段音视频不同步. 或者是流媒体服务器的配置影响.又或者网络接收层的程序效率不能实时播放或者同步(关于网络层与带宽暂时不考虑). 

前端插件

      前端插件的播放器可以做成简单的视频播放,但是如果需要提供截图,下载,暂定,缓存等功能.还需要对开源的videojs进行二次封装.

 企业平台或者政府平台

       如果要接入新的流媒体服务.则企业平台,政府平台需要梳理改动地方,并针对新的流服务方式进行新的控制于管理.如此 各平台与流媒体服务之间肯定有业务数据上的交互.相互间的接口调用必不可少.

转载地址：http://cfcmf.baihongyu.com/