# CC码视频监管系统方案 > 面向业务管理层的方案说明 > 编制日期:2026年7月 --- ## 摘要 CC码(广电内容编码)是广电总局推出的**强制性视频内容标识制度**,要求全网所有视频内容——包括影视剧、综艺、新闻、短视频、UGC用户创作——上线前必须取得CC码,所有视频平台必须接入CC码验证体系,**无码不得上线**。 本方案以**CC码中心**为核心枢纽,由其统一运行两套系统,实现CC码的全网监管: | 防线 | 机制 | 响应速度 | 覆盖范围 | |------|------|---------|---------| | **平台门禁** | CC码中心提供监管API,各平台调用API在上传、播出、CDN、终端四个环节验证CC码,无码拦截、违规秒级下架 | **秒级** | 所有对接平台 | | **网络探针** | CC码中心直接运行的独立巡查系统,爬虫巡查+水印提取+指纹比对+AI语义识别,不依赖平台配合 | **分钟级** | 全网(含未对接平台、境外平台) | > **平台门禁**是CC码中心提供给平台使用的API能力,**网络探针**是CC码中心自己运行的巡查系统。两者都由CC码中心统一管理,数据互通、协同处置。 **关键设计要点**: - **UGC专项**:平台代理赋码(码段授权+实时赋码),分级检测(快速筛查→重点检测→深度检测),合理使用与二创界定 - **直播专项**:频道/主播级赋码,播出中实时校验,分钟切片检测+秒级断流 - **存量处置**:12个月过渡期,分批补码(头部3个月→一般6个月→全量12个月),过渡期内网络探针重点巡查 - **误判申诉**:48小时申诉+24小时审核,分级处置+人工兜底+白名单+秒级恢复 - **水印嵌入**:CC码+平台代码+时间戳嵌入视频像素,不可见、抗压缩、抗裁剪,是全链路追溯的技术基础 - **CC码生命周期**:申请→审核→有效→暂停→恢复/下架→过期,全程状态管理,变更可追溯 - **组织保障**:5个团队约30~44人,7×24小时告警处理,平台考核与牌照续期挂钩 **实施路线**:5个阶段,18个月完成全量上线——3个月持证平台秒级拦截,6个月UGC赋码+网络探针,9个月存量补码+直播监管,12个月全量运行,18个月运营优化。 **核心价值**:从"人工巡查、天级发现、小时级下架"升级为"自动检测、秒级拦截、秒级全网下架",实现全网全量视频内容的实时监管闭环。 --- ## 一、政策背景与要解决的问题 ### 1.1 政策背景 CC码(广电内容编码)是广电总局和相关部门推出的**强制性视频内容标识制度**,要求: - **所有视频内容**——包括影视剧、综艺、纪录片、新闻、短视频、UGC用户创作——上线前必须取得CC码 - **所有视频平台**——包括持证平台、短视频平台、直播平台——必须接入CC码验证体系 - **无码不得上线**:没有CC码的视频内容,平台不得提供上传、发布、传播服务 > CC码相当于视频内容的"数字身份证"。与现有的网络剧片发行许可证制度**并行衔接**:影视剧既需要发行许可证,也需要CC码;UGC等不需要许可证的内容,只需CC码。CC码将监管范围从传统影视剧扩展到**全网所有视频内容**。 ### 1.2 现状痛点 当前视频内容监管面临四个核心难题: | 痛点 | 说明 | 现状 | |------|------|------| | **发现晚** | 违规视频上线后,靠人工巡查或群众举报才发现 | 往往已经传播数天,造成不良影响 | | **下架慢** | 发现违规后,需要逐级通知各平台人工处理 | 从发现到全网下架通常需要数小时甚至数天 | | **追责难** | 视频被搬运、剪辑后,难以追溯原始来源 | 无法证明"这个视频是从哪个正版内容剪辑来的" | | **UGC难管** | 短视频平台日均上传量达数百万条,人工审核杯水车薪 | 大量违规内容混在UGC中传播 | ### 1.3 我们的目标 通过CC码制度+技术手段,实现: - **正向发码**:所有视频内容(含UGC)上线前取得CC码,无码不上线 - **逆向监管**:在全网范围内自动发现、识别、处置违规视频内容 - **秒级下架**:违规内容一经发现,秒级通知全网下架 - **全量覆盖**:从影视剧到UGC短视频,从持证平台到境外平台,全覆盖、无死角 --- ## 二、核心思路:两道防线 我们采用**"预防为主,兜底为辅"**的双层设计,可以类比理解为**"门口安检 + 商场巡检"**: | 比喻 | 对应方案 | 作用 | |------|---------|------| | 门口安检 | 平台门禁 | 在内容上传/播出时查验CC码,无码不让进 | | 商场巡检 | 网络探针 | 安检被绕过时,巡检员在全网巡查发现违规 | ### 为什么需要两道防线 - **只有平台门禁**:平台如果不配合(不装安检门),就完全失控 - **只有网络探针**:发现违规后还要等平台配合才能下架,时延不可控 - **两层并行**:配合的平台秒级拦截,不配合的平台也能分钟级发现并处置 > CC码作为强制要求,所有平台必须接入平台门禁。但行政强制不能保证100%执行到位,网络探针作为技术兜底,确保"制度管得到的秒级管,制度暂时管不到的分钟级管"。 --- ## 三、平台门禁(秒级) ### 3.1 工作方式 平台门禁的核心是:**各视频平台调用CC码中心提供的监管API**,在业务流程中实时验证CC码的合法性和状态。平台不需要自建验证系统,只需对接CC码中心的统一API接口: ``` 视频平台 CC码中心 │ │ ├── 上传时 → 调用API验证CC码 ──→ 返回:合法/非法/已下架 ├── 播出时 → 调用API查询状态 ──→ 返回:有效/已暂停/已下架 ├── CDN分发时 → 调用API校验哈希 ──→ 返回:一致/被篡改 └── 终端播放时 → 调用API抽检 ──→ 返回:一致/异常 ``` > 平台只需对接一套API,不需要理解CC码的内部逻辑。CC码中心负责所有验证判断,平台根据返回结果执行拦截或放行。 在视频平台的四个关键环节嵌入CC码验证,类似"四道安检关卡": | 关卡 | 在什么环节检查 | 检查什么 | 不通过怎么办 | 用户是否有感知 | |------|-------------|---------|------------|-------------| | **第一关:上传拦截** | 内容上传到平台时 | 有没有CC码、码是否合法 | 拒绝上传,提示先去备案(UGC由平台代理赋码,详见第五章) | 上传者看到提示,观众无感 | | **第二关:播出校验** | 观众点击播放时 | CC码是否还有效(是否已被下架) | 返回"该内容已下架" | 观众看到下架提示 | | **第三关:CDN注入校验** | 内容分发到CDN时 | 文件是否被篡改 | 拒绝分发,退回审核 | 观众无感 | | **第四关:终端抽检** | 观众播放过程中 | 播放的内容和登记的是否一致 | 自动断流,切换备用源 | 极偶尔的卡顿,基本无感 | ### 3.2 秒级下架怎么实现 当监管方决定下架某个内容时,只需一条指令: ``` 监管方下达指令:"下架 CC码 第XXX号" │ │ CC码中心自动查找该CC码关联的所有: │ · 哪些平台有这个内容 │ · 哪些CDN缓存了这个内容 │ · 哪些运营商在分发这个内容 │ ▼ CC码中心通过API同时通知所有相关方(1秒内) │ ┌────┼────────────┬────────────┬────────────┐ ▼ ▼ ▼ ▼ ▼ 平台A 平台B 运营商A 运营商B CDN全网 自动下架 自动下架 清除缓存 清除缓存 黑名单拦截 (1秒) (1秒) (1秒) (1秒) (1秒) ``` **关键点**:监管方只需在CC码中心后台说"下架这个CC码",CC码中心自动翻译成各平台、各CDN能理解的执行指令,通过API下发,不需要人工逐个通知。 ### 3.3 适用范围 CC码是强制性要求,所有视频平台必须对接: | 平台类型 | 对接方式 | 效果 | |---------|---------|------| | IPTV集成播控平台 | 已有TCS-IPTV基础,天然对接 | 秒级拦截+秒级下架 | | 持证视频平台(爱奇艺/腾讯/优酷等) | 强制对接,行政要求 | 秒级拦截+秒级下架 | | 短视频平台(抖音/快手/B站等) | 强制对接,UGC批量发码(详见第五章) | 上传环节拦截+批量验证 | | 直播平台 | 强制对接,直播前预告赋码+播出中实时校验(详见第五章) | 播出环节秒级拦截 | | 中小视频平台 | 强制对接,分批过渡 | 过渡期内由网络探针重点巡查 | | 境外平台 | 无法对接 | 依靠网络探针检测+DNS封锁 | --- ## 四、网络探针(分钟级) 网络探针是**CC码中心直接运行**的独立巡查系统,不需要各平台配合接入,主动在全网范围内发现和识别违规内容。 ### 4.1 为什么需要网络探针 CC码虽是强制要求,但平台门禁仍有管不到的地方: | 场景 | 平台门禁为什么管不到 | 网络探针怎么管 | |------|-----------------|------------| | 平台对接有过渡期 | 中小平台分批接入,过渡期内未对接 | 系统自动巡查全网,发现违规 | | 平台执行不到位 | 形式上对接但实际未严格执行 | 系统独立检测,不依赖平台 | | UGC剪辑搬运 | 剪辑后的新内容未重新赋码 | 通过内容比对,识别出是哪个正版内容的片段 | | 境外平台传播 | 管不了境外平台 | 检测发现后,走DNS封锁 | | 有人故意去水印 | 去掉水印后平台无法验证 | 用内容指纹识别,即使去水印也能认出来 | | 存量内容未补码 | 补码完成前的存量内容 | 重点巡查,发现违规立即处置 | ### 4.2 工作方式 网络探针是CC码中心运行的**自动巡查系统**,独立于各平台运行,发现违规后直接通过CC码中心处置。分三步工作: **第一步:采集(发现视频)** | 采集方式 | 说明 | 覆盖范围 | |---------|------|---------| | 网络巡查 | 自动浏览各大视频网站,发现新上线的视频 | 主流视频平台、短视频平台、小网站 | | 直播录制 | 对电视直播频道实时录制片段 | 卫星频道、有线频道、网络直播 | | 群众举报 | 提供举报入口,接收群众举报的可疑链接 | 全网 | **第二步:检测(识别视频)** 对采集到的视频,用三种手段逐步识别: | 检测手段 | 通俗解释 | 速度 | 能扛什么破坏 | |---------|---------|------|------------| | **提取CC码** | 类似扫描身份证 | 秒级 | 扛得住压缩、转码、裁剪 | | **内容指纹比对** | 类比人脸识别,即使换了衣服也能认出 | 毫秒级 | 扛得住剪辑、加滤镜、去水印 | | **AI语义理解** | 类比让人看视频说"这跟某某剧是同一部" | 分钟级 | 扛得住深度混剪、拼接 | 三种手段层层递进:第一种认不出来就用第二种,第二种还不行就用第三种。 **第三步:处置(告警+下架)** 网络探针发现违规后,直接上报CC码中心,由CC码中心通过平台门禁API下达下架指令: | 检测结果 | 处置方式 | 响应速度 | |---------|---------|---------| | 发现伪造/无码内容 | 紧急电话+短信通知监管方,要求平台立即下架 | 立即 | | 发现去水印传播 | 短信通知+自动发行政通知给平台 | 5分钟内 | | 发现疑似违规 | 纳入日报,人工研判 | 24小时内 | ### 4.3 下架后的验证 网络探针还有一个重要职责——**验证下架是否真的执行了**: ``` 监管方下达下架指令 │ ├── 平台门禁通知各平台下架(秒级) │ └── 网络探针验证下架效果(分钟级) ├── 自动巡查该视频的URL → 还能访问吗? ├── 已下架 → 记录确认 ├── 仍能访问 → 升级告警:"XX平台未执行下架指令" └── 持续监控 → 防止偷偷重新上架 ``` --- ## 五、UGC短视频场景专项设计 ### 5.1 UGC为什么需要单独设计 UGC短视频与影视剧有本质区别,不能简单套用同一套流程: | 维度 | 影视剧 | UGC短视频 | |------|--------|----------| | 日均上传量 | 几十~几百部 | 数百万条 | | 内容来源 | 专业机构制作 | 普通用户创作 | | 单条时长 | 30分钟~2小时 | 15秒~5分钟 | | 是否需要审核 | 严格审核 | 平台自查+抽检 | | 违规风险 | 较低(已审核) | 较高(实时上传) | ### 5.2 UGC发码机制 UGC不能要求每个用户都去广电总局申请CC码,需要设计**批量发码+平台代理**机制。平台通过调用CC码中心的API完成批量赋码和备案: ``` 用户上传短视频 │ ├── 平台自动审核(AI初筛+人工复核) │ ├── 审核通过 → 平台调用CC码中心API批量赋码 │ ├── 平台获得码段授权(广电总局分配号段给平台) │ ├── 平台在号段内为每条UGC内容自动赋码(本地完成,无需逐条联网) │ └── 赋码信息通过API批量回传CC码中心备案 │ └── 审核不通过 → 拒绝发布 ``` **关键设计**: | 机制 | 说明 | |------|------| | **码段授权** | 广电总局给各平台分配CC码号段,平台在号段内自行赋码 | | **平台代理** | 用户无需直接对接广电系统,平台代为赋码 | | **实时赋码** | 用户上传审核通过后秒级赋码,不影响上传体验 | | **API批量回传** | 平台定期通过API将赋码清单批量回传CC码中心,纳入监管 | | **码段管控** | 广电可随时通过API收回或冻结平台码段,形成约束 | ### 5.3 UGC检测策略 UGC量巨大,不可能全量深度检测,采用**分级检测**策略。检测同样依赖平台调用CC码中心API + 网络探针独立检测双轨进行: | 检测级别 | 触发条件 | 检测方式 | 由谁执行 | 处理速度 | |---------|---------|---------|---------|---------| | **快速筛查** | 所有UGC | 平台调用CC码中心API验证元数据(有无码、码是否在有效号段内) | 平台门禁 | 毫秒级 | | **重点检测** | 疑似搬运正版内容 | 平台调用CC码中心指纹比对API,与影视剧本纹库匹配 | 平台门禁 | 秒级 | | **深度检测** | 疑似违规或高传播量内容 | 网络探针独立提取水印+AI语义分析 | 网络探针 | 分钟级 | **如何判断"疑似搬运正版内容"**: ``` UGC视频上传 │ ├── 计算内容指纹(秒级) │ ├── 与影视剧本纹库比对 │ ├── 指纹相似度>80% → 疑似搬运 → 进入重点检测 │ ├── 指纹相似度50~80% → 疑似二创 → 标记观察 │ └── 指纹相似度<50% → 原创内容 → 正常赋码 │ └── 分级处理 ├── 疑似搬运 → 提取水印 → 有CC码 → 正版授权?记录 │ → 无水印 → 告警:疑似盗版搬运 └── 疑似二创 → 记录关联关系 → 纳入版权追踪 ``` ### 5.4 合理使用与二创界定 并非所有使用正版素材的视频都是违规,需要区分**合理使用**和**侵权搬运**: | 类型 | 特征 | 处理方式 | |------|------|---------| | **原创内容** | 完全自主创作 | 正常赋码,正常传播 | | **合理使用(影评/解说)** | 使用少量片段+大量原创解说 | 正常赋码,标注引用来源 | | **二创混剪** | 基于正版素材的创意改编 | 赋码时标注"二创",关联原始CC码 | | **侵权搬运** | 整片搬运或大段搬运,无原创加工 | 拒绝赋码,下架处理 | | **去水印搬运** | 去除水印后整片搬运 | 拒绝赋码,下架+追责 | > 界定标准由广电总局制定,系统提供技术识别能力,最终判定由人工审核确认。 ### 5.5 直播场景专项设计 直播与点播有本质区别:直播是实时的,不能等审核完再播出。需要单独设计赋码和监管流程。直播赋码和校验同样通过CC码中心API完成,但增加实时校验机制: **直播赋码机制**: | 直播类型 | 赋码方式 | 说明 | |---------|---------|------| | 卫视直播频道 | 频道级赋码 | 每个频道一个CC码,提前报备节目单 | | 网络直播(秀场/游戏等) | 主播级赋码 | 平台为主播分配CC码,主播实名绑定 | | 事件直播(赛事/演唱会等) | 活动级赋码 | 活动主办方提前申请CC码 | | 突发直播(新闻等) | 平台应急赋码 | 平台用码段内应急码,事后补审 | **直播监管流程**: ``` 直播开始前 ├── 频道/主播/活动已赋CC码 → 正常开播 └── 未赋码 → 平台不得开播 直播进行中 ├── 平台门禁:调用CC码中心API实时校验CC码状态(是否已被下架) │ ├── CC码有效 → 继续播出 │ └── CC码已下架 → 秒级断流 │ └── 网络探针:实时录制片段 → 水印提取 + 指纹比对 ├── 内容正常 → 继续监控 ├── 发现违规 → 秒级告警 + 断流指令 └── 发现无码直播 → 紧急告警 + 行政通知 直播结束后 ├── 直播录像自动存档 → 补充检测 └── 发现违规片段 → 追溯处置 ``` **关键设计**: | 机制 | 说明 | |------|------| | **频道/主播级赋码** | 不需要每场直播单独申请,一次赋码长期有效 | | **实时校验** | 播出过程中持续校验CC码状态,下架指令秒级生效 | | **片段录制** | 网络探针对直播流按分钟切片录制,逐片检测 | | **应急码段** | 突发新闻等无法提前申请的场景,平台使用应急码段,事后补审 | | **录像存档** | 直播结束后录像自动存档,供事后追溯和补检 | ### 5.6 水印嵌入机制 前面多次提到"提取水印"和"去水印",这里说明水印是怎么嵌入到视频中的: **什么时候嵌入**: | 内容类型 | 嵌入时机 | 由谁嵌入 | |---------|---------|---------| | 影视剧/专业内容 | CC码签发后、内容上线前 | 内容制作方在母版中嵌入 | | UGC短视频 | 平台赋码后、发布前 | 平台在转码环节自动嵌入 | | 直播内容 | 直播流编码环节 | 平台在编码器中实时嵌入 | | 存量补码内容 | 补码后重新转码时 | 平台在重新转码时嵌入 | **水印嵌入什么信息**: | 信息 | 说明 | |------|------| | CC码 | 内容的唯一标识 | | 平台代码 | 内容上线平台的标识 | | 时间戳 | 嵌入时间,用于追溯 | **水印特性**: | 特性 | 说明 | |------|------| | **不可见** | 嵌入在画面像素中,人眼看不到,不影响观看体验 | | **不可听** | 如有音频水印,嵌入在音频中,人耳听不到 | | **抗压缩** | 经过转码、压缩后仍可提取 | | **抗裁剪** | 画面裁剪后仍可部分提取 | | **多帧冗余** | 水印重复嵌入在多帧中,部分帧丢失不影响提取 | > 水印嵌入是CC码监管的技术基础。没有水印,网络探针检测就无法识别视频内容的来源。广电总局应制定水印嵌入标准,所有平台和制作方按统一标准执行。 --- ## 六、两层如何配合 ### 6.1 正常情况(大多数内容) **影视剧/专业内容**: ``` 内容制作 → 送审取得CC码 → 上传平台(第一关验证通过)→ 平台审核 → 观众播放 │ 一切正常 网络探针不介入 ``` **UGC短视频**: ``` 用户创作 → 上传平台 → 平台审核 → 平台代理赋码 → 发布上线 → 观众播放 │ 一切正常 网络探针快速筛查通过 ``` ### 6.2 异常情况(违规内容) | 场景 | 平台门禁 | 网络探针 | 最终结果 | |------|--------|--------|---------| | 无CC码内容上传 | 第一关拦截,拒绝上传 | - | 内容根本不上线 | | UGC未赋码就发布 | 平台赋码流程异常,拦截 | - | 内容不上线,平台修复流程 | | 已下架内容被点播 | 第二关拦截,返回下架提示 | - | 观众看到下架提示 | | 平台过渡期未对接 | 管不到 | 爬虫发现→检测→告警→行政通知 | 分钟级发现,小时级下架 | | UGC搬运正版内容 | 赋码时指纹比对发现 | 重点检测→告警 | 秒级拦截上传 | | 正版内容被剪辑搬运 | 二创赋码时标注关联 | 指纹比对识别→判定是否合理使用 | 分钟级发现侵权 | | 有人故意去水印 | 验证不了 | 内容指纹识别→告警 | 分钟级发现,追责 | | 境外平台传播 | 管不到 | 检测发现→DNS封锁 | 天级处置 | | 存量内容未补码 | 过渡期内允许 | 重点巡查→发现违规立即处置 | 过渡期内重点监管 | ### 6.3 下架指令的执行 ``` 监管方一条指令 │ ├──→ 平台门禁:秒级通知全网下架(平台+CDN) │ └──→ 网络探针:分钟级验证下架效果 ├── 确认下架 → 结案 └── 未下架 → 升级处理 ``` --- ## 七、存量内容处置计划 CC码制度实施后,全网已有海量存量视频没有CC码,必须制定明确的处置计划: ### 7.1 存量内容分类处置 | 内容类型 | 处置方式 | 时间要求 | |---------|---------|---------| | **头部热播内容**(各平台Top1000) | 优先补登记CC码 | 制度生效后3个月内 | | **一般影视剧/综艺** | 分批补登记 | 制度生效后6个月内 | | **长尾专业内容** | 平台批量补登记 | 制度生效后12个月内 | | **存量UGC** | 平台按码段批量赋码 | 制度生效后12个月内 | | **已下架/失效内容** | 不需要补码 | - | ### 7.2 补码过渡期安排 ``` 制度生效 │ ├── 过渡期(12个月) │ ├── 存量内容可继续在线,但必须分批补码 │ ├── 补码完成前,纳入网络探针重点巡查 │ └── 过渡期内新发现违规的存量内容,立即下架 │ └── 过渡期结束 ├── 已补码内容 → 纳入正常监管流程 └── 未补码内容 → 强制下架,平台不得继续提供 ``` ### 7.3 存量补码的执行方式 | 角色 | 职责 | |------|------| | 广电总局 | 发布补码指令,分配码段 | | 各平台 | 负责本平台存量内容的批量补登记 | | CC码中心 | 提供批量赋码API,支持平台批量提交 | | 网络探针 | 验证各平台补码进度,对未按时完成的重点巡查 | --- ## 八、误判申诉与恢复机制 ### 8.1 为什么需要申诉机制 任何自动化检测都不可能100%准确。如果正常内容被误判为违规并下架,会影响平台正常运营和创作者权益,必须提供快速申诉和恢复通道。 ### 8.2 申诉流程 ``` 内容被下架/拦截 │ ├── 平台/创作者收到下架通知 │ 通知包含:下架原因、CC码、检测证据 │ ├── 平台/创作者发起申诉(48小时内) │ 申诉渠道:CC码中心申诉API / 平台代申诉 │ ├── 申诉审核(24小时内) │ ├── 自动复核:重新检测,确认是否误判 │ └── 人工复核:由审核人员判断 │ └── 申诉结果 ├── 申诉成功 → 立即恢复上线 → 记录误判案例 → 优化检测阈值 └── 申诉驳回 → 维持下架 → 告知驳回理由 ``` ### 8.3 误判防控措施 | 措施 | 说明 | |------|------| | **分级处置** | 低置信度告警先标记观察,不直接下架;高置信度才下架 | | **人工兜底** | UGC二创、影评解说等灰色地带,必须人工审核确认 | | **阈值可调** | 指纹相似度阈值根据误判案例持续优化 | | **白名单机制** | 已确认的合理使用内容纳入白名单,避免重复误判 | | **申诉数据反哺** | 申诉案例用于训练检测模型,持续降低误判率 | ### 8.4 恢复上线机制 | 场景 | 恢复方式 | 速度 | |------|---------|------| | 申诉成功 | CC码状态恢复为"有效",平台门禁播出校验自动放行 | 秒级 | | 申诉成功+CDN缓存 | CC码恢复+通知CDN清除下架标记 | 分钟级 | | 误批量下架 | 批量恢复CC码状态,批量通知平台 | 分钟级 | --- ## 九、实施计划 ### 9.1 分阶段路线 > 以下时间线从**项目启动**起算。存量补码时间线从**CC码制度正式生效**起算(见第七章),两者可能存在时间差:制度生效前完成系统建设,制度生效后启动存量补码。 | 阶段 | 时间 | 目标 | |------|------|------| | **第一阶段** | 3个月 | 平台门禁上线:监管API+秒级下架,对接IPTV+1~2家持证平台 | | **第二阶段** | 6个月 | 网络探针起步版上线+UGC赋码机制上线,对接短视频平台 | | **第三阶段** | 9个月 | 存量补码启动+直播监管上线+GPU加速检测 | | **第四阶段** | 12个月 | 全量上线:全网平台对接+存量补码完成+完整监管覆盖 | | **第五阶段** | 18个月 | 全量运行+对抗加固+运营优化 | ### 9.2 里程碑 | 时间点 | 里程碑 | 验收标准 | |--------|--------|---------| | 第3个月 | 持证平台秒级拦截上线 | 试点平台上传验证+播出校验+秒级下架 | | 第6个月 | UGC赋码+网络探针跑通 | 短视频平台批量赋码上线,日检测5000条,准确率≥90% | | 第9个月 | 存量补码+直播监管 | 存量Top1000补码完成,50路直播实时监测 | | 第12个月 | 全量运行 | 全网覆盖,存量补码完成,完整告警+下架+验证+申诉闭环 | | 第18个月 | 运营优化 | 误判率<2%,对抗测试通过,全量稳定运行 | --- ## 十、与已有系统的关系 本方案不是推倒重来,而是在已有的TCS-IPTV系统上**叠加增强**: | 已有能力 | 本方案新增 | 关系 | |---------|-----------|------| | CC码生成签发 | 平台侧验证API+UGC批量赋码+直播赋码 | 让CC码从"登记备案"升级为"实时验证+全量赋码" | | 送审文件验真 | 上传环节拦截 | 从"送审时验"扩展到"上传时验" | | CDN注入校验 | 无需改动 | 已有关卡,直接复用 | | 终端播放抽检 | 无需改动 | 已有关卡,直接复用 | | 应急下架指令 | 秒级全网同步 | 从"逐层通知"升级为"一键全网下架" | | 全生命周期监管 | 网络探针外部监控 | 新增"不依赖平台配合"的监管视角 | > **核心理念:不替代现有系统,在关键节点嵌入验证能力,新增网络探针兜底。** --- ## 十一、关键风险与应对 | 风险 | 发生概率 | 影响 | 应对措施 | |------|---------|------|---------| | 平台对接进度滞后 | 中 | 平台门禁覆盖不全 | 行政强制+分批过渡+网络探针重点巡查未对接平台 | | UGC赋码性能瓶颈 | 中 | 短视频平台上传受阻 | 码段授权+平台本地赋码+异步回传,不依赖实时联网 | | 水印被技术手段去除 | 低 | 网络探针检测难度增大 | 三种检测手段层层兜底,去水印还有指纹识别 | | 爬虫被网站反爬阻挡 | 中 | 部分网站采集不到 | 多种采集策略;群众举报通道补充 | | CDN厂商不配合下架 | 低 | 下架不彻底 | 行政处罚;DNS封锁作为最终手段 | | 误判正常内容为违规 | 中 | 影响正常播出和创作 | 分级处置+人工兜底+申诉通道+阈值持续优化 | | 存量补码进度滞后 | 中 | 过渡期结束后大量内容被强制下架 | 分批推进+进度监控+必要时延长过渡期 | | 合理使用界定争议 | 中 | 二创/影评创作者不满 | 界定标准由广电制定+人工审核+申诉机制 | | 建设成本超出预算 | 低 | 需要追加投入 | 分阶段建设,先验证再扩容,避免一次性大投入 | | 直播监管实时性不足 | 中 | 违规直播片段已播出 | 片段切片检测+秒级断流+录像事后追责 | | 水印标准不统一 | 中 | 跨平台检测失败 | 广电制定统一水印标准,强制执行 | --- ## 十二、方案价值总结 | 维度 | 现状 | 本方案实现后 | |------|------|------------| | **发现速度** | 人工巡查,天级~周级 | 秒级(平台门禁)+ 分钟级(网络探针) | | **下架速度** | 逐级通知,小时级~天级 | 一键指令,秒级全网下架 | | **覆盖范围** | 依赖平台配合,UGC基本失管 | 全量覆盖:影视剧+UGC+直播,持证平台+短视频+境外 | | **追溯能力** | 难以追溯来源 | CC码+水印+指纹,全链路追溯 | | **对抗能力** | 被动应对 | 水印+指纹+AI三层检测,扛转码/剪辑/去水印 | | **证据固化** | 人工截图取证 | 自动保存视频片段、截图、检测日志 | | **UGC管理** | 平台自查,标准不一 | 统一赋码+分级检测+合理使用界定 | | **存量处理** | 无系统方案 | 分批补码+过渡期安排+重点巡查 | | **误判处理** | 无申诉渠道 | 分级处置+申诉通道+快速恢复 | | **运营成本** | 大量人工巡查 | 自动化检测,人工只处理告警和审核 | | **直播监管** | 基本无实时监管 | 频道/主播级赋码+实时校验+秒级断流 | --- ## 十三、决策建议 1. **尽快启动第一阶段**(平台门禁),投入小、见效快,3个月即可实现持证平台秒级拦截 2. **同步启动网络探针MVP和UGC赋码机制**,UGC是最大的监管盲区,必须尽早覆盖 3. **同步启动存量补码计划**,存量内容量大,越早启动越主动 4. **推动CC码制度法规落地**,技术方案需要政策支撑,平台配合度取决于行政强制力 5. **分阶段扩容**,先验证再投入,避免一次性大规模建设 6. **建立申诉机制**,误判处理是业务领导最关切的实操问题,必须在上线前就绪 7. **平台门禁+网络探针缺一不可**,只有平台门禁会被绕过,只有网络探针下架慢,两层并行才能实现全覆盖、秒级响应 --- ## 十四、CC码生命周期管理 CC码不是一次性发放就结束的,每个CC码都有完整的生命周期状态管理: ### 14.1 CC码状态流转 ``` 申请 → 审核中 → 签发(有效)→ 暂停 → 恢复 │ │ │ └── 下架(永久) │ └── 过期(内容下线后自动过期) ``` ### 14.2 各状态说明 | 状态 | 含义 | 触发条件 | 平台行为 | |------|------|---------|---------| | **审核中** | CC码申请已提交,等待审批 | 内容制作方/平台提交申请 | 内容不得上线 | | **有效** | CC码已签发,内容可正常传播 | 审核通过 | 正常上传、播出、分发 | | **暂停** | 临时停止传播,待核实 | 收到举报或检测到疑似违规 | 平台暂停播出,但不删除 | | **恢复** | 暂停解除,恢复传播 | 核实后确认无违规 | 恢复正常播出 | | **下架** | 永久停止传播 | 监管方下达下架指令 | 平台立即删除,CDN清除缓存 | | **过期** | 内容已下线,CC码失效 | 内容自然下线或授权到期 | 平台不得再提供播放 | ### 14.3 状态变更的权限 | 操作 | 谁有权执行 | 生效速度 | |------|-----------|---------| | 申请CC码 | 内容制作方/平台代理 | - | | 审核签发 | 广电总局CC码中心 | 审核通过后即时 | | 暂停 | 监管方/平台举报 | 秒级 | | 恢复 | 监管方核实后 | 秒级 | | 下架 | 监管方 | 秒级全网同步 | | 过期 | 系统自动(授权到期或内容下线) | 自动触发 | > CC码生命周期管理确保每个内容从申请到下线的全过程都在监管之下,任何状态变更都有记录可查。 --- ## 十五、组织保障与运营机制 ### 15.1 运营组织架构 | 角色 | 职责 | 人员配置(建议) | |------|------|----------------| | **监管中心** | 统筹CC码签发、下架决策、申诉审核 | 5~8人 | | **审核团队** | CC码申请审核、误判申诉复核、合理使用界定 | 8~12人 | | **监控运营团队** | 网络探针系统运营、告警处理、爬虫策略调整 | 6~10人 | | **平台对接团队** | 推动各平台对接API、技术支持、进度跟踪 | 4~6人 | | **技术运维团队** | 系统运维、水印/指纹/AI模型优化 | 6~8人 | ### 15.2 日常运营机制 | 机制 | 频率 | 内容 | |------|------|------| | **实时告警处理** | 7×24小时 | 值班人员处理系统告警,决定是否下架 | | **每日巡检** | 每日 | 检查系统运行状态、爬虫覆盖率、检测准确率 | | **每周研判** | 每周 | 集中研判疑似违规内容,调整检测阈值 | | **每月报告** | 每月 | 向领导层提交监管月报:检测量、下架量、平台配合度 | | **季度评估** | 每季度 | 评估系统效果,优化检测策略,调整平台对接优先级 | ### 15.3 平台考核机制 | 考核维度 | 指标 | 权重 | |---------|------|------| | **对接进度** | 是否按计划完成API对接 | 30% | | **执行效率** | 下架指令执行率、执行速度 | 30% | | **赋码覆盖率** | 平台内容赋码比例(含存量补码进度) | 20% | | **违规率** | 平台被发现的违规内容数量 | 20% | > 考核结果与平台年检、牌照续期挂钩,确保平台有动力配合。 --- ## 十六、CC码与现有制度的关系 | 现有制度 | 与CC码的关系 | 说明 | |---------|-------------|------| | 网络剧片发行许可证 | **并行衔接** | 影视剧需要许可证+CC码;UGC只需CC码 | | 信息网络传播视听节目许可证 | **平台级并行** | 平台持此证是前提,CC码是平台必须接入的验证体系 | | IPTV集成播控牌照 | **天然对接** | 已有TCS-IPTV系统,CC码验证API直接复用 | | 广播电视节目制作经营许可证 | **内容制作方并行** | 制作方持此证制作内容,内容上线前还需取得CC码 | | 现有内容审查制度 | **前置环节** | 内容审查通过后,方可申请CC码;CC码中心不替代审查 | > **核心理念:CC码不替代任何现有制度,而是在现有制度之上增加一个"数字身份证"层,实现从"审批管理"到"实时监管"的升级。**