freedak/MAcode

Fork 0

Files

T

freedakgmail 807acd9780 docs: 补充自研开源参考项目和论文，修正水印选型为国产/自研方案确保数据安全

2026-07-21 21:32:16 +08:00

33 KiB

Raw Permalink Blame History

CC码音视频监管系统——可落地技术方案

基于业务版方案的技术实现规划编制日期：2026年7月

一、技术架构总览

1.1 架构原则

原则	说明
复用现有基础	在TCS-IPTV系统（Go+Gin+PostgreSQL）上扩展，不推倒重来
云原生	Kubernetes容器化部署，微服务架构，支持水平扩展
等保三级	所有组件部署于广电云等保三级VPC内
音视频统一	视频和音频共用CC码体系、共用API网关、共用监管架构
分层解耦	API网关层、业务服务层、检测引擎层、存储层独立部署、独立扩缩

1.2 服务拆分

服务名	语言	职责	部署形态
api-gateway	Go	统一API网关，鉴权、限流、路由	K8s Deployment, 3副本
cc-code-svc	Go	CC码生成、签发、生命周期管理、码段分配	K8s Deployment, 3副本
verify-svc	Go	CC码验证、状态查询、哈希校验	K8s Deployment, 5副本
ugc-code-svc	Go	UGC批量赋码、码段管理、批量回传	K8s Deployment, 3副本
takedown-svc	Go	秒级下架指令分发、全网同步、下架验证	K8s Deployment, 3副本
appeal-svc	Go	申诉接收、审核流转、恢复指令	K8s Deployment, 2副本
probe-crawler	Python	网络探针爬虫集群，音视频内容采集	K8s Deployment, 10~50副本
probe-detector	Python	水印提取、指纹比对、AI语义分析	K8s Deployment + GPU节点
fingerprint-svc	Python	视频/音频指纹提取与入库	K8s Deployment + GPU节点
watermark-svc	Rust/Go	视频水印嵌入/提取、音频水印嵌入/提取	K8s Deployment, 3副本
live-monitor	Go+Python	直播/广播实时录制、切片检测、断流指令	K8s Deployment, 5副本
admin-frontend	React	监管后台、运营管理、数据大屏	Nginx静态部署

二、技术栈选型

2.1 后端服务层

组件	选型	版本	选型理由
核心语言	Go	1.22+	高并发、低延迟，已有TCS-IPTV代码基础
Web框架	Gin	1.10+	轻量高性能，已有代码基础
ORM	GORM	2.0+	Go生态最成熟ORM，已有代码基础
API网关	Kong	3.x	开源成熟，插件丰富（JWT/限流/日志）
服务间通信	gRPC	—	内部服务高性能RPC，Protobuf契约
依赖注入	Wire	—	Go编译时依赖注入，类型安全

2.2 检测引擎层

组件	选型	版本	选型理由
检测服务语言	Python	3.11+	AI/媒体处理生态最丰富
检测服务框架	FastAPI	0.110+	异步高性能，自动生成API文档
任务调度	Celery + Redis	最新版	异步任务队列，支持GPU任务排队
GPU推理框架	NVIDIA Triton	2.x	多模型并行、动态批处理
深度学习框架	PyTorch	2.x	模型训练与推理

2.3 媒体处理层

组件	选型	版本	选型理由
视频水印	自研（DCT+QIM算法）	—	广电要求自主可控，需定制标准
视频水印备选	海致BD / 数字水印国产方案	商用	国产商用方案，自主可控，快速落地可采购
音频水印	自研（DSSS+心理声学模型）	—	抗翻录需定制优化
音频水印备选	自研（开源算法改进）	—	基于开源音频水印算法改进，避免闭源外国SDK的数据安全风险
视频指纹	自研（关键帧+深度指纹）	—	需自建指纹库，不依赖第三方
视频指纹备选	腾讯云/字节火山引擎API	SaaS	快速验证阶段可调用第三方（数据不出广电云）
音频指纹	自研（频谱图+Constellation Map）	—	类Shazam算法，技术成熟可自研
音频指纹备选	ACRCloud / Audible Magic	SaaS	仅用于快速验证，生产环境用自研
视频处理	FFmpeg	6.x+	开源标准，转码/裁剪/帧提取
音频处理	librosa / torchaudio	最新版	Python音频分析标准库

数据安全说明：广电监管系统涉及内容主权，不使用闭源外国商用SDK（如Digimarc、Fraunhofer）。原因：①闭源二进制无法审计后门或遥测；②美国/欧盟出口管制风险；③等保三级审查不通过；④水印格式不透明，广电无法制定自主标准。水印技术采用"自研为主、国产商用为辅"策略。

自研开源参考项目：

技术模块	开源项目	语言	License	说明
视频水印	AlexAgents/VidMark	Python	MIT	DWT-DCT-QIM算法实现，含嵌入/提取完整流程，抗压缩/噪声/滤波
视频水印	fabriziosalmi/open-video-watermark	Python	MIT	DCT频域水印，Flask Web应用+REST API，含Docker部署
视频水印	JumiRay/video-invisible-watermark	Python	MIT	DCT不可见水印，YUV亮度通道嵌入，多帧提取
音频水印	swesterfeld/audiowmark	C++	GPL-3.0	⭐569星，Patchwork算法，1024采样帧FFT，成熟可用
音频水印	dmeldrum6/Audio-Watermarking	JavaScript	—	DSSS+心理声学模型+Bark尺度掩蔽阈值+Reed-Solomon纠错，完整实现
音频水印	corupta/DSSS-watermark	Python	GPL-3.0	DSSS扩频水印Python脚本，含嵌入/检测完整代码
音频水印	Tranquil-Flow/carnation-radio	Rust/TS	—	Masked DSSS+心理声学掩蔽（Painter-Spanias模型），含抗翻录实测数据
音频指纹	rhthm/audio-fingerprint-engine	Python	—	Constellation Map+组合哈希+PostgreSQL，完整Shazam算法实现
音频指纹	inboxpraveen/Audio-Fingerprint	Python	—	生产级，3秒片段识别，SQLite+WAL，含REST API
音频指纹	ankitjosh78/AudioFingerprinting	Python	—	FastAPI+librosa+scipy，含YouTube导入和麦克风实时识别
视频指纹	ResNet50预训练模型 + Milvus向量检索	Python	Apache-2.0	torchvision提供ResNet50，Milvus官方提供Python SDK，工程集成即可

参考论文：

视频水印：Chen & Wornell, "Quantization Index Modulation", IEEE Trans. Info. Theory, 2001

音频水印：Cox et al., "Secure Spread Spectrum Watermarking", 1997；Garcia, "DSSS for Audio", 1999

心理声学模型：Zwicker & Fastl, "Psychoacoustics: Facts and Models", 1999；ISO/IEC 11172-3 (MPEG-1 Audio)

音频指纹：Avery Wang, "An Industrial-Strength Audio Search Engine", ISMIR 2003（Shazam核心论文）

自研难度评估与落地策略：

技术模块	自研难度	预估周期	难点分析	落地策略
视频水印	⭐⭐⭐ 中等	3~6个月	DCT+QIM算法是经典学术成果，论文充分；难点在抗裁剪+抗压缩的鲁棒性调优，需大量对抗测试。1~2个硕博背景算法工程师可完成	先采购国产商用方案快速集成（3个月），同步自研（6个月），自研版成熟后替换
音频水印	⭐⭐⭐⭐ 较难	6~9个月	DSSS扩频+心理声学模型组合复杂；抗翻录是公认难题，需反复实验调参；心理声学模型需音频信号处理专业背景。建议至少1个音频信号处理博士+1个工程师	自研为主，基于开源算法改进。音频水印抗翻录需持续优化，非一次性开发。不使用闭源外国SDK，避免数据安全风险
视频指纹	⭐⭐ 低	2~3个月	ResNet50是现成模型，关键帧提取用FFmpeg；本质是工程集成而非算法创新。难点在指纹库规模扩大后的检索性能优化	直接自研，1个PyTorch工程师即可
音频指纹	⭐⭐ 低	2~3个月	Shazam算法论文公开20年，实现教程众多；librosa已提供FFT和频谱分析工具；算法不复杂，工程化即可	直接自研，1个Python工程师即可

双轨落地路线：

快速落地（3个月内）：
  ├── 视频水印 → 采购国产商用方案集成上线（如海致BD）
  ├── 音频水印 → 基于开源算法改进，自研MVP上线
  ├── 视频指纹 → 自研MVP上线
  └── 音频指纹 → 自研MVP上线

自主可控（6~12个月）：
  ├── 视频水印 → 自研版替换国产商用方案
  └── 音频水印 → 自研版持续优化抗翻录能力

核心结论：指纹技术自研难度低，直接自研；水印技术有一定门槛，采用"先采购国产商用快速落地、同步自研逐步替换"的双轨策略。所有水印技术最终实现自主可控，不依赖闭源外国SDK。

2.4 AI推理层

组件	选型	版本	选型理由
推理服务	NVIDIA Triton	2.x	GPU模型服务化，动态批处理
视频语义理解	CLIP + 时序模型	—	OpenAI CLIP用于视频帧理解
视频语义备选	商汤/百度多模态API	SaaS	快速落地可调用第三方
音频语义理解	Whisper + 音频Embedding	—	语音识别+音频特征提取
模型仓库	MLflow	最新版	模型版本管理、实验追踪
GPU硬件	NVIDIA A10 / A100	—	A10性价比优，A100用于大规模推理

2.5 数据存储层

组件	选型	版本	用途	选型理由
关系型数据库	PostgreSQL	16.x	CC码记录、元数据、码段、申诉	已有代码基础，JSONB灵活schema
数据库高可用	Patroni + etcd	最新版	自动故障切换、读写分离	PG生态标准HA方案
缓存	Redis Cluster	7.x	热点CC码状态缓存、限流、分布式锁	毫秒级状态查询
向量数据库	Milvus	2.x	视频/音频指纹向量相似度检索	亿级指纹检索
时序数据库	ClickHouse	24.x	播放数据、检测日志、运营分析	海量写入、快速聚合
对象存储	MinIO	最新版	视频片段、音频片段、证据包	S3兼容，私有部署
搜索引擎	Elasticsearch	8.x	审核报告检索、日志检索	全文检索标准方案

2.6 消息与异步层

组件	选型	版本	用途
消息队列	Apache Kafka	3.x	下架指令广播、检测任务分发、播放数据回传
流处理	Apache Flink	1.18+	实时播放统计、异常检测、直播流处理
任务队列	Celery + Redis	最新版	异步任务（爬虫调度、通知发送）
定时调度	Airflow	2.x	定时爬虫、存量补码监控、报表生成

2.7 基础设施与DevOps

组件	选型	版本	用途
容器编排	Kubernetes	1.29+	容器编排、自动扩缩容
镜像仓库	Harbor	2.x	私有镜像仓库、安全扫描
密钥管理	HashiCorp Vault	最新版	API Key、数据库密码管理
指标监控	Prometheus + Grafana	最新版	指标采集、告警、可视化
日志采集	Loki + Promtail	最新版	全链路日志聚合
链路追踪	Jaeger / OpenTelemetry	最新版	分布式请求追踪
CI/CD	GitLab CI + ArgoCD	最新版	自动化构建、GitOps持续交付

2.8 前端层

组件	选型	版本	用途
管理后台	React	18.x	监管后台、运营管理
UI组件库	Ant Design	5.x	企业级中后台组件
图表可视化	ECharts	5.x	监管数据可视化
状态管理	Zustand	最新版	轻量全局状态管理

三、核心模块技术实现

3.1 CC码生成与生命周期管理（cc-code-svc）

复用现有：tcs-iptv/internal/cccode 已实现码段分配、序列号生成、PostgreSQL持久化。

需扩展：

功能	实现方案	数据库表
CC码生成	复用现有Generator，扩展音频内容类型	`cc_segments`表扩展category字段
生命周期状态机	状态字段+状态机校验，非法转换返回错误	`cc_records`表增加status字段
状态变更审计	每次变更记录操作人、时间、原因	新增`cc_status_log`表
码段管理	广电分配码段给平台，平台在码段内赋码	`cc_segments`表增加platform_id字段
码段冻结/回收	广电通过API冻结平台码段	`cc_segments`表增加frozen字段

CC码状态机：

pending（审核中）─审核通过→ active（有效）
active ─举报/疑似违规→ paused（暂停）
paused ─核实无违规→ active（恢复）
paused ─确认违规→ taken_down（下架）
active ─授权到期/内容下线→ expired（过期）

关键API：

接口	方法	说明	调用方
`/api/v1/code/apply`	POST	申请CC码	内容制作方/平台
`/api/v1/code/issue`	POST	审核通过后签发	监管方
`/api/v1/code/status`	GET	查询CC码状态	平台（高频调用）
`/api/v1/code/suspend`	POST	暂停CC码	监管方
`/api/v1/code/restore`	POST	恢复CC码	监管方
`/api/v1/code/takedown`	POST	下架CC码	监管方
`/api/v1/code/segment/allocate`	POST	分配码段给平台	监管方
`/api/v1/code/segment/freeze`	POST	冻结平台码段	监管方

3.2 平台门禁验证（verify-svc）

复用现有：tcs-iptv/internal/api/handlers.go 已有 /content/verify、/content/inject 等验证接口。

需扩展：增加音频内容验证、UGC批量验证、直播实时验证。

验证流程：

平台调用API → API网关鉴权 → verify-svc → Redis缓存查询
  ├── 命中缓存 → 直接返回状态（毫秒级）
  └── 未命中 → 查询PostgreSQL → 写入Redis → 返回（秒级）

四关验证API：

关卡	接口	检查内容	响应时间
上传拦截	`POST /api/v1/verify/upload`	CC码是否存在、是否在有效号段内	<100ms
播出校验	`GET /api/v1/verify/playback?cc_code=xxx`	CC码状态是否active	<50ms（缓存）
CDN注入校验	`POST /api/v1/verify/cdn`	文件哈希与登记哈希是否一致	<200ms
终端抽检	`POST /api/v1/verify/terminal`	播放内容哈希与登记哈希抽样比对	<200ms

性能设计：

Redis缓存CC码状态，TTL=10秒，热点码命中率>99%
verify-svc水平扩展，支持10万QPS
API网关限流：单平台默认1万QPS，可按需调整

3.3 秒级下架指令分发（takedown-svc）

复用现有：tcs-iptv 已有 /content/takedown 接口。

需扩展：从单平台下架升级为全网秒级同步下架。

技术实现：

监管方下达下架指令
    │
    ├── takedown-svc接收指令
    │   ├── 查询CC码关联的所有平台、CDN（从PostgreSQL）
    │   ├── 生成各平台的下架指令
    │   └── 写入Kafka topic: takedown.broadcast
    │
    ├── Kafka多分区并行消费
    │   ├── 消费者1 → 通知视频平台A（HTTP回调）
    │   ├── 消费者2 → 通知视频平台B（HTTP回调）
    │   ├── 消费者3 → 通知音频平台A（HTTP回调）
    │   ├── 消费者4 → 通知CDN全网（API调用）
    │   └── 消费者N → ...
    │
    └── 各平台/CDN执行下架 → 回传确认 → takedown-svc记录

关键设计：

设计点	方案
指令分发	Kafka多分区并行，每个平台一个分区，保证并行度
平台回调	HTTP POST回调平台下架API，超时3秒，重试2次
CDN清除	调用CDN API清除缓存+加入黑名单
下架确认	平台执行后回调确认接口，超时未确认自动告警
下架验证	网络探针分钟后验证URL是否仍可访问
指令幂等	指令ID去重，重复指令不重复执行

3.4 UGC批量赋码（ugc-code-svc）

技术实现：

平台获得码段授权
    │
    ├── 平台本地赋码（无需实时联网）
    │   ├── 从分配的码段中取序号
    │   ├── 生成CC码（平台本地完成，毫秒级）
    │   └── 嵌入水印（平台转码环节）
    │
    └── 批量回传CC码中心（异步）
        ├── 平台调用 POST /api/v1/ugc/batch-report
        ├── 请求体：[{cc_code, content_hash, title, uploader_id, timestamp}, ...]
        ├── 单次最多1000条
        └── CC码中心写入PostgreSQL，建立指纹索引

API设计：

接口	方法	说明
`/api/v1/ugc/segment/apply`	POST	平台申请码段
`/api/v1/ugc/batch-report`	POST	批量回传赋码信息
`/api/v1/ugc/batch-verify`	POST	批量验证UGC的CC码

性能设计：

平台本地赋码，零延迟，不影响用户上传体验
批量回传异步进行，5分钟一批，不阻塞业务
批量回传支持10万条/分钟吞吐

3.5 视频水印嵌入与提取（watermark-svc）

技术方案：基于DCT域量化索引调制（QIM）算法。

嵌入流程：

原始视频 → FFmpeg解码 → 分帧 → DCT变换 → QIM嵌入水印信息 → IDCT → 重新编码
                                                          │
                                          水印信息 = CC码(48bit) + 平台代码(16bit) + 时间戳(32bit)

提取流程：

待检测视频 → FFmpeg解码 → 分帧 → DCT变换 → QIM提取水印 → 多帧投票 → 输出CC码

技术参数：

参数	指标	说明
嵌入容量	96bit/帧	CC码48bit + 平台16bit + 时间戳32bit
不可见性	PSNR > 38dB	人眼不可察觉
抗压缩	H.264/H.265压缩后提取率 > 95%	常见转码场景
抗裁剪	画面裁剪50%后提取率 > 80%	多帧冗余保证
嵌入速度	1分钟视频处理 < 10秒	FFmpeg GPU加速
提取速度	1分钟视频处理 < 5秒	关键帧采样提取

实现语言：Rust（性能要求高，FFmpeg绑定成熟）或 Go+CGO（复用FFmpeg C库）。

3.6 音频水印嵌入与提取

技术方案：基于扩频水印（DSSS）+心理声学模型。

嵌入流程：

原始音频 → 分帧 → FFT → 心理声学模型计算掩蔽阈值 → DSSS扩频嵌入 → IFFT → 重编码
                                                    │
                                    水印信息 = CC码(48bit) + 平台代码(16bit) + 时间戳(32bit)

技术参数：

参数	指标	说明
嵌入容量	96bit/10秒	每10秒嵌入一轮完整水印
不可听性	SNR > 20dB	人耳不可察觉
抗压缩	MP3 128kbps后提取率 > 90%	常见音频格式
抗翻录	安静环境翻录提取率 > 70%	嘈杂环境下降明显，依赖音频指纹兜底
抗变速	0.9x~1.1x范围内提取率 > 80%	超出范围依赖音频指纹
嵌入速度	1分钟音频处理 < 5秒
提取速度	1分钟音频处理 < 3秒

关键设计：音频水印作为追溯手段，音频指纹（3.7节）作为主力识别技术。两者独立运行，互为补充。

3.7 视频指纹（fingerprint-svc）

技术方案：关键帧提取 + 深度感知哈希（Deep pHash）。

指纹提取流程：

视频 → FFmpeg关键帧提取（每秒1帧） → ResNet50特征提取 → 降维到256维向量 → 存入Milvus

指纹比对流程：

待检测视频 → 同样提取指纹向量 → Milvus余弦相似度检索 → Top-K结果 → 阈值判断
  ├── 相似度 > 0.85 → 疑似搬运
  ├── 相似度 0.50~0.85 → 疑似二创
  └── 相似度 < 0.50 → 原创内容

技术参数：

参数	指标	说明
指纹维度	256维浮点向量	ResNet50特征降维
提取速度	1分钟视频 < 2秒（GPU）	A10 GPU
比对速度	毫秒级	Milvus HNSW索引
指纹库容量	亿级	Milvus分布式集群
准确率	> 95%（搬运检测）	经转码/加滤镜后仍可识别

3.8 音频指纹

技术方案：基于频谱图的Constellation Map算法（类Shazam）。

指纹提取流程：

音频 → FFT频谱分析 → 提取能量峰值点 → 组合峰值对 → 生成指纹哈希 → 存入Milvus

指纹比对流程：

待检测音频 → 同样提取指纹哈希 → Milvus检索 → 匹配峰值对数量统计 → 阈值判断
  ├── 匹配数 > 阈值高 → 疑似翻录
  ├── 匹配数中等 → 疑似翻唱/改编
  └── 匹配数低 → 原创音频

技术参数：

参数	指标	说明
指纹格式	32bit哈希/峰值对	Constellation Map
提取速度	1分钟音频 < 1秒（CPU）	纯信号处理，无需GPU
比对速度	毫秒级	Milvus HNSW索引
抗翻录	翻录后识别率 > 90%	Shazam级别
抗变速	0.9x~1.1x识别率 > 85%	超出范围需AI语义辅助
抗降噪	常规降噪后识别率 > 90%
翻唱识别	有限（需AI语义辅助）	翻唱改变波形特征，指纹难匹配

3.9 网络探针爬虫集群（probe-crawler）

技术方案：分布式爬虫 + 浏览器自动化。

采集方式	技术实现	部署规模
视频网站巡查	Scrapy + Playwright（浏览器自动化）	10~20副本
音频平台巡查	Scrapy + API抓取	5~10副本
直播/广播录制	FFmpeg拉流录制，按分钟切片	5副本（每副本50路）
音频流监测	FFmpeg拉取音频流 → 切片 → 送检测	5副本

反反爬策略：

策略	说明
代理IP池	商业代理IP服务，轮换IP
User-Agent轮换	随机UA，模拟真实浏览器
请求频率控制	每站点QPS限制，避免触发反爬
浏览器自动化	Playwright渲染JS，绕过简单反爬
群众举报补充	Web举报入口 + API，作为爬虫补充

3.10 直播实时监管（live-monitor）

技术方案：

直播流/广播流 → FFmpeg拉流 → 按分钟切片 → 并行送检
                                        ├── 水印提取（秒级）
                                        ├── 指纹比对（秒级）
                                        └── AI语义分析（分钟级）
                                              │
                                        检测结果 → 正常：继续监控
                                                 → 违规：秒级断流指令

技术参数：

参数	指标	说明
并发监测路数	500路（初期）→ 2000路（目标）	按GPU资源线性扩展
切片间隔	60秒	平衡检测延迟与计算量
检测延迟	水印/指纹 < 10秒，AI语义 < 60秒	切片完成后计时
断流指令	< 1秒	通过API通知平台断流

四、数据库设计

4.1 核心表结构

cc_records（CC码记录表）：

字段	类型	说明
id	BIGSERIAL	主键
cc_code	VARCHAR(64)	CC码，唯一索引
content_type	VARCHAR(16)	video/audio/live_video/live_audio
category	VARCHAR(32)	内容类目（微短剧/网剧/音乐/播客等）
title	VARCHAR(256)	内容标题
file_hash	VARCHAR(64)	文件SHA256哈希
perceptual_hash	VARCHAR(128)	感知哈希（视频/音频指纹摘要）
fingerprint_vector	JSONB	指纹向量（存Milvus的引用ID）
status	VARCHAR(16)	pending/active/paused/taken_down/expired
platform_id	VARCHAR(32)	所属平台
cp_name	VARCHAR(128)	内容制作方
is_ugc	BOOLEAN	是否UGC内容
parent_cc_code	VARCHAR(64)	父CC码（二创/衍生音频关联）
watermark_info	JSONB	水印嵌入信息
created_at	TIMESTAMP	创建时间
updated_at	TIMESTAMP	更新时间

cc_segments（码段表）：

字段	类型	说明
id	BIGSERIAL	主键
segment_prefix	VARCHAR(32)	码段前缀
platform_id	VARCHAR(32)	分配给哪个平台
category	VARCHAR(32)	内容类目
start_seq	BIGINT	起始序号
end_seq	BIGINT	结束序号
current_seq	BIGINT	当前已用序号
frozen	BOOLEAN	是否冻结
allocated_at	TIMESTAMP	分配时间

takedown_orders（下架指令表）：

字段	类型	说明
id	BIGSERIAL	主键
order_id	VARCHAR(64)	指令ID，唯一索引
cc_code	VARCHAR(64)	目标CC码
reason	TEXT	下架原因
issued_by	VARCHAR(64)	下达人
status	VARCHAR(16)	pending/executing/confirmed/failed
targets	JSONB	下架目标列表（平台+CDN）
confirmations	JSONB	各平台确认回执
created_at	TIMESTAMP	下达时间
completed_at	TIMESTAMP	完成时间

appeals（申诉表）：

字段	类型	说明
id	BIGSERIAL	主键
appeal_id	VARCHAR(64)	申诉ID
cc_code	VARCHAR(64)	关联CC码
appellant	VARCHAR(128)	申诉人/平台
reason	TEXT	申诉理由
evidence	JSONB	证据材料
status	VARCHAR(16)	pending/reviewing/approved/rejected
reviewer	VARCHAR(64)	审核人
result	TEXT	审核结论
created_at	TIMESTAMP	申诉时间
resolved_at	TIMESTAMP	结案时间

detection_logs（检测日志表，ClickHouse）：

字段	类型	说明
event_id	UUID	事件ID
cc_code	String	检测到的CC码（如有）
content_url	String	内容URL
detection_method	String	watermark/fingerprint/ai_semantic
result	String	normal/suspected/violation
confidence	Float32	置信度
platform	String	发现平台
detected_at	DateTime	检测时间

4.2 Kafka Topic规划

Topic	分区数	用途	保留期
`topic.code.apply`	6	CC码申请事件	7天
`topic.code.issued`	6	CC码签发事件	30天
`topic.takedown.broadcast`	24	下架指令广播	7天
`topic.takedown.confirm`	6	下架确认回执	30天
`topic.detection.task`	12	检测任务分发	3天
`topic.detection.result`	12	检测结果上报	30天
`topic.ugc.batch-report`	6	UGC批量回传	7天
`topic.playback.event`	24	播放数据回传	3天
`topic.appeal.created`	3	申诉创建	30天
`topic.system.dlq`	3	死信队列	永久

五、部署架构

5.1 Kubernetes集群规划

集群	节点配置	用途
业务集群	6~10台 8C16G	API网关、业务服务、管理后台
检测集群	4~~8台 8C16G + 2~~4台 GPU(A10)	爬虫、检测引擎、指纹提取、AI推理
存储集群	3台 4C8G（PG主从）+ 3台 8C32G（Milvus）+ 3台 4C8G（ClickHouse）	数据库
消息集群	3台 4C8G	Kafka + ZooKeeper

5.2 GPU资源规划

用途	GPU型号	数量	说明
视频指纹提取	A10	2~4张	ResNet50深度模型推理，GPU比CPU快10~50倍
音频指纹提取	无需GPU	—	Constellation Map是纯信号处理（FFT+峰值检测），CPU即可，1分钟音频<1秒
AI视频语义	A10	1~2张	CLIP多模态模型推理，兜底检测
AI音频语义	A10	1张	Whisper语音识别+音频Embedding，兜底检测
水印嵌入/提取	无需GPU	—	DCT/DSSS变换，CPU计算即可

5.3 网络架构

互联网 ←→ 广电云安全网关 ←→ API网关(Kong) ←→ 业务服务集群
                                    │
                                    ├── 检测集群（内网，不对外）
                                    ├── 存储集群（内网）
                                    └── 消息集群（内网）

平台用户 ←→ 互联网 ←→ API网关 ←→ 业务服务
监管人员 ←→ 广电专网 ←→ 管理后台 ←→ 业务服务

六、分阶段实施计划

第一阶段（3个月）：平台门禁上线

交付物	说明
cc-code-svc	CC码生成、签发、状态管理，复用现有TCS-IPTV代码
verify-svc	四关验证API，Redis缓存
takedown-svc	秒级下架指令分发
api-gateway	Kong网关，鉴权限流
平台SDK	Go/Java SDK，分发给试点平台
管理后台	CC码管理、下架操作界面
部署	K8s业务集群 + PG + Redis + Kafka

对接目标：IPTV平台 + 1~2家持证视频平台

第二阶段（6个月）：网络探针MVP + UGC赋码

交付物	说明
ugc-code-svc	UGC批量赋码、码段管理
probe-crawler	爬虫集群，覆盖主流视频+音频平台
probe-detector	水印提取 + 视频指纹比对 + 音频指纹比对
fingerprint-svc	视频指纹提取与入库
watermark-svc	视频水印嵌入/提取
Milvus集群	指纹向量库
检测集群	GPU节点部署

对接目标：短视频平台 + 1~2家音频平台

第三阶段（9个月）：存量补码 + 直播监管 + 音频扩展

交付物	说明
存量补码工具	平台批量补码API + 进度监控
live-monitor	直播/广播实时录制、切片检测、断流
音频watermark-svc	音频水印嵌入/提取
音频fingerprint-svc	音频指纹提取与入库
AI语义检测	CLIP视频语义 + Whisper音频语义
appeal-svc	申诉接收、审核流转

第四阶段（12个月）：全量运行

交付物	说明
全平台对接	全网视频+音频平台完成API对接
存量补码完成	全量存量音视频内容补码
网络探针全量	爬虫覆盖全量平台，日检测量达标
完整监管闭环	告警→下架→验证→申诉全流程
监管大屏	数据可视化、运营报表

第五阶段（15个月）：音频监管优化

交付物	说明
音频指纹库完善	Top10000音乐 + Top5000播客指纹入库
音频水印加固	抗翻录优化、抗变速优化
翻唱/混音检测	AI音频语义模型优化
播客/有声书全量	全量覆盖

第六阶段（18个月）：运营优化

交付物	说明
误判率优化	误判率 < 2%
对抗测试	去水印/翻录/变速对抗测试通过
自动化运营	告警自动处理率 > 80%
性能优化	全链路性能调优

七、关键技术风险与应对

风险	等级	应对方案
音频水印抗翻录不达标	高	自研方案先验证再上线；备选采购Fraunhofer商用方案；音频指纹作为主力兜底
视频指纹库规模过大	中	Milvus分布式集群，按内容类目分Collection，HNSW索引优化
爬虫被反爬阻挡	中	代理IP池+Playwright浏览器自动化+群众举报补充
GPU资源不足	中	分级检测策略，快速筛查用CPU，深度检测才用GPU；按需扩容
平台对接进度滞后	中	SDK简化对接难度，提供Go/Java双语言SDK+完整文档+技术支持
直播检测延迟超标	中	优先用水印/指纹（秒级），AI语义作为后台异步补充
Kafka消息积压	低	Consumer Lag告警+自动扩容消费者副本
PG单点故障	低	Patroni HA方案，一主两从，自动故障切换

八、与现有TCS-IPTV系统的关系

现有模块	复用方式	扩展内容
`internal/cccode`	直接复用码段分配、序列号生成	扩展音频内容类型、码段冻结
`internal/api/handlers.go`	复用验证、下架接口框架	增加音频验证、UGC批量、直播接口
`internal/chain`	复用版权链交互	无需改动
`internal/config`	复用配置管理	增加新服务配置项
`internal/monitor`	复用Prometheus监控	无需改动
`cmd/api-svc/main.go`	复用服务启动框架	拆分为多个独立微服务

核心理念：TCS-IPTV是CC码中心的核心服务基础，音视频监管系统在其之上扩展检测引擎、网络探针、音频监管能力，形成完整闭环。

33 KiB Raw Permalink Blame History Unescape Escape

CC码音视频监管系统——可落地技术方案

一、技术架构总览

1.1 架构原则

1.2 服务拆分

二、技术栈选型

2.1 后端服务层

2.2 检测引擎层

2.3 媒体处理层

2.4 AI推理层

2.5 数据存储层

2.6 消息与异步层

2.7 基础设施与DevOps

2.8 前端层

三、核心模块技术实现

3.1 CC码生成与生命周期管理（cc-code-svc）

3.2 平台门禁验证（verify-svc）

3.3 秒级下架指令分发（takedown-svc）

3.4 UGC批量赋码（ugc-code-svc）

3.5 视频水印嵌入与提取（watermark-svc）

3.6 音频水印嵌入与提取

3.7 视频指纹（fingerprint-svc）

3.8 音频指纹

3.9 网络探针爬虫集群（probe-crawler）

3.10 直播实时监管（live-monitor）

四、数据库设计

4.1 核心表结构

4.2 Kafka Topic规划

五、部署架构

5.1 Kubernetes集群规划

5.2 GPU资源规划

5.3 网络架构

六、分阶段实施计划

第一阶段（3个月）：平台门禁上线

第二阶段（6个月）：网络探针MVP + UGC赋码

第三阶段（9个月）：存量补码 + 直播监管 + 音频扩展

第四阶段（12个月）：全量运行

第五阶段（15个月）：音频监管优化

第六阶段（18个月）：运营优化

七、关键技术风险与应对

八、与现有TCS-IPTV系统的关系

33 KiB

Raw Permalink Blame History