企业官网建设流程全解析

0. 先说结论

高速上的摄像头不是一批装的，所以"把所有流拉过来"这件事，比听起来难得多。

如果只能记住一句话：先做汇聚层，再上 AI 检测。顺序反了，算法吃的就是脏数据。

下面按这条顺序拆：现实约束 → 两条路径怎么选 → 汇聚层怎么分层 → 落地时最容易出问题的地方。

1. 高速场景和园区监控，根本不是一回事

很多人拿园区监控的经验直接套高速，第一步就踩坑。差别在这几处：

结论：高速场景的第一约束不是"能不能识别"，而是"能不能拿到稳定、完整、时间准确的流"。这也是为什么接入层必须单独设计。

2. 两条主流路径：级联 vs 直取

一句话选型建议：存量混装路段优先走 28181；单一网络域内的新建段可以 RTSP 直取。多数实际项目是两者并存。

3. 汇聚层建议这样分层

┌──────────────┐ │ 应用层 │ 调阅 / 拼接 / AI 事件检测 / 告警 ├──────────────┤ │ 汇聚层 │ 统一目录、统一转码、统一时钟、统一鉴权 ├──────────────┤ │ 接入层 │ 28181 / RTSP / 私有 SDK 协议适配 └──────────────┘ ↓ 前端摄像头（多品牌、多年代、多网域）

关键设计点：

• 接入层只做协议适配，不做业务。它的唯一职责是把不管什么来源的流，变成统一的内部格式。
• 汇聚层必须统一三件事：点位命名与桩号映射、时间戳来源、流转封装格式。这三样不统一，后面做 AI 检测和事后取证会一路踩坑。
• 接入层与检测层解耦。GPU 资源扩缩、算法版本升级，都不应该动接入层。

4. GB/T 28181 落地时，必须提前对齐的参数

注意：以下不是"照抄配置"，而是联调前必须逐项确认并且双方签字对齐的清单。绝大多数接入失败，都是这里某一项没对齐。

【网络与信令】 □ 传输协议：UDP 还是 TCP（跨 NAT、丢包严重时必须改 TCP） □ SIP 服务器 IP / 端口 / 信令端口与媒体端口是否放行 □ SIP 域、SIP 服务器 ID、设备 ID 编码是否符合 20 位编码规则 □ 是否有多级级联：上下级平台的域、ID、级联层级 【注册与心跳】 □ 注册鉴权方式（含算法）与密码 □ 注册有效期与重注册策略 □ 心跳周期与超时判定 【目录】 □ 目录订阅方式、订阅周期、是否支持增量 □ 目录里的点位编码与物理桩号是否一一对应 □ 点位的在线/离线状态如何判定 【媒体流】 □ 主码流/子码流选择与码率上限 □ 封装格式（PS over RTP / 裸流） □ 是否支持 TCP 被动/主动模式切换 【时间】 □ 前端设备是否接入 NTP □ 平台侧校时策略

最后那一组时间，是最容易被忽略又最致命的。设备时钟不同步，复盘时录像是错位的，取证直接用不了。

5. RTSP 直取的几个常见坑

如果走直取，这几处值得提前预判：

• 鉴权方式不统一：各家对 Digest / Basic 的实现细节有差异，有些还有私有鉴权，写死了就换不了设备。
• 传输协议选择：UDP 起不来就换 TCP（RTSP interleaved），不要死磕。跨网场景下 TCP 几乎是必选项。
• 子码流才是检测用流：检测任务不要拉主码流，带宽和算力都扛不住。通常是主码流录像取证、子码流 AI 检测。
• 断流重连：TCP 连接假死很难发现，必须做应用层心跳 + 自动重连，否则"在线"是假的。

6. 排查清单（这节可以直接存下来当手册）

7. 最后：顺序不能反

这两年接触的项目里，效果差的几乎都是同一个原因——前端还没汇聚干净，就急着上算法。

接入层解决"拿得到、看得全、时间准"，汇聚层解决"统一口径"，然后才轮到事件检测解决"找得快"。三步的顺序反了，后面每一步都在给前一步还债。

关于算力估算口径和多厂家格式对比，我整理了一份《高速视频监控·AI事件检测选型清单》，包括接入方式对比表、GPU 资源估算口径、延迟指标怎么定三个部分。需要的评论或私信【云监方案】，我发你。