selfrelease
a329d4906b
- 方案文档: AVCC 体系建设、IPTV TCS 需求(0-req)/PRD(1-prd)/任务(2-task)/二三四期任务 - tcs-iptv: Go 后端(哈希SDK/MA码生成/可信数据空间mock/业务编排/HTTP API+HMAC鉴权) - web-console: React+AntD 监管大屏(角色工作台/全流程演示/监管片库) - 一剧一码+集级哈希, 集级下架/恢复, 全栈测试通过
324 lines
18 KiB
Markdown
324 lines
18 KiB
Markdown
# TCS-IPTV 内容可信锁定系统 — 需求规格说明书
|
||
|
||
> 版本：V1.0
|
||
> 编制日期：2026年6月
|
||
> 基于文档：《MA+哈希码 IPTV内容可信锁定系统（TCS-IPTV）完整方案》
|
||
> 文档编号：0-req-IPTV
|
||
|
||
---
|
||
|
||
## 引言
|
||
|
||
本需求文档定义 TCS-IPTV（Trusted Content System for IPTV）内容可信锁定系统的功能性与非功能性需求。系统通过"MA码（监管身份）+ 哈希码（技术指纹）"双锚定机制，在 CP（内容供应商）、IPTV 集成播控平台、运营商（分发网络）三方现有系统之上建立一层"可信身份映射层"，实现 IPTV 内容"审过即锁定，锁定即通行，通行可追溯"。
|
||
|
||
本系统的核心约束是：**不替代三方现有系统**，仅在关键节点（送审、入库、分发、播放）以最小侵入方式嵌入校验能力，并通过映射层统一对接。
|
||
|
||
---
|
||
|
||
## 术语表
|
||
|
||
| 术语 | 全称 | 说明 |
|
||
|------|------|------|
|
||
| TCS-IPTV | Trusted Content System for IPTV | IPTV 内容可信锁定系统 |
|
||
| CP | Content Provider | 内容供应商 |
|
||
| 播控平台 | — | IPTV 集成播控平台 |
|
||
| 运营商 | — | IPTV 分发网络运营方（如中国电信、中国移动） |
|
||
| MA码 | — | 监管身份主键，由广电总局/省局签发（如网络剧片发行许可证号/备案号） |
|
||
| CTID | Content Twin ID | 内容孪生标识，由 MA码+哈希+版本+Merkle根 构成的唯一标识 |
|
||
| 文件哈希 | File Hash | SHA-256 算法，比特级敏感，精确锁定某版本文件 |
|
||
| 感知哈希 | Perceptual Hash | aHash/dHash/pHash，容忍转码压缩，跨格式识别同一内容 |
|
||
| Merkle Tree | — | 分段聚合哈希树，用于多集/长内容的分段定位 |
|
||
| 可信数据空间 | — | 基于联盟链/分布式账本的可信身份映射层 |
|
||
| EPG | Electronic Program Guide | 电子节目指南 |
|
||
| 转码版哈希 | — | 内容经授权转码中心转码后重新计算的版本哈希 |
|
||
| 重审 | Reaudit | 内容版本变更后触发的重新审核流程 |
|
||
|
||
---
|
||
|
||
## 角色定义
|
||
|
||
| 角色 | 描述 | 核心职责 |
|
||
|------|------|----------|
|
||
| 监管方 | 广电总局 / 省级广电局 | 签发 MA码、注册哈希、验真查询、映射管理、应急下架 |
|
||
| CP | 内容供应商 | 生产内容、计算哈希、送审申报、注册本方映射 |
|
||
| 播控平台 | IPTV 集成播控方 | 送审验真、合规审核、转码授权、EPG编排、注册本方映射、执行下架指令 |
|
||
| 运营商 | IPTV 分发网络方 | CDN注入校验、EPG发布、终端播放、数据上报、注册本方映射、执行下架指令 |
|
||
| 系统运维方 | TCS-IPTV 运营方 | 维护可信数据空间、智能合约、API网关、监控告警 |
|
||
|
||
---
|
||
|
||
## 需求列表
|
||
|
||
### 需求 1：母版哈希生成（CP端）
|
||
|
||
**User Story:** 作为 CP，我希望在内容制作完成后能够在本地对母版文件计算多维哈希值，以便在不上传原始文件的前提下为内容生成可验证的技术指纹。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN CP 在母版文件（ProRes/DPX 等格式）上发起哈希计算，THE 哈希计算SDK SHALL 计算该文件的全文件 SHA-256 哈希值。
|
||
2. WHEN 内容为多集/长内容，THE 哈希计算SDK SHALL 按场景或集数分段计算分段哈希，并生成 Merkle Tree 及其根哈希。
|
||
3. WHEN CP 发起哈希计算，THE 哈希计算SDK SHALL 计算该内容的感知哈希（aHash/dHash/pHash 之一或组合）。
|
||
4. THE 哈希计算SDK SHALL 在本地存证哈希值，且 SHALL NOT 上传原始内容文件。
|
||
5. WHEN 哈希计算完成，THE 哈希计算SDK SHALL 返回包含文件哈希、Merkle根、分段哈希列表、感知哈希的哈希值包。
|
||
6. IF 母版文件读取失败或格式不受支持，THEN THE 哈希计算SDK SHALL 返回错误信息并标识失败原因。
|
||
|
||
---
|
||
|
||
### 需求 2：送审申报与哈希上链（CP端）
|
||
|
||
**User Story:** 作为 CP，我希望登录备案系统提交节目信息与哈希值包，以便启动监管审核流程并将哈希存证。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN CP 提交送审申报，THE 系统 SHALL 接收节目信息（标题、集数、时长、分辨率）、片花、海报、剧本及哈希值包。
|
||
2. WHEN 哈希值包提交成功，THE 系统 SHALL 将哈希存证至可信数据空间并返回唯一送审流水号。
|
||
3. WHEN CP 提交的内容哈希在可信数据空间中已存在，THE 系统 SHALL 拒绝重复申报，并将该申报关联至已存在哈希对应的原 MA码。
|
||
4. THE 系统 SHALL 仅接收哈希值包，且 SHALL NOT 要求 CP 上传原始内容文件。
|
||
5. IF 哈希值包格式不完整（缺少文件哈希或 Merkle根），THEN THE 系统 SHALL 拒绝申报并提示缺失字段。
|
||
|
||
---
|
||
|
||
### 需求 3：MA码签发与强绑定（监管端）
|
||
|
||
**User Story:** 作为监管方，我希望在审核通过后签发 MA码并将其与送审哈希包强绑定，以便建立内容的合法监管身份。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 监管方对送审内容审核通过，THE MA码签发引擎 SHALL 签发 MA码（网络剧片发行许可证号或备案号）。
|
||
2. WHEN MA码签发，THE 系统 SHALL 将 MA码与送审哈希包以 1:1 关系写入可信数据空间，且该绑定 SHALL NOT 可被解绑。
|
||
3. THE 系统 SHALL 仅允许监管节点调用 MA码签发功能（issueMA）；IF 非监管节点调用，THEN THE 系统 SHALL 拒绝并返回权限错误。
|
||
4. WHEN MA码签发完成，THE 系统 SHALL 向 CP 发放"MA码+哈希证书"。
|
||
5. WHILE 内容未取得 MA码及哈希证书，THE 系统 SHALL NOT 允许该内容进入播控平台审核流程。
|
||
6. WHEN MA码绑定写入，THE 系统 SHALL 记录签发方、签发日期、MA类型、内容标题、集数等内容主表信息。
|
||
|
||
---
|
||
|
||
### 需求 4：送审文件验真（播控端）
|
||
|
||
**User Story:** 作为播控平台，我希望对 CP 送审的文件计算哈希并与可信数据空间比对，以便确认其为正版过审内容、拦截版本替换。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN CP 向播控平台送审（提交 MA码、送审文件、授权链文件），THE 验真模块 SHALL 计算送审文件哈希。
|
||
2. WHEN 送审文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 确认为正版过审内容并允许进入内容审核流程。
|
||
3. IF 送审文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 直接退回该送审，并标记为"疑似版本替换"。
|
||
4. WHEN 验真执行，THE 系统 SHALL 通过哈希验真接口查询可信数据空间，返回 valid、bound_hash、submitted_hash、match、version 等字段。
|
||
|
||
---
|
||
|
||
### 需求 5：内容审核与转码哈希绑定（播控端）
|
||
|
||
**User Story:** 作为播控平台，我希望对内容进行合规审核并在转码后为各版本重新生成并绑定哈希，以便多版本分发时保持可信锁定。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 送审文件验真通过，THE 播控平台 SHALL 对内容执行合规审核（政治、色情、暴力等维度）。
|
||
2. WHEN 内容审核通过且需要转码，THE 系统 SHALL 由授权转码中心执行转码，并在转码后重新计算各版本（如 H.264/H.265/4K/HD/SD）文件哈希。
|
||
3. WHEN 转码版哈希生成，THE 系统 SHALL 将转码版哈希与 MA码绑定并写入可信数据空间，且 SHALL 与原母版哈希建立父子关系。
|
||
4. THE 系统 SHALL 允许同一 MA码绑定多个转码版哈希记录，各转码版 SHALL 共享同一 MA码但拥有独立哈希记录。
|
||
|
||
---
|
||
|
||
### 需求 6：EPG编排与编码映射（播控端）
|
||
|
||
**User Story:** 作为播控平台，我希望在保留自有审核流水号的同时建立其与 MA码、哈希的映射关系，以便对接监管而不改造现有系统。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 内容纳入 EPG，THE 播控平台 SHALL 保留其自有审核流水号。
|
||
2. WHEN 内容入库，THE 系统 SHALL 在可信数据空间建立"播控流水号 ↔ MA码 ↔ 文件哈希 ↔ 转码版哈希"的映射关系。
|
||
3. WHEN 播控平台向运营商分发内容，THE 系统 SHALL 要求分发数据携带 MA码及哈希证书；IF 未携带，THEN THE 系统 SHALL 拒绝分发。
|
||
4. THE 播控平台 SHALL 仅能管理本方（broadcast）的映射记录。
|
||
|
||
---
|
||
|
||
### 需求 7：CDN注入校验（运营商端）
|
||
|
||
**User Story:** 作为运营商，我希望在内容注入 CDN 前校验其哈希，以便拒绝被篡改或非授权的内容。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 运营商接收播控平台分发的内容并准备注入 CDN，THE 注入校验模块 SHALL 计算注入文件哈希。
|
||
2. WHEN 注入文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 允许注入 CDN 并生成分发编码。
|
||
3. IF 注入文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 拒绝注入，触发告警并退回播控平台，同时暂停该内容分发。
|
||
4. WHEN 注入成功，THE 系统 SHALL 在可信数据空间注册运营商（operator）映射记录（分发编码、CDN端点）。
|
||
|
||
---
|
||
|
||
### 需求 8：终端播放哈希抽检（运营商端）
|
||
|
||
**User Story:** 作为运营商，我希望播放器在终端可选地对下载片段进行哈希抽检，以便防止 CDN 劫持或传输篡改。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHERE 终端哈希抽检功能开启，WHEN 播放器 SDK（或机顶盒固件）下载内容片段，THE 系统 SHALL 计算该片段哈希并与可信数据空间链上哈希比对。
|
||
2. IF 终端抽检哈希与链上哈希不匹配，THEN THE 系统 SHALL 断流并切换至备用源，同时上报异常日志。
|
||
3. THE 终端哈希抽检功能 SHALL 支持按网络负载策略性开启或关闭。
|
||
4. WHERE 内容为多集，THE 系统 SHALL 支持按集进行增量哈希校验以降低终端计算负载。
|
||
|
||
---
|
||
|
||
### 需求 9：统一维度数据上报与聚合
|
||
|
||
**User Story:** 作为监管方，我希望三方播放与业务数据以 MA码为统一维度聚合，以便获得口径一致的可信数据。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 运营商上报播出数据，THE 系统 SHALL 以 MA码为统一维度组织数据。
|
||
2. THE 可信数据空间 SHALL 按 MA码聚合 CP 播放量、播控审核量、运营商分发量，并保证各方数据口径一致。
|
||
3. WHEN 数据聚合完成，THE 系统 SHALL 提供按 MA码查询的统一数据视图。
|
||
|
||
---
|
||
|
||
### 需求 10：全生命周期监管查询（监管端）
|
||
|
||
**User Story:** 作为监管方，我希望通过监管大屏按 MA码查询内容全链路状态，以便实现精准溯源。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 监管方按 MA码查询，THE 监管大屏 SHALL 返回内容当前所在播控平台、当前所在运营商 CDN、当前哈希版本是否最新。
|
||
2. WHEN 监管方查询内容历史，THE 系统 SHALL 返回该 MA码的历史版本变更记录。
|
||
3. THE 监管大屏 SHALL 支持监管方按 MA码穿透查询三方系统的对应编码。
|
||
|
||
---
|
||
|
||
### 需求 11：违规应急下架（监管端）
|
||
|
||
**User Story:** 作为监管方，我希望下发单一 MA码下架指令即可触发全网下架，以便实现秒级应急响应而无需逐层人工翻译。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 监管方下发"下架 MA码 第XXX号"指令，THE 系统 SHALL 解析该 MA码并查询其绑定的所有三方编码及 CDN端点。
|
||
2. WHEN 下架指令解析完成，THE 系统 SHALL 自动将指令翻译为播控平台下架（审核流水号）与运营商下架（分发编码、CDN资源）的执行动作。
|
||
3. THE 系统 SHALL 在接收下架指令后秒级同步至全网三方系统，且 SHALL NOT 要求人工逐层翻译。
|
||
4. THE 系统 SHALL 仅允许监管方下发应急下架指令；播控平台与运营商 SHALL 仅执行指令而无下架发起权限。
|
||
|
||
---
|
||
|
||
### 需求 12：版本变更与重审触发
|
||
|
||
**User Story:** 作为系统，我希望在内容发生帧级变动时自动断开绑定并触发重审，以便保证审播一致。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN 内容发生任意帧级变动导致哈希变化，THE 系统 SHALL 判定原 MA码与哈希的绑定断裂。
|
||
2. WHEN 绑定断裂，THE 系统 SHALL 在版本变更表中记录变更原因、原哈希、新哈希，并将 reaudit_required 置为 true。
|
||
3. WHEN 单集内容被替换，THE 系统 SHALL 通过 Merkle Tree 重新计算该集哈希并定位被篡改的具体集数，且 SHALL NOT 要求全量重审。
|
||
4. WHILE 重审未通过，THE 系统 SHALL NOT 允许变更后的内容进入分发流程。
|
||
|
||
---
|
||
|
||
### 需求 13：跨省复用快速准入
|
||
|
||
**User Story:** 作为 CP，我希望在一省过审后凭 MA码+哈希证书在其他省份快速准入，以便降低跨省复用的边际成本。
|
||
|
||
#### 验收标准
|
||
|
||
1. WHEN CP 持 A省签发的 MA码+哈希证书向 B省播控平台送审，THE 系统 SHALL 仅要求提交 MA码与哈希证书，且 SHALL NOT 要求重新提交内容文件。
|
||
2. WHEN B省播控平台发起准入查询，THE 系统 SHALL 验证 MA码真实有效、哈希与原过审版一致、且内容不在黑名单中。
|
||
3. WHEN 三重校验通过，THE 系统 SHALL 允许 B省播控平台快速准入，并将内容审核简化为合规性抽检。
|
||
4. WHEN B省准入完成，THE 系统 SHALL 生成 B省审核流水号并注册对应映射关系。
|
||
|
||
---
|
||
|
||
### 需求 14：角色权限控制
|
||
|
||
**User Story:** 作为系统，我希望按角色矩阵严格控制各项操作权限，以便保证监管主键的权威性与不可越权。
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 系统 SHALL 仅允许监管方（广电总局/省局）执行签发 MA码、注册哈希、验真查询、映射管理、应急下架全部操作。
|
||
2. THE 系统 SHALL 允许播控平台执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 MA码、注册哈希、发起下架。
|
||
3. THE 系统 SHALL 允许运营商执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 MA码、注册哈希、发起下架。
|
||
4. THE 系统 SHALL 允许 CP 在送审时注册哈希、执行自查验真、管理本方映射；且 SHALL NOT 允许其签发 MA码或发起下架。
|
||
5. WHEN 任意角色尝试越权操作，THE 系统 SHALL 拒绝该操作并返回权限错误。
|
||
|
||
---
|
||
|
||
### 需求 15：异常处理
|
||
|
||
**User Story:** 作为系统，我希望对各类哈希校验异常采取明确的处理规则，以便保证流程的可控与可追溯。
|
||
|
||
#### 验收标准
|
||
|
||
1. IF 送审阶段哈希不匹配，THEN THE 系统 SHALL 退回 CP，要求说明版本差异，必要时要求重新送审。
|
||
2. IF CDN注入阶段哈希不匹配，THEN THE 系统 SHALL 拒绝注入、告警播控平台并暂停该内容分发。
|
||
3. IF 终端抽检阶段哈希不匹配，THEN THE 系统 SHALL 断流、切换备用源并上报异常日志。
|
||
4. WHEN 内容发生剪辑/修改，THE 系统 SHALL 要求重新计算哈希、提交变更申请并触发重新审核。
|
||
5. WHEN CP 以同一哈希换壳重发，THE 系统 SHALL 识别哈希已存在并拒绝重复申报，同时关联原 MA码。
|
||
|
||
---
|
||
|
||
### 需求 16：可信数据空间存证与智能合约
|
||
|
||
**User Story:** 作为系统，我希望通过联盟链与智能合约管理 MA码、哈希与映射的存证，以便保证数据不可篡改与可信。
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 可信数据空间 SHALL 维护内容主表、哈希绑定表、三方编码映射表、版本变更表四类核心数据结构。
|
||
2. THE 智能合约 SHALL 提供 issueMA（签发）、registerMapping（注册映射）、verifyHash（哈希校验）核心方法。
|
||
3. WHEN registerMapping 被调用，IF 对应 MA码尚未签发，THEN THE 系统 SHALL 拒绝注册映射。
|
||
4. THE 系统 SHALL 通过 Merkle Tree 存储多集内容的分段哈希，并支持按集定位篡改。
|
||
5. THE 可信数据空间 SHALL 保证已写入的 MA码与哈希绑定记录不可篡改。
|
||
|
||
---
|
||
|
||
### 需求 17：接口规范
|
||
|
||
**User Story:** 作为三方系统集成方，我希望通过标准化 API 与可信数据空间交互，以便低成本对接。
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 系统 SHALL 提供哈希上链接口（POST /api/v1/content/register），供 CP 提交标题、集数、各集文件哈希、Merkle根、感知哈希、时长、分辨率、CP媒资ID，并返回送审流水号与状态。
|
||
2. THE 系统 SHALL 提供哈希验真接口（GET /api/v1/content/verify），供播控/运营商按 MA码与文件哈希查询并返回 valid、bound_hash、submitted_hash、match、version、转码版列表。
|
||
3. THE 系统 SHALL 提供映射查询接口（GET /api/v1/content/mappings），供应急下架按 MA码查询三方编码映射与 CDN端点。
|
||
4. THE 系统 SHALL 对接口调用进行身份鉴权（如 Bearer Token）。
|
||
|
||
---
|
||
|
||
## 非功能性需求
|
||
|
||
### 需求 18：性能与时效
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 系统 SHALL 将违规内容下架响应时间从现状的 2-24 小时缩短至分钟级。
|
||
2. THE 系统 SHALL 将跨省复用审核周期从现状的 15-30 天缩短至 3-5 天。
|
||
3. THE 系统 SHALL 将三方数据对账差异从现状的 15-30% 降低至 5% 以内。
|
||
4. THE 系统 SHALL 实现内容版本替换的 100% 自动识别。
|
||
|
||
### 需求 19：兼容性与最小侵入
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 系统 SHALL NOT 要求三方放弃其自有编码体系。
|
||
2. THE 系统 SHALL 仅在送审、入库、分发、播放等关键节点嵌入校验，并通过映射层对接三方现有系统。
|
||
3. THE 系统 SHALL 完全符合广电总局网络剧片发行许可及备案制度。
|
||
4. THE 系统 SHALL 支持网络剧、微短剧、网络电影、网络动画等多形态内容，并 SHALL 可扩展至 OTT、手机 APP 等大小屏形态。
|
||
|
||
### 需求 20：安全与可信
|
||
|
||
#### 验收标准
|
||
|
||
1. THE 系统 SHALL 保证 MA码与哈希的绑定记录一经写入不可篡改、不可解绑。
|
||
2. THE 系统 SHALL 保证哈希计算在 CP 本地完成，原始内容文件 SHALL NOT 上传至可信数据空间。
|
||
3. THE 系统 SHALL 对所有关键操作（签发、注册、验真、下架）进行链上存证以支持审计。
|
||
|
||
---
|
||
|
||
## 关键约束与假设
|
||
|
||
| 类别 | 内容 |
|
||
|------|------|
|
||
| 约束 | 不替代三方现有系统，仅建立"可信身份映射层" |
|
||
| 约束 | MA码签发权与应急下架发起权仅归监管方 |
|
||
| 约束 | MA码与哈希 1:1 强绑定，不可解绑 |
|
||
| 假设 | 三方系统具备在关键节点集成哈希计算SDK与API调用的能力 |
|
||
| 假设 | 广电总局备案系统可对接 MA码签发与哈希绑定 |
|
||
| 依赖 | 联盟链/分布式账本基础设施可用 |
|
||
| 依赖 | 授权转码中心具备转码后哈希重算与上链能力 |
|
||
|
||
---
|
||
|
||
> 本需求文档作为 TCS-IPTV 系统设计与实现的依据，后续设计文档与任务分解将基于本文档展开。
|