UVP / 视频接入平台
完全开源，让国标视频接入更清晰、更自主。
UVP-GB28181 是一款支持 GB/T 28181-2016 与 GB/T 28181-2022 双版本的开源视频接入平台，提供 Linux amd64、Linux arm64 与 Windows amd64 共 3 款独立部署包，也可以用 Docker Compose 起一套。平台负责设备注册、目录查询、点播信令与媒体转发，可接入多台 ZLMediaKit 节点做调度，并把 SIP 会话、设备状态、媒体流和节点健康分层显示在同一套界面里。代码以 MIT 许可证开放，可自主部署、二次开发与闭源分发。
OVERVIEW
UVP 是一款开源的国标视频接入工具组合。组合支持 GB/T 28181-2016 与 GB/T 28181-2022 两个版本。产品线有 3 款：统一视频接入平台 UVP-GB28181、移动端模拟设备 UVP-28181-SIM、桌面端模拟器 UVP-28181-SIM-DESKTOP。平台负责把设备接进来并转发媒体。模拟器负责在没有真机的情况下造出设备并施压。三款产品都以 MIT 许可证开源或免费提供。可以部署在自有服务器上。不限制接入设备数量。也不依赖任何厂商云服务。
OUR PRODUCTS
从统一管理视频设备，到用移动端和桌面端模拟真实设备，按需要选择工具。
统一视频接入平台-GB28181
完全开源，让国标视频接入更清晰、更自主。
UVP-GB28181 是一款服务端的视频接入平台。设备通过 GB/T 28181 标准流程注册进来，目录、点播、回放、云台与报警在同一套界面里管理，媒体转发交给已接入的 ZLMediaKit 节点。提供 Linux 与 Windows 独立部署包共 3 款，也可以容器化部署。
国标28181移动端模拟器
用手机模拟国标设备，随时联调平台。
UVP-28181-SIM 是一款跑在 Android 手机上的虚拟摄像机。填上平台地址、SIP 编号与密码，手机就能以标准设备身份注册到平台。注册、实时点播、录像回放、云台控制都能做。信令日志按请求结构化展示。支持 GB/T 28181-2016 与 GB/T 28181-2022 两个版本，可在应用内切换。现场没有真机时，用它先跑通链路，再上真机验收。
国标28181桌面端模拟器
一台电脑，先跑通一台设备，再压满一万台。
UVP-28181-SIM-DESKTOP 是一款批量设备模拟与压测工具，跑在 Windows 与 macOS 上。单机最多拉起 10000 台虚拟设备，可配爬坡速率与真推流占比，实时显示成功率与 TPS。
三款产品对应接入链路上的 3 种角色。平台把设备接进来并转发媒体。移动端模拟器在现场快速造出一台设备。桌面端模拟器批量造设备做压测，单机上限 10000 台。选型只看两件事：手上有没有真机，要不要验证规模上限。三款可以单独使用。也可以组合成一条完整验证链路，从注册、点播一直跑到播放。
| 产品 | 形态 | 协议版本 | 运行平台 | 获取方式 |
|---|---|---|---|---|
| UVP-GB28181 | 服务端接入平台 | 2016 / 2022 | Linux amd64、Linux arm64、Windows amd64 | MIT 开源 |
| UVP-28181-SIM | 移动端模拟器 | 2016 / 2022 可切换 | Android | MIT 开源 |
| UVP-28181-SIM-DESKTOP | 桌面端模拟器 | 2016 / 2022 可切换 | Windows、macOS（仅 arm64） | 免费下载 |
ONE TRACEABLE PIPELINE
一次国标接入要经过 3 层。信令层完成注册、目录、点播与云台控制。媒体层把 PS 流从设备送到播放端。播放层决定用户最终看到什么。任何一层断了，设备列表都可能显示在线，但画面出不来。UVP 把三层拆开呈现在同一套界面里。排查时先确认断在哪一层，再往下钻。
具体到操作路径，4 个页面各管一层。SIP 会话页能看到每一次注册、心跳与点播请求的原始报文和应答码。设备与通道页给出在线状态、通道数量与最近一次心跳时间。媒体流页显示收流是否到达、转发给了几个客户端。节点健康页汇总多台 ZLMediaKit 的负载与可用性。四页对照，基本能把「设备在线但没画面」这一类问题定到某一层。不必从设备端一路试到平台。根据我们统计的排查记录，这类问题有八成能在前三页定层。
GB/T 28181 · TRACEABLE MEDIA PIPELINE
CAPACITY
国标平台的容量不能只看设备数量。要同时算入口带宽、转发带宽和录像存储三项。以常见的一种配置为例，按 1080P、H.264、单路 4 Mbps 估算：50 路设备接入，入口带宽按 1.1 倍余量约需 220 Mbps。同时 20 人观看，转发侧按 1.2 倍余量约需 96 Mbps。这些通道全部录像并保留 30 天，按 92% 的可用容量折算约需 67 TB，落盘速度约 25 MB/s。把码率换成 720P、2 Mbps，各项大致减半。根据我们统计的实测口径，这几个余量系数已经包含了常见的突发波动。
上面四个数字来自本站资源测算器使用的同一套公式，可以直接拿去写方案；换成自己的通道数与保留天数，在资源测算页重算一遍。
MEASURED
有。2026 年 10 月，我们在 1,000、10,000、50,000 三档规模下测过平台目录接口。环境是 Apple M5、32 GiB 内存、临时 SQLite 库。设备树按 1 个部门、3 层行政区构造，每台设备 1 个通道，在线与离线各半。1,000 台首次全量目录 42.2 ms，之后无变化刷新 P50 37.9 ms、P95 41.7 ms。10,000 台首次 666.3 ms，无变化 P50 505.0 ms、P95 521.8 ms。50,000 台首次 2439.2 ms，无变化 P50 2589.9 ms。浏览器侧，1,000 台全展开产生 12,094 个 DOM 节点、首屏 308.9 ms。10,000 台产生 120,094 个节点、首屏 2180.2 ms，最长主线程任务约 1.64 秒。
根据我们统计的实测口径，这些数字测的是设备目录的读取与渲染，不是视频并发路数，测试环境也不是生产 MySQL，只能当量级参考；完整报告与复现命令在项目仓库的 docs/device-channel-tree/performance 下。
VS. MEDIA SERVER ONLY
区别在信令层，不在媒体层。ZLMediaKit 的核心是接收、转封装和分发媒体流。它本身不负责设备注册、目录查询、点播信令和在线状态维护。这些能力属于 GB/T 28181 的信令部分，需要另外实现一层 SIP 服务。还要处理摘要认证、心跳续期、注册有效期和目录同步。任何一处没对齐，都会表现为「设备在线但播不出来」。UVP 把这层做好之后再接 ZLMediaKit 做媒体节点。装完即可接设备，并支持多节点接入与调度。
反过来也要说清楚：如果团队已经有成熟的 SIP 信令实现，直接组合 ZLMediaKit 会更轻，不必多引入一套平台。UVP 真正省掉的是从零写信令层、以及排障时没有分层界面的那部分工作量。
LIMITS
先说清楚 4 条限制。首先是协议范围：只走 GB/T 28181 标准流程，厂商私有 SDK 协议不在支持范围，只能用私有协议的老设备需要另做适配。其次是分析能力：平台侧不带视频智能分析，不做人形、车牌、行为识别，需要时接第三方。第三是桌面端包体：macOS 只有 arm64 包，覆盖 Apple 芯片，没有 Intel 版本；两个桌面安装包都未做代码签名与公证，首次运行要手动放行一次。最后是模拟器边界：品牌兼容、码流封装差异、GB 35114 加密这些只有真机能验，模拟器解决的是平台逻辑通不通。根据我们统计的常见问题，这 4 条被问到的次数最多。
BY TOPIC
首页讲的是全貌。具体问题在专题页里有更完整的答案。下面按 3 类最常见的判断分开。第一类是没有真机，想先把注册、心跳与点播链路跑通，看设备模拟器专题。第二类是要评估一台服务器能扛多少台设备，或者要写一份压测方案，看压测方法专题。第三类是要确认 2016 版与 2022 版在编码、时间戳与安全要求上的差异，再决定接哪个版本，看协议对照专题。三个专题各自独立成篇。每篇只回答一类问题。不必先读完产品介绍。根据我们统计的站内访问路径，这三类问题占了大半。
REFERENCES
协议实现以 1 份国家标准和 3 份 RFC 为准。SIP 信令与注册流程遵循 RFC 3261。摘要认证见 RFC 7616，它取代了早期的 RFC 2617。媒体传输使用 RFC 3550 定义的 RTP。2022 版与 2016 版的差异以 GB/T 28181-2022 原文为准。国标全文可在国家标准全文公开系统查询，无需登录，检索标准号即可。RFC 原文见IETF 数据中心，可在线检索全文。对照实现时如果标准条文与厂商行为不一致，以官方标准为准。把差异记进接入清单，下次换设备就不用重新踩一遍。
FAQ
能直接用，不需要单独授权。3 款产品里，平台 UVP-GB28181 与移动端模拟器 UVP-28181-SIM 都采用 MIT 许可证。商用、二次开发、私有化交付、闭源分发都在许可范围内。没有接入设备数、并发用户数或部署套数的限制。也不需要向作者报备或分成。桌面端模拟器 UVP-28181-SIM-DESKTOP 直接提供安装包，同样免费。MIT 是宽松型许可证，唯一要求是保留版权声明与许可声明。根据 MIT 许可证原文，把 UVP 嵌进对外销售的产品时，建议在交付文档里保留 LICENSE 文件，例如在安装包根目录放一份。这是 1 个文件的事，不涉及商务谈判。
区别在信令层，不在媒体层。ZLMediaKit 的核心是接收、转封装和分发媒体流。它本身不负责设备注册、目录查询、点播信令和在线状态维护。这些能力属于 GB/T 28181 的信令部分，需要另外实现一层 SIP 服务。还要处理摘要认证、心跳续期、注册有效期和目录同步。任何一处没对齐，都会表现为「设备在线但播不出来」。UVP 把这层做好之后再接 ZLMediaKit 做媒体节点。装完即可接设备，并支持多节点接入与调度。若团队已有成熟的 SIP 信令实现，直接用 ZLMediaKit 更轻。若要从零搭信令层，或者需要一个能看清每一步状态的排查界面，UVP 省掉的正是这部分工作量。
能，而且不必等真机。手机端模拟器可在 Android 手机上造出一台设备。桌面端模拟器最多可拉起 10000 台虚拟设备。注册、心跳、目录查询、实时点播、录像回放与云台控制都能跑完。通常的顺序是 3 步：先用模拟器验证平台逻辑，再接 1 台真机确认品牌兼容，最后做规模压测。要留意的是模拟器验不了厂商私有扩展、码流封装差异和 GB 35114 加密，这些只能上真机。根据我们统计的联调记录，这个顺序能省掉大半现场等待。
没有固定答案，取决于码率、是否同时取流、是否录像，以及服务器自身的磁盘与网卡。按 1080P、H.264、单路 4 Mbps 估算：50 路接入，入口带宽按 1.1 倍余量约需 220 Mbps；20 人同时观看，转发侧按 1.2 倍余量约需 96 Mbps；全部录像保留 30 天，按 92% 可用容量折算约需 67 TB，落盘速度约 25 MB/s。换成 720P、2 Mbps，各项大致减半。这些数字来自本站资源测算器使用的同一套公式，可以直接拿去写方案；实际配置建议按自己的通道数与保留天数重算一遍，再留 20% 余量。
能，同一个平台可以同时接入两个版本。每台设备按自己上报的版本走各自的注册与点播流程。方向要注意：2016 设备接 2022 平台通常没问题。2022 设备接 2016 平台，建议在设备侧开兼容模式，关掉扩展事件，媒体固定为 H.264。否则容易出现订阅中断或解析异常，现象很难定位。混接时优先看两件事：设备上报的 SIP 版本号是否与平台配置一致，目录订阅是否按各自版本返回。以官方标准原文为准，冲突时按标准实现。存量项目几乎都会遇到混接，建议在接入清单里逐台标注版本。
先查部署手册，Linux 与 Windows 各有一份。手册包含安装包内目录说明、启动步骤、端口要求与常见报错。多数启动失败是端口被占用，或者配置文件里的地址没改。手册里有一条容易漏的检查：安装包内的设备接入地址是否指向打包机的内网 IP。如果是，改成当前服务器的实际地址再启动。仍然解决不了，到源码仓库提 issue，把平台版本、操作系统、启动日志和报错栈一起贴上。也可以加页脚微信，日志和截图直接发过来。根据我们统计的支持记录，带日志的问题通常一轮就能定位。
GET STARTED
总的来说，三款工具覆盖了从设备接入、协议联调到规模压测的链路。按手上有没有真机、要不要验规模来选，再看下载页的当前版本。
