330 lines
7.8 KiB
Markdown
330 lines
7.8 KiB
Markdown
# 视频源结构化设计
|
||
|
||
## 背景
|
||
|
||
当前后台已经将配置体系逐步拆分为两层：
|
||
|
||
- `场景配置`：定义一个最终要运行的业务场景
|
||
- `基础配置`：承载可被场景配置复用的公共配置
|
||
|
||
第三方服务已经明确要作为一类可复用的基础配置存在。视频输入端也具有相同特征：
|
||
|
||
- 由客户现场提供
|
||
- 生命周期通常长于单个场景配置
|
||
- 多个场景可能复用同一路输入流
|
||
- 修改地址或元信息时，不应该逐个修改场景配置
|
||
|
||
因此，视频输入不应继续散落在场景配置实例的 `rtsp_url` 等字段中，而应独立为一类基础配置。
|
||
|
||
## 核心定义
|
||
|
||
本设计中的**一个视频源 = 一路输入流**。
|
||
|
||
它不是一台物理摄像机设备，也不是一台 NVR，而是一条能够被场景配置直接引用的输入流。
|
||
|
||
例如：
|
||
|
||
- 一台摄像机只有一路 RTSP，则对应一个视频源
|
||
- 一个 NVR 下有 8 路通道，则应建 8 个视频源
|
||
|
||
这个定义与当前识别链路最匹配，也最利于场景配置引用和后续维护。
|
||
|
||
## 目标
|
||
|
||
本次设计要解决以下问题：
|
||
|
||
1. 为视频源建立统一、结构化的数据模型
|
||
2. 在 `基础配置` 中增加独立的 `视频源` 管理页面
|
||
3. 让 `场景配置` 通过引用视频源，而不是直接填写 `rtsp_url`
|
||
4. 在不破坏现有配置链路的前提下，为后续逐步替换场景内联输入字段打基础
|
||
|
||
## 非目标
|
||
|
||
本次不包含以下内容：
|
||
|
||
- 不做完整的摄像机资产台账
|
||
- 不引入厂商、型号、采购信息、维护记录等固定资产字段
|
||
- 不做视频源在线探测或取流连通性检测
|
||
- 不做自动读取码流元信息
|
||
- 不处理多通道设备实体模型
|
||
|
||
## 设计原则
|
||
|
||
1. 一个视频源只表示一路可引用输入流
|
||
2. 识别相关字段优先，现场安装字段作为可选补充
|
||
3. 表单默认保持简洁，非必要字段不阻塞创建
|
||
4. 页面交互和第三方服务保持一致，降低认知成本
|
||
|
||
## 字段设计
|
||
|
||
推荐将视频源字段分为三组。
|
||
|
||
### 1. 基本信息
|
||
|
||
- `name`：视频源名称，唯一标识
|
||
- `source_type`：视频源类型
|
||
- `area`：区域
|
||
- `description`：描述
|
||
|
||
说明：
|
||
|
||
- `name` 用于被场景配置引用
|
||
- `area` 用于表达现场语义，例如“东门入口”“1号产线”“仓库西侧”
|
||
- `description` 用于补充说明
|
||
|
||
### 2. 输入参数
|
||
|
||
- `url`：输入地址
|
||
- `resolution`：标准分辨率等级，例如 `720p`、`1080p`、`1440p`、`4k`
|
||
- `frame_size`：像素尺寸，例如 `1280x720`、`1920x1080`
|
||
- `fps`：帧率
|
||
- `video_format`：视频格式，例如 `h264`、`h265`、`mjpeg`
|
||
|
||
说明：
|
||
|
||
- `url` 必填
|
||
- `resolution`、`frame_size`、`fps`、`video_format` 可选
|
||
|
||
### 3. 安装信息
|
||
|
||
- `focal_length`：焦距
|
||
- `mount_height`：安装高度
|
||
- `mount_angle`：安装角度
|
||
|
||
说明：
|
||
|
||
- 三个字段均为可选
|
||
- 它们主要用于表达现场安装条件，不应阻塞视频源创建
|
||
|
||
## 类型设计
|
||
|
||
第一版推荐支持以下视频源类型：
|
||
|
||
- `rtsp`
|
||
- `rtmp`
|
||
- `file`
|
||
- `usb_camera`
|
||
|
||
当前主路径仍然是 `rtsp`，但枚举应预先保留扩展空间。
|
||
|
||
页面文案可使用：
|
||
|
||
- RTSP
|
||
- RTMP
|
||
- 文件流
|
||
- USB 摄像头
|
||
|
||
## 数据结构
|
||
|
||
视频源建议使用与第三方服务类似的“顶层基础字段 + config 承载详细参数”的方式。
|
||
|
||
推荐结构：
|
||
|
||
```json
|
||
{
|
||
"name": "gate_cam_01",
|
||
"source_type": "rtsp",
|
||
"area": "东门入口",
|
||
"description": "东门主入口摄像头",
|
||
"config": {
|
||
"url": "rtsp://10.0.0.1/live",
|
||
"resolution": "1080p",
|
||
"frame_size": "1920x1080",
|
||
"fps": 25,
|
||
"video_format": "h264",
|
||
"focal_length": "4mm",
|
||
"mount_height": "3.2m",
|
||
"mount_angle": "15deg"
|
||
}
|
||
}
|
||
```
|
||
|
||
说明：
|
||
|
||
- 顶层保持对象识别字段
|
||
- `config` 用于承载输入参数和安装信息
|
||
- 第一版不再继续向下拆分成多层嵌套，避免结构过重
|
||
|
||
## 与现有配置字段的关系
|
||
|
||
当前场景配置实例中已存在：
|
||
|
||
- `display_name`
|
||
- `site_name`
|
||
- `rtsp_url`
|
||
- `channel_no`
|
||
|
||
在新结构下：
|
||
|
||
- `rtsp_url` 应逐步由视频源 `config.url` 替代
|
||
- `display_name` 仍属于场景实例显示语义，不属于视频源本身
|
||
- `site_name` 仍偏场景/站点上下文，不建议塞进视频源
|
||
- `channel_no` 如果表达的是输入流标识，可保留在场景实例或后续再决定是否并入视频源
|
||
|
||
## 场景配置中的引用方式
|
||
|
||
场景配置不应长期继续直接持有 `rtsp_url`，而应改为引用视频源。
|
||
|
||
由于当前场景配置是多实例结构，推荐按实例增加引用字段：
|
||
|
||
- `video_source_ref`
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"instances": [
|
||
{
|
||
"name": "cam1",
|
||
"template": "std_workshop_face_recognition_shoe_alarm",
|
||
"video_source_ref": "gate_cam_01",
|
||
"params": {
|
||
"display_name": "东门入口"
|
||
}
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
这比把视频源引用放在整个场景顶层更合理，因为一个场景通常会包含多路输入。
|
||
|
||
## 兼容策略
|
||
|
||
第一阶段建议采用兼容式落地：
|
||
|
||
1. 新建视频源资产
|
||
2. 场景配置实例开始支持 `video_source_ref`
|
||
3. 若实例中存在 `video_source_ref`，则预览和下发时优先使用视频源中的 `url`
|
||
4. 若不存在 `video_source_ref`，仍兼容现有 `rtsp_url`
|
||
|
||
这样可以逐步迁移，而不需要一次性改完所有历史配置。
|
||
|
||
## UI 设计
|
||
|
||
入口：
|
||
|
||
- `基础配置 -> 视频源`
|
||
|
||
页面交互与第三方服务保持一致：
|
||
|
||
- 顶部按钮：`新增视频源`、`编辑`、`删除`
|
||
- 列表区：视频源列表
|
||
- 详情区：默认只读
|
||
- 点击 `编辑` 后进入编辑态
|
||
- 点击 `新增视频源` 后清空详情并聚焦名称输入框
|
||
|
||
## 列表页字段
|
||
|
||
推荐列表列：
|
||
|
||
- 视频源名称
|
||
- 类型
|
||
- 区域
|
||
- URL 摘要
|
||
- 分辨率
|
||
- 帧率
|
||
|
||
说明：
|
||
|
||
- 列表中的“分辨率”优先显示 `resolution` 这类标准等级
|
||
- `frame_size` 作为详情中的技术补充字段，不默认放在列表里
|
||
- 焦距、安装高度、安装角度不放在列表里
|
||
|
||
## 详情页字段分组
|
||
|
||
### 基本信息
|
||
|
||
- 视频源名称
|
||
- 类型
|
||
- 区域
|
||
- 描述
|
||
|
||
### 输入参数
|
||
|
||
- URL
|
||
- 分辨率
|
||
- 像素尺寸
|
||
- 帧率
|
||
- 视频格式
|
||
|
||
### 安装信息
|
||
|
||
- 焦距
|
||
- 安装高度
|
||
- 安装角度
|
||
|
||
## 校验规则
|
||
|
||
### 必填
|
||
|
||
- `name`
|
||
- `source_type`
|
||
- `config.url`
|
||
|
||
### 可选
|
||
|
||
- `area`
|
||
- `description`
|
||
- `config.resolution`
|
||
- `config.frame_size`
|
||
- `config.fps`
|
||
- `config.video_format`
|
||
- `config.focal_length`
|
||
- `config.mount_height`
|
||
- `config.mount_angle`
|
||
|
||
### 基本格式建议
|
||
|
||
- `name` 必须唯一
|
||
- `fps` 如填写，应可解析为数值
|
||
- `resolution` 使用标准分辨率等级表达，例如 `720p`、`1080p`
|
||
- `frame_size` 第一版可先作为字符串保存，不强制拆成宽高整数
|
||
|
||
## 删除约束
|
||
|
||
如果某个视频源已被场景配置实例引用，则不允许直接删除。
|
||
|
||
删除前应检查：
|
||
|
||
- 是否存在场景实例的 `video_source_ref` 指向该视频源
|
||
|
||
如果存在引用，应提示：
|
||
|
||
- 当前视频源已被某些场景配置使用，不能删除
|
||
|
||
## 存储建议
|
||
|
||
建议沿用现有 SQLite 基础配置仓储模式，新增一类 `video_sources` 存储对象。
|
||
|
||
每条记录至少包含：
|
||
|
||
- `name`
|
||
- `source_type`
|
||
- `area`
|
||
- `description`
|
||
- `body_json`
|
||
- `created_at`
|
||
- `updated_at`
|
||
|
||
## 第一阶段实施范围
|
||
|
||
第一阶段只实现以下内容：
|
||
|
||
1. 视频源的数据结构与存储
|
||
2. `基础配置 -> 视频源` 列表和详情维护页
|
||
3. 场景配置实例支持 `video_source_ref`
|
||
4. 预览/下发时优先用视频源 URL 展开
|
||
5. 删除前引用检查
|
||
|
||
## 结论
|
||
|
||
视频源应被定义为**一路可被场景配置引用的输入流**。
|
||
|
||
采用“基础识别字段 + 输入参数 + 可选安装信息”的结构最适合当前系统阶段：
|
||
|
||
- 比单纯只存 URL 更完整
|
||
- 比完整摄像机资产台账更轻
|
||
- 既能服务识别配置，又能保留现场语义
|
||
|
||
第一版推荐按 `video_source_ref` 的方式逐步替换场景配置中的内联 `rtsp_url`，从而让视频源真正成为可复用、可维护的基础配置对象。
|