视频服务器：GB28181网络视频协议及相关流媒体开源框架
一、前言
某项目中需要集成视频管理平台，实现分布在各省公司的摄像及接入，对视频进行统一管理。本项目中视频管理平台采用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 结束( )。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 等其他协议之上工作。
- SSRC：同步信源是指产生媒体流的信源，例如麦克风、摄像机、RTP混合器等；它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。
- CSRC：特约信源是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，并把混合器作为组合RTP报文的 SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。基于以上分组及列表，这样接收者就可以根据CSRC来区分不同的信源；一般的，混合的RTP流中，每隔一段时间，就会有一个RTP报文包含了完整的CSRC表。
- 流的概念中时间标签是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后，就依照时间标签按照正确的速率恢复成原始的适时的数据。rtp 协议和 udp 二者共同完成运输层协议功能。udp 协议只是传输数据包，不管数据包传输的时间顺序。rtp 的协议数据单元是用 udp 分组来承载的。在承载 rtp 数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而 udp 的多路复用让 rtp 协议利用支持显式的多点投递，可以满足多媒体会话的需求。其中， 时间戳有32 位，时间戳反映 RTP 数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让 receiver 端知道在正确的时间将资料播放出来。
- RTCP 负责管理传输质量在当前应用进程之间交换控制信息。在 RTP 会话期间，各参与者周期性地传送 RTCP 包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和 RTCP 配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
- 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。
在GB/T28181协议中，为了确保视频监控联网系统的安全性，采用了多种加密措施来保护数据传输的安全。通过这些加密措施，GB/T28181协议可确保视频监控联网系统在数据传输、设备认证、信令交互等方面的安全性，为公共安全提供坚实的技术保障。以下是一些具体的加密措施：
1、设备身份认证：所有接入系统的设备都需要进行身份认证，以确保设备的合法性。
2、数据加密：在需要高安全级别的应用中，协议建议在网络层采用IPSec或在传输层采用TLS对SIP消息实现安全加密。此外，在应用层可采用S/MIME机制的端到端加密，传输过程中可采用RSA对会话密钥进行加密，传输内容可采用DES、3DES、AES(128)等算法加密。
3、SIP信令认证：SIP信令应进行数字摘要认证，支持MD5等数字摘要算法。在SIP消息头域中，启用Date域，增加Note域，以增强信令的安全性。
4、数据完整性保护：为了保护数据不被篡改，协议建议采用数字摘要、数字时间戳及数字水印等技术。数字摘要可采用MD5、SHA-1、SHA-256等算法。
5、访问控制：系统应实现统一的用户管理和授权，在身份鉴别的基础上，系统可采用基于属性或基于角色的访问控制模型对用户进行访问控制。跨域访问时，可采用信令Monitor-User-Identity携带的用户身份信息进行访问控制。
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_max
212992 #其他说明如下
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 收到下级不标准的国标推流。
3.7、同一单位公网出口下只有一台设备在线
1、SIP（Session Initiation Protocol）：常用于视频流设备的注册和会话管理。sip是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议[3] 、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。SIP支持基于UDP和TCP的传输,视频流传输使用偶数端口，端口+1默认为为RTCP使用端口；一般注册流程描述如下：
- 1、 SIP代理/摄像头终端向SIP服务器发送REGISTER请求；
- 2、 SIP服务器向SIP代理/摄像头终端发送响应401,并在响应的消息头WWW-Authenticate字段中给出适合SIP代理的认证体制和参数；
- 3、 SIP代理重新向SIP服务器发送REGISTER请求，在请求的Authenticate字段给出信任书，包含认证信息；(无代理忽略步骤2和3)
- 4、 SIP服务器对请求进行验证，如果检查出SIP代理身份合法，向SIP代理发送成功响应200 OK,如果身份不合法则发送拒绝服务应答。注册信令消息示范：
Register sip:SIP服务器编码@目的域名或者IP地址端口 SIP/2.0
Via:SIP/2.0/UDP 源域名或者IP地址端口
From:sip:SIP设备编码@源域名;tag=185328220
To: sip:SIP设备编码@源域名
Call-ID:ms1214-322164-681262131542511620107-0@172.18.162.3
CSeq:1 Register
我们可检查SIP注册消息（如 REGISTER）是否正确发送和接收。确认视频平台是否返回正确的响应（如 200 OK）。确认摄像头和视频平台使用的协议版本一致。如涉及NAT设备，确保NAT设备支持UDP穿透。
2、RTSP（Real-Time Streaming Protocol）：一百用于视频流的控制和传输。检查RTSP的 OPTIONS 或 DESCRIBE 请求是否正常。
3、ONVIF协议：用于网络摄像头的标准化通信。检查ONVIF的 Probe 消息是否正常。
4、执行tcpdump udp port 9000 and host ip -w error.pcap 然后导入wireshark筛选:sip || rtsp
Frame: 物理层的数据帧概况
Ethernet II: 数据链路层以太网帧头部信息
Internet Protocol Version 4: 互联网层IP包头部信息
Transmission Control Protocol: 传输层T的数据段头部信息，此处是TCP
Hypertext Transfer Protocol: 应用层的信息，此处是HTTP协议
Deepseek协助分析如下：
场景分析：同一网络出口下有9个摄像头IP，但只有一个SIP注册在线，其他都显示不在线。服务端抓包没抓到其他摄像头的dev id，但在防火墙上抓UDP包时能看到这些摄像头发出了register SIP信令，不过只有UDP包而没有SIP请求。这到底是怎么回事呢？
首先，我需要了解SIP协议的基本工作原理。SIP（Session Initiation Protocol）通常用于建立、修改和终止多媒体会话，比如VoIP或视频通话。SIP通常运行在UDP或TCP上，这里用户提到的是UDP。SIP注册过程中，设备会发送REGISTER请求到服务器，以保持其在线状态。
现在的问题是，服务端抓包没有看到其他摄像头的dev id，但防火墙上能看到UDP包中有这些摄像头的REGISTER信令。这说明摄像头确实发送了注册请求，但服务端没有正确处理或接收这些请求。可能的原因有很多，我需要逐一分析。
首先想到的是网络路径问题。虽然摄像头发送了UDP包，但这些包可能没有到达服务端。中间可能有防火墙、路由器或NAT设备阻止了这些包。用户提到在防火墙上能看到UDP包，说明包到达了防火墙，但之后是否被正确转发到服务端呢？需要检查防火墙规则，确保允许从摄像头到服务端的UDP流量通过，特别是SIP使用的端口（通常是5060）。
另外，NAT（网络地址转换）也是一个可能的因素。如果摄像头位于NAT后面，而服务端在公网上，可能需要检查NAT配置是否正确，确保SIP信令中的IP地址和端口没有被错误地转换。SIP协议中的Contact头字段通常包含设备的真实IP和端口，如果NAT设备没有正确处理这些信息，可能导致服务端无法正确响应或识别设备。
另一个可能性是SIP协议栈的问题。服务端可能没有正确解析接收到的SIP消息，导致无法识别dev id。或者摄像头发送的SIP消息格式不符合服务端的预期，比如缺少必要字段、版本不兼容等。这时候需要详细分析抓包文件，查看SIP消息的具体内容，确认是否符合RFC规范。
还有可能是服务端本身的配置问题。例如，服务端可能设置了白名单，只允许特定的dev id注册，或者有并发连接数的限制，导致其他摄像头无法注册。此外，服务端的SIP模块可能存在bug，无法正确处理多个并发注册请求。
此外，需要检查网络中的QoS（服务质量）设置。如果网络中存在带宽限制或优先级设置，可能导致SIP信令被延迟或丢弃，尤其是在高负载情况下。这会影响注册过程的及时性，导致摄像头显示为不在线。
还有一个角度是时间同步问题。SIP注册通常有有效期，如果摄像头和服务端的时间不同步，可能导致注册超时或失效。虽然这不太可能导致所有摄像头同时失效，但如果是单个摄像头的问题，可能需要考虑这一点。
接下来，用户提到在防火墙上抓到了UDP包，但服务端没有收到SIP请求。这说明数据包在到达防火墙后，可能在到达服务端的路径上丢失了。需要检查防火墙到服务端之间的网络设备，比如路由器、交换机，是否有ACL（访问控制列表）或过滤规则阻止了这些UDP包。此外，服务端本身的防火墙或主机防火墙（如iptables）也需要检查，确保开放了相应的端口。
另外，需要确认服务端监听的UDP端口是否正确配置。如果服务端只监听特定端口，而摄像头发送到其他端口，也会导致注册失败。同时，检查服务端的日志，查看是否有接收到注册请求的记录，以及可能的错误信息。
还有一个可能性是网络中的MTU（最大传输单元）设置问题。如果SIP消息的大小超过了MTU，可能导致分片，而某些网络设备可能不处理分片数据包，导致服务端无法重组完整的SIP消息。这可以通过检查抓包中的分片情况来验证。
此外，需要考虑服务端的处理能力。如果服务端处理大量并发注册请求时资源不足（如CPU、内存、套接字缓冲区等），可能导致丢包或处理延迟，使得部分摄像头无法成功注册。
最后，可能是摄像头的固件或配置问题。如果某些摄像头的SIP配置错误，比如错误的服务器地址、端口、认证信息等，也会导致注册失败。需要检查这些摄像头的配置，确保与服务端的要求一致。
综上，可能的网络问题包括：
- 防火墙或中间设备过滤了UDP/SIP流量。(后排查是用户侧华为Eudemon8000E防火墙会话配置问题)，注：UDP没有首包概念。
- NAT配置问题导致SIP信令中的地址转换错误。
- 服务端配置问题，如端口监听、ACL、并发连接限制。
- SIP消息格式不符合服务端要求。
- 网络路径中的MTU问题导致分片丢失。
- 服务端资源不足导致丢包。
- 摄像头配置错误。
为了进一步排查，可以采取以下步骤：
-
详细分析防火墙抓包和服务端抓包：对比两者，确认SIP请求是否确实到达服务端。如果防火墙上有抓包显示发送了REGISTER，但服务端没有收到，问题可能出在防火墙到服务端之间的路径。
-
检查防火墙规则：确保防火墙允许从摄像头IP到服务端IP和端口的UDP流量。
-
检查NAT配置：如果存在NAT，确认SIP信令中的Contact头字段是否正确反映公网IP和端口，必要时配置SIP ALG（应用层网关）或修复NAT穿透问题。
-
服务端抓包分析：在服务端使用tcpdump或Wireshark抓包，确认是否接收到摄像头的SIP请求。如果没有，需要排查中间网络设备。
-
检查服务端端口监听：使用
netstat -anu（UDP）确认服务端是否在正确端口上监听。 -
检查服务端日志：查看SIP服务的日志，了解是否有注册请求到达及可能的错误信息。
-
验证SIP消息格式：通过抓包分析摄像头发送的SIP REGISTER消息是否符合RFC规范，特别是Via、Contact、From/To头字段是否正确。
-
测试端到端连通性：从服务端向摄像头发送UDP包，测试双向连通性，确认没有单向阻断。
-
检查MTU和分片：使用ping测试大包（如
ping -s 1472）确认MTU是否合适，避免分片问题。 -
资源监控：检查服务端的CPU、内存、网络使用情况，确认是否存在资源瓶颈。
-
摄像头配置检查：随机抽查几个摄像头的SIP配置，确保服务器地址、端口、认证信息正确。
display firewall session table source inside *.*.*.* //查看会话表状态
display firewall session table //查看会话表简要信息
display firewall session table verbose //查看会话详细信息
display firewall session aging-time //查看的会话表老化时间设置
firewall session aging-time tcp 60 //TCP老化时间设置为60s
firewall session link-state check //会话状态监测
firewall session link-state tcp check
undo firewall session link-state check tcp/icmp //关闭，用于来回路径不一致的情况
firewall session aging-time service-set http 2000 //修改内置协议老化时间，注意单位是S
四、其他
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/{设备国标编号}_{通道国标编号}.flv
WS_FLV: ws[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/ws-flv/hls/{设备国标编号}_{通道国标编号}.flv
HLS: http[s]://{cms_ip}:{cms_http[s]_port}/sms/{sms_id}/hls/{设备国标编号}_{通道国标编号}/live.m3u8
RTMP: 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
五、常见主流的开源流媒体服务器及框架
5.1、Live555 [RTSP拉流]
一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输协议如 RTP/RTCP、RTSP、SIP等的支持。实现了对多种音视频编码格式的音视频数据的流化、接收和处理等支持，包括MPEG、H.263+、DV、JPEG视频和多种音频编码。因其良好的设计，Live555 非常容易扩展对其他格式的支持。目前，Live555 已经被用于多款播放器的流媒体播放功能的实现，如 VLC (VideoLan)、MPlayer。LIVE555 媒体服务器” 是完整的 RTSP 服务器应用程序。它可以流式传输MPEG 传输流文件（文件名后缀 “.ts”）、甲的 Matroska 或 WebM 的文件（文件名为后缀 “.MKV” 或 “.webm”）、一个奥格文件（文件名后缀 “.OGG”，‘OGV’，或 “.opus”）、MPEG-1 或 2 节目流文件（文件名后缀 “.mpg”）、MPEG-4 视频基本流文件（文件名后缀 “.m4e”）、H.264 视频基本流文件（文件名后缀 “.264”）、H.265 视频基本流文件（文件名后缀 “.265”）、一个 VOB 视频 + 音频文件（文件名后缀为 “.vob”）、DV 视频文件（文件名后缀 “.dv”）、MPEG-1 或 2（包括第 III 层，即 “MP3”）音频文件（文件名后缀 “ .mp3”）、WAV（PCM）音频文件（文件名后缀 “.wav”）、AMR 音频文件（文件名后缀 “.amr”）、AC-3 音频文件（文件名后缀 “.ac3”）和AAC（ADTS 格式）音频文件（文件名后缀 “.aac”）这几种媒体文件（必须存储在当前工作目录中，即从中启动应用程序的目录中或子目录中）。
关联资源：官网、Gitee_live555
Live555 Streaming Media框架由多个模块构成，以提供全面的流媒体功能。首先UsageEnvironment模块是核心，它抽象了系统环境，包含抽象类UsageEnvironment和TaskScheduler。
UsageEnvironment负责消息的输入输出和用户交互，TaskScheduler则负责异步事件处理和延迟调度，通过维护异步读取源处理通信事件，使用DelayQueue进行延迟处理。HashTable类在项目中通用，通过自定义子类，可以在特定环境（如GUI）中无缝运行，无需大幅度修改。BasicUsage Environment模块作为控制台应用的实现，专注于控制台的输入输出和信号响应的实现，是UsageEnvironment的实用化版本。GroupSock模块则是数据包传输的核心，它支持多播和单播通信，是数据包发送和接收的关键部分。
LiveMedia模块是整个框架的心脏，其中的抽象类Medium是其他所有类的基础。其中，RTSPClient负责发送RTSP请求并解析响应，进而创建RTP会话。MediaSession则表示一个RTP会话，可能包含多个子会话，如音频或视频。RTCPInstance负责RTCP协议的通信，是会话管理和质量反馈的基石。
源(Source)和sink(Sink)的概念类似于DirectShow中的Filter，Source抽象了数据源，如通过RTP读取，而Sink是数据消费的抽象，如存储到文件。MediaSource和MediaSink是它们的基础类，通过派生实现不同类型的流媒体格式和编码支持。数据流通常会经过多个Source和Sink，通过RTP子会话(MediaSubSession)相连，形成完整的流媒体传输链路。
5.2、EasyDarwin [RTSP拉流/推流]
EasyRTSPServer是由国内开源流媒体团队基于live555开发和维护的一款开源流媒体平台框架，基于Golang开发维护，支持RTSP推流分发（推模式转发）和RTSP拉流分发（拉模式转发）；目前由EasyDarwin开源社区开发维护，是一套非常稳定、易用、支持多种平台（包括Windows/Linux 32&64，Android，ARM等平台的RTSP Server开源项目，适用于IPCamera、NVR、编码器、安卓监控设备等软硬件产品，接口调用非常简单成熟，调用者无需关注RTSP Server中关于客户端监听接入、音视频多路复用、RTSP具体流程、RTP打包与发送等相关问题，支持多种音视频格式，再也不用像调用live555 RTSPServer那样处理整个RTSP OPTIONS/DESCRIBE/SETUP/PLAY
/RTP/RTCP的复杂流程和担心内存释放的问题了！EasyRTSPServer非常适合于安防领域、教育领域、互联网直播等领域；
EasyDarwin 开源项目至今包括有：EasyDarwin（开源流媒体服务器）、EasyCMS（中心管理服务器）、EasyCamera（云摄像机服务）、EasyClient（云平台客户端）、EasyAACEncoder（开源音频编码项目）、EasyAudioDecoder（开源音频解码项目）、EasyProtocol（开源云平台协议）等多个项目，完整地构架了一套开源流媒体云平台方案；
关联资源：官网、Github_EasyRTSPServer
1）EasyGBS（国标平台/服务） 包含 GB28181 信令服务，ONVIF 客户端，RTMP 推流，RTSP/RTMP 拉流协议等等，内嵌流媒体服务，同时也支持多个流媒体独立部署负载均衡。支持分发 FLV/HLS/WebRTC/RTMP/RTSP 等协议播放。
2）EasyCMS 开源的设备接入与管理服务，支持多设备、多客户端接入，能非常快速地帮助大家实现稳定的设备接入服务，可以根据自己的需求进行服务功能拆分（例如用户接入服务与设备接入服务拆分等），具体见 EasyCMS；
3）EasyDarwin 核心流媒体服务！RTSP 开源流媒体服务，高效、稳定、可靠、功能齐全，支持 RTSP 流媒体协议，支持安防行业需要的摄像机流媒体转发功能、支持互联网行业需要的多平台 (PC、Android、IOS) RTSP 直播（H264/MJPEG/MPEG4、AAC/PCMA/PCMU/G726）功能，底层 (Select/Epoll 网络模型、无锁队列调度) 和上层 (RESTful 接口、WEB 管理、多平台编译)、关键帧索引（秒开画面）、远程运维等方面优化，这些都是全代码完全开源的，具体接口调用方法和流程见：EasyDarwin；
4）EasyCamera 设备端（摄像机、移动设备、桌面程序）对接 EasyDarwin 平台的方案，跨平台，支持 Windows、Linux、ARM，其中 EasyDarwin 摄像机是我们定制的一款摄像机硬件与 EasyDarwin 平台进行对接的方案，摄像机采用海思 3518E 方案，支持 RTSP、Onvif、WEB 管理、配套 SDK 工具，作为开发和演示硬件工具，我们提供了全套完备的程序和文档，既可以用于流媒体学习，又可以用于方案移植参考，更可以直接用于项目中，用户可以将摄像机定制的部分替换成自己摄像机的硬件 SDK，具体接入方法见EasyCamera；
5）EasyClient 是 EasyDarwin 开源流媒体云平台的客户端实现，项目地址：EasyClient，功能包含：Windows、Android、iOS、H5 (支持微信) 四个部分。
5.3、Darwin Streaming Server(DSS)
Darwin Streaming Server（GitHub链接）是Apple提供的QuickTime Streaming Server技术的开源版本，它支持通过行业标准的RTP和RTSP协议在网络上传输流媒体内容。实时流媒体播放服务器，使用开放标准，让你可以透过互联网实时传送实况或预先录制的内容。
5.4、Open Streaming Server
Open-Stream 是一个完全集成的开源游戏流媒体平台，旨在提供低延迟的桌面流媒体服务。它支持多种设备和操作系统，包括 PC、Mac、Android 和 Linux。Open-Stream 利用开源技术如 Moonlight 和 Sunshine Game Stream Host，提供高达 4K 分辨率和 120fps 的流媒体服务。
相关资源：项目地址
5.5、开源流媒体平台FreeCast
一个P2P的流媒体开源平台,使用Java语言编写；
5.6、LiveGBS GB28181流媒体服务[多种类型直播]
支持设备或平台通过GB28181协议接入;
提供 WebRTC、RTSP、RTMP、HTTP-FLV、Websocket-FLV、HLS 等多种协议流输出;
提供实时流媒体处理，PS（TS）转ES;
支持 H264、H265 等多种视频格式接入;
支持语音对讲，级联语音对讲； 支持云台控制、预置位巡航;
5.7、Nginx-RTMP[RTMP直播]
支持RTMP、HLS、MPEG-DASH
支持RTMP、HLS点播
可将直播视频分段存储
支持 H.264 视频编解码、AAC 音频编解码
支持 FFmpeg 命令内嵌
支持回调 HTTP
可使用 HTTP 对直播进行删除、录播等控制
具有强大的缓冲功能，可确保在效率与码率间达到平衡
5.8、SRS(simple-rtmp-server)开源流媒体框架
SRS（Simple Real-Time Media Server）是一个完全开源的流媒体服务器，其核心开发语言是C++（非常适合用于构建需要处理大量并发连接和高数据吞吐量的服务器应用），旨在提供高效、稳定的实时音视频服务。SRS专注于实现互联网级别的集群部署，能够处理高并发的流媒体请求；它追求概念完整性和代码实现的简洁性，其设计追求简洁高效，相比其他服务器，更加轻量级，易于部署和维护。其主要功能包括支持多种流媒体协议、实现直播流的推流和播放、支持流媒体录制和转码等。SRS支持多种操作系统平台，包括但不限于Linux、MacOS和Windows。这种跨平台的能力使得SRS可以部署在各种环境中，满足不同用户的需求。另外，SRS拥有活跃的开发者社区，用户可以获得及时的技术支持和问题解答。SRS源码框架如下：
SRS源码的优点，更多参见源码分析：
- 1、轻量级，代码结构清楚，目前SRS3.0代码8万行左右，但几乎满足直播业务的所有要求。
- 2、SRS采用State Threads，支持高并发量，高性能。
- 3、SRS支持rtmp和hls，满足PC和移动直播要求。
- 4、SRS支持集群部署。小集群Forward，大集群edge。
SRS支持多种流媒体协议，包括但不限于：
- RTMP（Real-Time Messaging Protocol）：用于实时数据传输，支持音视频流的推送和播放。
- HTTP-FLV：通过HTTP协议传输FLV格式的音视频数据，适用于低延迟的直播场景。
- HLS（HTTP Live Streaming）：苹果公司开发的流媒体传输协议，支持将音视频流切片后通过HTTP传输，适用于移动端播放。
- WebRTC：支持实时音视频通信的开放标准，提供低延迟的点对点通信能力。
- 此外，SRS还支持与FFmpeg、Nginx等工具和服务的集成，以及通过协程技术优化服务器性能。
SRS在架构设计上采用了协程技术，这是一种轻量级的线程管理方式。协程允许程序在执行过程中暂停和恢复，这使得SRS能够高效地处理多个并发连接，同时保持较低的资源消耗。通过协程，SRS可以有效地管理大量的客户端连接，而不会因为线程切换的开销而影响性能。另SRS架构上采用了模块化设计，各个组件之间通过定义良好的接口进行通信。这种设计使得SRS的各个部分可以独立开发和测试，同时也便于进行功能扩展和性能优化。SRS的核心组件包括媒体处理模块、网络通信模块和配置管理模块等。
