视频服务器：GB28181网络视频协议

一、前言

某项目中需要集成视频管理平台，实现分布在各省公司的摄像及接入，对视频进行统一管理。本项目中视频管理平台采用GB/T28181实现的监控设备接入管理平台，支持在开放互联网和局域网对监控设备进行远程接入、远程管理、远程调阅、录像回看等功能。本文对此记录GB/T28181协议的原理和一些问题，以供后续参考。

相关资源：Nginx支持flv和mp4格式文件，同时支持Rtmp协议；同时打开rtmp的hls功能

二、视频协议

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单元的类型。：
  
  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/Onvif协议：一般不用作直播场景，RTSP一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。尽管RTSP协议也支持推流/拉流，且支持TCP、UDP切换以及其他诸多优点。但是泛用性不足，特别是现在的浏览器都不支持RTSP的播放。RTMP 和 RTSP 都是流媒体传输协议，它们之间的主要区别：1）RTMP 是一种基于 TCP 的实时传输协议，而 RTSP 是一种基于 UDP 的实时传输协议。2）传输方式：RTMP 是一种单向传输协议，信息只能从服务器端传输到客户端。而 RTSP 支持双向传输，允许服务器端和客户端之间进行实时通信。3）控制协议：RTSP 是一种控制协议，它可以用于控制媒体流的播放、暂停、停止等操作。而 RTMP 不是一种控制协议，它只负责媒体流的传输。4）安全性：RTMP 提供了较低的安全性，因为它使用 TCP 协议进行传输，容易受到中间人攻击。而 RTSP 提供了较高的安全性，因为它使用 UDP 协议进行传输，并支持加密和认证。5）应用场景：RTMP 主要用于直播和视频点播应用，而 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 等这类封装，必须拿到完整的音视频文件才能播放，因为里面的单个音视频数据块不带有时间戳信息，播放器不能将这些没有时间戳信息数据块连续起来，所以就不能实时的解码播放。

WebSocket

GA/T 1400协议
数字视频录像机（DVR）
网络视频录像机（NVR）
SIP协议：SIP（Session Initiation Protocol，会话发起协议）是一个用于建立，更改和终止多媒体会话的应用层控制协议，其中的会话可以是IP电话、多媒体分发及多媒体会议。SIP协议采用Client/Server模型，主要通过与代理服务器之间的通信来完成用户呼叫的建立过程。

2.2、GB28181网络视频协议

GB28181协议是指遵循国家标准GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》中所要求的进行视频处理的约定标准。它也是我国公安部提出的一个通用的视频监控联网协议。它规定了视频监控系统中前端设备、平台服务器、客户端之间的通信协议和数据格式，旨在实现不同厂家、不同设备之间的互联互通。其中：

1.该标准规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求，是视频监控领域的国家标准。
2.GB28181协议信令层面使用的是SIP（Session Initiation Protocol）协议；
3.流媒体传输层面使用的是实时传输协议（Real-time Transport Protocol，RTP）协议；

GB28181协议数据包封装格式：

如上图所示，视频连网系统在进行视音频传输及控制时应建立两个传输通道：会话通道和媒体流通道

• 会话通道：用于在设备之间建立会话并传输系统控制命令
• 媒体流通道：用于传输视音频数据,经过压缩编码的视音频流采用流媒体协议 RTP/RTCP传输

2.3、常见视频管理架构

三、问题及故障

3.1、视频断流

现场远程会议室录像机是通过国标GB28181协议注册到视频管理平台后，视频播放了一会儿就出现了断流的现象。

处理：现场抓包设备查和sip协议查看视频流推送通信过程，设备端会主动发bye，导致断流；然后更换网络环境，测试对比排除；当现场配置有防火墙时，对外的端口未能恰当开放，会导致断流现象。

eg1：相关经验表明，当设备网络较差时，设备会出现断流，超过指定的超时时间30s(各平台默认值不同)，就会主动清除流媒体服务，但是redis中的流数据还在，而当设备在录像时，自动保活会从redis中取保活流数据，所以就会出现设备状态显示正在播放，但是流已经消失的情况。这时，就需要检查对流的判断，确保异常后可重新拉流，现场实际为：断流后会重试拉流。

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）通道占用问题：

相关经验中，当通过数据库查看设备状态实际离线后（即它的通道实际也就离线了），但页面检查会发现设备通道是在线状态，故前台也会显示该设备在线，然实际是该摄像头使用了其他通道的标识，导致最终出现串流。故在代码层面应检测设备时如果处于离线状态，只需将关联的通道也置为离线状态即可。