feat: 更新CC码监管方案业务版文档，新增摘要、UGC专项、直播专项、存量处置、误判申诉、水印嵌入、CC码生命周期、组织保障等章节；同步macode到cccode重命名及其他代码变更
This commit is contained in:
freedakgmail
+33
-33
@@ -11,7 +11,7 @@
|
||||
|
||||
### 1.1 产品定位
|
||||
|
||||
TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、运营商** 三方现有系统之上的**内容可信身份映射层**。它通过"MA码（监管身份）+ 哈希码（技术指纹）"双锚定机制，让每一条 IPTV 内容拥有全网唯一、不可篡改、可追溯的可信身份，实现"**审过即锁定，锁定即通行，通行可追溯**"。
|
||||
TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、运营商** 三方现有系统之上的**内容可信身份映射层**。它通过"CC码（监管身份）+ 哈希码（技术指纹）"双锚定机制，让每一条 IPTV 内容拥有全网唯一、不可篡改、可追溯的可信身份，实现"**审过即锁定，锁定即通行，通行可追溯**"。
|
||||
|
||||
一句话定位：**不替代任何现有系统，只在三方之上加一层"可信锁"，把"是谁、是不是、在哪里"三个问题一次性解决。**
|
||||
|
||||
@@ -19,11 +19,11 @@ TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、
|
||||
|
||||
| 现状痛点 | 根因 | TCS-IPTV 的解法 |
|
||||
|---------|------|----------------|
|
||||
| 同一内容反复审核，边际成本不降 | 三方编码体系割裂，无法互认 | MA码+哈希一次锁定，跨省凭证复用 |
|
||||
| 同一内容反复审核，边际成本不降 | 三方编码体系割裂，无法互认 | CC码+哈希一次锁定，跨省凭证复用 |
|
||||
| 版本替换、换壳重发难识别 | 缺乏内容级技术指纹 | 文件哈希比特级锁定 + 感知哈希跨格式识别 |
|
||||
| 违规下架指令逐层翻译，响应滞后 | 编码不互通，需人工逐层映射 | 一个MA码自动翻译为三方下架指令，秒级同步 |
|
||||
| 跨省跨运营商复用要重走全流程 | 审核结果无法跨域信任 | 凭MA码+哈希证书快速准入，审核简化为抽检 |
|
||||
| 三方数据对账差异大 | 统计口径不统一 | 以MA码为统一维度聚合，口径一致 |
|
||||
| 违规下架指令逐层翻译，响应滞后 | 编码不互通，需人工逐层映射 | 一个CC码自动翻译为三方下架指令，秒级同步 |
|
||||
| 跨省跨运营商复用要重走全流程 | 审核结果无法跨域信任 | 凭CC码+哈希证书快速准入，审核简化为抽检 |
|
||||
| 三方数据对账差异大 | 统计口径不统一 | 以CC码为统一维度聚合，口径一致 |
|
||||
|
||||
### 1.3 目标用户
|
||||
|
||||
@@ -40,8 +40,8 @@ TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、
|
||||
### 2.1 产品目标
|
||||
|
||||
- **G1 审播一致**：送审版=播出版，任何篡改秒级识别
|
||||
- **G2 一码通行**：一省过审，全网凭 MA码+哈希准入
|
||||
- **G3 精准溯源**：凭 MA码秒级定位三方系统与全链路状态
|
||||
- **G2 一码通行**：一省过审，全网凭 CC码+哈希准入
|
||||
- **G3 精准溯源**：凭 CC码秒级定位三方系统与全链路状态
|
||||
- **G4 数据可信**：播放量、结算、上报以统一标识聚合
|
||||
- **G5 最小侵入**：不改造三方现有系统，仅在关键节点嵌入校验
|
||||
|
||||
@@ -74,7 +74,7 @@ TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、
|
||||
**画像B — 审核和监管部门审核员/监管员（王主任）**
|
||||
- 职责：内容合规审核（CSPS）、违规处置、全网监管
|
||||
- 痛点：出问题难定位，下架指令逐层打电话翻译，慢且易漏
|
||||
- 期望：一个MA码看清全链路，一键下架全网生效
|
||||
- 期望：一个CC码看清全链路，一键下架全网生效
|
||||
|
||||
**画像C — 运营商分发工程师（老李）**
|
||||
- 职责：CDN注入、EPG发布、数据上报
|
||||
@@ -84,35 +84,35 @@ TCS-IPTV 是一套架设在 **内容提供商（CP）、审核和监管部门、
|
||||
### 3.2 核心使用场景
|
||||
|
||||
**场景1：内容首次送审与赋码（端到端正向流程）**
|
||||
小赵在 CP 媒资系统完成制作 → 用哈希SDK对母版计算哈希包 → 登录备案系统提交节目信息+哈希包 → 审核和监管部门审核通过、签发MA码并强绑定哈希 → 小赵拿到"MA码+哈希证书"。
|
||||
小赵在 CP 媒资系统完成制作 → 用哈希SDK对母版计算哈希包 → 登录备案系统提交节目信息+哈希包 → 审核和监管部门审核通过、签发CC码并强绑定哈希 → 小赵拿到"CC码+哈希证书"。
|
||||
> 痛点解法：让内容从源头就获得全网唯一、不可篡改的可信身份，为后续一切流转奠定基础。
|
||||
|
||||
**场景2：内容入库发布（审核→媒资库→运营商）**
|
||||
送审文件验真通过 → CSPS审核合规 → 转码并绑定各版本哈希 → 合格内容进入媒体资源库 → 从媒体资源库携带MA码+哈希证书向运营商发布 → 运营商注入CDN前校验哈希 → 校验通过注入分发。
|
||||
送审文件验真通过 → CSPS审核合规 → 转码并绑定各版本哈希 → 合格内容进入媒体资源库 → 从媒体资源库携带CC码+哈希证书向运营商发布 → 运营商注入CDN前校验哈希 → 校验通过注入分发。
|
||||
> 痛点解法：保证"送审版=播出版"，转码多版本各自锁定，杜绝入库到分发环节的偷换。
|
||||
|
||||
**场景3：跨省快速复用**
|
||||
小赵已在A省过审 → 向B省仅提交MA码+哈希证书（不传文件） → 系统三重校验（MA码有效+哈希一致+非黑名单） → B省快速准入，审核简化为合规抽检。
|
||||
小赵已在A省过审 → 向B省仅提交CC码+哈希证书（不传文件） → 系统三重校验（CC码有效+哈希一致+非黑名单） → B省快速准入，审核简化为合规抽检。
|
||||
> 痛点解法：跨省复用从"重走全流程15-30天"压缩到"验真+抽检3-5天"，CP边际成本大幅下降。
|
||||
|
||||
**场景4：违规应急下架**
|
||||
王主任发现违规 → 下发"下架MA码第XXX号"单一指令 → 系统解析该MA码绑定的全部三方编码与CDN端点 → 自动翻译为媒资库撤除发布+运营商下架CDN资源 → 秒级全网同步。
|
||||
王主任发现违规 → 下发"下架CC码第XXX号"单一指令 → 系统解析该CC码绑定的全部三方编码与CDN端点 → 自动翻译为媒资库撤除发布+运营商下架CDN资源 → 秒级全网同步。
|
||||
> 痛点解法：下架响应从"2-24小时逐层人工翻译"升级为"一码下发、秒级全网生效"。
|
||||
|
||||
**场景5：版本篡改识别**
|
||||
内容被剪辑/替换 → 哈希变化 → MA码与哈希绑定断裂 → 系统标记reaudit_required → 通过Merkle Tree定位被篡改的具体集数 → 阻断分发并触发重审。
|
||||
内容被剪辑/替换 → 哈希变化 → CC码与哈希绑定断裂 → 系统标记reaudit_required → 通过Merkle Tree定位被篡改的具体集数 → 阻断分发并触发重审。
|
||||
> 痛点解法：版本替换/换壳重发从"几乎无法识别"升级为"100%自动识别并定位到具体集"。
|
||||
|
||||
**场景6：可信播放数据与自动分账结算（利益核心）**
|
||||
内容在多个运营商分发播出 → 各运营商以MA码为唯一维度上报播放数据 → 可信数据空间链上聚合，形成不可篡改的可信播放量 → 作为CP与运营商分账结算的统一依据 → 对账差异从15-30%降至5%以内，回款争议大幅减少。
|
||||
内容在多个运营商分发播出 → 各运营商以CC码为唯一维度上报播放数据 → 可信数据空间链上聚合，形成不可篡改的可信播放量 → 作为CP与运营商分账结算的统一依据 → 对账差异从15-30%降至5%以内，回款争议大幅减少。
|
||||
> 痛点解法：解决CP与运营商"播放量各执一词、分账扯皮、回款慢"的真金白银痛点。
|
||||
|
||||
**场景7：违规责任精准界定与追责（权责对等）**
|
||||
出现违规内容需追责 → 监管按MA码调取全链路哈希存证 → 逐环节比对（CP送审哈希 / CSPS审核结论 / 转码版哈希 / 媒资库发布哈希 / 运营商注入哈希 / 终端抽检哈希）→ 精准定位"问题出在哪个环节、是哪一方改动" → 责任落到具体方与具体节点。
|
||||
出现违规内容需追责 → 监管按CC码调取全链路哈希存证 → 逐环节比对（CP送审哈希 / CSPS审核结论 / 转码版哈希 / 媒资库发布哈希 / 运营商注入哈希 / 终端抽检哈希）→ 精准定位"问题出在哪个环节、是哪一方改动" → 责任落到具体方与具体节点。
|
||||
> 痛点解法：终结CP、审核监管、运营商三方"互相甩锅"，实现权责对等、有据可查。
|
||||
|
||||
**场景8：版权确权与维权举证（权利保护）**
|
||||
CP内容被盗版/换皮 → 凭MA码+哈希+上链时间戳形成不可抵赖的"谁先锁定谁有权"证据链 → 可直接用于侵权投诉与司法诉讼举证 → 系统识别盗版内容感知哈希与正版高度相似，辅助锁定侵权。
|
||||
CP内容被盗版/换皮 → 凭CC码+哈希+上链时间戳形成不可抵赖的"谁先锁定谁有权"证据链 → 可直接用于侵权投诉与司法诉讼举证 → 系统识别盗版内容感知哈希与正版高度相似，辅助锁定侵权。
|
||||
> 痛点解法：解决CP"被盗用拿不出有法律效力证据"的确权维权痛点。
|
||||
|
||||
**场景9：追更与增量更新（效率提升）**
|
||||
@@ -135,7 +135,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ ① CP工作域 ② 审核监管域 ③ 运营商域 │
|
||||
│ 哈希生成SDK 验真+CSPS对接 CDN注入校验 │
|
||||
│ 送审申报 MA码签发引擎 终端抽检SDK │
|
||||
│ 送审申报 CC码签发引擎 终端抽检SDK │
|
||||
│ 媒资库映射 数据上报 │
|
||||
│ 监管大屏+应急下架 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
@@ -150,7 +150,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
|------|------|--------|--------|---------|
|
||||
| F01 | 母版多维哈希生成SDK（文件/分段Merkle/感知） | CP工作域 | Must | 需求1 |
|
||||
| F02 | 送审申报与哈希上链 | CP工作域 | Must | 需求2 |
|
||||
| F03 | MA码签发与1:1强绑定 | 审核监管域 | Must | 需求3 |
|
||||
| F03 | CC码签发与1:1强绑定 | 审核监管域 | Must | 需求3 |
|
||||
| F04 | 送审文件验真 | 审核监管域 | Must | 需求4 |
|
||||
| F05 | CSPS审核对接与转码版哈希绑定 | 审核监管域 | Must | 需求5 |
|
||||
| F06 | 媒体资源库入库/发布与编码映射 | 审核监管域 | Must | 需求6 |
|
||||
@@ -174,7 +174,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
### 4.3 不在本期范围（Out of Scope）
|
||||
|
||||
- OTT、手机APP等大小屏融合接入（规划至四期，需求19.4 为可扩展性预留）
|
||||
- 内容推荐、计费结算的业务逻辑（系统仅提供以MA码为维度的数据聚合，不做结算）
|
||||
- 内容推荐、计费结算的业务逻辑（系统仅提供以CC码为维度的数据聚合，不做结算）
|
||||
- CSPS审核算法本身的改造（系统仅对接其审核结论，不介入审核规则）
|
||||
|
||||
---
|
||||
@@ -188,29 +188,29 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
→ 哈希SDK计算哈希包（本地，不传原文件）
|
||||
→ 送审申报（节目信息+哈希包）→ 获送审流水号
|
||||
│
|
||||
[审核监管] MA码签发引擎 审核通过 → 签发MA码 + 哈希1:1强绑定上链
|
||||
→ CP获"MA码+哈希证书"
|
||||
[审核监管] CC码签发引擎 审核通过 → 签发CC码 + 哈希1:1强绑定上链
|
||||
→ CP获"CC码+哈希证书"
|
||||
│
|
||||
[审核监管] 送审文件验真（哈希比对）
|
||||
→ 匹配 → 进入CSPS合规审核
|
||||
→ 转码 → 各版本哈希绑定（父子关系）
|
||||
→ 合格内容入媒体资源库（建立 媒资编码↔MA码↔哈希 映射）
|
||||
→ 合格内容入媒体资源库（建立 媒资编码↔CC码↔哈希 映射）
|
||||
│
|
||||
[审核监管→运营商] 从媒体资源库发布（携带MA码+哈希证书）
|
||||
[审核监管→运营商] 从媒体资源库发布（携带CC码+哈希证书）
|
||||
│
|
||||
[运营商] CDN注入校验（哈希比对）
|
||||
→ 匹配 → 注入CDN + 生成分发编码 + 注册映射
|
||||
→ EPG发布 → 用户点播
|
||||
→ （可选）终端片段哈希抽检
|
||||
│
|
||||
[运营商] 以MA码为维度上报播放数据 → 可信空间统一聚合
|
||||
[运营商] 以CC码为维度上报播放数据 → 可信空间统一聚合
|
||||
```
|
||||
|
||||
### 5.2 应急下架流程（逆向）
|
||||
|
||||
```
|
||||
[审核监管-监管主体] 下发"下架 MA码第XXX号"
|
||||
→ 可信空间解析MA码 → 查出全部三方编码+CDN端点
|
||||
[审核监管-监管主体] 下发"下架 CC码第XXX号"
|
||||
→ 可信空间解析CC码 → 查出全部三方编码+CDN端点
|
||||
→ 自动翻译为：
|
||||
· 媒体资源库：撤除发布
|
||||
· 运营商：下架分发编码YYY + CDN资源ZZZ
|
||||
@@ -225,7 +225,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
| CDN注入 | 哈希不匹配 | 拒绝注入，告警审核监管部门，暂停分发 |
|
||||
| 终端抽检 | 哈希不匹配 | 断流，切备用源，上报异常日志 |
|
||||
| 内容变更 | 哈希变化 | 绑定断裂，reaudit_required=true，触发重审 |
|
||||
| 换壳重发 | 哈希已存在 | 拒绝重复申报，关联原MA码 |
|
||||
| 换壳重发 | 哈希已存在 | 拒绝重复申报，关联原CC码 |
|
||||
|
||||
---
|
||||
|
||||
@@ -233,7 +233,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
|
||||
| 操作 | 内容提供商 | 审核和监管部门 | 运营商 |
|
||||
|------|:---------:|:-------------:|:------:|
|
||||
| 签发MA码 | ✗ | ✅（仅监管主体） | ✗ |
|
||||
| 签发CC码 | ✗ | ✅（仅监管主体） | ✗ |
|
||||
| 注册哈希 | ✅（送审时） | ✅ | ✗ |
|
||||
| 验真查询 | ✅（自查） | ✅ | ✅ |
|
||||
| 映射管理 | ✅（本方） | ✅ | ✅（本方） |
|
||||
@@ -257,10 +257,10 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
|
||||
### MVP 验收标准
|
||||
|
||||
- CP可完成哈希生成→送审→获MA码全流程
|
||||
- CP可完成哈希生成→送审→获CC码全流程
|
||||
- 审核监管部门可完成验真→CSPS审核对接→媒资库入库→发布
|
||||
- 运营商可完成CDN注入校验→分发
|
||||
- 监管可完成按MA码查询全链路 + 一键应急下架（秒级生效）
|
||||
- 监管可完成按CC码查询全链路 + 一键应急下架（秒级生效）
|
||||
- 版本篡改可被100%识别并阻断
|
||||
|
||||
---
|
||||
@@ -271,7 +271,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
|------|------|
|
||||
| 性能 | 下架响应分钟级；哈希验真接口实时返回 |
|
||||
| 兼容性 | 不改造CSPS、媒体资源库内部流程，仅通过映射层对接；保留三方自有编码 |
|
||||
| 安全 | MA码+哈希绑定不可篡改不可解绑；哈希本地计算不传原文件；关键操作链上存证 |
|
||||
| 安全 | CC码+哈希绑定不可篡改不可解绑；哈希本地计算不传原文件；关键操作链上存证 |
|
||||
| 合规 | 完全符合广电总局网络剧片发行许可及备案制度 |
|
||||
| 可扩展 | 支持网络剧/微短剧/网络电影/网络动画，可扩展至OTT/APP |
|
||||
|
||||
@@ -283,7 +283,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
|------|------|------|
|
||||
| 依赖 | 联盟链/分布式账本基础设施 | 一期完成选型与部署 |
|
||||
| 依赖 | CSPS与媒体资源库开放对接接口 | 提前与审核监管部门确认接口规范 |
|
||||
| 依赖 | 广电总局备案系统对接MA码签发 | 政策与技术双轨推进 |
|
||||
| 依赖 | 广电总局备案系统对接CC码签发 | 政策与技术双轨推进 |
|
||||
| 依赖 | 授权转码中心支持转码后哈希重算上链 | 纳入一期改造范围 |
|
||||
| 风险 | 三方系统改造意愿与排期 | 最小侵入设计 + 试点先行（广东/湖南） |
|
||||
| 风险 | 跨省信任机制的政策落地 | 与监管联合制定跨省复用规则 |
|
||||
@@ -293,7 +293,7 @@ CP上链授权信息（信息网络传播权的地域/期限/平台范围）→
|
||||
## 十、产品价值总结
|
||||
|
||||
> TCS-IPTV 的核心不是让三方放弃自己的系统，而是在三方系统之上建立一层"可信身份映射层"——
|
||||
> 用 **MA码** 解决"是谁"的监管问题，用 **哈希码** 解决"是不是"的技术问题，用 **可信数据空间** 解决"在哪"的溯源问题。
|
||||
> 用 **CC码** 解决"是谁"的监管问题，用 **哈希码** 解决"是不是"的技术问题，用 **可信数据空间** 解决"在哪"的溯源问题。
|
||||
> 三者叠加，IPTV内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。
|
||||
>
|
||||
> 对监管：从"逐层翻译滞后"升级为"一码穿透、秒级响应"。
|
||||
|
||||
Reference in New Issue
Block a user