freedakgmail
779 lines
35 KiB
Markdown
779 lines
35 KiB
Markdown
# 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 水印提取算法
|
||
|
||
```python
|
||
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 内容指纹匹配
|
||
|
||
```python
|
||
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 证据固化
|
||
|
||
```json
|
||
{
|
||
"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封锁兜底 |
|
||
| 误判率过高 | 正常内容被拦截 | 人工审核兜底 + 阈值可调 + 申诉通道 |
|
||
| 资源成本超预算 | 系统无法全量运行 | 分阶段建设 + 智能调度降本 |
|