MAcode/docs/IPTV.md

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 可信数据空间核心表结构

// 内容主表（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端集成）

# 伪代码示例
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风格
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内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。