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