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 监管大屏(角色工作台/全流程演示/监管片库) - 一剧一码+集级哈希, 集级下架/恢复, 全栈测试通过
498 lines
18 KiB
Markdown
498 lines
18 KiB
Markdown
# MA+哈希码 IPTV内容可信锁定系统（TCS-IPTV）完整方案
|
||
|
||
## 一、方案概述
|
||
|
||
### 1.1 背景
|
||
IPTV内容流转涉及CP（内容供应商）、IPTV集成播控平台、运营商（分发网络）三方主体，各自使用独立编码体系，导致：
|
||
- 同一内容反复审核，边际成本不降
|
||
- 版本替换、换壳重发难以识别
|
||
- 违规下架指令逐层翻译，响应滞后
|
||
- 跨省跨运营商复用几乎要重新走全流程
|
||
|
||
### 1.2 核心目标
|
||
建立**"监管身份+技术指纹"双锚定机制**，以MA码为监管主键、哈希码为技术指纹，实现：
|
||
- **审播一致**：送审版=播出版，任何篡改秒级识别
|
||
- **一码通行**：一省过审，全网凭MA码+哈希准入
|
||
- **精准溯源**：出问题凭MA码秒级定位三方系统
|
||
- **数据可信**：播放量、结算、上报以统一标识聚合
|
||
|
||
### 1.3 设计原则
|
||
- **不替代现有系统**：三方保留自有编码，通过映射层对接
|
||
- **最小侵入**：关键节点（送审、入库、分发、播放）嵌入校验
|
||
- **监管合规**：完全符合广电总局网络剧片发行许可及备案制度
|
||
- **可扩展**：支持网络剧、微短剧、网络电影、网络动画等多形态
|
||
|
||
---
|
||
|
||
## 二、系统总体架构
|
||
|
||
### 2.1 四方角色与定位
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 监管侧（广电总局/省局） │
|
||
│ 网络剧片发行许可证系统 / 备案系统 │
|
||
│ ↓ 签发MA码 │
|
||
├─────────────────────────────────────────────────────────────┤
|
||
│ CP端 播控平台端 运营商端 │
|
||
│ (内容供应商) (集成播控) (分发网络) │
|
||
│ │
|
||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||
│ │ 媒资系统 │ ──→ │ 审核系统 │ ──→ │ CDN/EPG │ │
|
||
│ │ 生产哈希 │ │ 验真哈希 │ │ 校验哈希 │ │
|
||
│ └─────────┘ └─────────┘ └─────────┘ │
|
||
│ │ │ │ │
|
||
│ └────────────────┴───────────────────┘ │
|
||
│ │ │
|
||
│ ┌──────────┴──────────┐ │
|
||
│ │ 可信数据空间（区块链） │ │
|
||
│ │ MA码↔哈希↔三方编码映射 │ │
|
||
│ └─────────────────────┘ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 2.2 三层技术架构
|
||
|
||
| 层级 | 功能 | 技术组件 |
|
||
|------|------|---------|
|
||
| **接入层** | 三方系统对接、文件上传、哈希计算 | 哈希计算SDK、API网关、文件切片服务 |
|
||
| **可信层** | MA码与哈希绑定、存证、映射查询 | 联盟链（或分布式账本）、智能合约、Merkle Tree存储 |
|
||
| **应用层** | 审核验真、分发校验、终端抽检、数据上报 | 审核工作台、CDN注入校验、播放器SDK、监管大屏 |
|
||
|
||
---
|
||
|
||
## 三、双锚定模型设计
|
||
|
||
### 3.1 核心概念：Content Twin ID（CTID）
|
||
|
||
每一条内容在系统中拥有唯一的**Content Twin ID**，由双锚定构成：
|
||
|
||
```
|
||
CTID = {
|
||
"ma_code": "（京）网微剧审字(2025)第XXX号", // 监管锚点
|
||
"content_hash": "sha256:a1b2c3d4...", // 技术锚点
|
||
"version": "v1.0", // 版本锚点
|
||
"merkle_root": "sha256:xyz789..." // 分段聚合锚点
|
||
}
|
||
```
|
||
|
||
**绑定规则**：
|
||
- MA码由广电总局/省局签发，代表**合法身份**
|
||
- 哈希码由内容本体计算，代表**数据真实性**
|
||
- 两者在可信数据空间中**1:1强绑定**，不可解绑
|
||
- 内容任何帧级变动 → 哈希变化 → 绑定断裂 → 需重新送审
|
||
|
||
### 3.2 双哈希机制
|
||
|
||
| 哈希类型 | 算法 | 用途 | 敏感度 |
|
||
|---------|------|------|--------|
|
||
| **文件哈希（File Hash）** | SHA-256 | 精确锁定某一版本文件 | 比特级敏感（转码即变） |
|
||
| **感知哈希（Perceptual Hash）** | aHash/dHash/pHash | 跨格式识别同一内容 | 容忍转码、压缩、分辨率调整 |
|
||
|
||
**应用逻辑**：
|
||
- 审核准入：文件哈希必须完全匹配
|
||
- 内容识别：感知哈希用于跨版本、跨格式关联
|
||
- 终端校验：文件哈希抽检完整性
|
||
|
||
---
|
||
|
||
## 四、全流程设计
|
||
|
||
### 4.1 第一阶段：CP端（内容生产与送审）
|
||
|
||
**Step 1：母版哈希生成**
|
||
- CP完成内容制作后，在**原始母版文件**（ProRes/DPX等）上计算：
|
||
- 全文件SHA-256
|
||
- 分段哈希（按场景/集数切分，生成Merkle Tree）
|
||
- 感知哈希
|
||
- 哈希值本地存证，不上传原文件，仅上传哈希
|
||
|
||
**Step 2：送审申报**
|
||
- CP登录广电总局"重点网络影视剧信息备案系统"或省级备案系统
|
||
- 填写节目信息，上传：
|
||
- 片花、海报、剧本
|
||
- **哈希值包**（含Merkle Tree根哈希）
|
||
- 系统返回**送审流水号**
|
||
|
||
**Step 3：审核通过与MA码签发**
|
||
- 省级广电/广电总局审核内容
|
||
- 审核通过后，系统：
|
||
- 签发MA码（或备案号）
|
||
- **将MA码与送审哈希包绑定写入可信数据空间**
|
||
- CP获得"MA码+哈希证书"，方可进入播控平台
|
||
|
||
---
|
||
|
||
### 4.2 第二阶段：播控平台端（审核与入库）
|
||
|
||
**Step 4：送审文件验真**
|
||
- CP向播控平台送审，提交：
|
||
- MA码
|
||
- 送审文件（母版或播出版）
|
||
- 授权链文件
|
||
- 播控平台**计算送审文件哈希**，查询可信数据空间：
|
||
- 哈希匹配 → 确认是"正版过审内容"，进入内容审核
|
||
- 哈希不匹配 → 直接退回，标记"疑似版本替换"
|
||
|
||
**Step 5：内容审核与转码授权**
|
||
- 播控平台对内容进行合规审核（政治、色情、暴力等）
|
||
- 审核通过后，如需转码（H.264/H.265/4K/HD多版本）：
|
||
- 由**授权转码中心**执行，转码后重新计算各版本文件哈希
|
||
- 生成"转码版哈希证书"，与MA码绑定，写入可信数据空间
|
||
- 原母版哈希与转码版哈希建立父子关系
|
||
|
||
**Step 6：EPG编排与编码映射**
|
||
- 播控平台将内容纳入EPG，内部保留自有审核流水号
|
||
- 在可信数据空间中建立映射：
|
||
```
|
||
播控流水号 ↔ MA码 ↔ 文件哈希 ↔ 转码版哈希
|
||
```
|
||
- 向运营商分发时，**必须携带MA码+哈希证书**
|
||
|
||
---
|
||
|
||
### 4.3 第三阶段：运营商端（分发与播出）
|
||
|
||
**Step 7：CDN注入校验**
|
||
- 运营商收到播控平台分发内容，注入CDN前：
|
||
- 计算注入文件哈希
|
||
- 查询可信数据空间，比对MA码绑定的哈希
|
||
- 匹配 → 注入CDN，生成分发编码
|
||
- 不匹配 → 拒绝注入，告警退回播控平台
|
||
|
||
**Step 8：EPG发布与终端播放**
|
||
- 运营商EPG系统展示内容，用户点播
|
||
- 播放器SDK（或机顶盒固件）**支持可选的终端哈希抽检**：
|
||
- 下载片段后计算哈希
|
||
- 与链上哈希比对，防止CDN劫持或传输篡改
|
||
- （此步骤为增强安全，可根据网络负载策略性开启）
|
||
|
||
**Step 9：数据上报**
|
||
- 运营商上报播出数据时，以MA码为统一维度
|
||
- 可信数据空间聚合三方数据（CP播放量、播控审核量、运营商分发量），口径一致
|
||
|
||
---
|
||
|
||
### 4.4 第四阶段：监管与应急
|
||
|
||
**Step 10：全生命周期监管**
|
||
- 广电总局/省局通过监管大屏，按MA码查询内容全链路状态：
|
||
- 当前在哪个播控平台
|
||
- 当前在哪个运营商CDN
|
||
- 当前哈希版本是否最新
|
||
- 历史版本变更记录
|
||
|
||
**Step 11：违规应急下架**
|
||
- 监管部门下发指令："下架MA码（京）网微剧审字(2025)第XXX号"
|
||
- 可信数据空间解析MA码 → 查询所有绑定的三方编码
|
||
- 指令自动翻译为：
|
||
- 播控平台：下架审核流水号XXX
|
||
- 运营商：下架分发编码YYY、CDN资源ZZZ
|
||
- **秒级全网同步**，无需人工逐层翻译
|
||
|
||
---
|
||
|
||
## 五、数据模型与编码规范
|
||
|
||
### 5.1 可信数据空间核心表结构
|
||
|
||
```json
|
||
// 内容主表（Content Registry）
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"ma_code": "（京）网微剧审字(2025)第123号",
|
||
"ma_type": "重点网络微短剧",
|
||
"title": "示例剧集",
|
||
"episode_count": 24,
|
||
"status": "已发证",
|
||
"issue_date": "2025-06-01",
|
||
"issuer": "北京市广播电视局"
|
||
}
|
||
|
||
// 哈希绑定表（Hash Binding）
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"hash_type": "file_sha256",
|
||
"hash_value": "a1b2c3d4e5f6...",
|
||
"file_format": "ProRes 422 HQ",
|
||
"resolution": "3840x2160",
|
||
"duration": 2700,
|
||
"version": "v1.0",
|
||
"merkle_root": "m1n2o3p4q5r6...",
|
||
"created_at": "2025-05-20T10:00:00Z",
|
||
"created_by": "CP-FS-MEDIA"
|
||
}
|
||
|
||
// 三方编码映射表（Identity Mapping）
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"party": "cp",
|
||
"party_id": "FS-MEDIA-77821",
|
||
"party_name": "飞翮信息"
|
||
}
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"party": "broadcast",
|
||
"party_id": "GD-2025-NS-004472",
|
||
"party_name": "广东IPTV播控"
|
||
}
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"party": "operator",
|
||
"party_id": "CT-IPTV-20250612-008923",
|
||
"party_name": "中国电信广东"
|
||
}
|
||
|
||
// 版本变更表（Version History）
|
||
{
|
||
"ctid": "ctid-uuid-001",
|
||
"version": "v2.0",
|
||
"change_reason": "片尾字幕修正",
|
||
"prev_hash": "a1b2c3d4...",
|
||
"new_hash": "b2c3d4e5...",
|
||
"reaudit_required": true,
|
||
"reaudit_status": "待审核"
|
||
}
|
||
```
|
||
|
||
### 5.2 Merkle Tree分段设计（针对多集/长内容）
|
||
|
||
```
|
||
Root Hash
|
||
/ \
|
||
Hash(A) Hash(B)
|
||
/ \ / \
|
||
Hash(E1) Hash(E2) Hash(E3) Hash(E4)
|
||
|
||
E1=第1集, E2=第2集, E3=第3集, E4=第4集
|
||
```
|
||
|
||
- 单集被替换：只需重新计算该集哈希，Merkle Root变化，系统识别
|
||
- 精准定位：可定位到"第几集被篡改"，无需全量重审
|
||
- 增量校验：终端播放时，可按集校验，降低计算负载
|
||
|
||
---
|
||
|
||
## 六、关键技术细节
|
||
|
||
### 6.1 哈希计算SDK（CP端集成）
|
||
|
||
```python
|
||
# 伪代码示例
|
||
import hashlib
|
||
from merkletools import MerkleTools
|
||
|
||
def compute_content_hash(file_path, segment_size=10*1024*1024):
|
||
# 分段计算
|
||
segments = []
|
||
with open(file_path, 'rb') as f:
|
||
while chunk := f.read(segment_size):
|
||
segments.append(hashlib.sha256(chunk).hexdigest())
|
||
|
||
# Merkle Tree
|
||
mt = MerkleTools(hash_type="sha256")
|
||
mt.add_leaf(segments)
|
||
mt.make_tree()
|
||
|
||
return {
|
||
"file_sha256": hashlib.sha256(open(file_path, 'rb').read()).hexdigest(),
|
||
"merkle_root": mt.get_merkle_root(),
|
||
"segment_hashes": segments,
|
||
"perceptual_hash": compute_phash(file_path) # 感知哈希
|
||
}
|
||
```
|
||
|
||
### 6.2 智能合约核心逻辑（可信数据空间）
|
||
|
||
```solidity
|
||
// 伪代码：Solidity风格
|
||
contract ContentRegistry {
|
||
|
||
mapping(string => Content) public contents; // MA码 => 内容
|
||
|
||
struct Content {
|
||
string maCode;
|
||
string merkleRoot;
|
||
string perceptualHash;
|
||
mapping(string => string) partyMappings; // 三方编码映射
|
||
bool isActive;
|
||
}
|
||
|
||
// 仅监管节点可调用
|
||
function issueMA(string memory maCode, string memory merkleRoot) public {
|
||
require(isRegulator(msg.sender), "Only regulator");
|
||
contents[maCode] = Content(maCode, 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 verifyHash(string memory maCode, string memory fileHash) public view returns (bool) {
|
||
return keccak256(abi.encodePacked(contents[maCode].merkleRoot))
|
||
== keccak256(abi.encodePacked(fileHash));
|
||
}
|
||
}
|
||
```
|
||
|
||
### 6.3 转码版哈希处理
|
||
|
||
当内容需要多版本分发（4K/HD/SD）时：
|
||
- 授权转码中心执行转码后，计算新版本文件哈希
|
||
- 在可信数据空间中建立**父子关系**：
|
||
```
|
||
母版哈希（父）──┬── 转码版A哈希（H.265 4K）
|
||
├── 转码版B哈希（H.264 HD）
|
||
└── 转码版C哈希（H.264 SD）
|
||
```
|
||
- 所有转码版共享同一MA码，但各自有独立哈希记录
|
||
- 运营商注入任一版本时，校验对应版本哈希
|
||
|
||
---
|
||
|
||
## 七、接口规范（关键API）
|
||
|
||
### 7.1 哈希上链接口（CP调用）
|
||
|
||
```
|
||
POST /api/v1/content/register
|
||
Headers: Authorization: Bearer {cp_token}
|
||
|
||
Body:
|
||
{
|
||
"title": "示例剧集",
|
||
"episode_count": 24,
|
||
"file_hashes": [
|
||
{
|
||
"episode": 1,
|
||
"file_sha256": "a1b2...",
|
||
"merkle_root": "m1n2...",
|
||
"perceptual_hash": "p1q2...",
|
||
"duration": 2700,
|
||
"resolution": "3840x2160"
|
||
}
|
||
],
|
||
"cp_media_id": "FS-MEDIA-77821"
|
||
}
|
||
|
||
Response:
|
||
{
|
||
"review_id": "REV-2025-12345",
|
||
"status": "pending_review",
|
||
"message": "哈希已存证，请进入备案系统完成申报"
|
||
}
|
||
```
|
||
|
||
### 7.2 哈希验真接口（播控/运营商调用）
|
||
|
||
```
|
||
GET /api/v1/content/verify?ma_code={ma_code}&file_hash={hash}
|
||
|
||
Response:
|
||
{
|
||
"valid": true,
|
||
"ma_code": "（京）网微剧审字(2025)第123号",
|
||
"bound_hash": "a1b2...",
|
||
"submitted_hash": "a1b2...",
|
||
"match": true,
|
||
"version": "v1.0",
|
||
"transcoded_versions": [
|
||
{"format": "H.265 4K", "hash": "t1u2..."}
|
||
]
|
||
}
|
||
```
|
||
|
||
### 7.3 映射查询接口（应急下架）
|
||
|
||
```
|
||
GET /api/v1/content/mappings?ma_code={ma_code}
|
||
|
||
Response:
|
||
{
|
||
"ma_code": "（京）网微剧审字(2025)第123号",
|
||
"mappings": [
|
||
{"party": "cp", "party_id": "FS-MEDIA-77821"},
|
||
{"party": "broadcast", "party_id": "GD-2025-NS-004472"},
|
||
{"party": "operator", "party_id": "CT-IPTV-20250612-008923"}
|
||
],
|
||
"cdn_endpoints": [
|
||
"cdn://ct-gd/iptv/vod/008923"
|
||
]
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 八、治理与运营机制
|
||
|
||
### 8.1 角色权限矩阵
|
||
|
||
| 角色 | 签发MA码 | 注册哈希 | 验真查询 | 映射管理 | 应急下架 |
|
||
|------|---------|---------|---------|---------|---------|
|
||
| 广电总局/省局 | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||
| 播控平台 | ❌ | ❌ | ✅ | ✅（本方） | ❌（执行指令） |
|
||
| 运营商 | ❌ | ❌ | ✅ | ✅（本方） | ❌（执行指令） |
|
||
| CP | ❌ | ✅（送审时） | ✅（自查） | ✅（本方） | ❌ |
|
||
|
||
### 8.2 异常处理规则
|
||
|
||
| 异常场景 | 处理规则 |
|
||
|---------|---------|
|
||
| 哈希不匹配（送审） | 退回CP，要求说明版本差异，必要时重新送审 |
|
||
| 哈希不匹配（CDN注入） | 拒绝注入，告警播控平台，暂停该内容分发 |
|
||
| 哈希不匹配（终端抽检） | 断流并切换至备用源，上报异常日志 |
|
||
| 版本变更（剪辑/修改） | 必须重新计算哈希，提交变更申请，触发重新审核 |
|
||
| CP换壳重发（同一哈希） | 系统识别哈希已存在，拒绝重复申报，关联原MA码 |
|
||
|
||
### 8.3 跨省复用流程
|
||
|
||
```
|
||
A省过审取得MA码 + 哈希证书
|
||
↓
|
||
CP向B省播控平台送审，仅提交：
|
||
- MA码
|
||
- 哈希证书（无需重新提交内容文件）
|
||
↓
|
||
B省播控平台查询可信数据空间：
|
||
- 验证MA码真实有效
|
||
- 验证哈希与A省过审版一致
|
||
- 确认内容未在黑名单
|
||
↓
|
||
B省播控平台快速准入（内容审核可简化为合规性抽检）
|
||
- 生成B省审核流水号
|
||
- 注册映射关系
|
||
↓
|
||
进入B省运营商分发流程
|
||
```
|
||
|
||
**核心价值**：跨省复用从"重新走全流程"压缩为"验真+抽检"，CP边际成本大幅下降。
|
||
|
||
---
|
||
|
||
## 九、实施路径建议
|
||
|
||
| 阶段 | 周期 | 目标 | 关键动作 |
|
||
|------|------|------|---------|
|
||
| **一期：试点验证** | 3个月 | 单省单运营商跑通 | 选择广东/湖南等IPTV大省，对接1家CP、1家播控、1家运营商，完成微短剧品类全流程验证 |
|
||
| **二期：扩展覆盖** | 6个月 | 多省多运营商接入 | 扩展至3-5省，覆盖网络剧、网络电影，接入主流CP 10家以上 |
|
||
| **三期：全国贯通** | 12个月 | 全国IPTV统一接入 | 对接广电总局备案系统，成为全国IPTV内容准入的基础设施 |
|
||
| **四期：大小屏融合** | 18个月 | OTT/APP同步接入 | 将MA+哈希机制扩展至OTT、手机APP，实现大小屏内容身份互通 |
|
||
|
||
---
|
||
|
||
## 十、预期成效
|
||
|
||
| 指标 | 现状 | 目标 |
|
||
|------|------|------|
|
||
| 跨省复用审核周期 | 15-30天 | 3-5天（验真为主） |
|
||
| 违规内容下架响应 | 2-24小时 | 分钟级 |
|
||
| 内容版本替换识别 | 几乎无法识别 | 100%自动识别 |
|
||
| 三方数据对账差异 | 15-30% | <5% |
|
||
| CP重复录入成本 | 每省每运营商重复录入 | 一次录入，全网复用 |
|
||
|
||
---
|
||
|
||
**总结**：这套方案的核心不是让三方放弃自己的系统，而是在三方系统之上建立一层**"可信身份映射层"**——用MA码解决"是谁"的监管问题，用哈希码解决"是不是"的技术问题，用可信数据空间解决"在哪"的溯源问题。三者叠加，IPTV内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。 |