Una entrada, múltiples programas de canales FAST

Una entrada, cientos de programas — Ejecutando canales FAST 24/7 en MediaLive

Un canal FAST 24/7 reproduce cientos de programas únicos al día, todos los días, para siempre. AWS MediaLive limita un canal a 20 anexos de entrada. El diseño ingenuo —una entrada por video— agota las ranuras antes del mediodía y fuerza un reinicio del canal que desconecta la transmisión en vivo. Resolvimos esto con una entrada dinámica que sirve a cada programa que el canal reproducirá, y una capa de orquestación a nivel de programa que mantiene la línea de tiempo auto-reparable a través de despliegues, fallos parciales y ediciones del operador.

Esta es la historia de ingeniería de cómo funciona realmente esa orquestación.

Resumen rápido

El problema de negocio

Un canal FAST es un servicio 24/7. Los operadores programan con antelación una semana o un mes completo de videos únicos, y el canal tiene que reproducir cada uno en el segundo exacto —cambiar de fuente limpiamente, mantener la marca de agua estable, emitir señales de pausa publicitaria, rellenar cualquier hueco con un slate con la marca de la estación. El espectador nunca debería ver un fotograma en negro, un logotipo atascado o el programa de la semana pasada en bucle.

Esa orquestación tiene que sobrevivir a todo lo que los operadores le hagan: editar la programación de mañana, añadir pausas publicitarias a mitad de semana, redesplegar después de un solo programa fallido, ejecutar dos clics de Deploy. El sistema aplica cada cambio de forma atómica al canal en vivo o se recupera limpiamente. "El canal se encuentra ahora en un estado que nadie entiende" no es un resultado aceptable en una infraestructura que se transmite en vivo.

Un breve resumen de MediaLive en 60 segundos

AWS MediaLive es un codificador en la nube de ejecución prolongada. Le proporcionas una o más entradas (transmisiones de origen o URLs de archivo) y una programación de acciones temporizadas —cambiar a esta entrada, activar esta superposición, insertar esta señal. El codificador se ejecuta indefinidamente, ejecutando acciones en sus marcas de tiempo programadas y emitiendo un HLS manifest que el reproductor del espectador consume.

Dos límites de AWS configuran todo lo siguiente:

• 20 anexos de entrada por canal. Límite estricto. Un canal de "Las 20 mejores películas" diseñado ingenuamente con una entrada por video llena el límite en la película 21.
• 1500 acciones de programación por canal. También un límite estricto. Cada programa consta de varias acciones (cambio de entrada, marca de agua por versión, señales de anuncio, cambio a slate), por lo que el límite real está más cerca de unos pocos cientos de programas en un momento dado.

Ambos límites son importantes para un canal 24/7 que se espera que reproduzca contenido único indefinidamente.

Por qué fallan los enfoques ingenuos

Los caminos obvios fallan de diferentes maneras:

• "Una entrada por programa." completa el límite de 20 anexos del primer día. Añadir más requiere recrear el canal —y la recreación del canal tarda 60-90 segundos durante los cuales la transmisión en vivo se interrumpe. Inaceptable en un servicio 24/7.
• "Recrear el canal para cada despliegue." El mismo problema, en cada despliegue. Los espectadores experimentan una interrupción cada vez que cambia la programación. Esta no es una opción real para un canal que se supone que está en vivo.
• "Pre-codificar toda la semana en un único archivo gigante en bucle." Mata el modelo de edición. ¿Quieres reordenar mañana? Vuelve a codificar toda la semana. ¿Quieres insertar un anuncio? Vuelve a codificar. La razón principal por la que los canales FAST funcionan como negocio es la programación dinámica y la inserción de anuncios por pausa — quemar todo en un solo archivo impide ambas cosas.
• "Ejecutar múltiples canales en paralelo." Requiere que el reproductor cambie entre ellos, multiplica el costo de AWS y rompe la cadena de audio, MediaPackage y CDN. No resuelve el problema, sino que lo multiplica.

La palanca que teníamos era una única característica documentada por AWS — el marcador de posición $urlPath$ en una entrada dinámica — y la libertad de construir cualquier orquestación que quisiéramos sobre ella.

Por qué esto es importante. El truco no es usar $urlPath$. AWS lo documenta. El truco es construir una capa de orquestación auto-reparable sobre ella que sobreviva a despliegues parciales, ediciones del operador y reintentos concurrentes —sin que el canal en vivo entre nunca en un estado que nadie pueda describir desde la UI.

Nuestra solución

Un canal de MediaLive. Una entrada dinámica vinculada a la URL exacta $urlPath$. Una entrada slate para rellenar huecos. En cada límite de programa, una acción InputSwitchScheduleActionSettings anula la URL de la entrada dinámica con la ruta S3 real de ese programa. El canal nunca necesita un nuevo anexo de entrada, nunca necesita un reinicio, nunca se desconecta.

El trabajo interesante es la capa de orquestación que se ejecuta encima de esa única entrada — nombrando cada acción con un ID de programa para que las huérfanas puedan limpiarse después de un fallo, rellenando los huecos ≥ 6 segundos con un slate para que el espectador nunca vea un fotograma congelado, activando la marca de agua un momento medido después de cada cambio de entrada para que la superposición no parpadee a través de los fotogramas en búfer, y pre-validando contra el límite de 1500 acciones para que los despliegues fallen en la UI en lugar de en medio de la ejecución en AWS.

Diagrama 1 · Arquitectura del canal

Arquitectura

• Entrada slate — un recurso estático adjunto al canal para rellenar los huecos entre programas.
• Entrada dinámica — creada una vez con Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. La URL es un marcador de posición; la ruta real se proporciona por programa en el momento de la programación.
• Orquestador Lambda (fastChannel-lambda-fun/index.js) — gestiona cada actividad que aparece en el canal. Genera un programId hexadecimal de 8 bytes por programa y etiqueta cada acción relacionada con él.
• Programación de MediaLive — una única lista ordenada de acciones, todas fluyendo a través de un BatchUpdateScheduleCommand. Limitado a 1500 acciones por AWS.
• Pre-validación de backend (schedule.service.ts) — llama a GET_SCHEDULE_COUNT de Lambda antes de cada despliegue y se niega a continuar si las nuevas acciones excederían el límite.

• Limpieza de huérfanas (sweepIncompleteProgramGroups) — se ejecuta después de cada despliegue. Agrupa las acciones por programId, elimina cualquier grupo al que le falte su acción de anclaje input-switch.

   

Decisiones clave de ingeniería

1. Una entrada dinámica, una anulación de URL por programa

La entrada dinámica se crea con Sources: [{ Url: "$urlPath$" }]. En cada límite de programa, la Lambda emite una acción InputSwitchScheduleActionSettings que suministra UrlPath: [program.videoUrl] — la URL S3 real del MP4 de ese programa. MediaLive sustituye el marcador de posición en el momento de la ejecución y extrae de la fuente real.

Un anexo de entrada ahora sirve a cada programa que el canal reproducirá —efectivamente videos únicos ilimitados durante la vida útil del canal, limitados solo por el límite de acciones de programación por despliegue en un momento dado. El límite de 20 entradas deja de ser una restricción, y el canal nunca necesita un reinicio para añadir nuevo contenido.

Diagrama 2 · Anulación de URL de entrada dinámica

Compromiso que hicimos intencionalmente. Una entrada dinámica no pre-valida la URL — MediaLive solo resuelve el marcador de posición en el momento del cambio, por lo que un error 404 aparece como un error del lado de la transmisión en lugar de un rechazo en el momento del despliegue. Aceptamos ese costo en cambio de la simplicidad arquitectónica de una sola entrada. La validación ffprobe separada del backend detecta fuentes malformadas antes del despliegue.

2. Nombres de acción etiquetados por programa permiten la auto-reparación

Cada acción emitida por la Lambda lleva el programId hexadecimal de 8 bytes del programa en su nombre: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Después de cada despliegue, sweepIncompleteProgramGroups lista cada acción actualmente en el canal, las agrupa por su programId incrustado, y elimina cualquier grupo al que le falte su acción de anclaje input-switch. Esa es la ruta de limpieza para despliegues parciales fallidos, ediciones conflictivas y cualquier otra condición que pueda dejar el canal con acciones huérfanas de un programa.

La codificación del nombre de la acción es todo el mecanismo de identidad. MediaLive en sí no tiene el concepto de "programa" — la capa de orquestación proyecta uno sobre él mediante convenciones de nomenclatura.

Por qué esto es importante. Sin el ID de programa incrustado en cada nombre de acción, la limpieza de huérfanas no tendría forma de saber qué acciones pertenecen juntas. La limpieza a nivel de acción borraría demasiado (reinicio de todo el canal) o demasiado poco (marcas de agua abandonadas que nunca se apagan). La convención de nomenclatura es el modelo de datos.

3. La regla slate de 6 segundos

Los programas rara vez se suceden perfectamente —casi siempre hay un hueco de unos segundos entre el final de un MP4 y el inicio del siguiente programa programado. La orquestación emite una acción de cambio a slate siempre que ese hueco sea ≥ 6 segundos (MIN_SLATE_GAP_MS = 6000).

El umbral no es arbitrario. MediaLive impone un espaciado mínimo de 5 segundos entre dos acciones de programación; emitir un cambio a slate más cerca de lo permitido del cambio de entrada del siguiente programa produce un rechazo. La regla de los 6 segundos le da a MediaLive su hueco requerido y deja a la capa de orquestación un segundo de margen de seguridad para la deriva del reloj. Por debajo de 6 segundos, dejamos que el último fotograma del programa anterior se congele brevemente en lugar de arriesgarnos a un rechazo de despliegue.

4. Marca de agua por versión con retraso de activación medido

La marca de agua es una acción StaticImageOutputActivate emitida por cada versión de salida (1080p, 720p, 480p, 360p) — cuatro acciones por programa. Cada acción se activa 1.500 ms después del cambio de entrada de ese programa.

El retraso existe porque los primeros fotogramas después de un cambio de entrada todavía están en búfer; activar la superposición en el momento exacto del cambio puede producir un parpadeo breve mientras la superposición se pinta en un fotograma aún no completamente renderizado. 1.500 ms fue el valor que produjo consistentemente una activación limpia en las cuatro versiones en las pruebas. Es una constante medida, no un parámetro documentado de MediaLive — y reside en un solo lugar del código para que futuras sintonizaciones sean un cambio de una sola línea.

Compromiso que hicimos intencionalmente. Las acciones de superposición por versión cuestan 4 veces el número de acciones en comparación con una única superposición global. Aceptamos el costo porque la ruta por versión permite que cada salida obtenga una marca de agua dimensionada exactamente para sus dimensiones de píxeles, en lugar de permitir que MediaLive reduzca una única superposición en las cuatro. El resultado es un logotipo visiblemente más nítido en las salidas SD — y deja suficiente presupuesto de acciones para cientos de programas antes de que el límite de 1500 sea relevante.

5. El límite de 1500 acciones, pre-validado en la UI

AWS limita estrictamente un canal de MediaLive a 1500 acciones de programación. Con ~7-8 acciones por programa (cambio de entrada + 4 marcas de agua + 2 señales de anuncio + slate ocasional), el canal puede albergar aproximadamente entre 180 y 200 programas activos, dependiendo de la densidad de anuncios y la frecuencia de slate. Eso es un límite real para los despliegues a largo plazo, y el número exacto depende de la complejidad de cada programa.

Antes de cada despliegue, el backend llama a GET_SCHEDULE_COUNT de Lambda, que cuenta las acciones en vivo en el canal a través de DescribeScheduleCommand y devuelve { liveCount, capacity: 1500 }. Si liveCount + (newPrograms × 8) excediera 1500, el backend lanza SCHEDULE_ACTION_CAP_EXCEEDED con el número exacto de margen — antes de enviar algo a MediaLive. El operador ve el límite en la UI con la guía para borrar programas anteriores primero. El despliegue nunca falla a medio camino.

Diagrama 3 · Cronología de acciones de un programa

Resultados

• Un único canal de MediaLive sirve programas únicos efectivamente ilimitados durante su vida útil, con un único anexo de entrada dinámica. El límite de 20 entradas ya no es una restricción que debamos considerar — la capacidad en un momento dado está regida por el límite de acciones de programación, no por el límite de entradas.
• La orquestación del canal es auto-reparable: cada despliegue termina con una limpieza de huérfanas, por lo que los despliegues parciales fallidos no pueden dejar la programación en un estado inconsistente.
• La capacidad de programación está limitada y es visible. Los operadores ven el límite de 1500 acciones en la UI antes de hacer clic, no como un rechazo opaco de AWS a mitad del despliegue.
• La convención de nomenclatura de ID de programa es toda la capa de identidad — y es una cadena. Sin nueva infraestructura, sin almacenamiento adicional, sin dependencias. La proyección más simple posible de "programa" en la lista plana de acciones de MediaLive.

Pila tecnológica: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)