一个 FAST 频道 的 Logo——角落里的小标志——是频道播放的每个节目、每个广告时段、每个片头片尾中唯一不变的视觉元素。它必须在观众可能接收到的任何质量水平下都显得专业。天真的做法是上传一个主图像，然后让 AWS MediaLive 根据每个版本进行缩放，这会在 1080p 时产生清晰的 Logo，但在 360p 时则会明显模糊。对于非宽带用户来说，这是一个品牌问题。以下是我们如何将 Logo 调整到每个版本的精确像素网格的方法。
快速概览
| 方面 | 详情 |
|---|---|
| 领域 | FAST 频道上的频道 Logo (DOG) 叠加 |
| 机制 | 每个输出的 StaticImageOutputActivate，对应每个版本 (1080p, 720p, 480p, 360p) |
| 资产生成 | 使用 Lanczos resampling 的 Python 脚本 |
| 激活时机 | 每次节目输入切换后 1.5 秒 |
| 状态 | 生产环境中 1× 每个版本的堆栈 |
业务问题
一个 FAST 频道并不能只提供一个质量级别。MediaLive 会将同一频道编码为多个版本——1080p、720p、480p、360p——每个观众的播放器会选择其连接能支持的最佳版本。使用蜂窝数据的移动观众观看 360p；使用宽带的智能电视观众获得 1080p。他们都在看同一个品牌标志，并且都期望它看起来专业。当 Logo 在 1080p 时清晰，但在 360p 时明显模糊时，品牌就会不一致——这对于一个 24/7 频道来说并非小事，因为 Logo 是观众看到比任何单一节目都多的元素。
叠加层实际应用的位置
在多版本编码器管道中，叠加层可以应用在两个位置：
在每个版本的缩放器之前，一个主图像被合成到源上，然后整个内容根据每个输出进行缩放——这就是 MediaLive 使用全局 StaticImageActivate 操作所做的事情
在缩放器之后，当画布已经达到最终尺寸时，每个输出都会应用自己的叠加层。在 API 中，这种差异看起来很小。但从视觉上看，并非如此。在缩放器之前合成的任何内容都会继承缩放器引入的所有伪影，而在 360p 时，缩放器是激进的。
为什么显而易见的解决方案会失败
“上传一个主图像，让 MediaLive 缩放它。” 全局操作在每个输出的缩放器运行之前将主图像合成。一个大尺寸的主图像被缩放为 360p 的 64×21px Logo，这是一个大约 40 倍的缩小——即使是 Lanczos resampling 也会在这种比例下丢失精细细节，并且结果还会通过与视频本身相同的压缩链。
“使用更大的主图像。” 这会使缩放比例更大，而不是更小——伪影会变得更糟，而不是更好。
“在标清输出上跳过 Logo。” 合规性和品牌要求需要在每个版本上都显示标志。这不是一个选项。
“在编码时将 Logo 烧录到源视频中。” 失去了所有的操作杠杆——无法进行按活动或按区域的 Logo 更改，并且不重新编码整个媒体库就无法更新。
“使用全局叠加层，并为每个分辨率手动指定坐标。” 全局操作是根据固定的 1920×1080 参考来计算位置的，因此如果源视频的宽度小于这个尺寸，就会产生画布外的坐标——Logo 会偏离角落或被裁剪。
实际的解决方案是完全绕过 MediaLive 的叠加层缩放：在编码器处理之前，我们自己将 Logo 尺寸调整到每个版本的画布。
解决方案
每个版本的 Logo 都预渲染为其精确的像素尺寸，并存储为单独的 PNG 文件。在每个节目边界，一个 Lambda 编排器会发出四个 StaticImageOutputActivate 操作——每个版本一个——每个操作都指向已为该特定输出调整好尺寸的 PNG 文件。MediaLive 不会对叠加层执行任何缩放。
全局 (天真做法) 每个输出 (我们实施的方法)
master.png ──► 合成到源画布上 master.png ──► Lanczos resize (离线)
生成 4 个精确尺寸的 PNGs
│ │
▼ ▼
每个版本的缩放器 每个版本的缩放器
(也缩放叠加层 → (叠加层未被触及——
标清输出上的模糊 Logo) 在精确像素尺寸下，
之后合成)一个 Python 脚本使用 Lanczos resampling 从单个主图像生成四个不同尺寸的 PNG 文件，选择它是为了在小尺寸下获得可预测、可重复的行为，而不是为了在像素质量竞赛中取胜。每个 Logo 大约占据其画布宽度的 10%——既可见又不干扰——添加一个新的版本只需一个数组条目和一个新的 PNG。
值得一提的关键决策
1.5 秒的激活延迟。 水印开启操作在每次输入切换后 1.5 秒触发，而不是在精确切换时刻——立即激活可能会在尚未稳定的帧上出现闪烁。该值经过经验性调整，并集中为一个单一常量，以便将来的调整只需修改一行代码。
离线、人工触发的资产生成——有意为之。 Lanczos resize 管道并未自动化为构建步骤或 CDN 侧转换。Logo 资产的更改频率足够低，以至于一次命令式重新生成是恰到好处的自动化程度；构建进一步自动化的成本超过了每年运行两次脚本的成本。
存在“加粗”变体但未投入使用。 生成器还生产了一种带有较粗描边的 dilated-alpha 变体，旨在在低 SD 比特率下 H.264 量化后仍能保持可见。它目前未投入生产——标准变体足以满足当前的比特率范围，并且目前没有任何测量数据支持切换。它作为经过代码测试的备用方案存在：保持可用成本低廉，但目前投入使用为时尚早。
我们仍在关注什么
没有哪个生产视频管道是真正完美的，随着时间的推移，这种方法仍有机会得到改进。
目前的实现确保每个版本都收到专门为其自身输出分辨率准备的 Logo，从而消除了 MediaLive 管道中的运行时叠加缩放。然而，最终的呈现效果自然仍受每个版本的分辨率和视频压缩的限制，尤其是在较低比特率下。随着流媒体配置文件不断发展，我们将继续评估在这些条件下，不同的 Logo 处理方式是否能提供可衡量的视觉优势。
资产生成器已经支持标准和加粗的 Logo 变体。如果未来的测试表明加粗版本在较低比特率版本中表现更好，我们将使 Logo 变体选择由配置驱动，以便在不重新部署应用程序的情况下进行更改。
结果
现在，每个版本都收到专门为其画布尺寸定制的 Logo，MediaLive 不执行任何运行时叠加缩放。每个输出都使用为其目标分辨率准备的图稿，避免了运行时叠加缩放引入的额外模糊，同时保持了该版本能提供的最佳实际视觉质量。
先前全局叠加方法中的坐标漂移错误——即 Logo 可能在宽度小于 1920px 的源视频上发生偏移——已从结构上消除，因为每个输出的激活完全在输出坐标中操作。
替换 Logo 现在是一个简单的操作任务：使用单个脚本重新生成特定于版本的资产并上传它们。无需重新编码视频，也无需手动编辑每个版本。
此实现遵循一个简单的工程原则：尽可能在管道的早期解决问题，并围绕平台能力进行设计，而不是依赖下游的变通方案。通过在编码前准备正确的资产，实时管道保持更简单、更可预测且更易于维护。
如果您在实时视频管道中遇到类似的版本或叠加质量问题，请联系我们。
技术栈： AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
