摘要

  • MediaLive 生成两种带不同水印的输出，下游再为观看会话组合序列；编码完成不等于追溯完成。
  • 水印配置错误时频道仍可能继续播出。翻倍的是启用组内用于输出计费的视频输出数量，不是整个业务账单。

直播画面没有黑屏，保护层却可能已经失效。AWS 于 9 月 10 日为 MediaLive 加入 A/B 取证水印，内容方可借助不同标记的视频版本及下游会话序列，追查未经授权的再分发来源。但如果采购验收仍只有“能不能播”，新增的追溯能力就没有真正得到验收。

故障排查文档把这个区别说得很直接：配置不正确时，MediaLive 会停用该输出组的水印，而频道继续运行并输出视频。告警可在控制台查看，也会成为 CloudWatch 事件。此外，某些规格不受支持的视频版本可能没有水印，却不伴随频道错误。只盯着频道运行状态，不能证明每一种画质版本都保留了可用证据。

这项功能并非由编码器独自完成。功能说明规定，MediaLive 为受支持输出组中的每种视频规格产生 A、B 两种水印版本，分别送往成对的目的地。随后，由识别水印的源站或 CDN 按观看请求选取片段，组成会话专属序列。逐观众选择及面向观众的播放清单，都不是 MediaLive 在此承担的工作。产出两种版本与完成一次可追溯交付，是不同的结果。

上游还有许可与时序条件。首个可用实现来自 Irdeto，运营方须直接安排有效许可，并将其存入 AWS Secrets Manager。频道持续运行也不能替代时码检查：如果输入没有可用的嵌入式 UTC 时码，水印序列就可能无法在下游被可靠检测。许可字段已填、编码器已启动、最终检测成功，不能合并成一个状态。

中间的封装环节也不能丢掉位置信息。MediaPackage 文档说明，基于 epoch locking 的 CMAF 接入和水印节奏信息，会在合并片段时保留水印位的位置，供下游 CDN 推导正确位置。视频可被顺利封装，并不自动说明会话选择或检测已经完成。各环节必须交接的是可用证据，而不仅是可播放的字节。

账单也需要明确分母。计费说明将每个 A/B 版本视为单独的视频输出，因此启用组内用于输出计费的数量翻倍，其他输出组不受此变化影响。由此不能推出总账单翻倍，不能说每位观众下载两份视频，也不能直接估算 CDN 流量会增加多少。许可、分发和检测的商业安排仍须分别确认。

A/B 更不是主备线路的另一种叫法。配置指南将水印目的地角色与标准频道中的 pipeline 字段分开。若把 B 版仅当作不常使用的备用，就会同时误解输出用途与付费对象。内容方增加这项支出的理由，应该是最终交付能支持所需追溯，而不是后台出现了两种版本。