diff --git a/docs/CC码音视频监管系统-技术方案.md b/docs/CC码音视频监管系统-技术方案.md new file mode 100644 index 0000000..bf8c914 --- /dev/null +++ b/docs/CC码音视频监管系统-技术方案.md @@ -0,0 +1,664 @@ +# 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算法） | — | 广电要求自主可控，需定制标准 | +| 视频水印备选 | Digimarc / 海致BD | 商用 | 快速落地可采购商用方案 | +| 音频水印 | 自研（DSSS+心理声学模型） | — | 抗翻录需定制优化 | +| 音频水印备选 | Fraunhofer AudioMark | 商用 | 成熟商用方案，快速验证 | +| 视频指纹 | 自研（关键帧+深度指纹） | — | 需自建指纹库，不依赖第三方 | +| 视频指纹备选 | 腾讯云/字节火山引擎API | SaaS | 快速验证阶段可调用第三方 | +| 音频指纹 | 自研（频谱图+Constellation Map） | — | 类Shazam算法，技术成熟可自研 | +| 音频指纹备选 | ACRCloud / Audible Magic | SaaS | 成熟商用音频识别服务 | +| 视频处理 | FFmpeg | 6.x+ | 开源标准，转码/裁剪/帧提取 | +| 音频处理 | librosa / torchaudio | 最新版 | Python音频分析标准库 | + +### 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码中心的核心服务基础，音视频监管系统在其之上扩展检测引擎、网络探针、音频监管能力，形成完整闭环。** diff --git a/docs/CC码音视频监管系统方案-业务版.md b/docs/CC码音视频监管系统方案-业务版.md index e8237fd..fda6aed 100644 --- a/docs/CC码音视频监管系统方案-业务版.md +++ b/docs/CC码音视频监管系统方案-业务版.md @@ -196,9 +196,9 @@ CC码虽是强制要求，但平台门禁仍有管不到的地方： |---------|---------|---------|------|------------| | **提取CC码** | 类似扫描身份证 | 视频+音频 | 秒级 | 扛得住压缩、转码、裁剪 | | **视频指纹比对** | 类比人脸识别，即使换了衣服也能认出 | 视频 | 毫秒级 | 扛得住剪辑、加滤镜、去水印 | -| **音频指纹比对** | 类比声纹识别，即使翻录、变速也能认出 | 音频 | 毫秒级 | 扛得住翻录、格式转换、变速、降噪 | +| **音频指纹比对** | 类比声纹识别，翻录后仍能认出 | 音频 | 毫秒级 | 扛得住翻录、格式转换、轻度变速、降噪 | | **AI视频语义理解** | 类比让人看视频说"这跟某某剧是同一部" | 视频 | 分钟级 | 扛得住深度混剪、拼接 | -| **AI音频语义理解** | 类比让人听音频说"这跟某某内容是同一段" | 音频 | 分钟级 | 扛得住语音合成、变速、混音 | +| **AI音频语义理解** | 类比让人听音频说"这跟某某内容是同一段" | 音频 | 分钟级 | 对翻唱、混音的识别能力有限，作为兜底补充 | 检测手段层层递进：第一种认不出来就用第二种，第二种还不行就用第三种。视频和音频检测独立运行，同一内容的视频画面和音频轨道分别检测，任一命中即告警。 @@ -454,7 +454,7 @@ UGC视频上传 | 维度 | 视频指纹 | 音频指纹 | |------|---------|---------| | 识别对象 | 画面内容 | 音频波形特征 | -| 抗干扰能力 | 抗剪辑、加滤镜、去水印 | 抗翻录、格式转换、变速、降噪、混音 | +| 抗干扰能力 | 抗剪辑、加滤镜、去水印 | 抗翻录、格式转换、轻度变速、降噪；翻唱和深度混音需AI语义辅助 | | 比对速度 | 毫秒级 | 毫秒级 | | 独立性 | 依赖画面 | 不依赖画面，纯音频即可识别 | | 适用场景 | 视频平台、短视频平台 | 音频平台、音乐平台、播客平台、视频提取音频 | @@ -498,12 +498,12 @@ UGC视频上传 |------|------| | **不可听** | 嵌入在音频信号中，人耳听不到，不影响收听体验 | | **抗压缩** | 经过MP3/AAC等有损压缩后仍可提取 | -| **抗翻录** | 经过扬声器播放→麦克风翻录后仍可部分提取 | -| **抗变速** | 变速播放（0.8x~1.5x）后仍可识别 | -| **抗降噪** | 经过降噪处理后仍可提取 | +| **抗翻录** | 在安静环境、高质量设备翻录后可部分提取；嘈杂环境或手机录音条件下提取率显著下降，此时主要依赖音频指纹兜底 | +| **抗变速** | 小范围变速（0.9x~1.1x）后仍可识别；大范围变速提取率下降，需音频指纹辅助 | +| **抗降噪** | 经过常规降噪处理后仍可提取 | | **多段冗余** | 水印重复嵌入在音频多个时段中，部分丢失不影响提取 | -> 音频水印是音频内容监管的技术基础。音频翻录门槛低、传播渠道隐蔽，音频水印+音频指纹双重保障，确保即使翻录、变速、格式转换后仍可追溯来源。广电总局应制定音频水印嵌入标准，与视频水印标准统一规划。 +> 音频水印是音频内容追溯的重要技术手段，但在抗翻录方面存在客观局限。实际应用中，**音频指纹是音频内容识别的主力技术**（成熟度类似Shazam），音频水印作为补充追溯手段。两者双重保障，音频指纹负责"认出是什么内容"，音频水印负责"追溯是谁的、从哪来的"。广电总局应制定音频水印嵌入标准，与视频水印标准统一规划。 ### 6.5 音频直播与广播监管