freedak/MAcode
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 更新CC码监管方案业务版文档，新增摘要、UGC专项、直播专项、存量处置、误判申诉、水印嵌入、CC码生命周期、组织保障等章节；同步macode到cccode重命名及其他代码变更

Browse Source
This commit is contained in:
freedakgmail
2026-07-20 22:25:40 +08:00
parent 9f1e2d0a21
commit eb4a82a877
76 changed files with 2600 additions and 2122 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/0-req-IPTV.md
+49 -49
View File
@@ -9,7 +9,7 @@
## 引言
本需求文档定义 TCS-IPTV（Trusted Content System for IPTV）内容可信锁定系统的功能性与非功能性需求。系统通过"MA码（监管身份）+ 哈希码（技术指纹）"双锚定机制，在 CP（内容供应商）、IPTV 集成播控平台、运营商（分发网络）三方现有系统之上建立一层"可信身份映射层"，实现 IPTV 内容"审过即锁定，锁定即通行，通行可追溯"。
本需求文档定义 TCS-IPTV（Trusted Content System for IPTV）内容可信锁定系统的功能性与非功能性需求。系统通过"CC码（监管身份）+ 哈希码（技术指纹）"双锚定机制，在 CP（内容供应商）、IPTV 集成播控平台、运营商（分发网络）三方现有系统之上建立一层"可信身份映射层"，实现 IPTV 内容"审过即锁定，锁定即通行，通行可追溯"。
本系统的核心约束是：**不替代三方现有系统**，仅在关键节点（送审、入库、分发、播放）以最小侵入方式嵌入校验能力，并通过映射层统一对接。
@@ -23,8 +23,8 @@
| CP | Content Provider | 内容供应商 |
| 播控平台 | — | IPTV 集成播控平台 |
| 运营商 | — | IPTV 分发网络运营方（如中国电信、中国移动） |
| MA码 | — | 监管身份主键，由广电总局/省局签发（如网络剧片发行许可证号/备案号） |
| CTID | Content Twin ID | 内容孪生标识，由 MA码+哈希+版本+Merkle根 构成的唯一标识 |
| CC码 | — | 监管身份主键，由广电总局/省局签发（如网络剧片发行许可证号/备案号） |
| CTID | Content Twin ID | 内容孪生标识，由 CC码+哈希+版本+Merkle根 构成的唯一标识 |
| 文件哈希 | File Hash | SHA-256 算法，比特级敏感，精确锁定某版本文件 |
| 感知哈希 | Perceptual Hash | aHash/dHash/pHash，容忍转码压缩，跨格式识别同一内容 |
| Merkle Tree | — | 分段聚合哈希树，用于多集/长内容的分段定位 |
@@ -39,7 +39,7 @@
| 角色 | 描述 | 核心职责 |
|------|------|----------|
| 监管方 | 广电总局 / 省级广电局 | 签发 MA码、注册哈希、验真查询、映射管理、应急下架 |
| 监管方 | 广电总局 / 省级广电局 | 签发 CC码、注册哈希、验真查询、映射管理、应急下架 |
| CP | 内容供应商 | 生产内容、计算哈希、送审申报、注册本方映射 |
| 播控平台 | IPTV 集成播控方 | 送审验真、合规审核、转码授权、EPG编排、注册本方映射、执行下架指令 |
| 运营商 | IPTV 分发网络方 | CDN注入校验、EPG发布、终端播放、数据上报、注册本方映射、执行下架指令 |
@@ -72,24 +72,24 @@
1. WHEN CP 提交送审申报，THE 系统 SHALL 接收节目信息（标题、集数、时长、分辨率）、片花、海报、剧本及哈希值包。
2. WHEN 哈希值包提交成功，THE 系统 SHALL 将哈希存证至可信数据空间并返回唯一送审流水号。
3. WHEN CP 提交的内容哈希在可信数据空间中已存在，THE 系统 SHALL 拒绝重复申报，并将该申报关联至已存在哈希对应的原 MA码。
3. WHEN CP 提交的内容哈希在可信数据空间中已存在，THE 系统 SHALL 拒绝重复申报，并将该申报关联至已存在哈希对应的原 CC码。
4. THE 系统 SHALL 仅接收哈希值包，且 SHALL NOT 要求 CP 上传原始内容文件。
5. IF 哈希值包格式不完整（缺少文件哈希或 Merkle根），THEN THE 系统 SHALL 拒绝申报并提示缺失字段。
---
### 需求 3：MA码签发与强绑定（监管端）
### 需求 3：CC码签发与强绑定（监管端）
**User Story:** 作为监管方，我希望在审核通过后签发 MA码并将其与送审哈希包强绑定，以便建立内容的合法监管身份。
**User Story:** 作为监管方，我希望在审核通过后签发 CC码并将其与送审哈希包强绑定，以便建立内容的合法监管身份。
#### 验收标准
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类型、内容标题、集数等内容主表信息。
1. WHEN 监管方对送审内容审核通过，THE CC码签发引擎 SHALL 签发 CC码（网络剧片发行许可证号或备案号）。
2. WHEN CC码签发，THE 系统 SHALL 将 CC码与送审哈希包以 1:1 关系写入可信数据空间，且该绑定 SHALL NOT 可被解绑。
3. THE 系统 SHALL 仅允许监管节点调用 CC码签发功能（issueMA）；IF 非监管节点调用，THEN THE 系统 SHALL 拒绝并返回权限错误。
4. WHEN CC码签发完成，THE 系统 SHALL 向 CP 发放"CC码+哈希证书"。
5. WHILE 内容未取得 CC码及哈希证书，THE 系统 SHALL NOT 允许该内容进入播控平台审核流程。
6. WHEN CC码绑定写入，THE 系统 SHALL 记录签发方、签发日期、MA类型、内容标题、集数等内容主表信息。
---
@@ -99,8 +99,8 @@
#### 验收标准
1. WHEN CP 向播控平台送审（提交 MA码、送审文件、授权链文件），THE 验真模块 SHALL 计算送审文件哈希。
2. WHEN 送审文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 确认为正版过审内容并允许进入内容审核流程。
1. WHEN CP 向播控平台送审（提交 CC码、送审文件、授权链文件），THE 验真模块 SHALL 计算送审文件哈希。
2. WHEN 送审文件哈希与可信数据空间中 CC码绑定的哈希匹配，THE 系统 SHALL 确认为正版过审内容并允许进入内容审核流程。
3. IF 送审文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 直接退回该送审，并标记为"疑似版本替换"。
4. WHEN 验真执行，THE 系统 SHALL 通过哈希验真接口查询可信数据空间，返回 valid、bound_hash、submitted_hash、match、version 等字段。
@@ -114,20 +114,20 @@
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码但拥有独立哈希记录。
3. WHEN 转码版哈希生成，THE 系统 SHALL 将转码版哈希与 CC码绑定并写入可信数据空间，且 SHALL 与原母版哈希建立父子关系。
4. THE 系统 SHALL 允许同一 CC码绑定多个转码版哈希记录，各转码版 SHALL 共享同一 CC码但拥有独立哈希记录。
---
### 需求 6：EPG编排与编码映射（播控端）
**User Story:** 作为播控平台，我希望在保留自有审核流水号的同时建立其与 MA码、哈希的映射关系，以便对接监管而不改造现有系统。
**User Story:** 作为播控平台，我希望在保留自有审核流水号的同时建立其与 CC码、哈希的映射关系，以便对接监管而不改造现有系统。
#### 验收标准
1. WHEN 内容纳入 EPG，THE 播控平台 SHALL 保留其自有审核流水号。
2. WHEN 内容入库，THE 系统 SHALL 在可信数据空间建立"播控流水号 ↔ MA码 ↔ 文件哈希 ↔ 转码版哈希"的映射关系。
3. WHEN 播控平台向运营商分发内容，THE 系统 SHALL 要求分发数据携带 MA码及哈希证书；IF 未携带，THEN THE 系统 SHALL 拒绝分发。
2. WHEN 内容入库，THE 系统 SHALL 在可信数据空间建立"播控流水号 ↔ CC码 ↔ 文件哈希 ↔ 转码版哈希"的映射关系。
3. WHEN 播控平台向运营商分发内容，THE 系统 SHALL 要求分发数据携带 CC码及哈希证书；IF 未携带，THEN THE 系统 SHALL 拒绝分发。
4. THE 播控平台 SHALL 仅能管理本方（broadcast）的映射记录。
---
@@ -139,7 +139,7 @@
#### 验收标准
1. WHEN 运营商接收播控平台分发的内容并准备注入 CDN，THE 注入校验模块 SHALL 计算注入文件哈希。
2. WHEN 注入文件哈希与可信数据空间中 MA码绑定的哈希匹配，THE 系统 SHALL 允许注入 CDN 并生成分发编码。
2. WHEN 注入文件哈希与可信数据空间中 CC码绑定的哈希匹配，THE 系统 SHALL 允许注入 CDN 并生成分发编码。
3. IF 注入文件哈希与绑定哈希不匹配，THEN THE 系统 SHALL 拒绝注入，触发告警并退回播控平台，同时暂停该内容分发。
4. WHEN 注入成功，THE 系统 SHALL 在可信数据空间注册运营商（operator）映射记录（分发编码、CDN端点）。
@@ -160,35 +160,35 @@
### 需求 9：统一维度数据上报与聚合
**User Story:** 作为监管方，我希望三方播放与业务数据以 MA码为统一维度聚合，以便获得口径一致的可信数据。
**User Story:** 作为监管方，我希望三方播放与业务数据以 CC码为统一维度聚合，以便获得口径一致的可信数据。
#### 验收标准
1. WHEN 运营商上报播出数据，THE 系统 SHALL 以 MA码为统一维度组织数据。
2. THE 可信数据空间 SHALL 按 MA码聚合 CP 播放量、播控审核量、运营商分发量，并保证各方数据口径一致。
3. WHEN 数据聚合完成，THE 系统 SHALL 提供按 MA码查询的统一数据视图。
1. WHEN 运营商上报播出数据，THE 系统 SHALL 以 CC码为统一维度组织数据。
2. THE 可信数据空间 SHALL 按 CC码聚合 CP 播放量、播控审核量、运营商分发量，并保证各方数据口径一致。
3. WHEN 数据聚合完成，THE 系统 SHALL 提供按 CC码查询的统一数据视图。
---
### 需求 10：全生命周期监管查询（监管端）
**User Story:** 作为监管方，我希望通过监管大屏按 MA码查询内容全链路状态，以便实现精准溯源。
**User Story:** 作为监管方，我希望通过监管大屏按 CC码查询内容全链路状态，以便实现精准溯源。
#### 验收标准
1. WHEN 监管方按 MA码查询，THE 监管大屏 SHALL 返回内容当前所在播控平台、当前所在运营商 CDN、当前哈希版本是否最新。
2. WHEN 监管方查询内容历史，THE 系统 SHALL 返回该 MA码的历史版本变更记录。
3. THE 监管大屏 SHALL 支持监管方按 MA码穿透查询三方系统的对应编码。
1. WHEN 监管方按 CC码查询，THE 监管大屏 SHALL 返回内容当前所在播控平台、当前所在运营商 CDN、当前哈希版本是否最新。
2. WHEN 监管方查询内容历史，THE 系统 SHALL 返回该 CC码的历史版本变更记录。
3. THE 监管大屏 SHALL 支持监管方按 CC码穿透查询三方系统的对应编码。
---
### 需求 11：违规应急下架（监管端）
**User Story:** 作为监管方，我希望下发单一 MA码下架指令即可触发全网下架，以便实现秒级应急响应而无需逐层人工翻译。
**User Story:** 作为监管方，我希望下发单一 CC码下架指令即可触发全网下架，以便实现秒级应急响应而无需逐层人工翻译。
#### 验收标准
1. WHEN 监管方下发"下架 MA码 第XXX号"指令，THE 系统 SHALL 解析该 MA码并查询其绑定的所有三方编码及 CDN端点。
1. WHEN 监管方下发"下架 CC码 第XXX号"指令，THE 系统 SHALL 解析该 CC码并查询其绑定的所有三方编码及 CDN端点。
2. WHEN 下架指令解析完成，THE 系统 SHALL 自动将指令翻译为播控平台下架（审核流水号）与运营商下架（分发编码、CDN资源）的执行动作。
3. THE 系统 SHALL 在接收下架指令后秒级同步至全网三方系统，且 SHALL NOT 要求人工逐层翻译。
4. THE 系统 SHALL 仅允许监管方下发应急下架指令；播控平台与运营商 SHALL 仅执行指令而无下架发起权限。
@@ -201,7 +201,7 @@
#### 验收标准
1. WHEN 内容发生任意帧级变动导致哈希变化，THE 系统 SHALL 判定原 MA码与哈希的绑定断裂。
1. WHEN 内容发生任意帧级变动导致哈希变化，THE 系统 SHALL 判定原 CC码与哈希的绑定断裂。
2. WHEN 绑定断裂，THE 系统 SHALL 在版本变更表中记录变更原因、原哈希、新哈希，并将 reaudit_required 置为 true。
3. WHEN 单集内容被替换，THE 系统 SHALL 通过 Merkle Tree 重新计算该集哈希并定位被篡改的具体集数，且 SHALL NOT 要求全量重审。
4. WHILE 重审未通过，THE 系统 SHALL NOT 允许变更后的内容进入分发流程。
@@ -210,12 +210,12 @@
### 需求 13：跨省复用快速准入
**User Story:** 作为 CP，我希望在一省过审后凭 MA码+哈希证书在其他省份快速准入，以便降低跨省复用的边际成本。
**User Story:** 作为 CP，我希望在一省过审后凭 CC码+哈希证书在其他省份快速准入，以便降低跨省复用的边际成本。
#### 验收标准
1. WHEN CP 持 A省签发的 MA码+哈希证书向 B省播控平台送审，THE 系统 SHALL 仅要求提交 MA码与哈希证书，且 SHALL NOT 要求重新提交内容文件。
2. WHEN B省播控平台发起准入查询，THE 系统 SHALL 验证 MA码真实有效、哈希与原过审版一致、且内容不在黑名单中。
1. WHEN CP 持 A省签发的 CC码+哈希证书向 B省播控平台送审，THE 系统 SHALL 仅要求提交 CC码与哈希证书，且 SHALL NOT 要求重新提交内容文件。
2. WHEN B省播控平台发起准入查询，THE 系统 SHALL 验证 CC码真实有效、哈希与原过审版一致、且内容不在黑名单中。
3. WHEN 三重校验通过，THE 系统 SHALL 允许 B省播控平台快速准入，并将内容审核简化为合规性抽检。
4. WHEN B省准入完成，THE 系统 SHALL 生成 B省审核流水号并注册对应映射关系。
@@ -227,10 +227,10 @@
#### 验收标准
1. THE 系统 SHALL 仅允许监管方（广电总局/省局）执行签发 MA码、注册哈希、验真查询、映射管理、应急下架全部操作。
2. THE 系统 SHALL 允许播控平台执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 MA码、注册哈希、发起下架。
3. THE 系统 SHALL 允许运营商执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 MA码、注册哈希、发起下架。
4. THE 系统 SHALL 允许 CP 在送审时注册哈希、执行自查验真、管理本方映射；且 SHALL NOT 允许其签发 MA码或发起下架。
1. THE 系统 SHALL 仅允许监管方（广电总局/省局）执行签发 CC码、注册哈希、验真查询、映射管理、应急下架全部操作。
2. THE 系统 SHALL 允许播控平台执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 CC码、注册哈希、发起下架。
3. THE 系统 SHALL 允许运营商执行验真查询、本方映射管理、执行下架指令；且 SHALL NOT 允许其签发 CC码、注册哈希、发起下架。
4. THE 系统 SHALL 允许 CP 在送审时注册哈希、执行自查验真、管理本方映射；且 SHALL NOT 允许其签发 CC码或发起下架。
5. WHEN 任意角色尝试越权操作，THE 系统 SHALL 拒绝该操作并返回权限错误。
---
@@ -245,21 +245,21 @@
2. IF CDN注入阶段哈希不匹配，THEN THE 系统 SHALL 拒绝注入、告警播控平台并暂停该内容分发。
3. IF 终端抽检阶段哈希不匹配，THEN THE 系统 SHALL 断流、切换备用源并上报异常日志。
4. WHEN 内容发生剪辑/修改，THE 系统 SHALL 要求重新计算哈希、提交变更申请并触发重新审核。
5. WHEN CP 以同一哈希换壳重发，THE 系统 SHALL 识别哈希已存在并拒绝重复申报，同时关联原 MA码。
5. WHEN CP 以同一哈希换壳重发，THE 系统 SHALL 识别哈希已存在并拒绝重复申报，同时关联原 CC码。
---
### 需求 16：可信数据空间存证与智能合约
**User Story:** 作为系统，我希望通过联盟链与智能合约管理 MA码、哈希与映射的存证，以便保证数据不可篡改与可信。
**User Story:** 作为系统，我希望通过联盟链与智能合约管理 CC码、哈希与映射的存证，以便保证数据不可篡改与可信。
#### 验收标准
1. THE 可信数据空间 SHALL 维护内容主表、哈希绑定表、三方编码映射表、版本变更表四类核心数据结构。
2. THE 智能合约 SHALL 提供 issueMA（签发）、registerMapping（注册映射）、verifyHash（哈希校验）核心方法。
3. WHEN registerMapping 被调用，IF 对应 MA码尚未签发，THEN THE 系统 SHALL 拒绝注册映射。
3. WHEN registerMapping 被调用，IF 对应 CC码尚未签发，THEN THE 系统 SHALL 拒绝注册映射。
4. THE 系统 SHALL 通过 Merkle Tree 存储多集内容的分段哈希，并支持按集定位篡改。
5. THE 可信数据空间 SHALL 保证已写入的 MA码与哈希绑定记录不可篡改。
5. THE 可信数据空间 SHALL 保证已写入的 CC码与哈希绑定记录不可篡改。
---
@@ -270,8 +270,8 @@
#### 验收标准
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端点。
2. THE 系统 SHALL 提供哈希验真接口（GET /api/v1/content/verify），供播控/运营商按 CC码与文件哈希查询并返回 valid、bound_hash、submitted_hash、match、version、转码版列表。
3. THE 系统 SHALL 提供映射查询接口（GET /api/v1/content/mappings），供应急下架按 CC码查询三方编码映射与 CDN端点。
4. THE 系统 SHALL 对接口调用进行身份鉴权（如 Bearer Token）。
---
@@ -300,7 +300,7 @@
#### 验收标准
1. THE 系统 SHALL 保证 MA码与哈希的绑定记录一经写入不可篡改、不可解绑。
1. THE 系统 SHALL 保证 CC码与哈希的绑定记录一经写入不可篡改、不可解绑。
2. THE 系统 SHALL 保证哈希计算在 CP 本地完成，原始内容文件 SHALL NOT 上传至可信数据空间。
3. THE 系统 SHALL 对所有关键操作（签发、注册、验真、下架）进行链上存证以支持审计。
@@ -311,10 +311,10 @@
| 类别 | 内容 |
|------|------|
| 约束 | 不替代三方现有系统，仅建立"可信身份映射层" |
| 约束 | MA码签发权与应急下架发起权仅归监管方 |
| 约束 | MA码与哈希 1:1 强绑定，不可解绑 |
| 约束 | CC码签发权与应急下架发起权仅归监管方 |
| 约束 | CC码与哈希 1:1 强绑定，不可解绑 |
| 假设 | 三方系统具备在关键节点集成哈希计算SDK与API调用的能力 |
| 假设 | 广电总局备案系统可对接 MA码签发与哈希绑定 |
| 假设 | 广电总局备案系统可对接 CC码签发与哈希绑定 |
| 依赖 | 联盟链/分布式账本基础设施可用 |
| 依赖 | 授权转码中心具备转码后哈希重算与上链能力 |
docs/CC码监管方案-业务版.md
+677
View File
@@ -0,0 +1,677 @@
# CC码视频监管系统方案
> 面向业务管理层的方案说明
> 编制日期：2026年7月
---
## 摘要
CC码（广电内容编码）是广电总局推出的**强制性视频内容标识制度**，要求全网所有视频内容——包括影视剧、综艺、新闻、短视频、UGC用户创作——上线前必须取得CC码，所有视频平台必须接入CC码验证体系，**无码不得上线**。
本方案采用**"双层架构"**实现CC码的全网监管：
| 防线 | 机制 | 响应速度 | 覆盖范围 |
|------|------|---------|---------|
| **第一层：平台侧预防** | 在上传、播出、CDN、终端四个环节嵌入CC码验证，无码拦截、违规秒级下架 | **秒级** | 所有对接平台 |
| **第二层：独立监控兜底** | 爬虫巡查+水印提取+指纹比对+AI语义识别，不依赖平台配合 | **分钟级** | 全网（含未对接平台、境外平台） |
**关键设计要点**：
- **UGC专项**：平台代理赋码（码段授权+实时赋码），分级检测（快速筛查→重点检测→深度检测），合理使用与二创界定
- **直播专项**：频道/主播级赋码，播出中实时校验，分钟切片检测+秒级断流
- **存量处置**：12个月过渡期，分批补码（头部3个月→一般6个月→全量12个月），过渡期内第二层重点巡查
- **误判申诉**：48小时申诉+24小时审核，分级处置+人工兜底+白名单+秒级恢复
- **水印嵌入**：CC码+平台代码+时间戳嵌入视频像素，不可见、抗压缩、抗裁剪，是全链路追溯的技术基础
- **CC码生命周期**：申请→审核→有效→暂停→恢复/下架→过期，全程状态管理，变更可追溯
- **组织保障**：5个团队约30~44人，7×24小时告警处理，平台考核与牌照续期挂钩
**实施路线**：5个阶段，18个月完成全量上线——3个月持证平台秒级拦截，6个月UGC赋码+独立监控，9个月存量补码+直播监管，12个月全量运行，18个月运营优化。
**核心价值**：从"人工巡查、天级发现、小时级下架"升级为"自动检测、秒级拦截、秒级全网下架"，实现全网全量视频内容的实时监管闭环。
---
## 一、政策背景与要解决的问题
### 1.1 政策背景
CC码（广电内容编码）是广电总局和相关部门推出的**强制性视频内容标识制度**，要求：
- **所有视频内容**——包括影视剧、综艺、纪录片、新闻、短视频、UGC用户创作——上线前必须取得CC码
- **所有视频平台**——包括持证平台、短视频平台、直播平台——必须接入CC码验证体系
- **无码不得上线**：没有CC码的视频内容，平台不得提供上传、发布、传播服务
> CC码相当于视频内容的"数字身份证"。与现有的网络剧片发行许可证制度**并行衔接**：影视剧既需要发行许可证，也需要CC码；UGC等不需要许可证的内容，只需CC码。CC码将监管范围从传统影视剧扩展到**全网所有视频内容**。
### 1.2 现状痛点
当前视频内容监管面临四个核心难题：
| 痛点 | 说明 | 现状 |
|------|------|------|
| **发现晚** | 违规视频上线后，靠人工巡查或群众举报才发现 | 往往已经传播数天，造成不良影响 |
| **下架慢** | 发现违规后，需要逐级通知各平台人工处理 | 从发现到全网下架通常需要数小时甚至数天 |
| **追责难** | 视频被搬运、剪辑后，难以追溯原始来源 | 无法证明"这个视频是从哪个正版内容剪辑来的" |
| **UGC难管** | 短视频平台日均上传量达数百万条，人工审核杯水车薪 | 大量违规内容混在UGC中传播 |
### 1.3 我们的目标
通过CC码制度+技术手段，实现：
- **正向发码**：所有视频内容（含UGC）上线前取得CC码，无码不上线
- **逆向监管**：在全网范围内自动发现、识别、处置违规视频内容
- **秒级下架**：违规内容一经发现，秒级通知全网下架
- **全量覆盖**：从影视剧到UGC短视频，从持证平台到境外平台，全覆盖、无死角
---
## 二、核心思路：两道防线
我们采用**"预防为主，兜底为辅"**的双层设计，可以类比理解为**"门口安检 + 商场巡检"**：
| 比喻 | 对应方案 | 作用 |
|------|---------|------|
| 门口安检 | 第一层：平台侧预防 | 在内容上传/播出时查验CC码，无码不让进 |
| 商场巡检 | 第二层：独立监控 | 安检被绕过时，巡检员在全网巡查发现违规 |
### 为什么需要两道防线
- **只有第一层**：平台如果不配合（不装安检门），就完全失控
- **只有第二层**：发现违规后还要等平台配合才能下架，时延不可控
- **两层并行**：配合的平台秒级拦截，不配合的平台也能分钟级发现并处置
> CC码作为强制要求，所有平台必须接入第一层。但行政强制不能保证100%执行到位，第二层独立监控作为技术兜底，确保"制度管得到的秒级管，制度暂时管不到的分钟级管"。
---
## 三、第一层：平台侧预防（秒级）
### 3.1 工作方式
在视频平台的四个关键环节嵌入CC码验证，类似"四道安检关卡"：
| 关卡 | 在什么环节检查 | 检查什么 | 不通过怎么办 | 用户是否有感知 |
|------|-------------|---------|------------|-------------|
| **第一关：上传拦截** | 内容上传到平台时 | 有没有CC码、码是否合法 | 拒绝上传，提示先去备案（UGC由平台代理赋码，详见第五章） | 上传者看到提示，观众无感 |
| **第二关：播出校验** | 观众点击播放时 | CC码是否还有效（是否已被下架） | 返回"该内容已下架" | 观众看到下架提示 |
| **第三关：CDN注入校验** | 内容分发到CDN时 | 文件是否被篡改 | 拒绝分发，退回审核 | 观众无感 |
| **第四关：终端抽检** | 观众播放过程中 | 播放的内容和登记的是否一致 | 自动断流，切换备用源 | 极偶尔的卡顿，基本无感 |
### 3.2 秒级下架怎么实现
当监管方决定下架某个内容时，只需一条指令：
```
监管方下达指令："下架 CC码 第XXX号"
│
│ 系统自动查找该CC码关联的所有：
│ · 哪些平台有这个内容
│ · 哪些CDN缓存了这个内容
│ · 哪些运营商在分发这个内容
│
▼ 同时通知所有相关方（1秒内）
│
┌────┼────────────┬────────────┬────────────┐
▼ ▼ ▼ ▼ ▼
平台A 平台B 运营商A 运营商B CDN全网
自动下架 自动下架 清除缓存 清除缓存 黑名单拦截
(1秒) (1秒) (1秒) (1秒) (1秒)
```
**关键点**：监管方只需说"下架这个CC码"，系统自动翻译成各平台、各CDN能理解的执行指令，不需要人工逐个通知。
### 3.3 适用范围
CC码是强制性要求，所有视频平台必须对接：
| 平台类型 | 对接方式 | 效果 |
|---------|---------|------|
| IPTV集成播控平台 | 已有TCS-IPTV基础，天然对接 | 秒级拦截+秒级下架 |
| 持证视频平台（爱奇艺/腾讯/优酷等） | 强制对接，行政要求 | 秒级拦截+秒级下架 |
| 短视频平台（抖音/快手/B站等） | 强制对接，UGC批量发码（详见第五章） | 上传环节拦截+批量验证 |
| 直播平台 | 强制对接，直播前预告赋码+播出中实时校验（详见第五章） | 播出环节秒级拦截 |
| 中小视频平台 | 强制对接，分批过渡 | 过渡期内由第二层重点巡查 |
| 境外平台 | 无法对接 | 依靠第二层检测+DNS封锁 |
---
## 四、第二层：独立监控兜底（分钟级）
### 4.1 为什么需要第二层
CC码虽是强制要求，但第一层仍有管不到的地方：
| 场景 | 第一层为什么管不到 | 第二层怎么管 |
|------|-----------------|------------|
| 平台对接有过渡期 | 中小平台分批接入，过渡期内未对接 | 系统自动巡查全网，发现违规 |
| 平台执行不到位 | 形式上对接但实际未严格执行 | 系统独立检测，不依赖平台 |
| UGC剪辑搬运 | 剪辑后的新内容未重新赋码 | 通过内容比对，识别出是哪个正版内容的片段 |
| 境外平台传播 | 管不了境外平台 | 检测发现后，走DNS封锁 |
| 有人故意去水印 | 去掉水印后平台无法验证 | 用内容指纹识别，即使去水印也能认出来 |
| 存量内容未补码 | 补码完成前的存量内容 | 重点巡查，发现违规立即处置 |
### 4.2 工作方式
第二层像一个**自动巡查系统**，分三步工作：
**第一步：采集（发现视频）**
| 采集方式 | 说明 | 覆盖范围 |
|---------|------|---------|
| 网络巡查 | 自动浏览各大视频网站，发现新上线的视频 | 主流视频平台、短视频平台、小网站 |
| 直播录制 | 对电视直播频道实时录制片段 | 卫星频道、有线频道、网络直播 |
| 群众举报 | 提供举报入口，接收群众举报的可疑链接 | 全网 |
**第二步：检测（识别视频）**
对采集到的视频，用三种手段逐步识别：
| 检测手段 | 通俗解释 | 速度 | 能扛什么破坏 |
|---------|---------|------|------------|
| **提取CC码** | 类似扫描身份证 | 秒级 | 扛得住压缩、转码、裁剪 |
| **内容指纹比对** | 类比人脸识别，即使换了衣服也能认出 | 毫秒级 | 扛得住剪辑、加滤镜、去水印 |
| **AI语义理解** | 类比让人看视频说"这跟某某剧是同一部" | 分钟级 | 扛得住深度混剪、拼接 |
三种手段层层递进：第一种认不出来就用第二种，第二种还不行就用第三种。
**第三步：处置（告警+下架）**
| 检测结果 | 处置方式 | 响应速度 |
|---------|---------|---------|
| 发现伪造/无码内容 | 紧急电话+短信通知监管方，要求平台立即下架 | 立即 |
| 发现去水印传播 | 短信通知+自动发行政通知给平台 | 5分钟内 |
| 发现疑似违规 | 纳入日报，人工研判 | 24小时内 |
### 4.3 下架后的验证
第二层还有一个重要职责——**验证下架是否真的执行了**：
```
监管方下达下架指令
│
├── 第一层通知各平台下架（秒级）
│
└── 第二层验证下架效果（分钟级）
├── 自动巡查该视频的URL → 还能访问吗？
├── 已下架 → 记录确认
├── 仍能访问 → 升级告警："XX平台未执行下架指令"
└── 持续监控 → 防止偷偷重新上架
```
---
## 五、UGC短视频场景专项设计
### 5.1 UGC为什么需要单独设计
UGC短视频与影视剧有本质区别，不能简单套用同一套流程：
| 维度 | 影视剧 | UGC短视频 |
|------|--------|----------|
| 日均上传量 | 几十~几百部 | 数百万条 |
| 内容来源 | 专业机构制作 | 普通用户创作 |
| 单条时长 | 30分钟~2小时 | 15秒~5分钟 |
| 是否需要审核 | 严格审核 | 平台自查+抽检 |
| 违规风险 | 较低（已审核） | 较高（实时上传） |
### 5.2 UGC发码机制
UGC不能要求每个用户都去广电总局申请CC码，需要设计**批量发码+平台代理**机制：
```
用户上传短视频
│
├── 平台自动审核（AI初筛+人工复核）
│
├── 审核通过 → 平台代理向CC码系统批量申请CC码
│ ├── 平台获得码段授权（广电总局分配号段给平台）
│ ├── 平台在号段内为每条UGC内容自动赋码
│ └── 赋码信息回传CC码系统备案
│
└── 审核不通过 → 拒绝发布
```
**关键设计**：
| 机制 | 说明 |
|------|------|
| **码段授权** | 广电总局给各平台分配CC码号段，平台在号段内自行赋码 |
| **平台代理** | 用户无需直接对接广电系统，平台代为赋码 |
| **实时赋码** | 用户上传审核通过后秒级赋码，不影响上传体验 |
| **回传备案** | 平台定期将赋码清单回传CC码系统，纳入监管 |
| **码段管控** | 广电可随时收回或冻结平台码段，形成约束 |
### 5.3 UGC检测策略
UGC量巨大，不可能全量深度检测，采用**分级检测**策略：
| 检测级别 | 触发条件 | 检测方式 | 处理速度 |
|---------|---------|---------|---------|
| **快速筛查** | 所有UGC | CC码元数据验证（有无码、码是否在有效号段内） | 毫秒级 |
| **重点检测** | 疑似搬运正版内容 | 内容指纹比对（是否匹配已登记的影视剧指纹） | 秒级 |
| **深度检测** | 疑似违规或高传播量内容 | 水印提取+AI语义分析 | 分钟级 |
**如何判断"疑似搬运正版内容"**：
```
UGC视频上传
│
├── 计算内容指纹（秒级）
│
├── 与影视剧本纹库比对
│ ├── 指纹相似度>80% → 疑似搬运 → 进入重点检测
│ ├── 指纹相似度50~80% → 疑似二创 → 标记观察
│ └── 指纹相似度<50% → 原创内容 → 正常赋码
│
└── 分级处理
├── 疑似搬运 → 提取水印 → 有CC码 → 正版授权？记录
│ → 无水印 → 告警：疑似盗版搬运
└── 疑似二创 → 记录关联关系 → 纳入版权追踪
```
### 5.4 合理使用与二创界定
并非所有使用正版素材的视频都是违规，需要区分**合理使用**和**侵权搬运**：
| 类型 | 特征 | 处理方式 |
|------|------|---------|
| **原创内容** | 完全自主创作 | 正常赋码，正常传播 |
| **合理使用（影评/解说）** | 使用少量片段+大量原创解说 | 正常赋码，标注引用来源 |
| **二创混剪** | 基于正版素材的创意改编 | 赋码时标注"二创"，关联原始CC码 |
| **侵权搬运** | 整片搬运或大段搬运，无原创加工 | 拒绝赋码，下架处理 |
| **去水印搬运** | 去除水印后整片搬运 | 拒绝赋码，下架+追责 |
> 界定标准由广电总局制定，系统提供技术识别能力，最终判定由人工审核确认。
### 5.5 直播场景专项设计
直播与点播有本质区别：直播是实时的，不能等审核完再播出。需要单独设计赋码和监管流程：
**直播赋码机制**：
| 直播类型 | 赋码方式 | 说明 |
|---------|---------|------|
| 卫视直播频道 | 频道级赋码 | 每个频道一个CC码，提前报备节目单 |
| 网络直播（秀场/游戏等） | 主播级赋码 | 平台为主播分配CC码，主播实名绑定 |
| 事件直播（赛事/演唱会等） | 活动级赋码 | 活动主办方提前申请CC码 |
| 突发直播（新闻等） | 平台应急赋码 | 平台用码段内应急码，事后补审 |
**直播监管流程**：
```
直播开始前
├── 频道/主播/活动已赋CC码 → 正常开播
└── 未赋码 → 平台不得开播
直播进行中
├── 第一层：实时校验CC码状态（是否已被下架）
│ ├── CC码有效 → 继续播出
│ └── CC码已下架 → 秒级断流
│
└── 第二层：实时录制片段 → 水印提取 + 指纹比对
├── 内容正常 → 继续监控
├── 发现违规 → 秒级告警 + 断流指令
└── 发现无码直播 → 紧急告警 + 行政通知
直播结束后
├── 直播录像自动存档 → 补充检测
└── 发现违规片段 → 追溯处置
```
**关键设计**：
| 机制 | 说明 |
|------|------|
| **频道/主播级赋码** | 不需要每场直播单独申请，一次赋码长期有效 |
| **实时校验** | 播出过程中持续校验CC码状态，下架指令秒级生效 |
| **片段录制** | 第二层对直播流按分钟切片录制，逐片检测 |
| **应急码段** | 突发新闻等无法提前申请的场景，平台使用应急码段，事后补审 |
| **录像存档** | 直播结束后录像自动存档，供事后追溯和补检 |
### 5.6 水印嵌入机制
前面多次提到"提取水印"和"去水印"，这里说明水印是怎么嵌入到视频中的：
**什么时候嵌入**：
| 内容类型 | 嵌入时机 | 由谁嵌入 |
|---------|---------|---------|
| 影视剧/专业内容 | CC码签发后、内容上线前 | 内容制作方在母版中嵌入 |
| UGC短视频 | 平台赋码后、发布前 | 平台在转码环节自动嵌入 |
| 直播内容 | 直播流编码环节 | 平台在编码器中实时嵌入 |
| 存量补码内容 | 补码后重新转码时 | 平台在重新转码时嵌入 |
**水印嵌入什么信息**：
| 信息 | 说明 |
|------|------|
| CC码 | 内容的唯一标识 |
| 平台代码 | 内容上线平台的标识 |
| 时间戳 | 嵌入时间，用于追溯 |
**水印特性**：
| 特性 | 说明 |
|------|------|
| **不可见** | 嵌入在画面像素中，人眼看不到，不影响观看体验 |
| **不可听** | 如有音频水印，嵌入在音频中，人耳听不到 |
| **抗压缩** | 经过转码、压缩后仍可提取 |
| **抗裁剪** | 画面裁剪后仍可部分提取 |
| **多帧冗余** | 水印重复嵌入在多帧中，部分帧丢失不影响提取 |
> 水印嵌入是CC码监管的技术基础。没有水印，第二层检测就无法识别视频内容的来源。广电总局应制定水印嵌入标准，所有平台和制作方按统一标准执行。
---
## 六、两层如何配合
### 6.1 正常情况（大多数内容）
**影视剧/专业内容**：
```
内容制作 → 送审取得CC码 → 上传平台（第一关验证通过）→ 平台审核 → 观众播放
│
一切正常
第二层不介入
```
**UGC短视频**：
```
用户创作 → 上传平台 → 平台审核 → 平台代理赋码 → 发布上线 → 观众播放
│
一切正常
第二层快速筛查通过
```
### 6.2 异常情况（违规内容）
| 场景 | 第一层 | 第二层 | 最终结果 |
|------|--------|--------|---------|
| 无CC码内容上传 | 第一关拦截，拒绝上传 | - | 内容根本不上线 |
| UGC未赋码就发布 | 平台赋码流程异常，拦截 | - | 内容不上线，平台修复流程 |
| 已下架内容被点播 | 第二关拦截，返回下架提示 | - | 观众看到下架提示 |
| 平台过渡期未对接 | 管不到 | 爬虫发现→检测→告警→行政通知 | 分钟级发现，小时级下架 |
| UGC搬运正版内容 | 赋码时指纹比对发现 | 重点检测→告警 | 秒级拦截上传 |
| 正版内容被剪辑搬运 | 二创赋码时标注关联 | 指纹比对识别→判定是否合理使用 | 分钟级发现侵权 |
| 有人故意去水印 | 验证不了 | 内容指纹识别→告警 | 分钟级发现，追责 |
| 境外平台传播 | 管不到 | 检测发现→DNS封锁 | 天级处置 |
| 存量内容未补码 | 过渡期内允许 | 重点巡查→发现违规立即处置 | 过渡期内重点监管 |
### 6.3 下架指令的执行
```
监管方一条指令
│
├──→ 第一层：秒级通知全网下架（平台+CDN）
│
└──→ 第二层：分钟级验证下架效果
├── 确认下架 → 结案
└── 未下架 → 升级处理
```
---
## 七、存量内容处置计划
CC码制度实施后，全网已有海量存量视频没有CC码，必须制定明确的处置计划：
### 7.1 存量内容分类处置
| 内容类型 | 处置方式 | 时间要求 |
|---------|---------|---------|
| **头部热播内容**（各平台Top1000） | 优先补登记CC码 | 制度生效后3个月内 |
| **一般影视剧/综艺** | 分批补登记 | 制度生效后6个月内 |
| **长尾专业内容** | 平台批量补登记 | 制度生效后12个月内 |
| **存量UGC** | 平台按码段批量赋码 | 制度生效后12个月内 |
| **已下架/失效内容** | 不需要补码 | - |
### 7.2 补码过渡期安排
```
制度生效
│
├── 过渡期（12个月）
│ ├── 存量内容可继续在线，但必须分批补码
│ ├── 补码完成前，纳入第二层重点巡查
│ └── 过渡期内新发现违规的存量内容，立即下架
│
└── 过渡期结束
├── 已补码内容 → 纳入正常监管流程
└── 未补码内容 → 强制下架，平台不得继续提供
```
### 7.3 存量补码的执行方式
| 角色 | 职责 |
|------|------|
| 广电总局 | 发布补码指令，分配码段 |
| 各平台 | 负责本平台存量内容的批量补登记 |
| CC码系统 | 提供批量赋码接口，支持平台批量提交 |
| 第二层监控 | 验证各平台补码进度，对未按时完成的重点巡查 |
---
## 八、误判申诉与恢复机制
### 8.1 为什么需要申诉机制
任何自动化检测都不可能100%准确。如果正常内容被误判为违规并下架，会影响平台正常运营和创作者权益，必须提供快速申诉和恢复通道。
### 8.2 申诉流程
```
内容被下架/拦截
│
├── 平台/创作者收到下架通知
│ 通知包含：下架原因、CC码、检测证据
│
├── 平台/创作者发起申诉（48小时内）
│ 申诉渠道：CC码系统申诉接口 / 平台代申诉
│
├── 申诉审核（24小时内）
│ ├── 自动复核：重新检测，确认是否误判
│ └── 人工复核：由审核人员判断
│
└── 申诉结果
├── 申诉成功 → 立即恢复上线 → 记录误判案例 → 优化检测阈值
└── 申诉驳回 → 维持下架 → 告知驳回理由
```
### 8.3 误判防控措施
| 措施 | 说明 |
|------|------|
| **分级处置** | 低置信度告警先标记观察，不直接下架；高置信度才下架 |
| **人工兜底** | UGC二创、影评解说等灰色地带，必须人工审核确认 |
| **阈值可调** | 指纹相似度阈值根据误判案例持续优化 |
| **白名单机制** | 已确认的合理使用内容纳入白名单，避免重复误判 |
| **申诉数据反哺** | 申诉案例用于训练检测模型，持续降低误判率 |
### 8.4 恢复上线机制
| 场景 | 恢复方式 | 速度 |
|------|---------|------|
| 申诉成功 | CC码状态恢复为"有效"，第一层播出校验自动放行 | 秒级 |
| 申诉成功+CDN缓存 | CC码恢复+通知CDN清除下架标记 | 分钟级 |
| 误批量下架 | 批量恢复CC码状态，批量通知平台 | 分钟级 |
---
## 九、实施计划
### 9.1 分阶段路线
> 以下时间线从**项目启动**起算。存量补码时间线从**CC码制度正式生效**起算（见第七章），两者可能存在时间差：制度生效前完成系统建设，制度生效后启动存量补码。
| 阶段 | 时间 | 目标 |
|------|------|------|
| **第一阶段** | 3个月 | 第一层上线：监管API+秒级下架，对接IPTV+1~2家持证平台 |
| **第二阶段** | 6个月 | 第二层起步版上线+UGC赋码机制上线，对接短视频平台 |
| **第三阶段** | 9个月 | 存量补码启动+直播监管上线+GPU加速检测 |
| **第四阶段** | 12个月 | 全量上线：全网平台对接+存量补码完成+完整监管覆盖 |
| **第五阶段** | 18个月 | 全量运行+对抗加固+运营优化 |
### 9.2 里程碑
| 时间点 | 里程碑 | 验收标准 |
|--------|--------|---------|
| 第3个月 | 持证平台秒级拦截上线 | 试点平台上传验证+播出校验+秒级下架 |
| 第6个月 | UGC赋码+独立监控跑通 | 短视频平台批量赋码上线，日检测5000条，准确率≥90% |
| 第9个月 | 存量补码+直播监管 | 存量Top1000补码完成，50路直播实时监测 |
| 第12个月 | 全量运行 | 全网覆盖，存量补码完成，完整告警+下架+验证+申诉闭环 |
| 第18个月 | 运营优化 | 误判率<2%，对抗测试通过，全量稳定运行 |
---
## 十、与已有系统的关系
本方案不是推倒重来，而是在已有的TCS-IPTV系统上**叠加增强**：
| 已有能力 | 本方案新增 | 关系 |
|---------|-----------|------|
| CC码生成签发 | 平台侧验证API+UGC批量赋码+直播赋码 | 让CC码从"登记备案"升级为"实时验证+全量赋码" |
| 送审文件验真 | 上传环节拦截 | 从"送审时验"扩展到"上传时验" |
| CDN注入校验 | 无需改动 | 已有关卡，直接复用 |
| 终端播放抽检 | 无需改动 | 已有关卡，直接复用 |
| 应急下架指令 | 秒级全网同步 | 从"逐层通知"升级为"一键全网下架" |
| 全生命周期监管 | 独立外部监控 | 新增"不依赖平台配合"的监管视角 |
> **核心理念：不替代现有系统，在关键节点嵌入验证能力，新增独立监控兜底。**
---
## 十一、关键风险与应对
| 风险 | 发生概率 | 影响 | 应对措施 |
|------|---------|------|---------|
| 平台对接进度滞后 | 中 | 第一层覆盖不全 | 行政强制+分批过渡+第二层重点巡查未对接平台 |
| UGC赋码性能瓶颈 | 中 | 短视频平台上传受阻 | 码段授权+平台本地赋码+异步回传，不依赖实时联网 |
| 水印被技术手段去除 | 低 | 第二层检测难度增大 | 三种检测手段层层兜底，去水印还有指纹识别 |
| 爬虫被网站反爬阻挡 | 中 | 部分网站采集不到 | 多种采集策略；群众举报通道补充 |
| CDN厂商不配合下架 | 低 | 下架不彻底 | 行政处罚；DNS封锁作为最终手段 |
| 误判正常内容为违规 | 中 | 影响正常播出和创作 | 分级处置+人工兜底+申诉通道+阈值持续优化 |
| 存量补码进度滞后 | 中 | 过渡期结束后大量内容被强制下架 | 分批推进+进度监控+必要时延长过渡期 |
| 合理使用界定争议 | 中 | 二创/影评创作者不满 | 界定标准由广电制定+人工审核+申诉机制 |
| 建设成本超出预算 | 低 | 需要追加投入 | 分阶段建设，先验证再扩容，避免一次性大投入 |
| 直播监管实时性不足 | 中 | 违规直播片段已播出 | 片段切片检测+秒级断流+录像事后追责 |
| 水印标准不统一 | 中 | 跨平台检测失败 | 广电制定统一水印标准，强制执行 |
---
## 十二、方案价值总结
| 维度 | 现状 | 本方案实现后 |
|------|------|------------|
| **发现速度** | 人工巡查，天级~周级 | 秒级（平台预防）+ 分钟级（独立监控） |
| **下架速度** | 逐级通知，小时级~天级 | 一键指令，秒级全网下架 |
| **覆盖范围** | 依赖平台配合，UGC基本失管 | 全量覆盖：影视剧+UGC+直播，持证平台+短视频+境外 |
| **追溯能力** | 难以追溯来源 | CC码+水印+指纹，全链路追溯 |
| **对抗能力** | 被动应对 | 水印+指纹+AI三层检测，扛转码/剪辑/去水印 |
| **证据固化** | 人工截图取证 | 自动保存视频片段、截图、检测日志 |
| **UGC管理** | 平台自查，标准不一 | 统一赋码+分级检测+合理使用界定 |
| **存量处理** | 无系统方案 | 分批补码+过渡期安排+重点巡查 |
| **误判处理** | 无申诉渠道 | 分级处置+申诉通道+快速恢复 |
| **运营成本** | 大量人工巡查 | 自动化检测，人工只处理告警和审核 |
| **直播监管** | 基本无实时监管 | 频道/主播级赋码+实时校验+秒级断流 |
---
## 十三、决策建议
1. **尽快启动第一阶段**（第一层平台侧预防），投入小、见效快，3个月即可实现持证平台秒级拦截
2. **同步启动第二层MVP和UGC赋码机制**，UGC是最大的监管盲区，必须尽早覆盖
3. **同步启动存量补码计划**，存量内容量大，越早启动越主动
4. **推动CC码制度法规落地**，技术方案需要政策支撑，平台配合度取决于行政强制力
5. **分阶段扩容**，先验证再投入，避免一次性大规模建设
6. **建立申诉机制**，误判处理是业务领导最关切的实操问题，必须在上线前就绪
7. **第一层+第二层缺一不可**，只有第一层会被绕过，只有第二层下架慢，两层并行才能实现全覆盖、秒级响应
---
## 十四、CC码生命周期管理
CC码不是一次性发放就结束的，每个CC码都有完整的生命周期状态管理：
### 14.1 CC码状态流转
```
申请 → 审核中 → 签发（有效）→ 暂停 → 恢复
│ │
│ └── 下架（永久）
│
└── 过期（内容下线后自动过期）
```
### 14.2 各状态说明
| 状态 | 含义 | 触发条件 | 平台行为 |
|------|------|---------|---------|
| **审核中** | CC码申请已提交，等待审批 | 内容制作方/平台提交申请 | 内容不得上线 |
| **有效** | CC码已签发，内容可正常传播 | 审核通过 | 正常上传、播出、分发 |
| **暂停** | 临时停止传播，待核实 | 收到举报或检测到疑似违规 | 平台暂停播出，但不删除 |
| **恢复** | 暂停解除，恢复传播 | 核实后确认无违规 | 恢复正常播出 |
| **下架** | 永久停止传播 | 监管方下达下架指令 | 平台立即删除，CDN清除缓存 |
| **过期** | 内容已下线，CC码失效 | 内容自然下线或授权到期 | 平台不得再提供播放 |
### 14.3 状态变更的权限
| 操作 | 谁有权执行 | 生效速度 |
|------|-----------|---------|
| 申请CC码 | 内容制作方/平台代理 | - |
| 审核签发 | 广电总局CC码系统 | 审核通过后即时 |
| 暂停 | 监管方/平台举报 | 秒级 |
| 恢复 | 监管方核实后 | 秒级 |
| 下架 | 监管方 | 秒级全网同步 |
| 过期 | 系统自动（授权到期或内容下线） | 自动触发 |
> CC码生命周期管理确保每个内容从申请到下线的全过程都在监管之下，任何状态变更都有记录可查。
---
## 十五、组织保障与运营机制
### 15.1 运营组织架构
| 角色 | 职责 | 人员配置（建议） |
|------|------|----------------|
| **监管中心** | 统筹CC码签发、下架决策、申诉审核 | 5~8人 |
| **审核团队** | CC码申请审核、误判申诉复核、合理使用界定 | 8~12人 |
| **监控运营团队** | 第二层监控系统运营、告警处理、爬虫策略调整 | 6~10人 |
| **平台对接团队** | 推动各平台对接API、技术支持、进度跟踪 | 4~6人 |
| **技术运维团队** | 系统运维、水印/指纹/AI模型优化 | 6~8人 |
### 15.2 日常运营机制
| 机制 | 频率 | 内容 |
|------|------|------|
| **实时告警处理** | 7×24小时 | 值班人员处理系统告警，决定是否下架 |
| **每日巡检** | 每日 | 检查系统运行状态、爬虫覆盖率、检测准确率 |
| **每周研判** | 每周 | 集中研判疑似违规内容，调整检测阈值 |
| **每月报告** | 每月 | 向领导层提交监管月报：检测量、下架量、平台配合度 |
| **季度评估** | 每季度 | 评估系统效果，优化检测策略，调整平台对接优先级 |
### 15.3 平台考核机制
| 考核维度 | 指标 | 权重 |
|---------|------|------|
| **对接进度** | 是否按计划完成API对接 | 30% |
| **执行效率** | 下架指令执行率、执行速度 | 30% |
| **赋码覆盖率** | 平台内容赋码比例（含存量补码进度） | 20% |
| **违规率** | 平台被发现的违规内容数量 | 20% |
> 考核结果与平台年检、牌照续期挂钩，确保平台有动力配合。
---
## 十六、CC码与现有制度的关系
| 现有制度 | 与CC码的关系 | 说明 |
|---------|-------------|------|
| 网络剧片发行许可证 | **并行衔接** | 影视剧需要许可证+CC码；UGC只需CC码 |
| 信息网络传播视听节目许可证 | **平台级并行** | 平台持此证是前提，CC码是平台必须接入的验证体系 |
| IPTV集成播控牌照 | **天然对接** | 已有TCS-IPTV系统，CC码验证API直接复用 |
| 广播电视节目制作经营许可证 | **内容制作方并行** | 制作方持此证制作内容，内容上线前还需取得CC码 |
| 现有内容审查制度 | **前置环节** | 内容审查通过后，方可申请CC码；CC码系统不替代审查 |
> **核心理念：CC码不替代任何现有制度，而是在现有制度之上增加一个"数字身份证"层，实现从"审批管理"到"实时监管"的升级。**
docs/CC码监管最优方案-双层架构.md
+778
View File
@@ -0,0 +1,778 @@
# CC码监管最优方案：平台侧API预防（秒级）+ 独立监控兜底（分钟级）
> 版本：V1.0
> 编制日期：2026年7月
> 关联文档：0-req-IPTV.md（TCS-IPTV需求规格）、IPTV系统融合MA码方案介绍.md
---
## 一、方案总览
### 1.1 设计目标
| 目标 | 指标 |
|------|------|
| 持证平台违规内容 | **秒级拦截**（上传/播出环节预防） |
| 已上线违规内容 | **秒级下架**（CC码指令全网同步） |
| 不配合平台/UGC | **分钟级发现** + 小时级处置 |
| 境外平台 | **天级封锁**（DNS/IP层面） |
| 检测准确率 | 水印提取 ≥95%，指纹匹配 ≥90% |
### 1.2 双层架构
```
┌──────────────────────────────────────────────────────────┐
│ 第一层：平台侧预防 │
│ （秒级，主动拦截） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 上传拦截 │ │ 播出校验 │ │ CDN注入 │ │终端抽检 │ │
│ │ (0ms) │ │ (+200ms) │ │ (秒级) │ │(实时) │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────┘ │
│ │ │ │ │ │
│ └────────────┴────────────┴────────────┘ │
│ │ │
│ 监管API网关（统一入口） │
│ CC码验证 · 哈希比对 · 黑名单查询 │
├──────────────────────────────────────────────────────────┤
│ 第二层：独立监控兜底 │
│ （分钟级，被动发现） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 爬虫采集 │ │ 直播旁路 │ │ 水印提取 │ │指纹比对 │ │
│ │ (持续) │ │ (实时) │ │ (秒级) │ │(毫秒级) │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────┘ │
│ │ │ │ │ │
│ └────────────┴────────────┴────────────┘ │
│ │ │
│ 告警引擎 → 行政通知 → 证据固化 │
└──────────────────────────────────────────────────────────┘
```
### 1.3 两层的关系
| 维度 | 第一层（平台侧预防） | 第二层（独立监控兜底） |
|------|-------------------|---------------------|
| 定位 | 事前预防 + 事中拦截 | 事后发现 + 兜底监管 |
| 时效 | 秒级（0~200ms） | 分钟级（10秒~数小时） |
| 依赖平台配合 | 强依赖 | 不依赖 |
| 覆盖范围 | 持证平台 | 全网 |
| 检测手段 | CC码验证 + 哈希比对 | 水印提取 + 指纹匹配 + AI语义 |
| 执行方式 | 平台自动执行 | 行政通知 + CDN黑名单 |
| 对抗能力 | 平台可绕过（不调API） | 无法绕过（外部独立检测） |
> **核心原则：第一层是防线，第二层是底线。第一层能拦住的不需要第二层介入；第一层被绕过的由第二层兜底。**
---
## 二、第一层：平台侧API预防（秒级）
### 2.1 四道拦截关卡
```
内容生命周期：
CP制作 → 上传平台 → 平台审核 → 入库 → 发布到CDN → 用户播放
拦截关卡：
┌─ 关卡1：上传拦截 ──┐ ┌─ 关卡2：播出校验 ─┐
│ 上传时验证CC码 │ │ 发布前验证CC码 │
│ 无码→拒绝上传 │ │ 码不合法→拒绝发布│
│ 时延：0ms │ │ 时延：0ms │
└──────────────────┘ └──────────────────┘
│
┌─ 关卡3：CDN注入校验 ─┐ ┌─ 关卡4：终端抽检 ──┐
│ 注入CDN前哈希校验 │ │ 播放时片段哈希抽检│
│ 哈希不匹配→拒绝注入│ │ 不匹配→断流切换 │
│ 时延：秒级 │ │ 时延：实时 │
└──────────────────┘ └──────────────────┘
```
### 2.2 关卡1：上传拦截（事前预防，0ms）
**场景**：用户/CP向平台上传视频时，平台调用监管API验证CC码。
```
用户上传视频
│
├── 平台提取视频元数据中的CC码
│
├── 调用监管API：POST /api/v1/verify/upload
│ Request:
│ {
│ "cc_code": "MA.156.8531.6101/WD/20260000001",
│ "file_hash": "sha256:abc123...",
│ "perceptual_hash": "phash:def456...",
│ "content_meta": {
│ "title": "xxx",
│ "duration": 3600,
│ "resolution": "1920x1080"
│ }
│ }
│
▼
监管API响应（<100ms）
│
├── { "action": "ALLOW", "cc_code": "valid", "hash_match": true }
│ → 平台允许上传
│
├── { "action": "DENY", "reason": "CC_CODE_NOT_FOUND" }
│ → 平台拒绝上传，提示"内容未取得CC码，请先完成备案"
│
├── { "action": "DENY", "reason": "HASH_MISMATCH" }
│ → 平台拒绝上传，提示"内容哈希与登记不符，疑似版本替换"
│
├── { "action": "DENY", "reason": "CC_CODE_REVOKED" }
│ → 平台拒绝上传，提示"该内容CC码已被吊销"
│
└── { "action": "QUARANTINE", "reason": "CC_CODE_NOT_FOUND", "suggestion": "ENTER_REVIEW" }
→ 平台允许暂存但不可发布，进入人工审核流程
```
**关键设计**：
- 平台在上传页面嵌入CC码验证SDK，上传前先验证
- 无CC码的内容不进入可发布状态（暂存区→人工审核→备案→发布）
- 验证API响应时间 <100ms（Redis缓存 + PostgreSQL索引）
### 2.3 关卡2：播出校验（事中拦截，+200ms）
**场景**：用户请求播放视频时，平台在返回播放地址前验证CC码状态。
```
用户点击播放
│
├── 平台向监管API查询CC码实时状态
│ GET /api/v1/verify/playback?cc_code={cc_code}
│
▼
监管API响应（<50ms，Redis缓存）
│
├── { "status": "ACTIVE" }
│ → 正常返回播放地址
│
├── { "status": "SUSPENDED", "action": "BLOCK" }
│ → 返回"该内容已被监管要求下架"
│
└── { "status": "REVOKED", "action": "BLOCK" }
→ 返回"该内容播出许可已被吊销"
```
**关键设计**：
- 平台播放器在请求播放地址时同步查询CC码状态
- CC码状态变更（下架/吊销）通过WebSocket实时推送到平台
- 查询走Redis缓存，命中率 >99%，响应 <50ms
- 用户感知延迟 <200ms（含网络往返）
### 2.4 关卡3：CDN注入校验（已有需求，对应需求7）
**场景**：运营商向CDN注入内容前，校验哈希。
```
运营商接收发布内容
│
├── 计算注入文件哈希（SHA-256）
│
├── 调用监管API：POST /api/v1/verify/cdn-inject
│ {
│ "cc_code": "MA.156.8531.6101/WD/20260000001",
│ "file_hash": "sha256:abc123...",
│ "cdn_endpoint": "cdn001.operator.com"
│ }
│
▼
├── 哈希匹配 → 允许注入CDN → 注册分发编码
└── 哈希不匹配 → 拒绝注入 → 告警 → 退回审核部门
```
### 2.5 关卡4：终端播放抽检（已有需求，对应需求8）
**场景**：播放器/机顶盒在播放时抽检片段哈希。
```
播放器下载片段
│
├── 计算片段哈希
│
├── 与可信数据空间链上哈希比对
│
├── 匹配 → 正常播放
└── 不匹配 → 断流 → 切换备用源 → 上报异常
```
### 2.6 应急下架指令链路（秒级全网同步）
**场景**：监管方下发CC码下架指令，秒级同步到全网。
```
监管方下发指令："下架 CC码 MA.156.8531.6101/WD/20260000001"
│ ← T0
▼
TCS-IPTV系统解析CC码
│ 查询该CC码绑定的所有：
│ ├── 媒资编码 → 媒体资源库
│ ├── 分发编码 → 各运营商CDN
│ ├── 审核流水号 → CSPS
│ └── 各平台内容ID
│ ← T0+10ms
▼
并行下发执行指令
│
├── → 媒体资源库：撤除发布状态 ← T0+100ms
├── → 运营商A CDN：删除缓存+下线URL ← T0+100ms
├── → 运营商B CDN：删除缓存+下线URL ← T0+100ms
├── → 持证平台A：标记内容下架 ← T0+100ms
├── → 持证平台B：标记内容下架 ← T0+100ms
└── → CDN黑名单推送：全局拦截 ← T0+200ms
│
▼
全网下架完成
← T0+1~3秒（取决于各节点网络延迟）
```
**技术实现**：
| 机制 | 说明 | 时延 |
|------|------|------|
| WebSocket长连接 | TCS与各平台/运营商保持长连接，指令实时推送 | 100ms |
| Redis Pub/Sub | CC码状态变更广播到所有订阅节点 | 50ms |
| CDN API对接 | 调用各CDN的Purge API清除缓存 | 200ms~1s |
| 播出校验联动 | 关卡2的播出校验会自动拦截已下架CC码 | 实时 |
| 兜底轮询 | 未保持长连接的节点每5秒轮询CC码状态 | ≤5秒 |
### 2.7 监管API接口清单
| 接口 | 方法 | 调用方 | 时延要求 | 说明 |
|------|------|--------|---------|------|
| `/api/v1/verify/upload` | POST | 平台上传服务 | <100ms | 上传时CC码+哈希验证 |
| `/api/v1/verify/playback` | GET | 平台播放服务 | <50ms | 播出时CC码状态查询 |
| `/api/v1/verify/cdn-inject` | POST | 运营商CDN | <200ms | CDN注入哈希校验 |
| `/api/v1/verify/terminal` | POST | 终端播放器SDK | <100ms | 终端片段哈希抽检 |
| `/api/v1/takedown/issue` | POST | 监管方 | - | 下发下架指令 |
| `/api/v1/takedown/status` | GET | 各执行方 | <50ms | 查询下架执行状态 |
| `/api/v1/cc-code/lookup` | GET | 各方 | <50ms | CC码信息查询 |
| `/api/v1/blacklist/push` | POST | 监管方→CDN | - | 推送CDN黑名单 |
| `ws:/api/v1/events` | WS | 各平台/运营商 | 实时 | CC码状态变更实时推送 |
---
## 三、第二层：独立监控兜底（分钟级）
### 3.1 适用场景
第二层在以下场景触发：
| 场景 | 第一层状态 | 第二层动作 |
|------|-----------|-----------|
| 持证平台绕过API直接上传 | 关卡1被绕过 | 爬虫发现 → 水印/指纹检测 → 告警 |
| 平台未对接监管API | 第一层缺失 | 爬虫发现 → 检测 → 行政通知 |
| UGC二次创作传播 | 不经过上传校验 | 爬虫发现 → 指纹匹配 → 告警 |
| 境外平台传播 | 无法要求配合 | 爬虫发现 → 检测 → DNS封锁 |
| 直播违规内容 | 播出校验未覆盖 | 旁路录制 → 实时检测 → 告警 |
| 水印被恶意去除 | 所有关卡失效 | 指纹匹配 + AI语义 → 告警 |
### 3.2 采集层
#### 3.2.1 爬虫采集
```
┌─────────────────────────────────────────┐
│ 爬虫任务调度中心 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 站点配置表 │ │ 任务队列 │ │
│ │ (Redis) │ │ (Kafka) │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │
│ ┌──────┴────────────────┴──────┐ │
│ │ 爬虫Worker集群 │ │
│ │ (Playwright无头浏览器) │ │
│ │ │ │
│ │ ├── 页面渲染 + JS执行 │ │
│ │ ├── 视频地址嗅探 │ │
│ │ │ (拦截m3u8/mp4/flv请求) │ │
│ │ ├── 反爬处理 │ │
│ │ │ (UA轮换/代理池/限速) │ │
│ │ └── 去重过滤 │ │
│ │ (URL指纹 + 内容指纹) │ │
│ └──────────┬────────────────────┘ │
│ │ │
│ ▼ │
│ 输出: {url, title, platform, stream_url, │
│ duration, upload_time, uploader} │
│ → Kafka topic: raw-video-tasks │
└─────────────────────────────────────────┘
```
**站点分级策略**：
| 级别 | 站点类型 | 轮巡频率 | 并发数 | 示例 |
|------|---------|---------|--------|------|
| P0 | 头部视频平台 | 5分钟 | 20 | 爱奇艺/腾讯/优酷/B站 |
| P1 | 中型平台 | 30分钟 | 10 | 芒果/搜狐/西瓜视频 |
| P2 | 短视频平台 | 15分钟 | 15 | 抖音/快手/小红书 |
| P3 | 长尾站点 | 2小时 | 5 | 各类小视频站/论坛 |
| P4 | 境外平台 | 1小时 | 5 | YouTube等（通过代理） |
#### 3.2.2 直播旁路录制
```
┌─────────────────────────────────────────┐
│ 直播旁路录制引擎 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 频道配置表 │ │ 录制Worker │ │
│ │ │ │ (FFmpeg) │ │
│ │ 卫星频道 │→ │ │ │
│ │ 有线频道 │→ │ ffmpeg -i │ │
│ │ 网络直播 │→ │ {url} │ │
│ │ │ │ -c copy │ │
│ │ │ │ -f segment│ │
│ │ │ │ -seg_time │ │
│ │ │ │ 300 │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ 切片输出 │
│ (每5分钟一个mp4) │
│ │ │
│ ▼ │
│ Kafka topic: live-tasks │
└─────────────────────────────────────────┘
```
### 3.3 检测层
#### 3.3.1 三级检测流水线
```
输入视频
│
├─────────────────────────────────────────────┐
▼ ▼
路径A：快速检测（CPU，毫秒级） 路径B：深度检测（GPU，秒级）
│ │
├── 第1步：元数据提取 ├── 第2步：水印提取
│ ffprobe提取CC码元数据 │ DCT频域水印提取
│ (moov box / EXT-X-CC-CODE) │ 多帧冗余提取 + 多数投票
│ 时延：100ms │ 时延：2~5秒/30秒片段
│ │
├── 找到CC码？ ├── 找到CC码？
│ ├── 是 → 验证码合法性 → 判定 │ ├── 是 → 验证 → 判定
│ └── 否 → 进入路径B │ └── 否 → 进入第3步
│ │
│ ├── 第3步：内容指纹匹配
│ │ pHash + DTW时序对齐
│ │ 时延：50ms
│ │
│ ├── 指纹匹配？
│ │ ├── 是 → 关联CC码 → 判定
│ │ └── 否 → 进入第4步
│ │
│ └── 第4步：AI语义匹配（兜底）
│ CLIP特征 + 向量检索
│ 时延：30秒/分钟视频
│
▼ ▼
决策层（合并A/B路径结果）
```
#### 3.3.2 水印提取算法
```python
class WatermarkExtractor:
"""
DCT频域水印提取器
嵌入位置：8x8 DCT块的中频系数
嵌入方式：QIM (Quantization Index Modulation)
冗余度：同一CC码在视频中重复嵌入，每30帧一个嵌入周期
"""
def __init__(self, secret_key: bytes):
self.key = secret_key # 监管方持有的水印密钥
self.block_size = 8
self.sample_interval = 30 # 每30帧采样
self.embed_positions = self._derive_positions() # 密钥派生嵌入位置
def extract(self, video_path: str) -> Optional[str]:
# 1. 解码为YUV帧序列
frames = self._decode_video(video_path)
# 2. 采样帧
sampled = frames[::self.sample_interval]
# 3. 逐帧提取水印比特
bit_accumulator = defaultdict(list)
for frame in sampled:
y_channel = frame[:, :, 0] # 亮度通道
# 分块DCT
for block in self._split_blocks(y_channel):
dct_block = cv2.dct(block.astype(np.float32))
# 从中频系数提取比特
for pos in self.embed_positions:
bit = self._extract_bit_qim(dct_block[pos[0], pos[1]])
bit_accumulator[pos].append(bit)
# 4. 多数投票解码
raw_bits = self._majority_vote(bit_accumulator)
# 5. ECC纠错解码
decoded = self._ecc_decode(raw_bits)
# 6. CRC校验
if not self._crc_check(decoded):
return None # 水印损坏或不存在
# 7. HMAC验证
cc_code = self._parse_cc_code(decoded)
if not self._hmac_verify(cc_code, self.key):
return None # 伪造水印
return cc_code
```
#### 3.3.3 内容指纹匹配
```python
class VideoFingerprintMatcher:
"""
视频内容指纹匹配器
指纹：关键帧pHash序列
匹配：汉明距离初筛 + DTW时序对齐
"""
def fingerprint(self, video_path: str) -> dict:
# 1. 降采样
frames = self._decode_downsample(video_path, size=(64, 64), gray=True)
# 2. 关键帧检测（场景切换点）
keyframe_indices = self._detect_keyframes(frames)
# 3. 计算关键帧pHash
keyframe_hashes = []
for idx in keyframe_indices:
phash = self._compute_phash(frames[idx])
keyframe_hashes.append(phash)
# 4. 计算视频级聚合哈希
avg_hash = self._compute_avg_hash(frames)
return {
'keyframe_hashes': keyframe_hashes,
'avg_hash': avg_hash,
'duration': self._get_duration(video_path),
'keyframe_count': len(keyframe_hashes)
}
def match(self, video_fp: dict, database) -> Optional[dict]:
# 1. avg_hash初筛（汉明距离<12）
candidates = database.search_by_avg_hash(
video_fp['avg_hash'],
hamming_threshold=12
)
if not candidates:
return None
# 2. 关键帧序列DTW对齐
best_match = None
best_score = 0
for candidate in candidates:
score = self._dtw_align(
video_fp['keyframe_hashes'],
candidate['keyframe_hashes']
)
if score > best_score:
best_score = score
best_match = candidate
# 3. 阈值判定
if best_score > 0.85:
return {
'cc_code': best_match['cc_code'],
'similarity': best_score,
'matched_title': best_match['title']
}
return None
```
### 3.4 决策与告警层
#### 3.4.1 决策矩阵
| 检测路径 | 结果 | 判定 | 动作 | 时效 |
|---------|------|------|------|------|
| 元数据 | CC码合法 | 正版传播 | 记录备案 | 秒级 |
| 元数据 | CC码不合法 | 伪造/篡改 | 告警+取证 | 秒级 |
| 水印 | CC码合法 | 正版传播 | 记录备案 | 秒级 |
| 水印 | CC码不合法 | 伪造CC码 | 告警+取证+行政通知 | 秒级 |
| 水印 | 无水印 | 疑似未登记 | 进入指纹匹配 | 秒级 |
| 指纹 | 匹配已登记CC码 | 疑似去水印传播 | 告警+取证+行政通知 | 毫秒级 |
| 指纹 | 未匹配 | 进入AI匹配 | - | 毫秒级 |
| AI语义 | 匹配 | 疑似深度篡改/混剪 | 告警+人工审核 | 分钟级 |
| AI语义 | 未匹配 | 未登记内容 | 进入备案审核流程 | 分钟级 |
#### 3.4.2 告警分级
| 级别 | 判定 | 通知方式 | 响应时效 |
|------|------|---------|---------|
| **P0-紧急** | 伪造CC码 + 大规模传播 | 电话+短信+API推送 | 立即 |
| **P1-高危** | 去水印传播 + 已登记内容 | 短信+API推送 | 5分钟内 |
| **P2-中危** | 未登记内容 + 疑似违规 | API推送+邮件 | 30分钟内 |
| **P3-低危** | 未登记内容 + 无明显违规 | 邮件+日报 | 24小时内 |
#### 3.4.3 证据固化
```json
{
"alert_id": "ALT-20260720-001234",
"level": "P1",
"timestamp": "2026-07-20T20:15:00Z",
"source": {
"type": "web_crawler",
"platform": "example.com",
"url": "https://example.com/video/12345",
"crawler_node": "crawler-03"
},
"video_info": {
"title": "xxx",
"duration": 3600,
"resolution": "1920x1080",
"format": "mp4"
},
"detection_result": {
"metadata_cc_code": null,
"watermark_cc_code": null,
"fingerprint_match": {
"matched": true,
"cc_code": "MA.156.8531.6101/WD/20260000001",
"similarity": 0.92,
"matched_title": "原始登记标题"
},
"ai_match": "skipped"
},
"verdict": "SUSPECTED_WATERMARK_REMOVAL",
"evidence": {
"video_clip": "/evidence/ALT-20260720-001234/clip.mp4",
"screenshot": "/evidence/ALT-20260720-001234/screenshot.jpg",
"fingerprint_diff": "/evidence/ALT-20260720-001234/diff.json",
"detection_log": "/evidence/ALT-20260720-001234/log.txt"
},
"actions": [
{ "action": "notify_platform", "status": "sent", "timestamp": "..." },
{ "action": "notify_regulator", "status": "sent", "timestamp": "..." },
{ "action": "preserve_evidence", "status": "done", "timestamp": "..." }
]
}
```
---
## 四、两层协同机制
### 4.1 正常流程（第一层生效）
```
CP上传内容 → 关卡1验证CC码 → 通过 → 平台审核 → 关卡2播出校验 → CDN注入校验 → 用户播放
↓
终端抽检（关卡4）
↓
一切正常，无需第二层介入
```
### 4.2 绕过场景（第二层兜底）
```
场景A：平台未对接API
内容上传 → 平台未验证CC码 → 内容上线
↓
第二层爬虫发现 → 检测 → 告警 → 行政通知平台下架
场景B：持证平台绕过API
内容上传 → 平台跳过CC码验证 → 内容上线
↓
第二层爬虫发现 → 检测 → 告警 → 追责平台
场景C：UGC二次创作
用户剪辑正版内容 → 上传到短视频平台 → 内容上线
↓
第二层爬虫发现 → 指纹匹配 → 判定是否侵权
场景D：水印被去除
内容被去水印处理 → 上传 → 平台无法验证CC码
↓
第二层爬虫发现 → 指纹匹配 → 告警
```
### 4.3 下架指令协同
```
监管方下发下架指令
│
├── 第一层：秒级同步
│ ├── WebSocket推送 → 持证平台自动下架（秒级）
│ ├── CDN Purge API → CDN缓存清除（秒级）
│ ├── Redis状态更新 → 播出校验自动拦截（实时）
│ └── CDN黑名单推送 → 全局URL拦截（秒级）
│
└── 第二层：验证下架效果
├── 爬虫轮巡目标URL → 确认是否已下架
├── 已下架 → 记录确认
├── 未下架 → 升级告警（平台未执行指令）
└── 持续监控 → 防止重新上架
```
### 4.4 数据回流
```
第二层检测发现的内容
│
├── 已登记CC码但未在平台备案 → 回流到TCS-IPTV → 补登记
├── 未登记内容 → 进入备案审核流程 → 补发CC码
├── 伪造CC码 → 回流到TCS → 标记伪造 → 追查来源
└── 去水印传播 → 回流到TCS → 记录侵权证据 → 追责
```
---
## 五、技术架构
### 5.1 系统部署架构
```
┌─────────────────────────────────────────────────────────────┐
│ TCS-IPTV 核心（已有） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ 标识服务 │ │ 验真服务 │ │ MA管理 │ │ 可信数据空间│ │
│ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 监管API网关（第一层） │ │
│ │ /verify/upload /verify/playback /verify/cdn-inject │ │
│ │ /takedown/issue /blacklist/push ws:/events │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 独立监控系统（第二层，新增） │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 爬虫集群 │ │ 录制引擎 │ │ 检测集群 │ │ │
│ │ │ (K8s) │ │ (K8s) │ │ (GPU K8s)│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 告警引擎 │ │ 证据存储 │ │ 下架验证 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 基础设施层 │ │
│ │ │ │
│ │ PostgreSQL │ Redis │ Kafka │ Elasticsearch │ │
│ │ Milvus(向量) │ MinIO(视频/证据) │ K8s集群 │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
### 5.2 第一层资源需求（增量）
| 组件 | 规格 | 数量 | 说明 |
|------|------|------|------|
| API网关 | 4核8GB | 3节点 | 高可用，负载均衡 |
| Redis | 8核32GB | 3节点 | CC码状态缓存，主从+哨兵 |
| WebSocket推送 | 2核4GB | 2节点 | 长连接管理 |
| **合计** | | | **~20核/40GB增量** |
> 第一层资源需求很小，因为验证逻辑轻量，主要依赖已有的TCS-IPTV核心系统。
### 5.3 第二层资源需求（分阶段）
| 阶段 | GPU | CPU | 内存 | 存储 | 带宽 | 月成本 |
|------|-----|-----|------|------|------|--------|
| MVP | 0 | 64核 | 128GB | 20TB | 200Mbps | ¥2~3万 |
| 中等 | 10×T4 | 128核 | 256GB | 50TB | 500Mbps | ¥6~8万 |
| 全量 | 30×T4 | 256核 | 512GB | 150TB | 1Gbps | ¥12~15万 |
> 第二层通过智能调度（粗筛先行、夜间批量、弹性伸缩）可降低40%资源消耗。
---
## 六、分阶段实施计划
### 第一阶段：平台侧API预防（对已有TCS-IPTV扩展）
| 任务 | 周期 | 依赖 |
|------|------|------|
| 监管API网关开发 | 4周 | TCS-IPTV核心 |
| 上传验证接口 | 2周 | API网关 |
| 播出校验接口 | 2周 | API网关 |
| WebSocket实时推送 | 2周 | API网关 |
| 应急下架指令链路 | 3周 | WebSocket + CDN API |
| 平台对接（1~2家试点） | 4周 | 接口就绪 |
| **小计** | **~12周** | |
### 第二阶段：独立监控MVP
| 任务 | 周期 | 依赖 |
|------|------|------|
| 爬虫采集管线 | 4周 | K8s + Kafka |
| 水印嵌入/提取原型 | 6周 | 水印算法选型 |
| 指纹匹配引擎 | 3周 | Milvus部署 |
| 检测流水线编排 | 2周 | 爬虫 + 水印 + 指纹 |
| 告警+证据固化 | 2周 | 检测流水线 |
| **小计** | **~12周** | |
### 第三阶段：检测规模化
| 任务 | 周期 | 依赖 |
|------|------|------|
| GPU集群部署 | 2周 | MVP验证通过 |
| 直播旁路录制 | 3周 | FFmpeg + K8s |
| AI语义匹配 | 4周 | CLIP模型 + Milvus |
| 对抗加固测试 | 4周 | 全检测链路 |
| 下架验证回路 | 2周 | 第一层 + 第二层 |
| **小计** | **~12周** | |
### 第四阶段：全量上线
| 任务 | 周期 | 依赖 |
|------|------|------|
| 全平台对接推广 | 8周 | 行政要求下发 |
| 弹性伸缩调优 | 2周 | 全量负载 |
| 监管大屏集成 | 3周 | 已有需求10 |
| 运营体系建设 | 4周 | 全系统 |
| **小计** | **~12周** | |
> **总周期约12个月**，第一层可在3个月内上线，第二层MVP在6个月内跑通。
---
## 七、与已有TCS-IPTV需求的对应关系
| 已有需求 | 本方案对应模块 | 增强点 |
|---------|-------------|--------|
| 需求3：CC码生成签发 | 第一层验证基础 | CC码作为验证主键 |
| 需求4：送审文件验真 | 第一层关卡1（上传拦截） | 从送审扩展到平台上传 |
| 需求7：CDN注入校验 | 第一层关卡3 | 已有，无需改动 |
| 需求8：终端播放抽检 | 第一层关卡4 | 已有，无需改动 |
| 需求11：违规应急下架 | 第一层下架指令链路 | 增加WebSocket实时推送+CDN黑名单 |
| 需求10：全生命周期监管 | 第二层独立监控 | 新增外部监控维度 |
| 需求9：统一维度数据上报 | 第二层数据回流 | 检测数据回流到TCS |
---
## 八、关键风险与应对
| 风险 | 影响 | 应对 |
|------|------|------|
| 持证平台不配合对接API | 第一层失效 | 行政强制要求 + 第二层兜底 |
| 水印被AI去除 | 第二层检测失效 | 多算法混合嵌入 + 指纹匹配兜底 + AI语义兜底 |
| 爬虫被反爬阻挡 | 第二层采集缺失 | 代理池 + 多策略 + 举报通道补充 |
| CDN厂商不配合黑名单 | 下架不彻底 | 行政处罚 + DNS封锁兜底 |
| 误判率过高 | 正常内容被拦截 | 人工审核兜底 + 阈值可调 + 申诉通道 |
| 资源成本超预算 | 系统无法全量运行 | 分阶段建设 + 智能调度降本 |
docs/IPTV.md
+36 -36
View File
@@ -10,10 +10,10 @@ IPTV内容流转涉及CP（内容供应商）、IPTV集成播控平台、运营
- 跨省跨运营商复用几乎要重新走全流程
### 1.2 核心目标
建立**"监管身份+技术指纹"双锚定机制**，以MA码为监管主键、哈希码为技术指纹，实现：
建立**"监管身份+技术指纹"双锚定机制**，以CC码为监管主键、哈希码为技术指纹，实现：
- **审播一致**：送审版=播出版，任何篡改秒级识别
- **一码通行**：一省过审，全网凭MA码+哈希准入
- **精准溯源**：出问题凭MA码秒级定位三方系统
- **一码通行**：一省过审，全网凭CC码+哈希准入
- **精准溯源**：出问题凭CC码秒级定位三方系统
- **数据可信**：播放量、结算、上报以统一标识聚合
### 1.3 设计原则
@@ -32,7 +32,7 @@ IPTV内容流转涉及CP（内容供应商）、IPTV集成播控平台、运营
┌─────────────────────────────────────────────────────────────┐
│ 监管侧（广电总局/省局） │
│ 网络剧片发行许可证系统 / 备案系统 │
│ ↓ 签发MA码 │
│ ↓ 签发CC码 │
├─────────────────────────────────────────────────────────────┤
│ CP端 播控平台端 运营商端 │
│ (内容供应商) (集成播控) (分发网络) │
@@ -46,7 +46,7 @@ IPTV内容流转涉及CP（内容供应商）、IPTV集成播控平台、运营
│ │ │
│ ┌──────────┴──────────┐ │
│ │ 可信数据空间（区块链） │ │
│ │ MA码↔哈希↔三方编码映射 │ │
│ │ CC码↔哈希↔三方编码映射 │ │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
@@ -56,7 +56,7 @@ IPTV内容流转涉及CP（内容供应商）、IPTV集成播控平台、运营
| 层级 | 功能 | 技术组件 |
|------|------|---------|
| **接入层** | 三方系统对接、文件上传、哈希计算 | 哈希计算SDK、API网关、文件切片服务 |
| **可信层** | MA码与哈希绑定、存证、映射查询 | 联盟链（或分布式账本）、智能合约、Merkle Tree存储 |
| **可信层** | CC码与哈希绑定、存证、映射查询 | 联盟链（或分布式账本）、智能合约、Merkle Tree存储 |
| **应用层** | 审核验真、分发校验、终端抽检、数据上报 | 审核工作台、CDN注入校验、播放器SDK、监管大屏 |
---
@@ -77,7 +77,7 @@ CTID = {
```
**绑定规则**：
- MA码由广电总局/省局签发，代表**合法身份**
- CC码由广电总局/省局签发，代表**合法身份**
- 哈希码由内容本体计算，代表**数据真实性**
- 两者在可信数据空间中**1:1强绑定**，不可解绑
- 内容任何帧级变动 → 哈希变化 → 绑定断裂 → 需重新送审
@@ -114,12 +114,12 @@ CTID = {
- **哈希值包**（含Merkle Tree根哈希）
- 系统返回**送审流水号**
**Step 3：审核通过与MA码签发**
**Step 3：审核通过与CC码签发**
- 省级广电/广电总局审核内容
- 审核通过后，系统：
- 签发MA码（或备案号）
- **将MA码与送审哈希包绑定写入可信数据空间**
- CP获得"MA码+哈希证书"，方可进入播控平台
- 签发CC码（或备案号）
- **将CC码与送审哈希包绑定写入可信数据空间**
- CP获得"CC码+哈希证书"，方可进入播控平台
---
@@ -127,7 +127,7 @@ CTID = {
**Step 4：送审文件验真**
- CP向播控平台送审，提交：
- MA码
- CC码
- 送审文件（母版或播出版）
- 授权链文件
- 播控平台**计算送审文件哈希**，查询可信数据空间：
@@ -138,16 +138,16 @@ CTID = {
- 播控平台对内容进行合规审核（政治、色情、暴力等）
- 审核通过后，如需转码（H.264/H.265/4K/HD多版本）：
- 由**授权转码中心**执行，转码后重新计算各版本文件哈希
- 生成"转码版哈希证书"，与MA码绑定，写入可信数据空间
- 生成"转码版哈希证书"，与CC码绑定，写入可信数据空间
- 原母版哈希与转码版哈希建立父子关系
**Step 6：EPG编排与编码映射**
- 播控平台将内容纳入EPG，内部保留自有审核流水号
- 在可信数据空间中建立映射：
```
播控流水号 ↔ MA码 ↔ 文件哈希 ↔ 转码版哈希
播控流水号 ↔ CC码 ↔ 文件哈希 ↔ 转码版哈希
```
- 向运营商分发时，**必须携带MA码+哈希证书**
- 向运营商分发时，**必须携带CC码+哈希证书**
---
@@ -156,7 +156,7 @@ CTID = {
**Step 7：CDN注入校验**
- 运营商收到播控平台分发内容，注入CDN前：
- 计算注入文件哈希
- 查询可信数据空间，比对MA码绑定的哈希
- 查询可信数据空间，比对CC码绑定的哈希
- 匹配 → 注入CDN，生成分发编码
- 不匹配 → 拒绝注入，告警退回播控平台
@@ -168,7 +168,7 @@ CTID = {
- （此步骤为增强安全，可根据网络负载策略性开启）
**Step 9：数据上报**
- 运营商上报播出数据时，以MA码为统一维度
- 运营商上报播出数据时，以CC码为统一维度
- 可信数据空间聚合三方数据（CP播放量、播控审核量、运营商分发量），口径一致
---
@@ -176,15 +176,15 @@ CTID = {
### 4.4 第四阶段：监管与应急
**Step 10：全生命周期监管**
- 广电总局/省局通过监管大屏，按MA码查询内容全链路状态：
- 广电总局/省局通过监管大屏，按CC码查询内容全链路状态：
- 当前在哪个播控平台
- 当前在哪个运营商CDN
- 当前哈希版本是否最新
- 历史版本变更记录
**Step 11：违规应急下架**
- 监管部门下发指令："下架MA码（京）网微剧审字(2025)第XXX号"
- 可信数据空间解析MA码 → 查询所有绑定的三方编码
- 监管部门下发指令："下架CC码（京）网微剧审字(2025)第XXX号"
- 可信数据空间解析CC码 → 查询所有绑定的三方编码
- 指令自动翻译为：
- 播控平台：下架审核流水号XXX
- 运营商：下架分发编码YYY、CDN资源ZZZ
@@ -308,10 +308,10 @@ def compute_content_hash(file_path, segment_size=10*1024*1024):
// 伪代码：Solidity风格
contract ContentRegistry {
mapping(string => Content) public contents; // MA码 => 内容
mapping(string => Content) public contents; // CC码 => 内容
struct Content {
string maCode;
string ccCode;
string merkleRoot;
string perceptualHash;
mapping(string => string) partyMappings; // 三方编码映射
@@ -319,20 +319,20 @@ contract ContentRegistry {
}
// 仅监管节点可调用
function issueMA(string memory maCode, string memory merkleRoot) public {
function issueMA(string memory ccCode, string memory merkleRoot) public {
require(isRegulator(msg.sender), "Only regulator");
contents[maCode] = Content(maCode, merkleRoot, "", true);
contents[ccCode] = Content(ccCode, merkleRoot, "", true);
}
// CP/播控/运营商注册映射
function registerMapping(string memory maCode, string memory party, string memory partyId) public {
require(contents[maCode].isActive, "MA not issued");
contents[maCode].partyMappings[party] = partyId;
function registerMapping(string memory ccCode, string memory party, string memory partyId) public {
require(contents[ccCode].isActive, "MA not issued");
contents[ccCode].partyMappings[party] = partyId;
}
// 哈希校验
function verifyHash(string memory maCode, string memory fileHash) public view returns (bool) {
return keccak256(abi.encodePacked(contents[maCode].merkleRoot))
function verifyHash(string memory ccCode, string memory fileHash) public view returns (bool) {
return keccak256(abi.encodePacked(contents[ccCode].merkleRoot))
== keccak256(abi.encodePacked(fileHash));
}
}
@@ -348,7 +348,7 @@ contract ContentRegistry {
├── 转码版B哈希（H.264 HD）
└── 转码版C哈希（H.264 SD）
```
- 所有转码版共享同一MA码，但各自有独立哈希记录
- 所有转码版共享同一CC码，但各自有独立哈希记录
- 运营商注入任一版本时，校验对应版本哈希
---
@@ -430,7 +430,7 @@ Response:
### 8.1 角色权限矩阵
| 角色 | 签发MA码 | 注册哈希 | 验真查询 | 映射管理 | 应急下架 |
| 角色 | 签发CC码 | 注册哈希 | 验真查询 | 映射管理 | 应急下架 |
|------|---------|---------|---------|---------|---------|
| 广电总局/省局 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 播控平台 | ❌ | ❌ | ✅ | ✅（本方） | ❌（执行指令） |
@@ -445,19 +445,19 @@ Response:
| 哈希不匹配（CDN注入） | 拒绝注入，告警播控平台，暂停该内容分发 |
| 哈希不匹配（终端抽检） | 断流并切换至备用源，上报异常日志 |
| 版本变更（剪辑/修改） | 必须重新计算哈希，提交变更申请，触发重新审核 |
| CP换壳重发（同一哈希） | 系统识别哈希已存在，拒绝重复申报，关联原MA码 |
| CP换壳重发（同一哈希） | 系统识别哈希已存在，拒绝重复申报，关联原CC码 |
### 8.3 跨省复用流程
```
A省过审取得MA码 + 哈希证书
A省过审取得CC码 + 哈希证书
↓
CP向B省播控平台送审，仅提交：
- MA码
- CC码
- 哈希证书（无需重新提交内容文件）
↓
B省播控平台查询可信数据空间：
- 验证MA码真实有效
- 验证CC码真实有效
- 验证哈希与A省过审版一致
- 确认内容未在黑名单
↓
@@ -495,4 +495,4 @@ B省播控平台快速准入（内容审核可简化为合规性抽检）
---
**总结**：这套方案的核心不是让三方放弃自己的系统，而是在三方系统之上建立一层**"可信身份映射层"**——用MA码解决"是谁"的监管问题，用哈希码解决"是不是"的技术问题，用可信数据空间解决"在哪"的溯源问题。三者叠加，IPTV内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。
**总结**：这套方案的核心不是让三方放弃自己的系统，而是在三方系统之上建立一层**"可信身份映射层"**——用CC码解决"是谁"的监管问题，用哈希码解决"是不是"的技术问题，用可信数据空间解决"在哪"的溯源问题。三者叠加，IPTV内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。
docs/TCS-IPTV系统线框图.svg
+27 -27
View File
@@ -25,13 +25,13 @@
<!-- 标题 -->
<rect x="0" y="0" width="1700" height="78" fill="url(#chainGrad)"/>
<text x="850" y="34" text-anchor="middle" fill="white" font-size="23" font-weight="bold">TCS-IPTV 内容可信锁定系统 · 总体线框图</text>
<text x="850" y="60" text-anchor="middle" fill="#b3c5ff" font-size="13">MA码（监管身份）+ 哈希码（技术指纹）双锚定 · 不替代现有系统，在三方之上建立"可信身份映射层"</text>
<text x="850" y="60" text-anchor="middle" fill="#b3c5ff" font-size="13">CC码（监管身份）+ 哈希码（技术指纹）双锚定 · 不替代现有系统，在三方之上建立"可信身份映射层"</text>
<!-- ============ 监管层 ============ -->
<rect x="40" y="100" width="1620" height="150" rx="10" fill="#fff5f5" stroke="#c62828" stroke-width="2"/>
<rect x="40" y="100" width="1620" height="34" rx="10" fill="url(#regGrad)"/>
<text x="60" y="123" fill="white" font-size="15" font-weight="bold">① 监管侧 — 广电总局 / 省级广电局（监管主键签发方 · 价值核心）</text>
<text x="1640" y="123" text-anchor="end" fill="#ffcdd2" font-size="11">★ 唯一拥有 MA码签发权 与 应急下架权</text>
<text x="1640" y="123" text-anchor="end" fill="#ffcdd2" font-size="11">★ 唯一拥有 CC码签发权 与 应急下架权</text>
<!-- 监管子系统 -->
<g>
@@ -52,29 +52,29 @@
<!-- 新建: MA签发与监管大屏 -->
<g>
<rect x="700" y="148" width="290" height="88" rx="6" fill="#ffebee" stroke="#c62828" stroke-width="2" stroke-dasharray="5,3"/>
<text x="845" y="168" text-anchor="middle" font-size="12" font-weight="bold" fill="#b71c1c">★ MA码签发引擎（新建）</text>
<text x="845" y="187" text-anchor="middle" font-size="10" fill="#555">审核通过 → 签发MA码</text>
<text x="845" y="203" text-anchor="middle" font-size="10" fill="#555">MA码 ↔ 哈希包 强绑定上链</text>
<text x="845" y="168" text-anchor="middle" font-size="12" font-weight="bold" fill="#b71c1c">★ CC码签发引擎（新建）</text>
<text x="845" y="187" text-anchor="middle" font-size="10" fill="#555">审核通过 → 签发CC码</text>
<text x="845" y="203" text-anchor="middle" font-size="10" fill="#555">CC码 ↔ 哈希包 强绑定上链</text>
<text x="845" y="222" text-anchor="middle" font-size="10" fill="#c62828">仅监管节点可调用 issueMA()</text>
</g>
<g>
<rect x="1010" y="148" width="290" height="88" rx="6" fill="#ffebee" stroke="#c62828" stroke-width="2" stroke-dasharray="5,3"/>
<text x="1155" y="168" text-anchor="middle" font-size="12" font-weight="bold" fill="#b71c1c">★ 全生命周期监管大屏（新建）</text>
<text x="1155" y="187" text-anchor="middle" font-size="10" fill="#555">按MA码查全链路状态</text>
<text x="1155" y="187" text-anchor="middle" font-size="10" fill="#555">按CC码查全链路状态</text>
<text x="1155" y="203" text-anchor="middle" font-size="10" fill="#555">在哪个播控/CDN/哈希版本</text>
<text x="1155" y="222" text-anchor="middle" font-size="10" fill="#555">历史版本变更追溯</text>
</g>
<g>
<rect x="1320" y="148" width="320" height="88" rx="6" fill="#ffebee" stroke="#c62828" stroke-width="2" stroke-dasharray="5,3"/>
<text x="1480" y="168" text-anchor="middle" font-size="12" font-weight="bold" fill="#b71c1c">★ 违规应急下架指挥台（新建）</text>
<text x="1480" y="187" text-anchor="middle" font-size="10" fill="#555">下发：下架 MA码 第XXX号</text>
<text x="1480" y="187" text-anchor="middle" font-size="10" fill="#555">下发：下架 CC码 第XXX号</text>
<text x="1480" y="203" text-anchor="middle" font-size="10" fill="#555">自动翻译为三方编码指令</text>
<text x="1480" y="222" text-anchor="middle" font-size="10" fill="#c62828">秒级全网同步，无需逐层人工</text>
</g>
<!-- 监管 → 可信空间 签发MA码 箭头 -->
<!-- 监管 → 可信空间 签发CC码 箭头 -->
<line x1="845" y1="236" x2="845" y2="300" stroke="#c62828" stroke-width="2.5" marker-end="url(#arrowRed)"/>
<text x="855" y="272" font-size="11" font-weight="bold" fill="#c62828">签发MA码 + 绑定哈希</text>
<text x="855" y="272" font-size="11" font-weight="bold" fill="#c62828">签发CC码 + 绑定哈希</text>
<!-- 应急下架 → 可信空间 -->
<line x1="1480" y1="236" x2="1480" y2="300" stroke="#c62828" stroke-width="2.5" stroke-dasharray="6,3" marker-end="url(#arrowRed)"/>
@@ -116,9 +116,9 @@
<text x="965" y="370" text-anchor="middle" font-size="12" font-weight="bold" fill="#311b92">三方编码映射表（Identity Mapping）</text>
<line x1="770" y1="378" x2="1160" y2="378" stroke="#d1c4e9"/>
<text x="770" y="400" font-size="10" fill="#444">CP编码 FS-MEDIA-77821 ┐</text>
<text x="770" y="422" font-size="10" fill="#444">播控编码 GD-2025-NS-004472 ├─ ↔ MA码</text>
<text x="770" y="422" font-size="10" fill="#444">播控编码 GD-2025-NS-004472 ├─ ↔ CC码</text>
<text x="770" y="444" font-size="10" fill="#444">运营商编码 CT-IPTV-...008923 ┘</text>
<text x="770" y="468" font-size="9" fill="#777">一个MA码解析出全部三方编码 + CDN端点</text>
<text x="770" y="468" font-size="9" fill="#777">一个CC码解析出全部三方编码 + CDN端点</text>
<text x="770" y="481" font-size="9" fill="#2e7d32">→ 应急下架时一键定位全网资源</text>
</g>
@@ -167,10 +167,10 @@
<text x="90" y="758">Step1 母版哈希生成：全文件SHA-256 + 分段哈希 + 感知哈希</text>
<text x="90" y="784">Step2 送审申报：登录备案系统，上传哈希值包（不传原文件）</text>
<text x="110" y="804" fill="#777">片花/海报/剧本 + Merkle Tree根哈希 → 返回送审流水号</text>
<text x="90" y="830">Step3 审核通过：省级/总局签发MA码，MA码↔哈希包上链</text>
<text x="110" y="850" fill="#777">CP获"MA码+哈希证书"，方可进入播控平台</text>
<text x="90" y="830">Step3 审核通过：省级/总局签发CC码，CC码↔哈希包上链</text>
<text x="110" y="850" fill="#777">CP获"CC码+哈希证书"，方可进入播控平台</text>
<text x="90" y="882" fill="#2e7d32" font-weight="bold">权限：注册哈希(送审时) · 验真自查 · 管理本方映射</text>
<text x="90" y="904" fill="#c62828">换壳重发：同哈希已存在 → 拒绝重复申报，关联原MA码</text>
<text x="90" y="904" fill="#c62828">换壳重发：同哈希已存在 → 拒绝重复申报，关联原CC码</text>
</g>
<!-- 播控平台端 -->
@@ -190,7 +190,7 @@
<text x="970" y="632" text-anchor="middle" font-size="11" font-weight="bold" fill="#0d47a1">★ 验真+映射模块（新建）</text>
<text x="970" y="650" text-anchor="middle" font-size="9" fill="#555">送审文件哈希验真</text>
<text x="970" y="666" text-anchor="middle" font-size="9" fill="#555">转码版哈希绑定</text>
<text x="970" y="682" text-anchor="middle" font-size="9" fill="#555">建立播控流水号↔MA码映射</text>
<text x="970" y="682" text-anchor="middle" font-size="9" fill="#555">建立播控流水号↔CC码映射</text>
</g>
<g font-size="10" fill="#333">
@@ -201,9 +201,9 @@
<text x="660" y="796" fill="#c62828">不匹配 → 直接退回，标记"疑似版本替换"</text>
<text x="640" y="822">Step5 审核+转码：授权转码中心转码，重算各版本哈希</text>
<text x="660" y="842" fill="#777">母版哈希与转码版建立父子关系上链</text>
<text x="640" y="868">Step6 EPG编排：建立 播控流水号↔MA码↔哈希 映射</text>
<text x="640" y="868">Step6 EPG编排：建立 播控流水号↔CC码↔哈希 映射</text>
<text x="640" y="894" fill="#1565c0" font-weight="bold">权限：验真查询 · 本方映射管理 · 执行下架指令</text>
<text x="640" y="914" fill="#c62828">向运营商分发必须携带 MA码+哈希证书</text>
<text x="640" y="914" fill="#c62828">向运营商分发必须携带 CC码+哈希证书</text>
</g>
<!-- 运营商端 -->
@@ -234,7 +234,7 @@
<text x="1210" y="796" fill="#c62828">不匹配 → 拒绝注入，告警退回播控平台</text>
<text x="1190" y="822">Step8 EPG发布+终端播放：播放器SDK片段哈希抽检</text>
<text x="1210" y="842" fill="#777">下载片段比对链上哈希，异常断流切备用源</text>
<text x="1190" y="868">Step9 数据上报：以MA码为统一维度聚合三方数据</text>
<text x="1190" y="868">Step9 数据上报：以CC码为统一维度聚合三方数据</text>
<text x="1190" y="894" fill="#e65100" font-weight="bold">权限：验真查询 · 本方映射管理 · 执行下架指令</text>
<text x="1190" y="914" fill="#777">CP播放量/播控审核量/运营商分发量口径一致</text>
</g>
@@ -275,16 +275,16 @@
<rect x="445" y="1000" width="390" height="150" rx="8" fill="#fff5f5" stroke="#c62828" stroke-width="1.5"/>
<text x="640" y="1024" text-anchor="middle" font-size="13" font-weight="bold" fill="#b71c1c">价值② 精准溯源</text>
<line x1="465" y1="1032" x2="815" y2="1032" stroke="#ffcdd2"/>
<text x="465" y="1056" font-size="10" fill="#444">凭一个MA码秒级定位三方系统</text>
<text x="465" y="1056" font-size="10" fill="#444">凭一个CC码秒级定位三方系统</text>
<text x="465" y="1078" font-size="10" fill="#444">在哪个播控、哪个CDN、哪个哈希版本</text>
<text x="465" y="1100" font-size="10" fill="#444">历史版本变更全程留痕</text>
<text x="465" y="1128" font-size="11" fill="#c62828" font-weight="bold">出问题 → MA码一键穿透全链路</text>
<text x="465" y="1128" font-size="11" fill="#c62828" font-weight="bold">出问题 → CC码一键穿透全链路</text>
</g>
<g>
<rect x="850" y="1000" width="390" height="150" rx="8" fill="#fff5f5" stroke="#c62828" stroke-width="1.5"/>
<text x="1045" y="1024" text-anchor="middle" font-size="13" font-weight="bold" fill="#b71c1c">价值③ 应急下架</text>
<line x1="870" y1="1032" x2="1220" y2="1032" stroke="#ffcdd2"/>
<text x="870" y="1056" font-size="10" fill="#444">下发"下架MA码第XXX号"单一指令</text>
<text x="870" y="1056" font-size="10" fill="#444">下发"下架CC码第XXX号"单一指令</text>
<text x="870" y="1078" font-size="10" fill="#444">系统自动翻译为三方编码下架动作</text>
<text x="870" y="1100" font-size="10" fill="#444">无需人工逐层翻译/逐省协调</text>
<text x="870" y="1128" font-size="11" fill="#c62828" font-weight="bold">下架响应：2-24小时 → 分钟级</text>
@@ -293,34 +293,34 @@
<rect x="1255" y="1000" width="385" height="150" rx="8" fill="#fff5f5" stroke="#c62828" stroke-width="1.5"/>
<text x="1447" y="1024" text-anchor="middle" font-size="13" font-weight="bold" fill="#b71c1c">价值④ 数据可信</text>
<line x1="1275" y1="1032" x2="1625" y2="1032" stroke="#ffcdd2"/>
<text x="1275" y="1056" font-size="10" fill="#444">播放量/结算/上报以MA码统一聚合</text>
<text x="1275" y="1056" font-size="10" fill="#444">播放量/结算/上报以CC码统一聚合</text>
<text x="1275" y="1078" font-size="10" fill="#444">三方数据同一口径，消除对账争议</text>
<text x="1275" y="1100" font-size="10" fill="#444">监管掌握真实全网数据</text>
<text x="1275" y="1128" font-size="11" fill="#c62828" font-weight="bold">三方对账差异：15-30% → &lt;5%</text>
</g>
<!-- ============ 跨省复用价值 ============ -->
<text x="40" y="1190" font-size="16" font-weight="bold" fill="#1a237e">⑤ 跨省复用流程 — "一码通行"：一省过审，全网凭MA码+哈希准入</text>
<text x="40" y="1190" font-size="16" font-weight="bold" fill="#1a237e">⑤ 跨省复用流程 — "一码通行"：一省过审，全网凭CC码+哈希准入</text>
<rect x="40" y="1205" width="1620" height="130" rx="8" fill="#f3e5f5" stroke="#311b92" stroke-width="1.5"/>
<g font-size="11">
<!-- 流程步骤横向 -->
<rect x="70" y="1235" width="230" height="70" rx="6" fill="white" stroke="#311b92"/>
<text x="185" y="1262" text-anchor="middle" font-weight="bold" fill="#311b92">A省过审</text>
<text x="185" y="1283" text-anchor="middle" font-size="9" fill="#555">取得 MA码 + 哈希证书</text>
<text x="185" y="1283" text-anchor="middle" font-size="9" fill="#555">取得 CC码 + 哈希证书</text>
<line x1="300" y1="1270" x2="345" y2="1270" stroke="#311b92" stroke-width="2.5" marker-end="url(#arrowBlue)"/>
<rect x="350" y="1235" width="250" height="70" rx="6" fill="white" stroke="#311b92"/>
<text x="475" y="1258" text-anchor="middle" font-weight="bold" fill="#311b92">向B省播控送审</text>
<text x="475" y="1278" text-anchor="middle" font-size="9" fill="#555">仅提交 MA码+哈希证书</text>
<text x="475" y="1278" text-anchor="middle" font-size="9" fill="#555">仅提交 CC码+哈希证书</text>
<text x="475" y="1294" text-anchor="middle" font-size="9" fill="#c62828">无需重新提交内容文件</text>
<line x1="600" y1="1270" x2="645" y2="1270" stroke="#311b92" stroke-width="2.5" marker-end="url(#arrowBlue)"/>
<rect x="650" y="1235" width="280" height="70" rx="6" fill="white" stroke="#311b92"/>
<text x="790" y="1258" text-anchor="middle" font-weight="bold" fill="#311b92">可信空间验真</text>
<text x="790" y="1278" text-anchor="middle" font-size="9" fill="#555">MA码有效 + 哈希一致 + 非黑名单</text>
<text x="790" y="1278" text-anchor="middle" font-size="9" fill="#555">CC码有效 + 哈希一致 + 非黑名单</text>
<text x="790" y="1294" text-anchor="middle" font-size="9" fill="#555">三重校验通过</text>
<line x1="930" y1="1270" x2="975" y2="1270" stroke="#311b92" stroke-width="2.5" marker-end="url(#arrowBlue)"/>
@@ -397,7 +397,7 @@
<!-- ============ 总结框 ============ -->
<rect x="40" y="1820" width="1620" height="120" rx="10" fill="url(#chainGrad)"/>
<text x="850" y="1855" text-anchor="middle" fill="white" font-size="16" font-weight="bold">设计哲学：不替代现有系统，在三方之上建立"可信身份映射层"</text>
<text x="850" y="1888" text-anchor="middle" fill="#d1c4e9" font-size="13">MA码解决"是谁"（监管身份）· 哈希码解决"是不是"（数据真实）· 可信数据空间解决"在哪"（全链溯源）</text>
<text x="850" y="1888" text-anchor="middle" fill="#d1c4e9" font-size="13">CC码解决"是谁"（监管身份）· 哈希码解决"是不是"（数据真实）· 可信数据空间解决"在哪"（全链溯源）</text>
<text x="850" y="1918" text-anchor="middle" fill="#b3c5ff" font-size="13" font-weight="bold">三者叠加 → 审过即锁定，锁定即通行，通行可追溯 · 监管从"逐层翻译滞后"升级为"一码穿透秒级响应"</text>
<!-- 图例 -->
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB