feat: 更新CC码监管方案业务版文档，新增摘要、UGC专项、直播专项、存量处置、误判申诉、水印嵌入、CC码生命周期、组织保障等章节；同步macode到cccode重命名及其他代码变更
This commit is contained in:
freedakgmail
+36
-36
@@ -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内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。
|
||||
Reference in New Issue
Block a user