AKStream的组成部分与运作原理

AKStream的组成(根据代码结构)

---

• AKStreamWeb
• AKStreamKeeper
• LibCommon
• LibGB28181SipServer
• LibLogger
• LibSystemInfo
• LibZLMediaKitMediaServer
• SIPSorcery
• LibGB28181SipClient

AKStreamWeb

• AKStreamWeb是AKStream的总控制中心，是全局的流媒体管理API服务，包含了所有流媒体功能的控制，如摄像头注册，录制计划，rtp推流,ptz控制以及GB28181客户端的相关功能等。
• AKStreamWeb在一个集群中只运行一份，负责收集来源于AKStreamKeeper的流媒体服务信息，并进行流媒体服务的管理
• 集成Sip网关相关功能，向GB28181设备提供如注册、目录获取、推流请求、历史录像查询、PTZ控制等功能
• 集成操作系统性能信息收集功能，提供如CPU,内存，磁盘等相关情况
• 集成数据库操作功能，对系统运行过程中所产生的数据进行数据库持久化保存
• 集成ZLMediaKit的集群控制功能，统一管理、调度各ZLMediaKit流媒体服务器
• 集成非GB28181设备的拉流功能，实现除GB28181 Rtp流以外的其他流类型的拉取与转换
• 集成Swagger调试环境，提供Web形式的接口调试功能
• 集成WebApi，提供第三方应用的全功能接入
• AKStreamWeb引用包含了LibCommon、LibLogger、LibSystemInfo、LibGB28181SipServer、LibZLMediaKitMediaServer、SIPSorcery、LibGB28181Client七个内部类库

AKStreamKeeper

• AKStreamKeeper是ZLMediaKit的治理程序，它用于流媒体服务器(ZLMediaKit)的相关控制，如控制流媒体服务器的启动，停止，重启，获取某个录制文件是否存在，裁剪与合并任务的执行等。
• 此服务针对于流媒体服务器进行部署，每一个流媒体服务(ZLMediaKit)都需要部署一个对应的AKStreamKeeper,此服务与AKStreamWeb通过WebApi进行通讯。
• AKStreamKeeper启动时，将自己的状态以心跳的方式汇报给AKStreamWeb,并帮助AKStreamWeb服务控制流媒体服务器(ZLMediaKit).
• AKStreamKeeper引用包含了LibCommon、LibLogger、LibSystemInfo三个内部类库

LibCommon

• LibCommon以.net类库形式存在的内部类库
• LibCommon主要提供的是系统中用到的各种枚举、结构、通用工具方法、数据库中间件等功能

LibGB28181SipServer

• LibGB28181SipServer以.net类库形式存在的内部类库
• 它是一个完整的GB28181 Sip信令网关，是一个自治理的全功能类库，关于GB28181 Sip信令服务的所有功能都在此类库中集成
• 提供设备注册、设备注销、设备目录获取、设备状态获取、设备信息获取、设备推流请求、设备终止流请求、设备历史录制文件列表获取、设备历史录制文件推流、设备历史文件终止推流请求等Sip信令通讯功能
• 提供GB28181设备及其音视频通道的管理，向外提供各种事件的触发，如有设备注册事件、有设备注销事件、有设备就绪事件、有设备心跳事件等等
• Sip网关同时支持TCP、UDP信令通道，尝试兼容IPV4与IPV6两种IP地址（Sip网关配置文件中指定信令端口为TCP时同时开放TCP与UDP端口）

LibLogger

• LibLogger是基于log4net的日志记录框架

LibSystemInfo

• 全平台的操作系统性能参数获取类库
• 已经完美支持Windows平台（即使完美支持，也不建议使用Windows平台）

LibZLMediaKitMediaServer

• 管理流媒体服务器的类
• 集成提供流媒体服务器(ZLMediaKit)所有WebApi调用功能
• 集成提供AKStreamKeeper所有WebApi调用功能

SIPSorcery

• Sip信令协议栈

LibGB28181SipClient

• 集成提供了GB28181客户端的相关功能
• 在AKStreamWeb的配置文件中将EnableGB28181SipClient配置打开，该库会被按json配置文件约束下实例化，全自动向GB28181服务端提供相关客户端功能。

第三方库的引用

• FreeSql,数据库连接、操作所用的库，几乎支持所有关系型数据库
• Newtonsoft.Json,AKStream所有Json序列化与反序列化工作由此库完成
• ini-parser-netstandard,用于解析ini文件，主要用于读取和修改ZLMediaKit的config文件
• Swagger,用于提供WebApi接口的Web可视化调试

AKStream的运作原理

---

首要说明

• 与StreamNode不太一样，AKStream所有工作都基于数据库，所有推流，拉流，视频录制等等操作均基于数据库中的VideoChannel表中的数据，只有数据库中存在才会做相关操作，不存在则不会有任何操作，所以切记，一切都从数据库开始
• 由于把一切规范到数据库后，AKStream的代码结构，架构设计也因此变得更简单清晰，不会像StreamNode那样使人产生概念上的歧义与理解困难，因此请记住，数据库中的数据是AKStream运作中的核心，所有操作的可能性都来源于数据库中的数据表现，会专门有一章节介绍数据库中各表各字段的含义

音视频流怎么才能让我们看到？

• 音视频流的编码格式、封装格式、提供方式因不同的设备不同的协议而各不相同。但往往我们希望把这些不同的情况统一起来，统一管理统一调度最后统一使用。AKStream的目标就在于此，它将不同设备的不同方式下的不同编码与提供方式的音视频流统一成一种方式向外提供。
• AKStream支持设备有网络摄像机、NVR、DVR、FFMPEG等，AKStream将这些不同设备的音视频流，在不论其封装格式，编码格式的前提下被分类两类

1. GB28181设备所产生的rtp流
2. 非GB28181设备所产生的其他流

• 对于GB28181设备，AKStream通过Sip信令沟通设备，设备进行GB28181信令的正确响应，AKStream通过WebApi与ZLMediaKit进行通讯，获取ZLMediakit的推流权限（端口申请），从而使GB28181设备主动向指定端口与指定参数的约束下进行推流，ZLMediaKit在收到GB28181设备的推流后，将rtp流协议转换成如http-flv,ws-flv,rtmp等协议的流并通过WebApi接口与AKStream通讯，告知AKStream相关推流与转换情况，AKStream收到这些信息后更新维护推流列表
• 对于非GB28181设备，AKStream通过ZLMediaKit内置的代理推流器或FFmpeg代理推流器，拉取非GB28181设备的视频流源地址（rtmp,rtsp,http等），ZLMediakit在正确拉取或拉取失败时会向AKStream的WebApi接口进行通知，AKStream得到通知后如GB28181设备一样进行处理
• 正确推流，并且被正确协议转换后，我们就可以在Web，移动端，客户端等场景下通过AKStream提供的各类转换协议地址观看到设备的实时音视频流

GB28181的Sip信令网关的工作流程

• 摄像头的GB28181配置页面配置AKStream中Sip网关的相关参数信息
• 摄像头上线时，自动通过GB28181协议向Sip网关注册自己
• Sip网关发现摄像头上线后，发启设备目录查询请求
• 摄像头收到设备目录查询请求后，按GB28181协议要求发送自身设备列表到Sip网关
• Sip网关收到设备列表后，完成摄像头推拉流必须的参数
• 摄像头与Sip网关保持心跳响应
• Sip网关在一定周期内发现摄像头心跳断连，自动跳出Sip设备列表中的摄像头

GB28181客户端

• 与LibGB28181SipServer相反，这是一个全自动的向GB28181Server提供客户端功能的模块
• 当LibGB28181SipClient被实例化后，它会根据配置文件描述向GB28181Server注册自己
• GB28181Server在收到GB28181Client的注册消息后，经过一系列的请求<->回复事件后，完成对GB28181Client的注册
• GB28181Client完成注册后，会自动与GB28181Server保持心跳同步
• GB28181Server向GB28181Client请求的包括且不限于[设备目录获取]、[设备信息获取]、[设备状态获取]、[实时流请求]、[实时流断开]提供响应
• GB28181Client的大多数功能都会全自动完成

AKStream的录制计划（模板）

• 与StreamNode不同的是，AKStream的录制计划以模板的形式提供
• AKStream可以添加、删除、修改、查询无限数量的录制模板，这些模板可以被一个音视频通道(数据库VideoChannel表中的一条记录)绑定，绑定模板以后，该音视频通道就拥有了这个录制计划所指定的录制规则，AKStream会按照录制计划所指定的规则进行录制
• 录制计划模板可以启用和停用，一个录制计划模板被停用时，所有绑定这个录制计划模板的音视频通道也同时失去了录制音视频文件的能力
• AKStream仅支持将音视频流录制成可快速播放的mp4文件（MP4的FastStart）
• 录制计划模板，以星期为单位控制每个星期n的00:00:01到23:59:59的录制与不录制控制，一个录制计划模板中可以出现多个星期n的数据，表示每天启用与停用录制可以多段
• 如果一个录制计划仅含有录制计划本身，则没有星期n的细节信息，AKStream默认其一直录制
• 只有音视频流正确上线（成功推拉流）的时候，才会启动录制

GB28181的音视频通道是怎么确定的

• GB28181是国标协议，国标协议中通过GB28181设备的通道ID来确定通道的类型
• GB28181设备通道总数是20位,其中11,12,13位为131，132，138，139时为视频通道
• 11，12，13位为137时为音频通道
• AKStream将11，12，13位大于等于140小于等于199的也认为是视频通道
• 当11，12，13位为135,205时此通道为告警通道（AKStream暂时没有对告警通道，告警信息进行处理与对接）

AKStream的推拉流流程

推流流程

• 所谓推流，就是让设备主动将自己的音视频流推到AKStream(ZLMediaKit)的指定端口指定参数下，现在AKStream只支持GB28181设备的rtp流按这种方式进行音视频接入
• GB28181设备向AKStream的Sip网关注册自己，告知AKStream自己是一个GB28181设备
• AKStream发现设备注册后，向GB28181设备发启设备目录查询请求
• GB28181设备收到设备目录查询请求后向AKStream发出自己的所有通道信息，注意GB28181设备的通道不仅仅有音视频通道，也同时会有非音视频通道，如告警通道等，AKStream会将这些通道全盘接收，当前内部逻辑只会处理音视频通道数据，其他通道仅仅只是保存在内部列表中，以作后用
• AKStream在获取到音视频通道时会自动向数据库VideoChannel表写入此通道的数据，同时确定了此通道的SSRC值和ZLMediaKit的StreamId值，数据库中这条记录的MainId则是SSRC的crc32后的16进制字符串，也同时是ZLMediaKit的StreamId,同时将这条记录的激活状态设置为未激活，待进行接口激活，此时记录的中的MediaServerId以unknow_server开头，表示此通道所属流媒体服务器还未知，在激活音视频通道时最重要的一点就是确定此音视频通道的流以后将要推到哪个流媒体服务器
• 通过接口激活此音视频通道，为它指定归属流媒体服务器，同时可设置其它流媒体相关参数，如是否自动推拉流，是否自动录制，是否可PTZ控制等参数
• 当设置成此音视频流自动推拉流时，AKStream的线程会及时发现，并进行自动推拉流请求，否则需要通过接口手动推拉流
• AKStream会向ZLMediaKit所在服务器找一个可以使用的rtp端口，这个端口会在一定范围内查找，具体可以看AKStreamKeeper配置文件一章中的详细说明，找到可用端口后，AKStream会向ZLMediaKit申请这个端口，ZLMediaKit将申请端口开放，并等待设备向他推流
• AKStream向ZLMediaKit申请端口成功后，组织GB28181的sdp信息向设备发送实时流请求，设备在收到sdp信息后将流推向sdp所约束的相关端口
• 至此ZLMediaKit将收到来自设备的rtp音视频流，ZLMediakit收到rtp音视频流后，进行协议转换，并向AKStream的相关接口报告流的详细信息
• AKStream收到ZLMediaKit的报告后，记录相关协议转换后的信息，完成实时流请求的推流流程

拉流流程

• 当前AKStream除GB28181是设备推流外，其他均是ZLMediaKit主动拉流
• ZLMediaKit的主动拉流方式有两种

1. 使用FFMPEG进行拉流，这种方式几乎支持所有格式所有编码
2. 使用内置的流代理器进行拉流，这种方式支持H.264,H.265/ACC,G711

• 在格式合适的情况下尽可能使用内置流代理器进行拉流，因为这种方式拉流速度较快，支持rtsp,rtmp,http协议
• 在VideoChannel表中的MethodGetStream字段中可以指定使用FFMPEG拉流还是使用内置拉流
• AKStream根据MethodGetStream字段中指定的拉流方式向ZLMediaKit发启拉流请求
• ZLMediaKit进行拉流，拉流成功后对流进行协议转换，并和GB28181一样报告给AKStream
• AKStream收到相关报告后的处理方法与GB28181一致，不再赘述

AKStream对音视频文件的裁剪与合并操作

• 有时需要提取某个摄像头在某个时间范围的视频，可以通过AKStream的相关接口进行获取
• 此操作是一个耗时操作，因此采用异步回调的方式来获取任务结果，调用方需提供一个WebApi接口来接受任务结果
• 可能因为某些原因造成回调时调用方的WebApi不可用，导致任务结果未收到的情况，系统提供任务状态查询接口供调用方查询，此接口同样适用于任务进度的追踪（AKStreamKeeper被重启后所有之前的任务结果会被清空，因为AKStreamKeeper没有数据库持久保存这些数据）

关于音视频通道激活

• 首次通过GB28181协议向Sip网关注册成功的设备(摄像头、NVR等),Sip网关会自动向此设备发起设备目录查询请求，设备（摄像头、NVR等）在收到目录查询请求时将自己所管理的视频通道信息返馈给Sip网关，Sip网关收到这些视频通道后，尝试性向数据库插入这些通道信息，以方便用户使用，插入数据库时系统自动检测相同设备ID和通道ID是否存在，如果已经存在则不再反复插入
• 因为AKStreamWeb可以集群部署ZLMediaKit流媒体服务，因此注册上线的GB28181设备在不人工干预的情况下无法确定哪个ZLMediaKit流媒体服务器为其提供收流服务，因此这类自动插入数据库的设备（摄像头、NVR等）处于未激活状态，在未激活状态下，系统不会对其做任何操作，同时可以发现在pushMediaServerId字段也都以unkonw_server开头以及enable=false,这个情况下，需要通过接口对这类摄像头进行激活。
• 音视频通道的激活是为了确定此通道归属流媒体服务器，也同时为此通道设置相关推流，录制等参数
• 与StreamNode不同，AKStream在音视频通道入库时就已经确定了音视频通道ID（MainID）,此ID等同于StreamNode的CameraId

音频的问题(为什么VLC有声音且有图像，WEB上没声音或者直接黑屏呢)

• 既然VLC有声音也有图像，那么说明AKStream工作正常，那么主要问题在WEB上，当前WEB的主流播放器是Flv.js，Flv.js当前支持的格式是H.264 + AAC / MP3，因此视频编码格式不是H.264,音频编码格式不是ACC或Mp3的话，就会出现各种问题。
• 所以，当出现VLC正常而WEB不正常的时候，请调整摄像头的音、视频编码格式。