freedakgmail
35 KiB
35 KiB
CC码监管最优方案：平台侧API预防（秒级）+ 独立监控兜底（分钟级）
版本：V1.0 编制日期：2026年7月 关联文档：0-req-IPTV.md（TCS-IPTV需求规格）、IPTV系统融合MA码方案介绍.md
一、方案总览
1.1 设计目标
| 目标 | 指标 |
|---|---|
| 持证平台违规内容 | 秒级拦截（上传/播出环节预防） |
| 已上线违规内容 | 秒级下架（CC码指令全网同步） |
| 不配合平台/UGC | 分钟级发现 + 小时级处置 |
| 境外平台 | 天级封锁（DNS/IP层面） |
| 检测准确率 | 水印提取 ≥95%，指纹匹配 ≥90% |
1.2 双层架构
┌──────────────────────────────────────────────────────────┐
│ 第一层：平台侧预防 │
│ （秒级，主动拦截） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 上传拦截 │ │ 播出校验 │ │ CDN注入 │ │终端抽检 │ │
│ │ (0ms) │ │ (+200ms) │ │ (秒级) │ │(实时) │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────┘ │
│ │ │ │ │ │
│ └────────────┴────────────┴────────────┘ │
│ │ │
│ 监管API网关（统一入口） │
│ CC码验证 · 哈希比对 · 黑名单查询 │
├──────────────────────────────────────────────────────────┤
│ 第二层：独立监控兜底 │
│ （分钟级，被动发现） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 爬虫采集 │ │ 直播旁路 │ │ 水印提取 │ │指纹比对 │ │
│ │ (持续) │ │ (实时) │ │ (秒级) │ │(毫秒级) │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────┘ │
│ │ │ │ │ │
│ └────────────┴────────────┴────────────┘ │
│ │ │
│ 告警引擎 → 行政通知 → 证据固化 │
└──────────────────────────────────────────────────────────┘
1.3 两层的关系
| 维度 | 第一层（平台侧预防） | 第二层（独立监控兜底） |
|---|---|---|
| 定位 | 事前预防 + 事中拦截 | 事后发现 + 兜底监管 |
| 时效 | 秒级（0~200ms） | 分钟级（10秒~数小时） |
| 依赖平台配合 | 强依赖 | 不依赖 |
| 覆盖范围 | 持证平台 | 全网 |
| 检测手段 | CC码验证 + 哈希比对 | 水印提取 + 指纹匹配 + AI语义 |
| 执行方式 | 平台自动执行 | 行政通知 + CDN黑名单 |
| 对抗能力 | 平台可绕过（不调API） | 无法绕过（外部独立检测） |
核心原则：第一层是防线，第二层是底线。第一层能拦住的不需要第二层介入；第一层被绕过的由第二层兜底。
二、第一层：平台侧API预防（秒级）
2.1 四道拦截关卡
内容生命周期：
CP制作 → 上传平台 → 平台审核 → 入库 → 发布到CDN → 用户播放
拦截关卡：
┌─ 关卡1：上传拦截 ──┐ ┌─ 关卡2：播出校验 ─┐
│ 上传时验证CC码 │ │ 发布前验证CC码 │
│ 无码→拒绝上传 │ │ 码不合法→拒绝发布│
│ 时延：0ms │ │ 时延：0ms │
└──────────────────┘ └──────────────────┘
│
┌─ 关卡3：CDN注入校验 ─┐ ┌─ 关卡4：终端抽检 ──┐
│ 注入CDN前哈希校验 │ │ 播放时片段哈希抽检│
│ 哈希不匹配→拒绝注入│ │ 不匹配→断流切换 │
│ 时延：秒级 │ │ 时延：实时 │
└──────────────────┘ └──────────────────┘
2.2 关卡1：上传拦截（事前预防，0ms）
场景：用户/CP向平台上传视频时，平台调用监管API验证CC码。
用户上传视频
│
├── 平台提取视频元数据中的CC码
│
├── 调用监管API：POST /api/v1/verify/upload
│ Request:
│ {
│ "cc_code": "MA.156.8531.6101/WD/20260000001",
│ "file_hash": "sha256:abc123...",
│ "perceptual_hash": "phash:def456...",
│ "content_meta": {
│ "title": "xxx",
│ "duration": 3600,
│ "resolution": "1920x1080"
│ }
│ }
│
▼
监管API响应（<100ms）
│
├── { "action": "ALLOW", "cc_code": "valid", "hash_match": true }
│ → 平台允许上传
│
├── { "action": "DENY", "reason": "CC_CODE_NOT_FOUND" }
│ → 平台拒绝上传，提示"内容未取得CC码，请先完成备案"
│
├── { "action": "DENY", "reason": "HASH_MISMATCH" }
│ → 平台拒绝上传，提示"内容哈希与登记不符，疑似版本替换"
│
├── { "action": "DENY", "reason": "CC_CODE_REVOKED" }
│ → 平台拒绝上传，提示"该内容CC码已被吊销"
│
└── { "action": "QUARANTINE", "reason": "CC_CODE_NOT_FOUND", "suggestion": "ENTER_REVIEW" }
→ 平台允许暂存但不可发布，进入人工审核流程
关键设计：
- 平台在上传页面嵌入CC码验证SDK，上传前先验证
- 无CC码的内容不进入可发布状态（暂存区→人工审核→备案→发布）
- 验证API响应时间 <100ms（Redis缓存 + PostgreSQL索引）
2.3 关卡2：播出校验（事中拦截，+200ms）
场景：用户请求播放视频时，平台在返回播放地址前验证CC码状态。
用户点击播放
│
├── 平台向监管API查询CC码实时状态
│ GET /api/v1/verify/playback?cc_code={cc_code}
│
▼
监管API响应（<50ms，Redis缓存）
│
├── { "status": "ACTIVE" }
│ → 正常返回播放地址
│
├── { "status": "SUSPENDED", "action": "BLOCK" }
│ → 返回"该内容已被监管要求下架"
│
└── { "status": "REVOKED", "action": "BLOCK" }
→ 返回"该内容播出许可已被吊销"
关键设计：
- 平台播放器在请求播放地址时同步查询CC码状态
- CC码状态变更（下架/吊销）通过WebSocket实时推送到平台
- 查询走Redis缓存，命中率 >99%，响应 <50ms
- 用户感知延迟 <200ms（含网络往返）
2.4 关卡3：CDN注入校验（已有需求，对应需求7）
场景：运营商向CDN注入内容前，校验哈希。
运营商接收发布内容
│
├── 计算注入文件哈希（SHA-256）
│
├── 调用监管API：POST /api/v1/verify/cdn-inject
│ {
│ "cc_code": "MA.156.8531.6101/WD/20260000001",
│ "file_hash": "sha256:abc123...",
│ "cdn_endpoint": "cdn001.operator.com"
│ }
│
▼
├── 哈希匹配 → 允许注入CDN → 注册分发编码
└── 哈希不匹配 → 拒绝注入 → 告警 → 退回审核部门
2.5 关卡4：终端播放抽检（已有需求，对应需求8）
场景：播放器/机顶盒在播放时抽检片段哈希。
播放器下载片段
│
├── 计算片段哈希
│
├── 与可信数据空间链上哈希比对
│
├── 匹配 → 正常播放
└── 不匹配 → 断流 → 切换备用源 → 上报异常
2.6 应急下架指令链路（秒级全网同步）
场景：监管方下发CC码下架指令，秒级同步到全网。
监管方下发指令："下架 CC码 MA.156.8531.6101/WD/20260000001"
│ ← T0
▼
TCS-IPTV系统解析CC码
│ 查询该CC码绑定的所有：
│ ├── 媒资编码 → 媒体资源库
│ ├── 分发编码 → 各运营商CDN
│ ├── 审核流水号 → CSPS
│ └── 各平台内容ID
│ ← T0+10ms
▼
并行下发执行指令
│
├── → 媒体资源库：撤除发布状态 ← T0+100ms
├── → 运营商A CDN：删除缓存+下线URL ← T0+100ms
├── → 运营商B CDN：删除缓存+下线URL ← T0+100ms
├── → 持证平台A：标记内容下架 ← T0+100ms
├── → 持证平台B：标记内容下架 ← T0+100ms
└── → CDN黑名单推送：全局拦截 ← T0+200ms
│
▼
全网下架完成
← T0+1~3秒（取决于各节点网络延迟）
技术实现：
| 机制 | 说明 | 时延 |
|---|---|---|
| WebSocket长连接 | TCS与各平台/运营商保持长连接，指令实时推送 | 100ms |
| Redis Pub/Sub | CC码状态变更广播到所有订阅节点 | 50ms |
| CDN API对接 | 调用各CDN的Purge API清除缓存 | 200ms~1s |
| 播出校验联动 | 关卡2的播出校验会自动拦截已下架CC码 | 实时 |
| 兜底轮询 | 未保持长连接的节点每5秒轮询CC码状态 | ≤5秒 |
2.7 监管API接口清单
| 接口 | 方法 | 调用方 | 时延要求 | 说明 |
|---|---|---|---|---|
/api/v1/verify/upload |
POST | 平台上传服务 | <100ms | 上传时CC码+哈希验证 |
/api/v1/verify/playback |
GET | 平台播放服务 | <50ms | 播出时CC码状态查询 |
/api/v1/verify/cdn-inject |
POST | 运营商CDN | <200ms | CDN注入哈希校验 |
/api/v1/verify/terminal |
POST | 终端播放器SDK | <100ms | 终端片段哈希抽检 |
/api/v1/takedown/issue |
POST | 监管方 | - | 下发下架指令 |
/api/v1/takedown/status |
GET | 各执行方 | <50ms | 查询下架执行状态 |
/api/v1/cc-code/lookup |
GET | 各方 | <50ms | CC码信息查询 |
/api/v1/blacklist/push |
POST | 监管方→CDN | - | 推送CDN黑名单 |
ws:/api/v1/events |
WS | 各平台/运营商 | 实时 | CC码状态变更实时推送 |
三、第二层：独立监控兜底（分钟级）
3.1 适用场景
第二层在以下场景触发：
| 场景 | 第一层状态 | 第二层动作 |
|---|---|---|
| 持证平台绕过API直接上传 | 关卡1被绕过 | 爬虫发现 → 水印/指纹检测 → 告警 |
| 平台未对接监管API | 第一层缺失 | 爬虫发现 → 检测 → 行政通知 |
| UGC二次创作传播 | 不经过上传校验 | 爬虫发现 → 指纹匹配 → 告警 |
| 境外平台传播 | 无法要求配合 | 爬虫发现 → 检测 → DNS封锁 |
| 直播违规内容 | 播出校验未覆盖 | 旁路录制 → 实时检测 → 告警 |
| 水印被恶意去除 | 所有关卡失效 | 指纹匹配 + AI语义 → 告警 |
3.2 采集层
3.2.1 爬虫采集
┌─────────────────────────────────────────┐
│ 爬虫任务调度中心 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 站点配置表 │ │ 任务队列 │ │
│ │ (Redis) │ │ (Kafka) │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │
│ ┌──────┴────────────────┴──────┐ │
│ │ 爬虫Worker集群 │ │
│ │ (Playwright无头浏览器) │ │
│ │ │ │
│ │ ├── 页面渲染 + JS执行 │ │
│ │ ├── 视频地址嗅探 │ │
│ │ │ (拦截m3u8/mp4/flv请求) │ │
│ │ ├── 反爬处理 │ │
│ │ │ (UA轮换/代理池/限速) │ │
│ │ └── 去重过滤 │ │
│ │ (URL指纹 + 内容指纹) │ │
│ └──────────┬────────────────────┘ │
│ │ │
│ ▼ │
│ 输出: {url, title, platform, stream_url, │
│ duration, upload_time, uploader} │
│ → Kafka topic: raw-video-tasks │
└─────────────────────────────────────────┘
站点分级策略：
| 级别 | 站点类型 | 轮巡频率 | 并发数 | 示例 |
|---|---|---|---|---|
| P0 | 头部视频平台 | 5分钟 | 20 | 爱奇艺/腾讯/优酷/B站 |
| P1 | 中型平台 | 30分钟 | 10 | 芒果/搜狐/西瓜视频 |
| P2 | 短视频平台 | 15分钟 | 15 | 抖音/快手/小红书 |
| P3 | 长尾站点 | 2小时 | 5 | 各类小视频站/论坛 |
| P4 | 境外平台 | 1小时 | 5 | YouTube等（通过代理） |
3.2.2 直播旁路录制
┌─────────────────────────────────────────┐
│ 直播旁路录制引擎 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 频道配置表 │ │ 录制Worker │ │
│ │ │ │ (FFmpeg) │ │
│ │ 卫星频道 │→ │ │ │
│ │ 有线频道 │→ │ ffmpeg -i │ │
│ │ 网络直播 │→ │ {url} │ │
│ │ │ │ -c copy │ │
│ │ │ │ -f segment│ │
│ │ │ │ -seg_time │ │
│ │ │ │ 300 │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ 切片输出 │
│ (每5分钟一个mp4) │
│ │ │
│ ▼ │
│ Kafka topic: live-tasks │
└─────────────────────────────────────────┘
3.3 检测层
3.3.1 三级检测流水线
输入视频
│
├─────────────────────────────────────────────┐
▼ ▼
路径A：快速检测（CPU，毫秒级） 路径B：深度检测（GPU，秒级）
│ │
├── 第1步：元数据提取 ├── 第2步：水印提取
│ ffprobe提取CC码元数据 │ DCT频域水印提取
│ (moov box / EXT-X-CC-CODE) │ 多帧冗余提取 + 多数投票
│ 时延：100ms │ 时延：2~5秒/30秒片段
│ │
├── 找到CC码？ ├── 找到CC码？
│ ├── 是 → 验证码合法性 → 判定 │ ├── 是 → 验证 → 判定
│ └── 否 → 进入路径B │ └── 否 → 进入第3步
│ │
│ ├── 第3步：内容指纹匹配
│ │ pHash + DTW时序对齐
│ │ 时延：50ms
│ │
│ ├── 指纹匹配？
│ │ ├── 是 → 关联CC码 → 判定
│ │ └── 否 → 进入第4步
│ │
│ └── 第4步：AI语义匹配（兜底）
│ CLIP特征 + 向量检索
│ 时延：30秒/分钟视频
│
▼ ▼
决策层（合并A/B路径结果）
3.3.2 水印提取算法
class WatermarkExtractor:
"""
DCT频域水印提取器
嵌入位置：8x8 DCT块的中频系数
嵌入方式：QIM (Quantization Index Modulation)
冗余度：同一CC码在视频中重复嵌入，每30帧一个嵌入周期
"""
def __init__(self, secret_key: bytes):
self.key = secret_key # 监管方持有的水印密钥
self.block_size = 8
self.sample_interval = 30 # 每30帧采样
self.embed_positions = self._derive_positions() # 密钥派生嵌入位置
def extract(self, video_path: str) -> Optional[str]:
# 1. 解码为YUV帧序列
frames = self._decode_video(video_path)
# 2. 采样帧
sampled = frames[::self.sample_interval]
# 3. 逐帧提取水印比特
bit_accumulator = defaultdict(list)
for frame in sampled:
y_channel = frame[:, :, 0] # 亮度通道
# 分块DCT
for block in self._split_blocks(y_channel):
dct_block = cv2.dct(block.astype(np.float32))
# 从中频系数提取比特
for pos in self.embed_positions:
bit = self._extract_bit_qim(dct_block[pos[0], pos[1]])
bit_accumulator[pos].append(bit)
# 4. 多数投票解码
raw_bits = self._majority_vote(bit_accumulator)
# 5. ECC纠错解码
decoded = self._ecc_decode(raw_bits)
# 6. CRC校验
if not self._crc_check(decoded):
return None # 水印损坏或不存在
# 7. HMAC验证
cc_code = self._parse_cc_code(decoded)
if not self._hmac_verify(cc_code, self.key):
return None # 伪造水印
return cc_code
3.3.3 内容指纹匹配
class VideoFingerprintMatcher:
"""
视频内容指纹匹配器
指纹：关键帧pHash序列
匹配：汉明距离初筛 + DTW时序对齐
"""
def fingerprint(self, video_path: str) -> dict:
# 1. 降采样
frames = self._decode_downsample(video_path, size=(64, 64), gray=True)
# 2. 关键帧检测（场景切换点）
keyframe_indices = self._detect_keyframes(frames)
# 3. 计算关键帧pHash
keyframe_hashes = []
for idx in keyframe_indices:
phash = self._compute_phash(frames[idx])
keyframe_hashes.append(phash)
# 4. 计算视频级聚合哈希
avg_hash = self._compute_avg_hash(frames)
return {
'keyframe_hashes': keyframe_hashes,
'avg_hash': avg_hash,
'duration': self._get_duration(video_path),
'keyframe_count': len(keyframe_hashes)
}
def match(self, video_fp: dict, database) -> Optional[dict]:
# 1. avg_hash初筛（汉明距离<12）
candidates = database.search_by_avg_hash(
video_fp['avg_hash'],
hamming_threshold=12
)
if not candidates:
return None
# 2. 关键帧序列DTW对齐
best_match = None
best_score = 0
for candidate in candidates:
score = self._dtw_align(
video_fp['keyframe_hashes'],
candidate['keyframe_hashes']
)
if score > best_score:
best_score = score
best_match = candidate
# 3. 阈值判定
if best_score > 0.85:
return {
'cc_code': best_match['cc_code'],
'similarity': best_score,
'matched_title': best_match['title']
}
return None
3.4 决策与告警层
3.4.1 决策矩阵
| 检测路径 | 结果 | 判定 | 动作 | 时效 |
|---|---|---|---|---|
| 元数据 | CC码合法 | 正版传播 | 记录备案 | 秒级 |
| 元数据 | CC码不合法 | 伪造/篡改 | 告警+取证 | 秒级 |
| 水印 | CC码合法 | 正版传播 | 记录备案 | 秒级 |
| 水印 | CC码不合法 | 伪造CC码 | 告警+取证+行政通知 | 秒级 |
| 水印 | 无水印 | 疑似未登记 | 进入指纹匹配 | 秒级 |
| 指纹 | 匹配已登记CC码 | 疑似去水印传播 | 告警+取证+行政通知 | 毫秒级 |
| 指纹 | 未匹配 | 进入AI匹配 | - | 毫秒级 |
| AI语义 | 匹配 | 疑似深度篡改/混剪 | 告警+人工审核 | 分钟级 |
| AI语义 | 未匹配 | 未登记内容 | 进入备案审核流程 | 分钟级 |
3.4.2 告警分级
| 级别 | 判定 | 通知方式 | 响应时效 |
|---|---|---|---|
| P0-紧急 | 伪造CC码 + 大规模传播 | 电话+短信+API推送 | 立即 |
| P1-高危 | 去水印传播 + 已登记内容 | 短信+API推送 | 5分钟内 |
| P2-中危 | 未登记内容 + 疑似违规 | API推送+邮件 | 30分钟内 |
| P3-低危 | 未登记内容 + 无明显违规 | 邮件+日报 | 24小时内 |
3.4.3 证据固化
{
"alert_id": "ALT-20260720-001234",
"level": "P1",
"timestamp": "2026-07-20T20:15:00Z",
"source": {
"type": "web_crawler",
"platform": "example.com",
"url": "https://example.com/video/12345",
"crawler_node": "crawler-03"
},
"video_info": {
"title": "xxx",
"duration": 3600,
"resolution": "1920x1080",
"format": "mp4"
},
"detection_result": {
"metadata_cc_code": null,
"watermark_cc_code": null,
"fingerprint_match": {
"matched": true,
"cc_code": "MA.156.8531.6101/WD/20260000001",
"similarity": 0.92,
"matched_title": "原始登记标题"
},
"ai_match": "skipped"
},
"verdict": "SUSPECTED_WATERMARK_REMOVAL",
"evidence": {
"video_clip": "/evidence/ALT-20260720-001234/clip.mp4",
"screenshot": "/evidence/ALT-20260720-001234/screenshot.jpg",
"fingerprint_diff": "/evidence/ALT-20260720-001234/diff.json",
"detection_log": "/evidence/ALT-20260720-001234/log.txt"
},
"actions": [
{ "action": "notify_platform", "status": "sent", "timestamp": "..." },
{ "action": "notify_regulator", "status": "sent", "timestamp": "..." },
{ "action": "preserve_evidence", "status": "done", "timestamp": "..." }
]
}
四、两层协同机制
4.1 正常流程（第一层生效）
CP上传内容 → 关卡1验证CC码 → 通过 → 平台审核 → 关卡2播出校验 → CDN注入校验 → 用户播放
↓
终端抽检（关卡4）
↓
一切正常，无需第二层介入
4.2 绕过场景（第二层兜底）
场景A：平台未对接API
内容上传 → 平台未验证CC码 → 内容上线
↓
第二层爬虫发现 → 检测 → 告警 → 行政通知平台下架
场景B：持证平台绕过API
内容上传 → 平台跳过CC码验证 → 内容上线
↓
第二层爬虫发现 → 检测 → 告警 → 追责平台
场景C：UGC二次创作
用户剪辑正版内容 → 上传到短视频平台 → 内容上线
↓
第二层爬虫发现 → 指纹匹配 → 判定是否侵权
场景D：水印被去除
内容被去水印处理 → 上传 → 平台无法验证CC码
↓
第二层爬虫发现 → 指纹匹配 → 告警
4.3 下架指令协同
监管方下发下架指令
│
├── 第一层：秒级同步
│ ├── WebSocket推送 → 持证平台自动下架（秒级）
│ ├── CDN Purge API → CDN缓存清除（秒级）
│ ├── Redis状态更新 → 播出校验自动拦截（实时）
│ └── CDN黑名单推送 → 全局URL拦截（秒级）
│
└── 第二层：验证下架效果
├── 爬虫轮巡目标URL → 确认是否已下架
├── 已下架 → 记录确认
├── 未下架 → 升级告警（平台未执行指令）
└── 持续监控 → 防止重新上架
4.4 数据回流
第二层检测发现的内容
│
├── 已登记CC码但未在平台备案 → 回流到TCS-IPTV → 补登记
├── 未登记内容 → 进入备案审核流程 → 补发CC码
├── 伪造CC码 → 回流到TCS → 标记伪造 → 追查来源
└── 去水印传播 → 回流到TCS → 记录侵权证据 → 追责
五、技术架构
5.1 系统部署架构
┌─────────────────────────────────────────────────────────────┐
│ TCS-IPTV 核心（已有） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ 标识服务 │ │ 验真服务 │ │ MA管理 │ │ 可信数据空间│ │
│ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 监管API网关（第一层） │ │
│ │ /verify/upload /verify/playback /verify/cdn-inject │ │
│ │ /takedown/issue /blacklist/push ws:/events │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 独立监控系统（第二层，新增） │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 爬虫集群 │ │ 录制引擎 │ │ 检测集群 │ │ │
│ │ │ (K8s) │ │ (K8s) │ │ (GPU K8s)│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 告警引擎 │ │ 证据存储 │ │ 下架验证 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 基础设施层 │ │
│ │ │ │
│ │ PostgreSQL │ Redis │ Kafka │ Elasticsearch │ │
│ │ Milvus(向量) │ MinIO(视频/证据) │ K8s集群 │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
5.2 第一层资源需求（增量）
| 组件 | 规格 | 数量 | 说明 |
|---|---|---|---|
| API网关 | 4核8GB | 3节点 | 高可用，负载均衡 |
| Redis | 8核32GB | 3节点 | CC码状态缓存，主从+哨兵 |
| WebSocket推送 | 2核4GB | 2节点 | 长连接管理 |
| 合计 | ~20核/40GB增量 |
第一层资源需求很小，因为验证逻辑轻量，主要依赖已有的TCS-IPTV核心系统。
5.3 第二层资源需求（分阶段）
| 阶段 | GPU | CPU | 内存 | 存储 | 带宽 | 月成本 |
|---|---|---|---|---|---|---|
| MVP | 0 | 64核 | 128GB | 20TB | 200Mbps | ¥2~3万 |
| 中等 | 10×T4 | 128核 | 256GB | 50TB | 500Mbps | ¥6~8万 |
| 全量 | 30×T4 | 256核 | 512GB | 150TB | 1Gbps | ¥12~15万 |
第二层通过智能调度（粗筛先行、夜间批量、弹性伸缩）可降低40%资源消耗。
六、分阶段实施计划
第一阶段：平台侧API预防（对已有TCS-IPTV扩展）
| 任务 | 周期 | 依赖 |
|---|---|---|
| 监管API网关开发 | 4周 | TCS-IPTV核心 |
| 上传验证接口 | 2周 | API网关 |
| 播出校验接口 | 2周 | API网关 |
| WebSocket实时推送 | 2周 | API网关 |
| 应急下架指令链路 | 3周 | WebSocket + CDN API |
| 平台对接（1~2家试点） | 4周 | 接口就绪 |
| 小计 | ~12周 |
第二阶段：独立监控MVP
| 任务 | 周期 | 依赖 |
|---|---|---|
| 爬虫采集管线 | 4周 | K8s + Kafka |
| 水印嵌入/提取原型 | 6周 | 水印算法选型 |
| 指纹匹配引擎 | 3周 | Milvus部署 |
| 检测流水线编排 | 2周 | 爬虫 + 水印 + 指纹 |
| 告警+证据固化 | 2周 | 检测流水线 |
| 小计 | ~12周 |
第三阶段：检测规模化
| 任务 | 周期 | 依赖 |
|---|---|---|
| GPU集群部署 | 2周 | MVP验证通过 |
| 直播旁路录制 | 3周 | FFmpeg + K8s |
| AI语义匹配 | 4周 | CLIP模型 + Milvus |
| 对抗加固测试 | 4周 | 全检测链路 |
| 下架验证回路 | 2周 | 第一层 + 第二层 |
| 小计 | ~12周 |
第四阶段：全量上线
| 任务 | 周期 | 依赖 |
|---|---|---|
| 全平台对接推广 | 8周 | 行政要求下发 |
| 弹性伸缩调优 | 2周 | 全量负载 |
| 监管大屏集成 | 3周 | 已有需求10 |
| 运营体系建设 | 4周 | 全系统 |
| 小计 | ~12周 |
总周期约12个月，第一层可在3个月内上线，第二层MVP在6个月内跑通。
七、与已有TCS-IPTV需求的对应关系
| 已有需求 | 本方案对应模块 | 增强点 |
|---|---|---|
| 需求3：CC码生成签发 | 第一层验证基础 | CC码作为验证主键 |
| 需求4：送审文件验真 | 第一层关卡1（上传拦截） | 从送审扩展到平台上传 |
| 需求7：CDN注入校验 | 第一层关卡3 | 已有，无需改动 |
| 需求8：终端播放抽检 | 第一层关卡4 | 已有，无需改动 |
| 需求11：违规应急下架 | 第一层下架指令链路 | 增加WebSocket实时推送+CDN黑名单 |
| 需求10：全生命周期监管 | 第二层独立监控 | 新增外部监控维度 |
| 需求9：统一维度数据上报 | 第二层数据回流 | 检测数据回流到TCS |
八、关键风险与应对
| 风险 | 影响 | 应对 |
|---|---|---|
| 持证平台不配合对接API | 第一层失效 | 行政强制要求 + 第二层兜底 |
| 水印被AI去除 | 第二层检测失效 | 多算法混合嵌入 + 指纹匹配兜底 + AI语义兜底 |
| 爬虫被反爬阻挡 | 第二层采集缺失 | 代理池 + 多策略 + 举报通道补充 |
| CDN厂商不配合黑名单 | 下架不彻底 | 行政处罚 + DNS封锁兜底 |
| 误判率过高 | 正常内容被拦截 | 人工审核兜底 + 阈值可调 + 申诉通道 |
| 资源成本超预算 | 系统无法全量运行 | 分阶段建设 + 智能调度降本 |