El logotipo de un canal FAST —la pequeña marca en la esquina— es la única constante visual en cada programa, cada pausa publicitaria, cada cartel que emite el canal. Debe verse profesional en cada nivel de calidad que un espectador pueda recibir. El enfoque ingenuo —subir una imagen maestra y dejar que AWS MediaLive la escale por cada versión— produce un logotipo nítido a 1080p y uno visiblemente suave a 360p. Esto es un problema de marca para cada espectador que no tiene banda ancha. Así es como ajustamos el tamaño del logotipo a la cuadrícula de píxeles exacta de cada versión.
Resumen rápido
| Aspecto | Detalle |
|---|---|
| Dominio | Superposición de logotipo de canal (DOG) en canales FAST |
| Mecanismo | StaticImageOutputActivate por salida por versión (1080p, 720p, 480p, 360p) |
| Generación de activos | Script de Python usando remuestreo Lanczos |
| Tiempo de activación | 1.5s después de cada cambio de entrada de programa |
| Estado | 1× pila por versión en producción |
El problema de negocio
Un canal FAST no ofrece un único nivel de calidad. MediaLive codifica el mismo canal en múltiples versiones — 1080p, 720p, 480p, 360p — y el reproductor de cada espectador elige la mejor que su conexión puede soportar. Los espectadores móviles con datos celulares ven 360p; los espectadores de smart-TV con banda ancha obtienen 1080p. Todos están viendo la misma marca, y todos esperan que se vea profesional. Cuando el logotipo es nítido a 1080p y visiblemente suave a 360p, la marca es inconsistente —no es un detalle menor en un canal 24/7 donde el logotipo es el único elemento que los espectadores ven más que cualquier programa individual.
Dónde se aplican realmente las superposiciones
En una tubería de codificador de múltiples versiones, una superposición puede aplicarse en dos lugares:
Antes del escalador por versión, donde una imagen maestra se compone sobre la fuente y todo el conjunto se reduce por salida — esto es lo que hace MediaLive con una acción global StaticImageActivate
después del escalador, donde cada salida obtiene su propia superposición aplicada una vez que el lienzo ya está en tamaño final. La diferencia parece pequeña en la API. Visualmente, no lo es. Cualquier cosa compuesta antes del escalador hereda cada artefacto que introduce el escalador, y a 360p, el escalador es agresivo.
Por qué fallan las soluciones obvias
"Subir una maestra y dejar que MediaLive la escale." La acción global compone la maestra antes de que se ejecute el escalador por salida. Una maestra grande reducida a un logotipo de 64×21px para 360p es una reducción de aproximadamente 40x — incluso el remuestreo Lanczos pierde detalles finos a esa proporción, y el resultado luego pasa por la misma cadena de compresión que el propio video.
"Usar una maestra más grande." Esto hace que la relación de reducción sea mayor, no menor — el artefacto empeora, no mejora.
"Omitir el logotipo en salidas SD." Los requisitos de cumplimiento y de marca exigen la marca en cada versión. No es una opción.
"Grabar el logotipo en el video fuente en el momento de la codificación." Pierde cada palanca operativa — no hay cambios de logotipo por campaña o por región, y no hay actualización sin volver a codificar toda la biblioteca.
"Usar una superposición global con coordenadas manuales por resolución." La acción global calcula la posición contra una referencia fija de 1920×1080, por lo que los videos fuente más estrechos que eso producen coordenadas fuera del lienzo — el logotipo se desplaza de la esquina o se recorta.
La verdadera palanca fue eludir por completo el escalado de superposición de MediaLive: ajustar el tamaño del logotipo al lienzo de cada versión nosotros mismos, antes de que el codificador lo toque.
La solución
El logotipo de cada versión se prerrenderiza a sus dimensiones exactas en píxeles y se almacena como un PNG separado. En cada límite de programa, un orquestador Lambda emite cuatro StaticImageOutputActivate acciones —una por versión— cada una apuntando al PNG ya dimensionado para esa salida específica. MediaLive no realiza ningún escalado en la superposición.
GLOBAL (ingenuo) POR-SALIDA (lo que entregamos)
master.png ──► compuesto sobre master.png ──► Redimensionamiento Lanczos (offline)
lienzo fuente en 4 PNGs de tamaño exacto
│ │
▼ ▼
escalador por versión escalador por versión
(también escala la (la superposición no se toca —
superposición → logo compuesta después, a
suave en salidas SD) tamaño exacto en píxeles)Un script de Python genera los cuatro PNGs dimensionados a partir de una única maestra utilizando remuestreo Lanczos, elegido por su comportamiento predecible y repetible en tamaños pequeños, más que por ganar un concurso de calidad de píxeles. Cada logotipo ocupa aproximadamente el 10% del ancho de su lienzo — visible sin ser intrusivo — y añadir una nueva versión es una única entrada de array más un nuevo PNG.
Decisiones clave dignas de mención
Retraso de activación de 1.5 segundos. Las acciones de activación de marca de agua se disparan 1.5 segundos después de cada cambio de entrada, no en el momento exacto del cambio — la activación inmediata puede parpadear contra cuadros aún no estables. El valor se ajustó empíricamente y se centralizó como una única constante para que los ajustes futuros sean un cambio de una sola línea.
Generación de activos offline, activada por humanos — deliberadamente. La tubería de redimensionamiento Lanczos no está automatizada como paso de construcción o transformación del lado del CDN. Los activos del logotipo cambian con la suficiente poca frecuencia como para que una regeneración con un solo comando sea la cantidad correcta de automatización; el costo de construir más automatización supera el de ejecutar un script dos veces al año.
Existe una variante "gruesa" pero no se entrega. El generador también produce una variante con alfa dilatado y trazos más gruesos, diseñada para sobrevivir a la cuantificación H.264 en bajas tasas de bits SD. No está en producción — la variante estándar es suficiente para el rango de tasas de bits actual, y ninguna medición justifica aún el cambio. Existe como reserva probada en código: barata de mantener disponible, prematura de enviar.
Lo que seguimos observando
Ninguna tubería de video en producción está verdaderamente terminada, y aún existen oportunidades para refinar este enfoque con el tiempo.
La implementación actual asegura que cada versión reciba un logotipo preparado específicamente para su propia resolución de salida, eliminando el escalado de superposición en tiempo de ejecución de la tubería de MediaLive. La apariencia final, sin embargo, sigue limitada naturalmente por la resolución y la compresión de video de cada versión, particularmente a tasas de bits más bajas. A medida que los perfiles de streaming evolucionen, continuaremos evaluando si diferentes tratamientos de logotipo proporcionan beneficios visuales medibles bajo esas condiciones.
El generador de activos ya soporta tanto la variante estándar como una más gruesa del logotipo. Si pruebas futuras demuestran que la versión más gruesa funciona mejor para versiones de menor tasa de bits, haremos que la selección de la variante del logotipo se base en la configuración para que pueda cambiarse sin volver a desplegar la aplicación.
Resultados
Cada versión recibe ahora un logotipo dimensionado específicamente para su propio lienzo, sin que MediaLive realice ningún escalado de superposición en tiempo de ejecución. Cada salida utiliza arte preparado para su resolución objetivo, evitando el suavizado adicional introducido por el escalado de superposición en tiempo de ejecución mientras se conserva la mejor calidad visual práctica que esa versión puede ofrecer.
El error de desviación de coordenadas del enfoque de superposición global anterior, donde los logotipos podían desplazarse en videos fuente más estrechos que 1920px, se elimina estructuralmente porque la activación por salida opera enteramente en coordenadas de salida.
Reemplazar el logotipo es ahora una tarea operativa sencilla: regenerar los activos específicos de la versión con un solo script y subirlos. No se requiere recodificación de video ni edición manual por versión.
Esta implementación sigue un principio de ingeniería simple: resolver los problemas lo antes posible en la tubería y diseñar en función de las capacidades de la plataforma en lugar de depender de soluciones provisionales posteriores. Al preparar el activo correcto antes de la codificación, la tubería en vivo sigue siendo más sencilla, predecible y fácil de mantener.
Si se encuentra con problemas similares de calidad de versiones o superposiciones en una tubería de video en vivo, póngase en contacto.
Pila Tecnológica: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)
