视频、流媒体协议、GBT28181、GAT1400

参考资料

国标文件下载

一、流媒体概述 && 视频基础知识

流媒体：是指采用流式传输的方式在网络中传输音频、视频和多媒体文件的形式，流媒体技术让我们能够实时观看在线视频、收听在线音乐，而无需等待整个文件下载完成

流式传输方式：是将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，

由服务器向用户计算机连续、实时传送。用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。

视频基础知识：

1）视频：每秒超过 24 帧的连续画面播放就可以叫视频。
2）分辨率：图像的横向和纵向的像素数量，表示图像的精细程度。视频精细程度并不只取决于视频分辨率，还取决于屏幕分辨率。最佳体验为屏幕与视频分辨率相同且全屏播放，视频分辨率过高的话屏幕没有能力去呈现，视频分辨率过低的话无法发挥屏幕的能力。
- 上采样：当 720P 的视频在 1080P 屏幕上播放时，需要将图像放大，放大操作叫上采样；
- 下采样：当 1080P 的视频在 720P 屏幕上播放时，需要将图像缩小，缩小操作叫下采样；
3）码率：单位时间播放音频或视频的比特数，单位是bps。码率（单位为Mbps）=文件大小（单位为MB）✖️8➗视频时长（单位为秒）。在计算机中，1 Byte=8 bit，1MB=8Mb，大写的 B，代表 Byte（字节）。小写的 b，代表 bit（比特）。
- 动态码率：Variable Bit Rate（VBR）码率随着图像复杂程度的不同而随之变化，内容简单的片段采用较小的码率，内容复杂的片段采用较大的码率，这样既保证了播放质量，又兼顾了数据量的限制；
- 静态比特率：Constant Bit Rate（CBR）码率恒定。
4）采样率：每秒从连续信号中提取并组成离散信号的采样个数，单位为赫兹（Hz）。
5）帧率：用于测量显示帧数的量度，单位为 FPS。帧率越高，画面越流畅、逼真，对显卡的处理能力要求越高，数据量越大
6）视频编码：通过特定的压缩技术，将某个视频格式的文件转换成另一种视频格式。编码的终极目的，就是为了压缩。各种五花八门的视频编码方式，都是为了让视频变得体积更小，有利于存储和传输。
7）视频编码格式的标准化：任何技术，都有标准。自从有视频编码以来，就诞生过很多的视频编码标准。编码的两大组织：ISO/IEC（国际标准化组织）、ITU-T（国际电信联盟通信标准部）。
- ISO/IEC 制定的编码标准：MPEG-x 系列，MPEG-1、MPEG-2、MPEG-4、MPEG-7、MPEG-21 和 MPEG-H等；
- ITU-T 制定的编码标准：H.26x系列，：H.261、H.262、H.263、H.264 和 H.265 等。
8）视频数据的封装（文件格式）：一个视频不光有画面，还有声音，还有字幕。为了把它们统统打包到一起，我们就需要用一个盒子，给它们封装起来。
- 封装，简单来说，就是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中。
- 文件格式只是一个外壳，本身并不决定视频的画质好坏，最终决定视频质量的，还是要看里面到底装了什么。目前主要的视频容器有如下：MPG、VOB、MP4、3GP、ASF、RMVB、WMV、MOV、Divx、MKV、FLV、TS/PS等。
9）视频解码：将视频压缩编码过的数据，解压缩成为视频原始数据，即视频编码的反过程
10）直播流程：
11）直播流程的关键环节：
- 实时音视频采集（音视频录制设备）：通过摄像头和麦克风采集音视频数据，并进行参数设置和同步处理；
- 音视频编码：将采集到的音视频数据进行编码，以便进行传输。选择合适的编码器和编码格式，如AAC、Opus、H.264、H.265和VP8等；
- 传输协议：选择合适的传输协议，如RTSP、RTMP、HLS和WebRTC等，以保证音视频数据的实时传输；
- 服务器处理：服务器接收、转发和存储音视频数据，进行负载均衡、转码和录制等处理；
- 音视频解码与播放(视频APP或网页播放器插件等)：将接收到的音视频数据进行解包、解码、渲染和播放，实现音视频同步和延迟优化。

二、几种流媒体协议

RTP :(Real-time Transport Protocol)

RTP 详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。
负责实时媒体数据的封包和传输，提供时间戳和序列号，是建立在 UDP 协议上的传输层协议, 和控制协议 RTCP 一起使用，
RTP 不像http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或简写 RTCP)

实时传输控制协议,是实时传输协议(RTP)的一个姐妹协议
RTP和RTCP属于传输层协议，RTP负责实际传输音频视频数据，RTCP则监控服务质量并传输控制信息

RTSP:(Real-time Streaming Protocol)

RTSP是应用层协议，可以控制多媒体流的播放、暂停、回放等操作。主要应用场景：安防监控、视频会议；
RTSP传输一般需要 2-3 个通道，命令和数据通道分离。
- 1个RTSP控制通道（TCP，长连接）,使用文本指令（如SETUP, PLAY, TEARDOWN）控制媒体流
- 至少1个RTP数据通道（UDP或TCP），用于传输视频数据
- 1个RTCP控制通道（UDP或TCP），与RTP通道配对出现 , 传输用于质量反馈和调整

流媒体传输实现机制：

RTSP作为应用层控制协议，建立和控制会话，通过客户端和服务器之间的交互（如DESCRIBE、SETUP、PLAY等请求）来管理流媒体会话，确定传输参数；
RTP在传输层上对媒体数据进行封装和传输，提供时间戳和序列号以支持数据重组和同步；
RTCP定期发送统计信息（如丢包率、延迟）用于质量反馈和调整，从而实现高效的流媒体传输。

RTMP(Real Time Messaging Protocol)

RTMP协议是 Adobe 的私有协议，未完全公开。主要应用场景：直播推流、互动直播
RTMP一般在 TCP 1个通道上传输命令和数据。信令与数据在单一TCP连接上复用，通过不同的“块流”传输控制消息（如connect, play）和媒体数据
RTMP协议一般传输的是 flv，f4v 格式流。
RTMP 基于 flash 无法在 iOS 的浏览器里播放，但是实时性比 HLS 要好

HLS:HTTP Live Streaming(HLS)

苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议. 主要应用场景：大规模直播分发、视频点播 ,主要应用在iOS系统
基于HTTP的无状态请求，信令控制简单，主要通过下载/更新M3U8索引文件来引导播放
HLS 点播，基本上就是常见的分段HTTP点播，不同在于，它的TS文件分段切片非常小
HLS 直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。 HLS 协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件(MPEG-TS格式)，而客户端则不断的下载并播放这些小文件，
因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播

MPEG-DASH

与HLS类似，基于HTTP。客户端通过下载MPD文件获取媒体描述信息，从而控制播放
视频内容被切分为小分段，支持多种封装格式（如MP4），通过HTTP下载

WebRTC

web端实现流媒体的协议。主要应用场景：视频会议、在线教育互动、一对一通话。

信令通道不由WebRTC自身定义，通常使用SIP或基于Web的技术（如WebSocket）交换会话信息
媒体数据通过 SRTP（安全RTP）在UDP上传输，实现加密的低延迟通信

选型参考

追求极致实时性（如视频监控、视频会议、无人机图传）：RTSP或WebRTC是首选。RTSP在设备端集成度高，WebRTC在浏览器端有天然优势
- RTSP延迟极低 (100-500毫秒，可优化至50毫秒内)。受益于UDP传输及简洁的控制模型
- RTSP扩展控制非常强。提供类似录像机的精细控制（播放、暂停、定位等），适合回放调查
- RTSP设备兼容性极高。是IP摄像头、NVR等安防前端设备的原生协议和行业标准
需要进行大规模、高兼容性的视频分发（如秀场直播、点播平台）：HLS或MPEG-DASH是标准选择。它们能轻松利用CDN分发，适应各种网络条件，代价是较高的延迟。

三、流媒体扩展介绍（sip、GBT28181、GAT1400）

H.264与H.265

H.264与H.265
都是视频压缩格式，由于视频本身的码流太大，所以需要经过压缩然后再通过网络进行传输。H.264是目前比较主流的压缩算法，像视频会议设备一般都采用这个编码格式。基础的H.264可以支持在1M带宽下传输720P 30帧/秒的图像；H.264 HIGH PROFILE支持在512K带宽下传输720P 30帧/秒的图像。
H.265
是比较新的压缩算法，可以更一步提高压缩比，随着我们现在生活中出现的视频格式越来越大（比如现在基本都是1080P甚至4K的显示器，4K片源将来也会越来越多），就需要像H.265这样的新压缩算法，提高效率、节约带宽或存储空间。H.265支持在384K带宽下传输720P 30帧/秒。

DVR：Digital Video Recorder，数字视频记录器

通常称为数字硬盘录像机，因为采用硬盘作为存储载体已经是最主流的模式。

DVR最主要的特点是：可以单独工作的监/控/设备，可以在本地监/控、回放及报/警处理，当然，现在的DVR也基本具备网络功能，可以实现网络传输

DVS：Digital Video Server，数字视频服务器

简称视频服务器，其实，视频服务器是从视频编码器发展而来，主要用来解决远程监控的问题

数字视频服务器DVS与数字视频记录器DVR的最大区别是，视频服务器DVS必须要在网络上才能有用，无法单独使用，一旦网络失效，视频服务器就失去作用。

NVR：Network Video Recorder, 网络视频记录器

或者叫网络硬盘录像机，其实还有另一个名字：Hybrid DVR，即混合型DVR，

实际上，是在DVR的基础上，增加了对视频服务器网络摄像机的接入，即除了自身具备硬盘录像机的功能外，还可以存储一些视频服务器/网络摄像机的视频数据。

HVR:（High Definition & Hybrid Digital Video Recorder）高清混合数字硬盘录像机

是同时支持模拟BNC与数字网络RJ45接口的安防监控存储设备

IPC即IP-CAMERA

是集成视频服务器和摄像机的功能为一体的数字视频设备；IP-CAMERA网络摄像机一般有内置Web服务的数字摄像机和录音设备，直接与以太网（有线、无线）相连。

用户可通过标准Web浏览器观看和收听网络摄像机传送过来的视频和声音

备注：

IPC（网络摄像机）和NVR（网络视频录像机）能够收发SIP请求，核心原因在于其内部固件中嵌入了SIP协议栈，使其自身就成为一个SIP用户代理（SIP User Agent）。这意味着它们不仅仅是简单的音视频采集或存储设备，更是一个独立的网络通信终端
IPC（网络摄像机）和NVR（网络视频录像机）能传输流媒体数据，是因为其内部集成了完够整的流媒体协议栈。可以理解为它们内置了一套专门的“通信规则”，将采集到的音视频数据打包、通过网络发送
设备固件如何内置sip和流媒体协议栈：预置了实现相应通信功能的专用软件程序包，这些代码会被编译进设备的主程序，成为固件不可或缺的一部分。
- 使用开源协议栈：对于研发能力强的团队，可以直接使用如 osip或 resiprocate这样的开源SIP库，以及 live555等流媒体库。这种方式灵活度高，但需要自行处理集成、适配和稳定性问题。
- 采用商用SDK：为了加快上市速度并确保稳定性和兼容性，许多厂商会选择采购成熟的商用SDK。例如，EasyGBD就是一个专为GB28181设备端开发的开发工具，提供了封装好的接口，大大降低了开发难度。
- 芯片原厂提供解决方案：很多时候，主芯片（SoC）供应商会提供完整的软件解决方案（Reference Design），其中已经集成了基础的多媒体处理和网络通信组件。设备厂商在此基础上进行二次开发，添加业务逻辑和界面

设备区别和监控场景选择

全新部署且希望实现高清网络监控：优先选择 IPC + NVR 的组合。这是当前的主流方案，能充分发挥高清、网络化的优势。
希望对原有的模拟系统进行升级，并保留现有模拟摄像机：可以采用模拟摄像机 + DVS + NVR 的方案。DVS负责将模拟信号转为数字信号，然后由NVR进行存储管理。
小范围、低成本、以本地监控为主的场景：模拟摄像机 + DVR 的方案依然简单实用，成本较低。
需要兼顾新旧设备：HVR 是理想选择，它能在不大幅增加系统成本的前提下，灵活地混合接入模拟和网络摄像机，实现无缝过渡。

SIP（Session initialization Protocol，会话初始协议）

是由IETF（Internet Engineering Task Force，因特网工程任务组）制定的多媒体通信协议。是一个应用层的信令控制协议。
用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。

SIP采用类似HTTP的请求-响应机制，核心方法包括Invite、Ack、Options、Bye、Cancel、Register 和 Message、Info，消息头部携带会话参数。
支持TLS加密和身份认证确保安全性。用户可通过唯一标识符（如SIP URI）实现跨网络位置通信，会话
SIP 信息可以在 TCP 上传输也可以在 UDP 上传输，如果用户没有指定发送方式，则默认采用 udp 发送
SIP协议使用SDP协议进行媒体描述，RTP/RTCP协议传送音视频数据流
SDP描述的会话协商和媒体协商信息应采用SIP的invite方法消息体携带传输，如下图展示，会话建立使用sip的invite方法，指明了消息体类型Content-Type: application/sdp
- 设备安全注册/注销、采用sip的Register实现会话连接 Content-type:application/sdp
  - 客户端向服务器发送 Register命令消息时，消息中的 Expire字段设置为0即是注销
- 实时视音频点播、历史视音频的回放
  - 采用sip的Invite方法实现会话连接，Content-type:application/sdp，s=play 时点播，Playback历史回放
  - 采用 RTP/RTCP协议实现媒体传输
- 音视频下载：
  - 采用sip的Invite方法实现会话连接，Content-type:application/sdp
  - SDP消息体中s字段为“Download”代表文件下载, u字段代表下载通道ID和下载类型, t字段代表下载时间段, 可扩展a字段携带下载倍速参数

参数/头域                  作用与含义                                   示例或说明
Request-Line     指明SIP方法（如INVITE）和请求目标URI。      INVITE sip:bob@example.com SIP/2.0
Via              记录请求经过的路径，响应将按此路径返回。     包含分支参数branch，用于标识事务。
From/To          标识会话的发起方和接收方。                  包含SIP URI和可选标签tag。
Call-ID          全局唯一标识符，用于关联同一会话的所有消息。  由随机字符串和主机名组成。
CSeq             命令序列号，用于区分和排序同一会话中的请求。  格式为数字 SIP方法，如1 INVITE。
Contact          提供后续请求可直接发送的联系地址。           <sip:alice@192.168.1.100:5060>
Content-Type     指明消息体（Body）的类型。                  值为application/sdp时，表示消息体是SDP数据。
Content-Length   指明消息体的长度（字节数）。                 如Content-Length: 1972。

为何选择SIP？对于IPC/NVR厂商而言，采用SIP协议主要有三大优势：

- 标准与互操作性：SIP是IETF定义的开放标准，遵循它易于实现不同厂商设备与平台之间的互联互通，避免私有协议带来的封闭性。中国的GB/T 28181国家标准的信令层正是基于SIP制定的。
- 灵活与可扩展性：SIP是文本式协议，易于调试和扩展。除了基本呼叫控制，还通过扩展方法（如INFO用于历史媒体的回放控制、MESSAGE用于报警事件通知）支持丰富的安防业务需求。
- 与承载分离：SIP的信令通道与RTP的媒体通道分离，架构清晰，便于网络地址转换（NAT）穿透和部署

SIP在安防设备中的核心工作流程

设备注册 (Device Registration)
目的：设备上线后，主动向您流媒体服务中的SIP服务器“报到”，告知服务器“我是谁”和“我在哪里”。
实现方式：设备会向SIP服务器发送 REGISTER 请求。请求中包含了设备的唯一标识（如国标ID为 34020000002000000001）、设备域名以及自身的网络地址（IP和端口）。这就像设备在向服务器做自我介绍并留下联系方式。
安全机制：通常采用类似Web服务的挑战-应答认证。服务器先返回401 Unauthorized并附带一个随机数（nonce），设备将密码和该随机数进行哈希运算后，在第二次REGISTER请求中提交，以此证明身份，防止密码被窃听。

心跳保持 (Keepalive)
目的：维持注册状态，让服务器知道设备始终在线、工作正常。
实现方式：设备会按设定间隔（如每60秒）定期向服务器发送 MESSAGE 请求作为心跳消息。消息体通常是XML格式的状态报告。若服务器连续多次收不到心跳，就会判定设备离线。

会话控制与媒体流传输 (Session Control & Media Streaming)
目的：响应点播、回放等请求，建立音视频传输通道。
实现方式：
会话建立：当您的平台需要观看实时视频时，会向设备发送 INVITE 请求。该请求的消息体（SDP，会话描述协议）中包含了平台希望接收媒体的IP、端口、支持的视频编码（如H.264/H.265）等信息。
媒体协商：设备收到后，若支持该格式，会回复200 OK，并在SDP中确认参数。双方通过SIP信令完成媒体协商。
流传输：协商成功后，设备直接通过RTP/RTCP协议将音视频流推送到SDP中指定的地址。请注意，SIP只负责建立和管理的“呼叫”，真正的音视频数据由RTP传输。
会话终止：点播结束，任一方（平台或设备）会发送 BYE 请求来结束会话，停止流传输

SDP（Session describe Protocol，会话描述协议）

SDP（会话描述协议）是用于设备之间实时通信会话建立过程的会话协商和媒体协商描述, （如音视频通话、流媒体传输等）具体参数的文本型协议。

它本身不传输数据，而是像一份详细的“菜单”或“蓝图”，清晰地列出通信双方需要了解的会话所有信息，以便成功建立连接。
它本身不具备协商能力，主要用来描述传输协商内容的，即不直接决定最终使用哪种编解码格式。真正的协商逻辑是由SIP通过特定的模型（如Offer/Answer模型）来完成的。
会话协商和媒体协商的信息应采用SIP的invite方法消息体携带传输: 如上图，会话建立使用sip的invite方法，指明了消息体类型Content-Type: application/sdp

SDP 协议的核心在于通过简洁的文本，以 key=value 的键值对形式描述会话。一段标准的 SDP 描述通常包含分为会话级（Session Level）和媒体级（Media Level）描述两个层次的通用信息：

会话级参数（Session Level）：对整个会话生效的全局信息。
v=：SDP协议版本号，通常为0。
o=：会话发起者标识，包含用户名、会话ID、版本号、网络类型和地址等信息。
c=：连接信息，指明媒体流发送的基础网络地址。
s=-:会话名称                         #play 实时点播，downnload下载历史音视频，Playback回放
t=：会话时间，0 0表示会话不受时间限制。  #历史录像获取传起始时间戳

媒体级参数（Media Level）：描述特定媒体流（如音频、视频）的详细信息，以m=行开头。
m=：媒体行，这是媒体描述的核心。它指明了媒体类型（如audio/video）、接收端口、传输协议（如RTP/AVP）以及支持的负载类型（Payload Type） 列表。例如：m=audio 7078 RTP/AVP 96 97。
a=rtpmap：将m=行中的负载类型映射到具体的编解码器。例如：a=rtpmap:96 OPUS/48000/2。
a=fmtp：提供特定编解码器的额外格式参数。例如：a=fmtp:96 useinbandfec=1。
a=sendrecv：表示媒体流的方向，常见值有sendrecv（双向）、recvonly（只接收）等。
a=ice-ufrag/ a=ice-pwd：用于ICE（交互式连接建立）过程的身份验证凭证，对建立P2P连接至关重要。

SDP 需要与 SIP、RTP/RTCP、RTSP 等其他协议配合才能工作。以下是其最常见的协作流程：

- 生成要约：呼叫方（A）生成一份 SDP 描述，列出自己支持的媒体类型（音频、视频）、编解码器、可接收的IP地址和端口等。这份描述称为 Offer。
- 发送要约：A 通过 SIP 协议的 INVITE请求（或其他协议对应方式）将 SDP Offer 发送给被呼叫方（B）。
- 生成应答：B 收到 Offer 后，解析其中的SDP Offer。根据自己的能力从中选择双方都支持的媒体参数，生成一份 SDP Answer，从而完成协商。例如，如果 Offer 中支持编解码器1和2，而B只支持1，则 Answer 中确定使用编解码器1。
- 发送应答：B 通过 SIP 的 200 OK响应将 SDP Answer 返回给 A。
- 建立媒体流：主叫方A收到200 OK后，发送ACK确认。双方根据协商一致的 SDP 参数（如确定的编解码器、IP地址、端口）直接建立媒体连接（通常通过RTP/RTCP、RTSP协议传输音视频数据），正式开始通信

MANSCDP(监控报警联网系统控制描述协议)，也叫媒体回放控制协议

用来描述 “前端设备控制、报警信息、设备目录信息” 等控制命令

采用SIP的 Message方法的消息体携带传输, 如下图，设备目录查询，使用sip的message方法，指明了消息体类型Content-Type: Application/MANSCDP+xml 主要命令：请求命令Query、Control、Notify，应答命令Response
- 设备控制Control: 包括命令类型(CmdType)、命令序列号(SN)、设备编码(DeviceID)、子命令、执行结果 (Result) 等.控制命令的类型包括球机/云台控制、远程启动、录像控制、报警布防/撤防、报警复位、强制关键帧、拉框放大、拉框缩小、看守位控制、设备配置等
- 报警通知Notify：包括命令类型(CmdType)、命令序列号 (SN)、设备编码(DeviceID)、报警级别(AlarmPriority)等。可选项:报警时间( AlarmTime)、报警方式(AlarmMethod)、经度(Longitude)、纬度(Latitude)、扩展报警类型(AlarmType)、报警类型参数( AlarmTypeParam)
- 设备目录、设备信息、设备状态、设备配置、设备预置位查询Query: 包括命令类型(CmdType)、命令序列号(SN) 、设备/区域/系统编码/业务分组/虚拟组织(DeviceID)等
- 文件检索：主要用区域、设备、录像时间段、录像地点、录像内容为条件进行查询,用 Message消息发送检索请求和返回查询结果
- 语音广播通知、语音广播应答：Broadcast、 Broadcast
- 心跳保持Notify (CmdType=Keepalive) 制采用 SIP扩展协议Message方法实现，通过周期性的状态信息报送,实现注册服务器与源设备之间的状态检测即心跳机制。使用sip的message方法，指明了消息体类型Content-Type: Application/MANSCDP+xml
- 级联：下级向上级通过message方法，发送Notify命令CmdType=catalog，上报目录信息
（事件、目录）订阅、通知：使用sip的SUBSCRIBE、NOTIFY方法，Content-type:Application/MANSCDP+xml

设备目录查询示例，Application/MANSCDP+xml

MESSAGE sip:34020000001320000007@192.168.15.151:5060 SIP/2.0	 #SIP协议命令类型
Via: SIP/2.0/UDP 192.168.15.118:5061;rport;branch=z9hG4bKPj77458f1b
Max-Forwards: 70
From: <sip:34020000001240000001@192.168.15.118>;tag=026c1956     #SIP请求的发送者	
To: <sip:34020000001110000001@192.168.15.151>			         #SIP请求的接受者
Contact: <sip:34020000001240000001@192.168.15.118:5061>		#SIP请求发送者的实际地址
Call-ID: 172fbd2d-a964-4064-8d36-223fc61336ba			    #和tag共同标志一次完整通信会话
CSeq: 21896 MESSAGE 			                            #在Call-ID相同情况下,标志消息顺序编号(当消息没有响应时,会加一重发)
Allow: INVITE, ACK, BYE, CANCEL, UPDATE
Content-Type: Application/MANSCDP+xml			    #SDP负载消息的类型
Content-Length:   155

（MANSCDP消息体）
<?xml version="1.0"?>  
<Query>  						                    #命令类型(查询命令)
<CmdType>Catalog</CmdType>  				        #命令类型(Catalog 设备目录查询、RecordInfo 查询历史录像)
<SN>248</SN> 					                    #命令序列号
<DeviceID>34020000001110000001</DeviceID>			#查询设备ID号(NVR设备ID号)
</Query>  

MANSRTSP（监控报警联网系统实时流协议）

用来描述 “历史视音频的回放控制命令”，实现设备在端到端之间对视音频流的正常播放、快速、暂停、停止、随机拖动播放等远程控制

历史视音频的回放
- 采用sip的Invite方法实现会话连接， Content-type:application/sdp
- 采用SIP的Info方法的消息体携带传输历史媒体的回放控制命令, Content-type:Application/MANSRTSP, MANSRTSP消息体中传输媒体回放控制命令 Play、Pause、Teardown
- 采用 RTP/RTCP协议实现媒体传输。

MANSRTSP媒体播放请求示例 Content-type:Application/MANSRTSP ，服务器的响应消息中给出RTP-Info头信息

Infosip:媒体流发送者设备编码@目的域名或IP地址端口SIP/2.0
To:<sip:媒体流发送者设备编码@目的域名>;tag=949c43d7
Contact:<sip:媒体流接收者设备编码@源IP地址端口>
Call-ID:wlss-f7c53b46-eea27828118c3b50449185980f4bfdf0@172.20.16.4
Via:SIP/2.0/UDP 源域名或IP地址
From:<sip:媒体流接收者设备编码@源域名>;tag=e3719a0b
Content-Length:消息实体的字节长度
CSeq:6Info
Content-Type:Application/MANSRTSP
Max-Forwards:70

#（MANSRTSP消息体）
PLAYRTSP/1.0
CSeq:2
Range:npt=now   #在 Range头中给出播放时间范围,表示从暂停位置开始
Scale:2.0 #以2倍速恢复播放

开源sip库PJSIP，类比Apache-http-client

PJSIP是实现SIP协议栈的功能强大、高度可移植的开源多媒体通信库，它实现了SIP、SDP、RTP、STUN、TURN及ICE等协议，支持语音、视频通信、即时消息及NAT穿越功能，被广泛用于构建VoIP电话、视频会议、即时通讯等实时通信应用
核心组件包括PJSIP、PJMEDIA、PJNATH、PJLIB-UTIL和PJLIB，可运行于Windows、Linux、macOS、iOS及Android等操作系统。

PJSIP的核心功能主要包括以下几个方面：

SIP消息处理：包括SIP请求和响应消息的发送与接收、请求的路由和转发以及错误消息的生成。
事务状态管理：PJSIP维护SIP事务的内部状态，并且对事务的响应进行时序控制。
编解码：支持多种音频和视频编解码格式，保证通信双方能够以标准格式交换媒体信息。
网络和媒体传输：提供底层的网络功能，包括IPv4/IPv6的网络传输支持以及使用RTP/RTCP协议的媒体传输。
安全性：内置加密和认证机制，支持TLS和SRTP，保障通信的私密性和数据的完整性

常见开源sip库：

Sofia-SIP：这是一个用ANSI C编写的事件驱动型SIP协议栈，广泛用于FreeSWITCH等系统。它支持SIP RFC 3261及部分扩展（如TCP、TLS、IPv6），提供SIP用户代理（UA）、注册和会话管理功能。其异步事件驱动架构确保了高性能，适合对实时性和效率要求较高的通信系统。
reSIProcate：这是一个基于C++的SIP协议栈，由SIPfoundry社区发起，采用面向对象设计，支持B2BUA、TLS、会话定时器等高级功能。它包含repro（SIP代理）和rutil（通用工具库）等组件，支持SUBSCRIBE、PUBLISH、NOTIFY等扩展，适合需要高度可扩展性和定制化的应用。
Kamailio（原SER）：这是一个高性能SIP服务器项目，基于SIP Express Router，支持大规模分布式部署。它可作为SIP代理、注册服务器、重定向服务器或B2BUA使用，支持WebSocket、IPv6、TLS和异步处理，并拥有丰富的模块（如认证、负载均衡、NAT Traversal），适合构建大型SIP网络基础设施。
osip + eXosip：osip是一个用C编写的轻量级SIP协议栈，专注于SIP基础功能（如消息处理和事务管理）；eXosip是osip的扩展库，提供了更高层次的封装，简化了客户端开发。eXosip支持传输层管理、SSL/TLS、线程和自动状态机，适合需要快速实现SIP通信（如呼叫、注册）但不需要复杂多媒体功能的场景

onvif（”Open Network Video Interface Forum 开放式网络视频接口论坛）

ONVIF是国际标准，由安讯士、博世、索尼等多家安防厂商共同发起成立的行业联盟制定。致力于为不同厂商生产的网络视频设备提供统一的通信标准，使得来自不同品牌的摄像头IPC、录像机NVR、视频管理软件等设备能够相互通信和协同工作。

定义了一系列标准化的网络服务接口，包括设备发现、设备管理、媒体配置、图像设置、PTZ（Pan/Tilt/Zoom）控制、事件处理等。
ONVIF基于SOAP（简单对象访问协议, 一种基于XML的协议）和 WSDL（Web Services Description Language）实现通信；
- 信令通道基于Web Services。所有控制指令（如获取设备信息、云台控制、获取流地址）都被封装在SOAP（一种基于XML的协议）信封中，通过HTTP/HTTPS协议在客户端与设备间传输
- 音视频流数据传输则使用成熟的流媒体协议RTSP进行会话控制（如建立、播放、暂停），而实际的音视频数据则通过RTP在UDP或TCP上传输
- 使用WS-Discovery进行设备自动发现。新设备接入网络后，可以主动广播自己的存在，也可以响应其他设备的搜索请求，使得系统能够快速识别和添加新设备。
  - 平台探测：向多播地址 239.255.255.250:3702发送 Probe消息
  - 摄像头响应：收到消息后，回复 ProbeMatch消息，其中包含自己的设备服务和地址（XAddr）
ONVIF更适合多品牌集成的商业项目，而GBT28181专攻国内公共安全领域的大规模级联系统

一个视频管理平台（客户端）需要连接并显示一个ONVIF摄像头的实时画面，典型交互过程如下：

1.设备发现
平台：向多播地址 239.255.255.250:3702发送 Probe消息。
摄像头：收到消息后，回复 ProbeMatch消息，其中包含自己的设备服务和地址（XAddr）。

2.获取设备信息与服务能力
平台：向摄像头回复的地址发送 GetDeviceInformation请求（一个SOAP消息），获取设备型号、厂商、固件版本等。
摄像头：返回包含请求信息的SOAP响应。
平台：可能进一步调用 GetCapabilities来查询设备支持哪些服务（如媒体、PTZ、事件等）及其访问点。

3.获取视频流地址
平台：调用媒体服务的 GetProfiles接口，获取设备预设的媒体配置文件列表（这些文件定义了编码、分辨率、帧率等参数）。
平台：选择所需的配置文件后，使用 GetStreamUri接口，并传入配置文件的令牌（Token），请求该视频流的访问地址。
摄像头：返回一个RTSP格式的URL，例如 rtsp://192.168.1.100/stream1。

4.建立连接并传输视频流
平台：拿到RTSP URL后，脱离ONVIF协议，使用标准的RTSP客户端与该URL建立连接。这个过程通常包括RTSP DESCRIBE, SETUP, PLAY等命令。
摄像头：响应RTSP命令，随后通过RTP协议开始推送音视频数据流

在实际系统中ONVIF、GBT28181可以协同工作，一种常见的模式是：

在设备接入层使用 ONVIF协议来集成不同品牌的前端摄像机（IPC）和网络录像机（NVR），实现灵活的设备管理；( 公安项目中一般使用28181的注册方式里进行设备接入)
在平台互联层，则通过 GB/T 28181协议将本级平台向上级监控中心（如公安指挥中心）进行级联，满足大规模联网和合规要求

GB/T28181|中华人民共和国国家标准

全称为：GB/T28181-2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》，
是由公安部科技信息化局提出，由全国安全防范报警系统标准化技术委员会(SAC/TC100)归口，公安部一所等多家单位共同起草的一部国家标准（以下简称28181）。

GB28181协议在全国平安城市、交通、道路等监控中广泛采用，若想做统一的大监控平台，则支持28181协议接入是必不可少的

GB28181对联网系统的用户和设备的管理，全部通过一个20位的设备ID号来管理
会话通道：GB28181将 SIP定位为联网系统的主要信令基础协议，用于建立会话，传输控制命令；配合使用 SDP/MANSCDP/MANSRTSP 传输 “ 会话和控制命令” 的消息体，以及响应的消息体；
媒体流通道：用于传输音视频数据，经过压缩编码的音视频流，通过流媒体协议RTP/RTCP传输数据、

sip互联结构

sip级联

sip-非sip

sip通信协议

1 范围
2 规范性引用文件
3 术语和定义、缩略语 
4 互联结构
	4.1 SIP监控域互联结构
	4.2 SIP监控域与非SIP监控域互联结构
	4.3 联网系统通信协议结构
5 传输要求
	5.1 网络传输协议要求
	5.2 媒体传输协议要求
	5.3 信息传输延迟时间
	5.4 网络传输带宽
	5.5 网络传输质量
	5.6 视频帧率
6 交换要求
	6.1 统一编码规则
        编码规则 A 由中心编码(8位)、行业编码(2位)、类型编码(3位)和序号(7位) 四个码段共 20 位十进制数字字符构成, 即系统编码 = 中心编码 + 行业编码 + 类型编码 + 序号。
        1）中心编码
          1，2 位-----省
          3，4 位-----市
          5，6 位-----区
          7，8 位-----基层接入单位编码
          举例：江苏 32 南京 02 江宁 81 湖熟街道 01,  那么江苏南京江宁湖熟街道的国标 ID 可以为 32028101 00 200 0 000000
        2）行业编码：实际工作中，你可以自己定义 00 代表什么行业？一直到 99，可以自定义 如：
          00------社会治安路面接入
          01------社会治安社区接入
          02------社会治安内部接入
        3）类型编码
          200----中心服务器
          111----DVR
          118----NVR----不同厂家的编码不同，但不重要，查下 NVR 的本地国标编码便知
          132----摄像机
          注意：工作中一定要记住 20 位国标编码中的 11-13 位，看到就能分辨它代表什么？记住以上 4 种，足够你用。
          119----在线视频图像信息采集设备
          120----在线视频图像信息采集系统
          121----视频卡口
          502----公安视频图像分析设备/系统
          503----公安视频图像信息数据库
          504----公安视频图像信息应用平台
        4）序号第1 位为网络标识编码: 0、1、2、3、4为监控报警专网, 5为公安信息网, 6 为政务网, 7为 Internet网, 8为社会资源接入网, 9 预留最后6位，用来表示数量的
          3202810000132 0 000000 ~ 3202810000132 0 999999 999999+1=1 百万个摄像机编码
          3202810000200 0 000000 ~ 3202810000200 0 999999 999999+1=1 百万个中心服务器编码
	6.2 媒体压缩编解码： 视频编解码采用 H.264或 MPEG-4,应优先采用SVAC;音频编解码推荐采用 G.711、G.723.1、G.729或SVAC。
	6.3 媒体存储封装格式： 视音频等媒体数据的存储封装格式应为 PS格式,格式见ISO/IEC13818-1:2000
	6.4 SDP定义
	6.5 网络传输协议的转换
	6.6 控制协议的转换
	6.7 媒体传输协议的转换
	6.8 媒体数据格式的转换
	6.9 与其他系统的数据交换
	6.10 信令字符集：联网系统与设备的SIP信令字符集宜采用 GB2312编码格式。
7 控制要求
	7.1 注册： 应支持设备或系统进入联网系统时向SIP服务器进行注册登记的工作模式
	7.2 实时视音频点播：应支持按照指定设备、指定通道进行图像的实时点播,支持多用户对同一图像资源的同时点播
	7.3 设备控制：应支持向指定设备发送控制信息,如球机/云台控制、录像控制、报警设备的布防/撤防等,实现对设备的各种动作进行遥控。
	7.4 报警事件通知和分发：应能实时接收报警源发送来的报警信息,根据报警处置预案将报警信息及时分发给相应的用户终端或系统、设备
	7.5 设备信息查询: 应支持分级查询并获取联网系统中注册设备或系统的目录信息、状态信息等
	7.6 状态信息报送: 应支持以主动报送的方式搜集、检测网络内的监控设备、报警设备、相关服务器以及连接的联网系统的运行情况
	7.7 历史视音频文件检索: 应支持对指定设备上指定时间段的历史视音频文件进行检索 
	7.8 历史视音频回放: 应支持对指定设备或系统上指定时间的历史视音频数据进行远程回放,回放过程应支持正常播放、快速播放、慢速播放、画面暂停、随机拖放等媒体回放控制
	7.9 历史视音频文件下载: 应支持对指定设备指定时间段的历史视音频文件进行下载
	7.10 网络校时: IP网络接入设备应支持SIP信令的统一校时,接入设备应在注册时接受来自SIP服务器通过消息头 Date域携带的授时
	7.11 订阅和通知: 宜支持订阅和通知机制,支持事件以及目录订阅和通知
	7.12 语音广播和语音对讲
8 传输、交换、控制【安全性要求】
	8.1 设备身份认证
	  - 对于非标准SIP设备, 宜通过网关进行认证
	  - 在低安全级别应用情况下, 应采用 基于口令的数字摘要认证 方式对设备进行身份认证
	  - 在高安全级别应用情况下, 应采用 基于数字证书的认证 方式对设备进行身份认证
	8.2 数据加密
	8.3 SIP信令认证: 应对SIP信令做数字摘要认证,宜支持 MD5、SHA-1、SHA-256等数字摘要算法
	8.4 数据完整性保护: 宜采用数字摘要、数字时间戳及数字水印等技术防止信息的完整性被破坏,即防止恶意篡改系统数据
	8.5 访问控制: 应实现统一的用户管理和授权,在身份鉴别的基础上,系统宜采用基于属性或基于角色的访问控制模型对用户进行访问控制
9 控制、传输【流程和协议接口】
	9.1 注册和注销: SIP客户端、网关、SIP设备、联网系统等 SIP代理(SIP UA)使用Register进行注册和注销。注册和注销时应进行认证,基于数字摘要的挑战应答式安全技术进行注册
	9.2 实时视音频点播
	  - 实时视音频点播的SIP消息应通过本域或其他域的SIP服务器进行路由、转发, 目标设备的实时视音频流宜通过本域内的媒体服务器进行转发
	  - 实时视音频点播采用SIP协议中的Invite方法实现会话连接, 采用 RTP/RTCP协议实现媒体传输
	  - 实时视音频点播的信令流程分为客户端主动发起和第三方呼叫控制两种方式
	9.3 设备控制: 源设备向目标设备发送设备控制命令,控制命令的类型包括球机/云台控制、远程启动、录像控制、报警布防/撤防、报警复位、强制关键帧、拉框放大、拉框缩小、看守位控制、设备配置等
	9.4 报警事件通知和分发
	9.5 网络设备信息查询
	9.6 状态信息报送
	9.7 设备视音频文件检索
	9.8 历史视音频的回放
	9.9 视音频文件下载
	9.10 校时：SIP校时在注册过程中完成,信令流程同注册信令流程
	9.11 订阅和通知
	9.12 语音广播和语音对讲

GA/T1400|中华人民共和国公共安全行业标准

GA/T1400分成4个部分，是于2017年首次发布关于图片、视频片段、文件等属性对象的传输协议，全称为：

GA/T1400.1－2017《公安视频图像信息应用系统第1部分：通用技术要求》
GA/T1400.2－2017《公安视频图像信息应用系统第2部分：应用平台技术要求》
GA/T1400.3－2017《公安视频图像信息应用系统第3部分：数据库技术要求》 –对象属性字段的具体定义–
GA/T1400.4－2017《公安视频图像信息应用系统第4部分：接口协议要求》 –对接api接口的具体定义 –

GAT1400的价值：
解决“数据孤岛”问题。在安防项目中，摄像头品牌繁多，产生的图片和视频格式各异。
GAT1400通过一套标准化的接口，规定了数据如何描述、如何上传、如何查询。无论哪个厂商的设备或平台，只要支持GAT1400，就能顺利接入公安的视图库系统，实现跨地区、跨层级的数据共享和调度

GA/T 1400核心特点：

其核心：是构建一个统一的“视图库”，让各类视频图像信息能够在不同系统与平台间高效、规范地流转，最终服务于公安实战
处理数据类型：文件、图片、视频片段及相关的结构化信息（如人员、人脸、车辆、车牌、物品、场景等）
接口协议部分详细定义了设备与平台、平台与平台间的数据交互：规定了数据的传输协议，采用HTTP/REST方式通过URI唯一标识接口，支持注册、注销、保活、校时等公共功能，并涵盖多种数据类型的采集接口。
多级平台级联：支持从区县到部级的多级平台级联，形成树形管理体系
多协议接入‌：兼容GB28181、Ehome等多种协议，满足复杂网络环境下的多协议接入需求。

GA/T 1400 组成架构：

公安视频图像信息应用平台（应用平台）
- 组成部分：
  - 接入功能模块：为应用平台提供与视频监控联网平台或共享平台、离线视频图像信息采集设备、公安视频图像分析系统、公安视频图像信息数据库、统一的认证与鉴权系统、PGIS/GIS 及其他公安信息系统等的接口服务。
  - 应用功能模块：提供综合应用基础服务，包括视频监控基本应用、采集标注、查询与检索、时空分析、布控与告警、订阅与通知、视频图像分析、视频案事件管理、统计分析等功能
  - 管理功能模块：对接入功能和应用功能模块进行管理，包括用户管理、设备管理、运维管理，以及日志管理等功能。
  - 应用门户：提供面向各警种的应用门户。
- 接入链接关系
  - 1.通过GB/T 28181协议与 “视频监控联网平台或共享平台” 的互联
  - 2.基于硬盘物理数据接口、USB接口、本地网络接口等多种通用接口，接入 “离线视频图像信息采集设备”
  - 3.通过 “分析接口” 接入 “公安视频图像分析设备/系统”
  - 4.通过 “数据服务接口” 接入 “视图库”
  - 5.与 PGIS/GIS、警综平台、资源平台等其他信息系统交互
  - 6.支持接入统一的鉴权认证系统
公安视频图像信息数据库（视图库）
- 组成部分：
  - 接口功能模块包括：采集接口、数据服务接口和级联接口。
  - 应用功能模块包括：注册、保活、对象 CRUD 操作、布控与告警、订阅与通知和联网服务等功能。
  - 管理功能模块包括：存储管理、用户管理、设备管理、运维管理、日志管理和时钟同步等功能。
- 接入链接关系
  - 1.通过 “采集接口” 为 “在线视频图像信息采集设备” 和在线视频图像信息采集系统（以下简称采集系统）提供接入认证与鉴权服务，接收采集设备及采集系统发送的数据
  - 2.通过 “采集接口和数据服务接口” 为 “公安视频图像分析系统/设备” 提供接入认证与鉴权服务，接收分析系统/设备发送的分析结果数据
  - 3.通过 “数据服务接口” 为 “公安视频图像信息应用平台” 或其他公安信息应用系统（如各警种的应用平台）提供接入认证与鉴权、视频图像信息对象的 CRUD 操作、布控与告警、订阅与通知等服务；
    - 采用分布式部署方式，部署在视频专网内的”视图库” 通过 “级联接口和边界接入平台” 向部署在公安信息网内的 “ 视图库” 共享数据；
    - 宜根据需要通过定制接口接收其他公安信息应用系统的数据.
  - 4.通过 “级联接口” 为上下级视图库提供接入认证与鉴权、视频图像信息对象的 CRUD 操作、布控与告警、订阅与通知、联网等服务。
  - 5.支持通过统一的认证与鉴权系统进行用户权限管理。
公安视频图像分析设备/系统
- 分析设备/系统通过 “采集接口” 对来自 “视频监控联网平台或共享平台” 的视频连续分析结果直接存入 “视图库”
- 分析设备/系统通过 “数据服务接口” 访问 “视图库”
- 分析设备/系统通过 “分析接口” 为 “应用平台” 提供分析服务
- 与 “视频监控联网平台或共享平台” 的互联
在线视频图像信息采集设备/系统
- 采集设备(IPC/NVR)：输出的视频图像信息应存入 “视图库”，输出的视频流应按照GB/T28181中规定的协议接入 “ 视频监控联网平台或共享平台” (sip服务器+流媒体服务器)
- 采集系统：从 “视频监控联网平台或共享平台” 获取视频流，经解析后提取视频、图像信息，存入 “视图库”

公安视频图像信息应用系统

应用平台

视图库

接口交互

GAT1400的工作流程示例:

- 设备/系统注册：下级系统（如区县公安局的视图库）需要向上级平台（如市局平台）进行注册、保活（发送心跳包）和注销。这是建立通信关系的第一步，确保上级平台知晓下级系统的存在和状态。
- 数据上传与订阅：前端采集设备或系统通过标准的API接口，将结构化后的信息（例如，一张抓拍的人脸图片及其时间、地点等属性）上传到视图库。同时，平台也支持订阅和布控功能。比如，市局平台可以向下级视图库订阅某个重点关注区域的所有车辆通行数据，一旦有新车牌触发规则，数据会立刻上报。
- 数据查询与服务：授权用户可以通过统一的接口，对海量视图数据进行条件检索、以图搜图等深度应用，快速锁定目标。这些标准化接口也向上层业务应用（如警务综合平台、治安防控系统）开放，为指挥决策、案件侦查提供数据服务支持

补充说明
实现GA/T 1400标准的视图库平台，需要集成SIP信令服务和媒体信令服务（或者私有协议），以支持设备的注册、发现、会话控制及音视频流传输。
但是设备控制并非1400的重点，1400的核心在于基于http restful接口的标准数据上报（采集）、级联、分析、数据服务（查询）等功能。

## 视图库平台的双重角色
对上层应用（上级视图库、如警务系统、管理平台）：
角色：服务提供者。
行为：平台提供符合GA/T 1400标准的RESTful API接口。这些接口使用HTTP/HTTPS协议，数据格式通常为XML或JSON。上层应用只需要调用这些简单、统一的Web API，例如请求获取设备列表、下发云台控制指令或订阅报警信息，无需关心底层设备的复杂差异。

对下层设备（如IPC、NVR）：
角色：客户端或控制端。
行为：平台主动转换并下发指令。当平台接收到上层的HTTP请求后，其内部的协议适配模块会根据目标设备的类型和支持的协议，将通用指令“翻译”成设备能听懂的语言。这主要包括：
转换为SIP信令：对于支持GB/T 28181 国家标准的设备，平台会将控制命令（如PTZ）封装成SIP协议（例如MESSAGE或INVITE请求）发送给设备。
转换为私有协议：对于不支持国标的老旧设备或使用厂商特定协议的设备（如海康威视的Ehome、大华的主动注册），平台需要通过集成设备的SDK 或实现其私有协议来进行通信。

## 实现的关键能力
一个成熟的GA/T 1400视图库平台，其技术核心不仅仅是实现标准API，更在于强大的协议兼容和转换能力：
多协议接入网关：平台必须内置多种协议的适配器，能够同时管理通过GB/T 28181、RTSP、ONVIF以及各类私有协议接入的设备。
设备管理能力：维护一个设备目录，记录每个设备的唯一标识（如设备ID）、IP地址、支持的协议类型、能力集（是否支持云台等）等信息。
状态管理与会话保持：管理设备注册、保活状态，并维持必要的控制会话，确保指令的可靠送达。

第一部分–通用技术要求；

范围 
规范性引用文件
术语和定义.缩略语
1 术语和定义
2 缩略语
设计原则
1 互通性
2 扩展性
3 可靠性
4 规范性
5 安全性
6 易维护性
7 易操作性
系统结构（规范）
1 系统组成
2 级联结构
视频图像信息对象
1 自动采集的视频图像信息对象：在采集过程中没有人工干预、由触发事件触发采集的视频图像信息对象
2 人工采集的视频图像信息对象：在采集过程中需要人工甄别后所采集的视频图像信息对象
统一标识编码（规范）
1 设备与用户统一标识编码规则：符合GB/T 28181编码规范要求, 即20位系统编码 = 区域中心编码8 + 行业编码2 + 类型编码3 + 序号7
2 视频图像信息对象统一标识编码规则
	  "视频案/事件对象" 统一标识编码规则30位 = 公安机关机构编码12位 + 时间编码14位 + 序号4位
	  "视频图像信息基本对象" 统一标识编码规则41位 = 设备编码20位 + 子类型编码2位 + 时间编码14位 + 序号5位（子类型：01-视频片段、02-图像、03-文件 99-其他）
	  "视频图像信息语义属性对象" 统一标识编码规则48位 = 视频图像信息基本对象统一标识41位  + 子类型编码2位 + 序号5位（子类型：01-人员、02-机动车、03-非机动车、04-物品、05-场景、06-人脸、07-视频图像标签、99-其他）
3 布控与订阅统一标识编码规则33位 = 公安机关机构编码12位 + 子类型编码2位 + 时间编码14位 + 序号5位（子类型：01-布/撤控、02-告警、03-订阅、04-通知 99-其他）
系统功能（要求）
1 视频监控基本功能：视频浏览、录像下载/回放、云镜控制等视频监控基本功能
2 采集标注：支持自动采集标注和人工采集标注两种方式
3 存储：具有视频图像信息对象的存储功能
4 查询与检索：支持基于视频图像信息对象特征属性及其组合的查询与检索功能
5 时空分析：具有基于PGIS/GIS的视频图像资源操作、视频图像信息对象特征属性时空分析等功能
6 布控/告警：具备对指定视频图像信息对象进行在线实时布控/告警的功能
7 订阅与通知：具有对视图库的视频图像信息对象及其目录、采集设备/系统目录与状态、案事件信息等订阅、撤销订阅、通知等功能
8 视频图像分析：具有增强视频图像内容理解、提高视频图像画面质量等的分析处理功能
9 视频案事件管理：具有视频案事件的创建、更新及删除等管理功能
10 时钟同步
11 统计分析：有基于视频图像信息对象的统计报表和分析功能
12 用户权限管理：系统各部分应具有各自相对独立的用户权限管理功能，宜支持通过统一的鉴权认证系统进行用户权限管理
13 设备管理：提供分析设备/系统、采集设备/系统的管理功能
14 日志管理：系统各部分应具有相对独立的运行日志和操作日志管理功能
15 数据备份：系统应具有数据备份功能，可按照多种策略需要配置备份 
系统性能（要求）
1 视图库
2 应用平台
3 分析设备/系统
4  时钟同步：系统内的服务器设备、采集设备等设备时钟与北京时间的偏差应不超过1s
接口协议结构（要求）： 系统中相关的各接口协议结构应采用REST架构进行定义，REST服务通过HTTP的方法实现，消息体采用JSON进行封装
安全性
1 物理安全
2 信息安全
3 通信和网络安全
电磁兼容性
环境适应性
电源适应性
可靠性
运行与维护

第二部分–应用平台技术要求；

范围
规范性引用文件
3术语和定义、缩略语
1 术语和定义
2 缩略语
应用平台结构
1 应用平台功能组成图
2 应用平台外部连接关系
功能
1 接入，同上接入外部连接关系
2 应用：同GA/T1400.1－2017《公安视频图像信息应用系统 第1部分：通用技术要求》的 第8节 系统功能（要求）8.1-8.11点，要求描述更具体一点
3 管理：同GA/T1400.1－2017《公安视频图像信息应用系统 第1部分：通用技术要求》的 第8节 系统功能（要求）8.12-8.15点，要求描述更具体一点
6性能 

第三部分–数据库技术要求；

1 范围
2 规范性引用文件
3 术语、定义和缩略语
	3.1 术语和定义：VIID： 视频图像信息数据库(Video and Image Information Database)
	3.2 缩略语
4 公安视频图像信息数据库组成
	4.1 公安视频图像信息数据库功能结构
	4.2 公安视频图像信息数据库外部连接关系
5 视图库存储对象----(对象实体定义规范)
	5.1 视图库存储对象类型（6种对象，即5.3--5.8）
	5.2 对象描述方法：通过“对象名称”、“对象标签”、“对象集合标签”、“对象特征属性”、“XMLSchema 描述” 等属性进行描述；
	5.3 采集设备与采集系统相关对象
		- 采集设备对象: APE APEList
		- 采集设备状态对象: APEStatus APEStatusList
		- 采集系统对象: APS APSList
		- 采集系统状态对象: APSStatus APSStatusList
		- 视频卡口对象: Tollgate TollgateList
		- 车道对象: Lane LaneList
	5.4 视频图像信息对象
		- 视频片段对象 VideoSliceInfo VideoSliceInfoList
		- 图像对象 ImageInfo ImageInfoList
		- 文件对象 FileInfo FileInfoList
		- 人员对象 Person PersonList
		- 人脸对象 Face FaceList
		- 机动车对象 MotorVehicle MotorVehicleList
		- 非机动车对象 NonMotorVehicle NonMotorVehicleList
		- 物品对象 Thing ThingList
		- 场景对象 Scene SceneList
		- 视频案事件对象 CaseInfo CaseInfoList
		- 视频图像标签对象 VideoLabel VideoLabelList 
	5.5 视频图像分析规则对象
		- 视频图像分析规则对象 AnalysisRule AnalysisRuleList
	5.6 布控与告警对象
		- 布控对象 Disposition DispositionList
		- 告警对象 DispositionNotification DispositionNotificationList
	5.7 订阅与通知对象
		- 订阅对象 Subscribe SubscribeList
		- 通知对象 SubscribeNotification SubscribeNotificationList
	5.8 联网服务对象
		- 联网服务器对象 VIIDServer VIIDServerList
6 功能
	6.1 接口: 消息头中的 content-type 头字段应设为 application/VIID+JSON。
	6.2 应用----（功能接口分类）:
		6.2.1 注册保活
		6.2.2 对象 CRUD 操作
			6.2.2.1 对象的读取操作
			6.2.2.2 采集设备与采集系统对象的 CUD 操作
			6.2.2.3 视频卡口和车道对象的 CUD 操作
			6.2.2.4 视频图像信息对象的 CUD 操作
			6.2.2.5 视频案事件对象的 CUD 操作
			6.2.2.6 视频图像分析规则对象的 CUD 操作
		6.2.3 布控与告警
		6.2.4 订阅与通知
		6.2.5 联网服务
		6.2.6 对象列表及集合操作
	6.3 管理
		6.3.1 存储管理：支持设置存储时间及周期
		6.3.2 用户管理
			6.3.2.1 用户注册及身份认证
			6.3.2.2 身份认证模式
			6.3.2.3 用户访问控制
			6.3.2.4 用户授权策略：管理用户和系统用户
		6.3.3 设备管理
		6.3.4 运维管理
		6.3.5 日志管理：记录系统运行日志和操作日志
		6.3.6 时钟同步
7 性能
	7.1 对象存储时间
	7.2 存储对象格式
	7.3 并发性能规格
	7.4 检索
8 其他
附录A(规范性附录)视图库对象特征属性
附录B(规范性附录)视图库元数据定义
附录C(规范性附录)视图库对象和对象集合XMLSchema描述
附录D(规范性附录)基于 XML的消息体格式
附录E(规范性附录)XML转JSON规范
附录F(规范性附录)查询指令规范

第四部分–接口协议要求

1 范围
2 规范性引用文件
3 术语、定义和缩略语 
	3.1 术语和定义
	3.2 缩略语
4 接口分类与协议结构 
	4.1 接口分类：（根据交互实体关系分为：级联接口、采集接口、数据服务接口、分析接口）
	4.2 协议结构 
	  - 所有接口交互信息定义为 REST 架构下的资源，使用 URI 唯一标识，接口对应资源使用树状层级结构组织。
	  - 接口交互连接方式应支持 HTTP 长连接和短连接
	  - HTTP请求头域中应扩展增加<User-Identify>，携带请求者的系统用户ID等身份属性，用于标识请求者
5 接口功能----（接口清单规范，主要是定义 接口功能描述）
	5.1 公共功能
	  注册：POST，注册失败时，应延迟 300s 内的随机时间后重新注册
	  保活：POST，注册成功后，在 90s 内未交互信息则进行心跳保活。
	  注销：POST
	  校时:GET 
	5.2 采集接口 *n个
	5.3 数据服务接口 *n个
	5.4 级联接口 *n个 
	5.5 分析接口 *n个 
6 接口资源描述 （Http请求头 = URI + Head参数 + 请求方法）---（功能接口详细列表）
	6.1 视图库资源描述 : 视图库资源定义视图库与采集设备或采集系统、上下级视图库、应用平台、分析系统等之间交互的信息（主要涉及 级联接口、采集接口、数据服务接口）
	  视图库相关资源URI：/VIID/*
	  资源 XML Schema 描述: 
	6.2 分析系统资源描述 ： 分析系统资源定义分析系统与应用平台之间交互的信息（主要涉及 分析接口）
	  分析系统资源 URI：/VIAS/*
	  资源 XML Schema 描述: 
7 接口消息 （Http请求体 + 返回体）
	7.1 接口消息描述：接口消息Content-Type头部域应设为application/*+JSON。
	7.2 视图库接口消息：视图库接口消息定义视图库与采集设备或采集系统、上下级视图库、应用平台、分析系统等之间的接口消息
	7.3 分析系统接口消息 ：分析系统接口消息定义分析系统与应用平台之间的接口消息
8 消息交互流程 （接口交互时序图）
	8.1 创建资源消息交互流程 
	8.2 读取资源消息交互流程 
	8.3 更新资源消息交互流程 
	8.4 删除资源消息交互流程
9 消息交互安全性 
附录A(规范性附录)REST架构协议模型 
附录B(资料性附录)关键消息交互流程示例 

GB/T 28181 和 GA/T 1400联系

GB/T 28181 和 GA/T 1400 是中国公共安全视频监控领域两个至关重要且功能互补的国家/行业标准。
GB/T 28181 主要解决视频流的“联网”和“传输”问题，而 GA/T 1400 则侧重于联网后视频图像信息的“管理”和“应用”。

一个典型的工作流程如下：

- 1.前端设备接入与联网：各类不同品牌、型号的前端摄像机、录像机（NVR）等，首先通过 GB/T 28181 协议接入到一个区域或单位的视频监控平台中，实现统一的实时视频调看和控制。
- 2.数据汇聚与处理：该平台或专门的接入网关，不仅通过GB/T 28181协议获取视频流，还可能通过其他方式获取图片和视频片段。然后，利用AI算法对这些资源进行智能分析，提取出人、车、物等结构化信息。
- 3.数据上报与应用：平台或网关将视频、图片文件及其对应的结构化描述信息，按照 GA/T 1400 标准定义的接口协议，上传到更上一级的公安视频图像信息应用系统（即视图库）。此后，各类公安实战应用系统（如研判系统、布控系统）则通过GA/T 1400标准接口从视图库中查询、订阅和调用这些数据，实现深度应用。

四、网络摄像头RTSP视频流WEB端实时播放实现方案

1、FFmpeg + nginx 将转 hls 通过 video.js 在支持h5浏览器播放

参见：Nginx+FFmpeg实现rtsp流转hls流，在WEB通过H5 video实现视频播放

不足：hls延迟较rtmp、http-flv大

2、FFmpeg + nginx-rtmp-module + h5 video，rtsp转rtmp播放

https://blog.csdn.net/gui66497/article/details/78590190 https://blog.csdn.net/LLittleF/article/details/81111713

注：通过video.js播放rtmp流。需要将代码放到服务器，本地windows电脑无法播放

不足：需要浏览器开启flash

3、FFmpeg + nginx-http-flv-module + flv.js，rtsp转rtmp，直接播放flv格式

基于nginx-rtmp-module，通过配置将rtmp转为flv，最后通过flv.js播放。 https://github.com/winshining/nginx-http-flv-module/blob/master/README.CN.md https://segmentfault.com/a/1190000016043297 https://blog.csdn.net/qq_22633333/article/details/96288603#comments

这种方式是最理想的，目前找到的方案。当然单指不想花钱买收费方案的。

4、WebRTC

https://github.com/lulop-k/kurento-rtsp2webrtc https://www.jianshu.com/p/1ddfa72de165

5、streamedian

https://github.com/Streamedian/html5_rtsp_player https://streamedian.com/ https://streamedian.com/#demo https://blog.csdn.net/u011489205/article/details/79327275

6、h5stream

https://www.linkingvision.com/ https://github.com/liweilup/h5stream https://blog.csdn.net/Dnison/article/details/81663137

7、liveqing

https://www.liveqing.com