一、前言
某项目中需要集成视频管理平台，实现分布在各省公司的摄像及接入，对视频进行统一管理。本项目中视频管理平台采用GB/T28181实现的监控设备接入管理平台，支持在开放互联网和局域网对监控设备进行远程接入、远程管理、远程调阅、录像回看等功能。本文对此记录GB/T28181协议的原理和一些问题，以供后续参考。
相关资源：Nginx支持flv和mp4格式文件，同时支持Rtmp协议；同时打开rtmp的hls功能、wvp-GB28181-pro、国内项目地址
二、视频协议
2.1、相关术语
1）H265/H264视频编码：
H.265：又称为High Efficiency Video Coding (HEVC)，是H.264的后继者，同样由VCEG和MPEG联合开发。H.265的目标是在H.264的基础上进一步提高压缩效率，理论上可以比H.264节省大约50%的比特率，同时保持相同的视频质量。相对于H.264，它能提供：更大的编码单元（CU）尺寸，从64×64到8×8像素的自适应四叉树结构；改进了运动预测和帧内预测；支持更高效的熵编码方法和更精细的量化参数控制。这些改进使得H.265在处理高清和超高清视频时更加高效，但同时也意味着更高的计算复杂度，可能影响到实时编码和解码的性能。基于H.265的高效性，它更适合在高清和4K视频的流媒体和存储领域；\H.264：全称MPEG-4 Part 10或Advanced Video Coding (AVC)，是由ITU-T的视频编码专家组（VCEG）和ISO/IEC的动态图像专家组（MPEG）联合开发的一种视频编码标准。H.264的主要目标是在与早期标准（如MPEG-2和MPEG-4 Part 2）相同的视频质量下，提供大约两倍的压缩效率。这意味着使用H.264编码的视频文件可以比使用旧标准编码的文件小一半左右，这对于网络传输和存储来说非常重要。通过块运动补偿预测、变换编码、熵编码（如CABAC或CAVLC）等多种技术实现了高效压缩。对于与265的区别，首先H264/H265都是视频压缩标准，但265会比264更先进，一般能将文件大小压缩后比264再降低约50%以上，可在相同质量下使用更低的码率，即H.265在相同码率下可以提供更高的视频质量；而264相对于一些老设备更具兼容性，因H.265是较新的压缩标准，不是所有的设备和平台都支持，相比H.264是更为广泛支持的标准，在包括手机、电视、电脑等多个平台上广泛应用，故一般取H.264即可。NALU（Network Abstraction Layer Unit）是NAL层的基本数据单位，由一个头部（一个字节）和一个负载部分组成，其中头部包含了控制信息，用于指示NAL单元的类型、重要性等级以及其他相关参数；负载部分包含了实际的编码数据，如图像数据、参数集数据等；而负载数据的结构和内容取决于NAL单元的类型。H264结构中，一个视频图像编码后的数据叫做一帧，一帧由一个片(slice)或多个片
组成，一个片由一个或多个宏块(MB)组成，一个宏块由16x16的yuv数据组成。宏块作为
H264编码的基本单位。在H264协议内定义了三种帧，分别是I帧、B帧与P帧。I帧就是一个完整的图像帧，而B、帧与P帧所对应的就是不编码全部图像的帧。P帧与B帧的差别就是P帧是
参考I帧而生成的，而B帧是参考前后图像帧编码生成的。H264采用的核心算法是帧内压缩和帧间压缩，帧内压缩是生成|帧的算法，帧间压缩是生成B帧和P帧的算法。
2）输出HTTP-FLV、HTTP-MP4
HTTP-FLV：将音视频数据封装成 FLV格式文件，然后通过 HTTP 协议传输给客户端。它具有低延迟特定，内容延迟可以做到 2-5 秒；只要浏览器支持 FlashPlayer 就能简易的播放；它的地址是http://开头的，是基于HTTP协议的，可以简单地理解为RTMP的HTTP协议版本，功能和工作原理是相似的，且RTMP切片数据功能，HTTP-FLV也是支持的，但HTTP-FLV协议一般只能用作拉流观看。实际体验中， HTTP-FLV延迟会略高于RTMP，但是HTTP-FLV相对RTMP适配更多的播放场景。Nginx中已经集成 nginx-http-flv-module支持该协议，Nginx的HTTP-FLV插件是包含RTMP功能的，所以一般HTTP-FLV的流媒体服务，推流是以RTMP协议，拉流是用HTTP-FLV协议。综上，目前比较流行的方案是，直播源推流是RTMP协议，直播拉流观看是HTTP-FLV协议。HTTP-MP4：基于HTTP的MP4协议，将音视频数据封装成封装成mp4格式。MP4 文件的数据都是封装在一个又一个名为 Box 的单元中。一个 MP4 文件由若干个 Box/FullBox 组成，每个 Box 包含了 Header 和 Data。所有的Metadata（媒体描述元数据），包括定义媒体的排列和时间信息的数据都包含在这样的一些结构box中。Metadata 对媒体数据（比如视频帧）引用说明，而媒体数据在这些引用文件中的排列关系全部在第一个主文件中的metadata描述，这样就会导致视频时长越大文件头就会越大、加载越慢。 4K流媒体代表(40962160分辨率)，8K流媒体高清代表(81924320分辨率)720P(1280*720分辨率) ，1080P(1920 * 1080分辨率)RTMP：RTMP协议是既可以推流、也可以拉流的协议。RTMP和HTTP-FLV都是建立在FLV封装之上的，RTMP一般用作直播源推流，HTTP-FLV一般用作直播观看；RTMP地址是rtmp://开头的，且推流地址与播放地址是一样的。相对于HTTP方式，很多防火墙会墙掉 RTMP，但是一般不会墙 HTTP，因此 HTTP FLV 出现奇怪问题的概率会很小，FLV 是最简单的流媒体封装，HTTP 是最广泛的协议，这两个组合在一起维护性更高，比 简单很多。RTMP通信是建立在TCP长连接通道上的，在封装音视频数据时会强制切片，限制每个数据包的大小，这在一定程度保证了实时性，有一定的弱网抵抗能力，因为每个数据包都不会太大，所以当某个数据包校验失败时，重新发送的成本不会太大，但也由于合并数据包会加大CPU压力，所以是有一定的性能消耗的。RTMP具备低延迟，内容延迟可以做到 2-5 秒。
\WebRTC是一种 点对点的视频/语音通话协议。由于WebRTC是基于UDP的，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。在一些交互性较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议；WebRTC的延迟理论上可以达到1秒内。WebRTC协议支持推流和拉流，地址一般是以
webrtc://开头的，且推流和拉流地址一般是一样的。WebRTC虽然是点对点的协议，但是应用在直播场景的话，是需要搭建WebRTC服务器作为流媒体服务的，流媒体服务软件可以使用SRS，SRS是国内研发的一个比较流行的开源流媒体服务软件，目前4.0已经囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议。\RTSP（（Real-Time Streaming Protocol））/Onvif（国际标准）协议：一般不用作直播场景，RTSP 是基于文本的协议，采用 ISO10646 字符集，使用 UTF-8 编码方案；RTSP 是应用级协议， 控制实时数据的发送。RTSP（实时流协议）一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。尽管RTSP协议也支持推流/拉流，且支持TCP、UDP切换以及其他诸多优点。但是泛用性不足，特别是现在的浏览器都不支持RTSP的播放。另，RTMP 和 RTSP 都是流媒体传输协议（现场用的是RTP 协议（摄像机主动推流），），它们之间的主要区别：1）RTMP 是一种基于 TCP 的实时传输协议，而 RTSP 是一种基于 UDP 的实时传输协议。2）传输方式：RTMP 是一种单向传输协议，信息只能从服务器端传输到客户端。而 RTSP 支持双向传输，允许服务器端和客户端之间进行实时通信。3）控制协议：RTSP 是一种控制协议，它可以用于控制媒体流的播放、暂停、停止等操作。而 RTMP 不是一种控制协议，它只负责媒体流的传输。4）安全性：RTMP 提供了较低的安全性，因为它使用 TCP 协议进行传输，容易受到中间人攻击。而 RTSP 提供了较高的安全性，因为它使用 UDP 协议进行传输，并支持加密和认证。5）应用场景：RTMP 主要用于直播和视频点播应用，而 RTSP 主要用于实时视频监控和安防监控等应用。RTSP 是用来控制声音或影像的多媒体串流协议， 并允许同时多个串流需求控制。RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成数据传输。HTTP 与 RTSP 相比，HTTP 请求由客户机发出，服务器作出响应；使用 RTSP 时，客户机和服务器都可以发出请求，即 RTSP 可以是双向的。RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如 UDP、组播 UDP 与 TCP 提供途径，并为选择基于 RTP 上发送机制提供方法。RTSP 中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，RTSP 是对称的协议，客户机和服务器都可以发送和回应请求。RTSP 作为一个基于文本的协议，它使用 UTF-8 编码（RFC2279） 和 ISO10646 字符序列，采用 RFC882 定义的通用消息格式，每个语句行由 CRLF 结束(\r\n)。RTSP 的消息包括请求和应答两类。
3）HLS：(HTTP Live Streaming)是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。HLS协议一般只用作拉流观看，严格来说，HLS其实是一个 文本协议，而并非流媒体协议，它的延迟较高（ts0，segment-time：5，10s）。HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，它也很容易使用内容分发网络来传输媒体流。HLS一般主用于通过HTTP协议下载静态视频文件，HLS协议的文件由两部分组成：一是多个只有几秒长度的 .ts碎片 视频文件，另一个是记录这些视频文件地址的.m3u8索引文件；HLS观看地址是以http://开头、.m3u8结尾的，实际上这个地址就是索引文件的地址，客户端获取到索引文件后，就可以下载对应的碎片视频文件并开始播放了；.m3u8索引文件会记录所有的碎片视频文件地址，HLS在点播的场景下，优势是更加明显的。由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更佳明显。另.m3u8索引文件支持二级索引，就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址，大部分网页播放器的“自动”也是因为这个。HLS最大的优点：支持HTML5 就可以直接打开播放，这意味着可以把一个直播链接进行转发分享后用户通过浏览器就能播放，不需要安装任何独立的 APP，HLS协议可以用于点播和直播观看，可适配多种播放场景。采用HLS协议的点播视频，会比.mp4、.flv的视频更快地播放出来，且在加载中跳转视频也会更加顺滑。
采用HLS协议的直播场景，视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件，每生成一个新的视频文件都会同步更新.m3u8索引文件。且碎片视频文件的个数是有上限的，当达到上限后，默认会将最旧的视频文件删除且更新.m3u8索引文件。所以在直播的场景下，客户端也需要不断定时重新获取.m3u8索引文件；即HLS协议并不适合直播的场景。直播场景下，由于需要生成静态文件，直播延迟很大，大概在5-30秒左右，使用直播CDN的话，由于边缘节点同步等问题，直播延迟甚至可能会达到1分钟左右。
注：由于HLS协议的视频文件、索引文件都是无状态的静态文件，是直接写入磁盘的 ，所以如果长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘可能会磁道会损坏，固态硬盘的寿命会加速衰减。这种情况下，最好挂载一段内存空间作为HLS相关文件的写入位置，以减轻磁盘写入压力过大的问题。
4）流（stream）：数据在网络上按时间先后次序传输和播放的连续音/视频数据流。之所以可以按照顺序传输和播放连续是因为在类似 RTMP、FLV 协议中，每一个音视频数据都被封装成了包含时间戳信息头的数据包。而当播放器拿到这些数据包解包的时候能够根据时间戳信息把这些音视频数据和之前到达的音视频数据连续起来播放。而像MP4、MKV 等这类封装，必须拿到完整的音视频文件才能播放，因为里面的单个音视频数据块不带有时间戳信息，播放器不能将这些没有时间戳信息数据块连续起来，所以就不能实时的解码播放。
5）RTP（Real-time Transport Protocol）：它是一种网络传输协议但一般不作为单独应用层协议使用，一般负责音视频数据的封包和传输；RTP（Real-Time Transport Protocol）报文头中有 SSRC和CSRC；其中，同步信源(SSRC)标识符占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。特约信源(CSRC)标识符的每个标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。RTP 本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠 RTCP 提供这些服务。rtp 协议就是提供了时间标签，序列号以及其它的结构用于控制适时数据的流放。RTP 协议和 RTP 控制协议 RTCP通常 一起使用。RTP 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP 的典型应用建立在 UDP 上，但也可以在 TCP 或 ATM 等其他协议之上工作。
\RTSP 与 RTP 最大的区别：RTSP 是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如**：回放、快进、倒退等操作。当然，RTSP 可基于 RTP** 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性，它是一种类似于 http 协议的网络应用层协议。作为一个应用层协议， RTSP 提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。RTP 是实时传输协议，一般不作为单独应用层协议处理；rtsp 可基于 rtp 之上，比如常见的视频流传输过程：视频压缩文件 -> rtp 打包 -> 基于 udp 的 rtsp 网络传输；其中，RTP over UDP 是 RTP 下层使用 udp 传输，RTP over RTSP 是指的用 rtsp 协议建立会话， 然后使用 RTP 协议传输数据，至于下面用 udp 还是 tcp 是不确定的；
6）WebSocket：它是一种在单个TCP连接上进行全双工通信的协议，是HTML5规范提出的一种协议，WebSocket是基于TCP协议的，和HTTP协议是并存的两种协议；目前除了IE浏览器，其他浏览器都基本支持。在HTML5规范中，HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。要使用HTML5 Web Sockets从一个Web客户端连接到一个远程端点，需要创建一个新的WebSocket实例并为之提供一个URL来表示你想要连接到的远程端点。该规范定义了ws://以及wss://模式来分别表示WebSocket和安全WebSocket连接；使用WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。实际，一个WebSocket连接是在客户端与服务器之间HTTP协议的初始握手阶段将其升级到Web Socket协议来建立的，其底层仍是TCP/IP连接。注：Socket是传输控制层接口，WebSocket是应用层协议。WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。HTTP是单向的，WebSocket是需要浏览器和服务器握手进行建立连接的；而http是浏览器发起向服务器的连接，服务器预先并不知道这个连接。WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。总之，在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一次握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；之后，在此基础上建立websocket连接。
7）GA/T 1400协议：它是公安视频图像信息应用系统的重要标准，具有灵活性、可扩展性、环保性、兼容性及安全性等特点。它规范了公安通信系统的数据交换格式，协议在公安系统和其他物联网领域得到广泛应用。GA/T 1400协议也被称为视图库标准，全称为 《公安视频图像信息应用系统》。这一标准在公安系统中具有举足轻重的地位，它详细规定了公安视频图像信息应用系统的设计原则、系统结构、视频图像信息对象、统一标识编码、系统功能、系统性能、接口协议结构、安全性、电磁兼容性、环境适应性、电源适应性、可靠性以及运行与维护等方面的通用技术要求。该协议支持ipv6，可以支持大量的物联网设备同时接入网络；协议还具有低功耗特性，采用先进的加密技术，确保视频图像信息在传输过程中不被窃取或篡改。通过该协议，公安部门可以实现对视频图像信息的实时传输、处理和存储。该协议应用在民用领域，可为用户提供更加高效、安全的视频监控服务。
8）数字视频录像机（DVR：Digital Video Recorder）： 它是一套进行图像存储处理的计算机系统，具有对图像/语音进行长时间录像、录音、远程监视和控制的功能，DVR集合了录像机、画面分割器、云台镜头控制、报警控制、网络传输等五种功能于一身，用一台设备就能取代模拟监控系统一大堆设备的功能，该设备也叫PVR（personal video recorder），相对于传统的模拟视频录像机，它采用硬盘录像，故也俗称为硬盘录像机；它的样子就想一台服务器主机一样，DVR将模拟视频进行数字化编码压缩并储存在硬盘上，其“D”字母主要涉及的是编码及储存技术，与网络传输关系不大，因此DVR通常就近安装在模拟摄像机（模拟摄像机采用模拟信号进行传输，距离较短且容易受到干扰）附近的机房内。而NVR从网络上获取经过编码压缩的视频流然后进行存储转发，其字母“N”涉及的网络传输，因此我们在NVR设备上一般看不到视频信号的直接连接，其输入及输出的都是已经编码并添加了网络协议的IP数据。
9）网络视频录像机（NVR:Network Video Recorder）：NVR最主要的功能是通过网络接收IPC（网络摄像机）设备传输的数字视频码流， 并进行存储、管理，从而实现网络化带来的分布式架构优势。 简单来说，通过Nvr，可以同时观看、浏览、回放、管理、存储多个网络摄像机。摆脱了电脑硬件的牵绊，再也不用面临安装软件的繁琐。NVR不可以独立工作、自成系统，NVR需要与前端的IP摄像机或DVS配合使用，实现对前端视频的存储和管理。对于DVR，可以直接连接模拟摄像机进行视频获取、存储和管理，完全可以自成系统独立工作。NVR不受摄像机、编码器及控制中心的物理位置限制，而只要求网络连通就可以了；而DVR由于直接与模拟摄像机链接，因此物理位置受制于现场设备的布局，通常需要就近部署；
10）SIP协议：SIP（Session Initiation Protocol，会话发起协议）是一个用于建立，更改和终止多媒体会话的应用层控制协议，其中的会话可以是IP电话、多媒体分发及多媒体会议。SIP协议采用Client/Server模型，主要通过与代理服务器之间的通信来完成用户呼叫的建立过程，是互联网上现代交互式通信（语音通话，视频通话等）的基础，在在线即时交流、语音和视频数据传输等场景中也有较好的应用。SIP是一种基于文本的协议，它的语法和消息非常类似于HTTP协议，不同之处在于SIP不仅可以用TCP,也可以用UDP封装。SIP采用统一资源定位(URL,UniformResourceLocators)来指示会话的发起方(From当前请求的目的地(RequestURL)和最终的接收方(To)。SIP在消息体中采用SDP(SessionDescriptionProtocol,会话描述协议）来描述多媒体会话的媒体信息。SIP最大的特点是仅需利用已有的消息头字段，对其进行简单必要的扩充，就能很方便地支持各项新业务和智能业务，具有很强的灵活性和可扩充性。SIP协议天然具有对移动性的支持。SIP的动态注册机制，使用户端的移动变得十分方便。SIP用户是通过类似于e-mail地址的URL标识，通过这种方式可以用一个统一名字标识不同的终端和通信方式，为网络服务和用户使用提供充分的灵活性。按逻辑功能区分，SIP系统由4种元素组成：用户代理、代理服务器、重定向服务器以及注册服务器。
11）QUIC（Quick UDP Internet Connections）协议：它是一种由Google开发的新型网络传输协议，旨在通过UDP提供与TCP类似的可靠传输服务，同时解决传统TCP协议的延迟和拥塞控制问题。QUIC整合了TLS加密、流量控制、连接管理等功能，优化了传输性能，尤其是在高延迟和不稳定（弱）网络环境中表现出色。通过将连接建立与加密握手结合，QUIC能够显著减少连接建立的时间，通常情况下，QUIC只需一次往返（1-RTT）即可完成握手。QUIC默认使用TLS 1.3加密，提供与HTTPS同等的安全性，避免了传统TCP在加密层次上的额外开销。另外，QUIC支持多路复用，在一个QUIC连接中可以同时传输多个数据流，每个流都有独立的流量控制和错误恢复机制，避免了TCP中“队头阻塞”问题。流是QUIC数据传输的基本单位，每个流都有唯一的ID，可以独立传输，避免互相影响。QUIC能够快速检测丢包并进行重传，改进了传统TCP的拥塞控制和丢包恢复机制；QUIC还允许实现自定义的拥塞控制算法。相关经验表明，对使用QUIC协议和其他协议（TCP协议）在弱网的表现统计发现：QUIC协议在登录成功、推拉流成功的耗时，大幅低于TCP协议，优化百分比在30%以上，极端场景甚至超过90%。QUIC能够在IP地址变化时保持连接，对于移动网络中的网络变化设备切换特别有利；非常适合实时通信场景：由于其低延迟和高可靠性，QUIC适用于视频会议、在线游戏等需要实时数据传输的应用，基于QUIC协议实现信令服务可有效降低视频传输过程中的丢包导致的视频问题。
2.2、GB28181网络视频协议
GB28181协议是指遵循国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》中所要求的进行视频处理的约定标准。它也是我国公安部提出的一个通用的视频监控联网协议。它规定了视频监控系统中前端设备、平台服务器、客户端之间的通信协议和数据格式，旨在实现不同厂家、不同设备之间的互联互通。其中：
1.该标准规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求，是视频监控领域的国家标准。
2.GB28181协议信令层面使用的是SIP（Session Initiation Protocol）协议；
3.流媒体传输层面使用的是实时传输协议（Real-time Transport Protocol，RTP）协议；
GB28181协议数据包封装格式：
如上图所示，视频连网系统在进行视音频传输及控制时应建立两个传输通道：会话通道和媒体流通道
会话通道：用于在设备之间建立会话并传输系统控制命令媒体流通道：用于传输视音频数据,经过压缩编码的视音频流采用流媒体协议 RTP/RTCP传输GB/T28181协议从本质上说和ONVIF都是一样的，目的都是为了降低视频监控设备互联的难度。该协议都是基于IP网络。GB/T28181平台服务器进行模块化设计、支持分布式部署。具有设备管理模块、信令模块、流媒体模块、存储模块。支持多个中心信令服务器部署、支持多个流媒体负载均衡。流媒体模块支持RTSP、RTMP等协议访问。支持对摄入摄像机的云台控制。GB/T28181不仅包括设备间的级联，也包含系统的级联，故并不矛盾。如网络摄像机通过ONVIF协议接入NVR，NVR在通过GB/T28181标准接入平台，或者网络摄像机通过ONVIF协议接入平台，平台间的级联通过GB/T28181规范进行。GB/T28181还支持区域平台级联，构建三级平台级联模式，区域级联能有效的解决资源共享问题。目前大多在国标实现的视频直播，几乎都是围绕着GB28181这个国标协议进行流的互联网直播和管理的。GB28181采用了通信领域流行的SIP协议。一般会有一个国标服务器，为摄像头这些终端设备提供支撑和服务。如果需要使用国标摄像头，需要先配置国标服务器，在服务器上创建摄像头的参数，也就是摄像头的20位国标ID。
2.3、常见视频管理架构
现场视频服务架构：
GB（国标平台）服务，一般包含：信令服务(CMS：中心信令服务器 ) 和 流媒体服务(SMS/NMS) 两部分；可将多个 SMS部署LiveSMS在不同服务器上来提升视频流分发性能, 让它们执行同一个CMS即可。
上图中，国标域是视频网关配置的国标域参数，一般是视频服务器国标ID的前十位；传输协议：一般情况下如果你的网络带宽较好，选择UDP。如果网络带宽一般或者通过互联网传输可以选择TCP。GB28181目前已经发布三个版本，分别是2011，2016，2022。目前主流的版本使用的都是2016版本。SIP服务器的ID就是我们说的平台的国标ID，在国标28181体系内任何一个设备都有一个国标ID,每个摄像头有一个自己的20位ID,录像机，平台，网关，编解码都有自己的国标ID，以接入国标网关。与SIP服务器ID一样，国标服务器也会有一个域ID,一般是服务器ID的前十位。SIP服务器地址就是国标平台的IP地址。SIP用户名和SIP认证ID,就是我们在平台上为摄像头创建的国标ID和用户名。原则上这两个ID使用同样的参数。密码就是在国标平台上创建国标ID时的配套密码，这里一定要与服务器端配置的一致，不然无法注册成功。
国标28181的工作逻辑，需要向国标平台发起注册信息，当服务器平台验证通过后，代表摄像头当前正常挂载在服务器平台下，在注册有效期内就可以调看摄像头视频。如果超过有效期，并且一直没有收到新的注册消息，这个摄像头就会处于离线状态。国标平台和摄像头之间需要有一个保活机制，来确认当前的网络状态，各项指标，通信正常。这里、、可以配置多久发一次心跳，一般默认为60秒发一次。
视频接入网关是一款视频融合设备，可以解决各种视频资源之间的接入，转发，转码互通问题。通过简单的接口调用，可以实现丰富的视频业务集成。
三、问题及故障
3.1、视频断流
现场远程会议室录像机是通过国标GB28181协议注册到视频管理平台后，视频播放了一会儿就出现了断流的现象。
处理：现场抓包设备查和sip协议查看视频流推送通信过程，设备端会主动发bye，导致断流；然后更换网络环境，测试对比排除；当现场配置有防火墙时，对外的端口未能恰当开放，会导致断流现象。
eg1：相关经验表明，当设备网络较差时，设备会出现断流，超过指定的超时时间30s(各平台默认值不同)，就会主动清除流媒体服务，但是redis中的流数据还在，而当设备在录像时，自动保活会从redis中取保活流数据，所以就会出现设备状态显示正在播放，但是流已经消失的情况。这时，就需要检查对流的判断，确保异常后可重新拉流，现场实际为：断流后会重试拉流。
eg2：UDP传输rtp数据包丢帧，可能原因：1)连续发送数据包太快；2)发送数据包太长 ；3）接收端处理时间过长导致丢包。4）发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包；这种情况可以设置socket接收缓冲，可简单理解，每个Socket拥有两个内核缓冲区（对应2个缓冲区文件），修改缓冲区的内核限制的最大值可优化缓冲性能；5）发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如：多个mut size的包连续发送中间不sleep,也有可能导致丢包，这种情况也有时可以通过设置socket接收缓冲缓解，最好还是加入sleep；
cat /proc/sys/net/core/rmem_max212992 #其他说明如下rmem_max：一个Socket的读缓冲区可由程序设置的最大值，单位字节；wmem_max：一个Socket的写缓冲区可由程序设置的最大值，单位字节；rmem_default：一个Socket的被创建出来时，默认的读缓冲区大小，单位字节；wmem_default：一个Socket的被创建出来时，默认的写缓冲区大小，单位字节；eg3：基于UDP的RTP传输在复杂的公网环境下，尤其网络不好时，极易面临丢包、乱序、重复、抖动等问题，严重影响实时音视频互动效果，即使是一个rtp包得丢失，如果接收端不做处理，也会导致视频马赛克的出现或断流黑屏。可尝试采用多种方法改善，比如：视频接收端 jitter buffer 处理包乱序/重复问题，FEC(前向纠错) 优先处理丢包恢复，以及当FEC恢复不了丢失数据包时采用丢包重传策略请求重传数据包，如果重传依然有丢包情况，则解码端不去解码(有可能花屏)，直接请求发送方发送I帧（Intra-coded Frame，内部编码帧，它是一种关键帧，完全独立于其他帧进行编码，不依赖其他帧，它可以作为视频解码的起点，在一个图像序列中只有一个I帧）。相关经验实践表明，通过以上措施能有效避免丢包导致的花屏，卡顿现象，另外通过调整FEC冗余度，可以达到不同丢包率的处理。
在Internet 上进行音视频实时互动采用的传输层方案有TCP(如:RTMP)和UDP(如:RTP)两种。基于TCP的方式时，在Internet传输实时音视频数据时会引发很多问题。首先就是延迟问题，在传输信道丢包率较高时，TCP的传输质量下滑严重，重传拥塞导致音视频延时非常大，失去实时互通的意义。特别是无线信道(WIFI、4G、3G)下，使用TCP做双向互通通讯稳定性欠佳，易出现音视频长时间卡住不动然后快放的现象。实践中，更多的产品选择采用的协议是UDP(一般上层应用层协议为RTP，以提供序号和音视频同步的服务)。UDP同TCP相比能提供更高的吞吐量和较低的延迟，非常适合低延时的音视频互动场合。虽然UDP 提高了性能，但它是以不能保障数据完整性为代价的，它不能对所传数据提供担保，常见的问题有：包乱序、包丢失、包重复，尤其在无线信道(WIFI、4G、3G)下，UDP包乱序和包丢失可以说是常态。视频码流的少量丢失都会导致解码后的视频出现花屏的现象。H264、HEVC这样的高压缩率视频压缩标准使得压缩的冗余度非常低，码流的丢失除了影响本帧的解码外，还将影响以此为参考的视频帧解码，导致花屏的累积扩散，直至下一个关键帧的到来视频画面方能恢复。虽然解码器内部会做一定的错误掩盖处理，但效果并不理想，特别是采用ffmpeg这类开源的解码器，其错误掩盖算法做得比较简单。为此，在很多产品中不得不采用较小的GOP(较小的I帧间隔)，以期在出现丢包花屏后能尽快的用I帧码流刷新画面。这种方法副作用较大，而且某些场合下甚至会适得其反。因为I帧压缩效率远不如P帧、B帧，I帧往往比P帧、B帧大很多，频繁的I帧将给传输信道带来持续的波动压力，造成更严重的丢包、乱序。另外，因为编码器码率控制的缘故，I帧占用较多的码流后，紧接着的P、B帧将不得不采用较大的QP量化参数(较差的图像质量)以保证码率的局部可控，这样带来的直观感受是图像随着I帧间隔周期性的
发虚、马赛克。乱序的 UDP 包不经过顺序恢复直接送解码器同样会导致解码花屏，因为解码器内部会将迟到的数据包丢弃。
3.2、视频串流
GB28181协议下频繁出现串流和断流的问题主要涉及到几个方面：设备配置冲突、网络问题、协议实现的不一致性以及服务保活机制的问题，主要出现在网络方面。
1）摄像设备配置冲突：
如果现场两台设备配置冲突，比如：配置参数SIP用户ID必须为唯一值（一般会根据地区编码设置不同ID），否则会向视频管理平台进行不间断地注册，这样就会导致这两台设备的视频流冲突，一会是A设备的流，一会是B设备的流。
\
2）网络问题：
在网络通信过程中，随着视频流并发和资源下载等负载增高，出现通过国标GB28181协议注册到视频监控平台后频繁断流，可能是因为现场网络环境存在问题，如：防火墙设置导致端口未能开放，进而影响视频流的正常传输。可通过开启对应端口后，尝试查看视频流是否可恢复正常。
eg1：当设备网络较差时，设备会断流，超过指定的时间30s(各平台默认值不同)，就会主动清
除流媒体服务，但是redis中的流数据还在，而当设备在录像时，自动保活会从redis中取保活流数据，所以就会出现设备状态显示正在播放，但是流已经消失的情况。
3）协议实现的不一致性：
GB28181协议在实施过程中，由于不同厂商的实现可能存在差异，导致协议解析出现问题，进而影响到服务稳定性。例如，部分机型不按照标准ps协议封包，导致级联平台中的ssrc直接默认为0，无法使用ssrc校验码流，从而引发串流问题。此外，rtp码流无法避免串流和异常码流攻击，即使采用ssrc校验也不能完全避免。
4）服务keep-alive机制的问题：
在设备进行播放保活时，如果对流信息判断不当，可能导致断流现象。例如，如果设备端主动发送bye信令，而服务端未能正确处理这种情况，就会导致视频流意外断开。解决这一问题的方法包括对流信息进行正确判断，并在必要时自动重新拉流。
5）通道占用问题：
相关经验中，当通过数据库查看设备状态实际离线后（即它的通道实际也就离线了），但页面检查会发现设备通道是在线状态，故前台也会显示该设备在线，然实际是该摄像头使用了其他通道的标识，导致最终出现串流。故在代码层面应检测设备时如果处于离线状态，只需将关联的通道也置为离线状态即可。
6）处理：
网络示例：基于UDP协议传输的国标设备视频流的防串流方法，平台携带媒体流信息通过
SIP服务向国标设备GB发送断流信令，并等待国标设备回复;平台基于返回结果判断国标设备回复是否正常;正常则平台向流媒体服务发送断流请求;不正常则结束断流流程并记录断流异常日志，同时标记媒体流信息为待确认的可用状态；流媒体服务接收断流请求，将待关闭端口标记为可释放的同时启动监测，设备断流后还有媒体流数据向该端口发送时，向平台发送告警通知;若设备断流成功则通知平台删除媒体流信息;平台将异常信息推送给运维平台，运维平台通知相关运维人员进行情况确认和维护。本发明有效避免串流现象出现，保障每一个端口只有一路流接入。
3.3、播放花屏、卡顿
一般是由于设备端视频向服务端传输时网络跟不上导致，可以在设备端的配置页面，把视频的码率降低。一般公网播放的话建议码率设置到256-1024kbps之间。如果码率太高，设备端上行带宽很可能跟不上。其次, 可以将流传输模式改为 TCP 被动 来改善播放效果:TCP 被动 流传输模式需要设备支持, 同时要求一定的 TCP 收流端口区间开放, 如果以上条件不满足, 以 TCP 被动模式拉流, 将获得错误信息 “none rtp data receive”。
3.4、“invite device[xx] failed, res…”
CMS 向下级设备拉流失败, res 后面是下级设备回复内容。可检查CMS 信令日志查找到详细的报错信息。如果是 “res[503] Service Unavailable” 一般是由于下级录像机上通道离线导致。如果是 “res[415] Unsupported Media Type” 并且正在调阅设备录像， 一般是对应的时间段在下级设备上没有录像存储导致。
3.5、none rtp data receive
一般是SMS 收不到下级推流, 首先需要排查服务器端 UDP & TCP 接收流 端口是否开放。
3.6、“invalid rtp payload type[xx]”
一般是SMS 收到下级不标准的国标推流。
四、其他
1）直播流地址格式
WEBRTC: webrtc[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/rtc/{设备国标编号}_{通道国标编号}FLV: http[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/flv/hls/{设备国标编号}_{通道国标编号}.flvWS_FLV: ws[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/ws-flv/hls/{设备国标编号}_{通道国标编号}.flvHLS: http[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/hls/{设备国标编号}_{通道国标编号}/live.m3u8RTMP: rtmp://{sms_ip}:{rtmp_port}/hls/{设备国标编号}_{通道国标编号}RTSP: rtsp://{sms_ip}:{rtsp_port}/{设备国标编号}_{通道国标编号}2）视频大小估算
eg1:比如显示器正在播放一个视频，分辨率是1280*720，帧率是25，那么一秒所产生正
常的数据大小为:
1280*720(位像素)*25(张)/8(1字节8位)(结果:B)/1024(结果:KB)/1024(结果:MB)=2.75MB