Blog de Amazon Web Services (AWS)
Distribución de video en vivo a través de los servicios de AWS
Por Víctor López, arquitecto de soluciones especializado en Media & Entertainment
Introducción
La necesidad de los proveedores de contenido para generar distribución de contenido en vivo a través de internet para mejorar la calidad, reducir latencia o simplemente por la falta de infraestructura por parte de los operadores de TV de paga para recibir los canales de TV por satélite ha impulsado a que este tipo de flujos sean utilizados con mayor frecuencia.
Entregar servicios en vivo a través de internet requiere de proporcionar el camino adecuado, la seguridad de la transmisión y recepción, así como las herramientas para monitoreo desde el inicio hasta el final del flujo.
Alcance
En este blog hablaremos de las mejores prácticas con el objetivo de generar una señal en vivo desde un sitio hacia AWS y cómo hacer la distribución de ese contenido, de manera segura, resiliente y con las herramientas de monitoreo necesarias.
Comencemos por explicar por medio de un diagrama la arquitectura del flujo de trabajo que puede utilizar el proveedor de contenido en vivo para distribuir su canal en vivo a cualquier operador de TV de paga desde su sitio de transmisión hasta cualquier parte del mundo.
Arquitectura
El diagrama considera una arquitectura híbrida utilizando los servicios y soluciones on-premise de AWS; comenzamos por una solución para la contribución del canal en vivo hacia la nube y AWS. Esta solución ofrece la capacidad de generar un canal en vivo desde el sitio de transmisión del proveedor, tomando como entrada la señal en SDI (Serial Digital Interface) que puede provenir de un router de SDI o de un distribuidor de video.
Consideramos el uso de un encoder Elemental Live para contribuir el video en cualquiera de los códecs de video disponibles como en configuración de redundancia 1 + 1 y controlado a través del sistema de gestión Elemental Conductor Live. El video generado por la solución de encoding de Elemental Live puede ser en cualquiera de los protocolos soportados. Estamos contemplando el uso de un camino redundante utilizando dos proveedores de internet diferentes para inyectar ambos flujos a la nube de AWS. En este blog usamos SRT (Secure Reliable Transport), uno de los protocolos más utilizado para distribución de contenido.
El servicio de AWS utilizado para la distribución del contenido es AWS Elemental MediaConnect, diseñado para ofrecer la posibilidad de recibir un flujo de video redundante y distribuirlo a cualquier región a los operadores de TV de paga de una manera segura, confiable y con el monitoreo de los parámetros de video que identifican si hay algún error para la solución de problemas.
Pueden monitorearse los parámetros de video esenciales basados en el standard TR 101 290 en prioridades 1 y 2 , la evaluación de la salud de los flujos se realiza a través del servicio AWS CloudWatch, este servicio se encarga de seleccionar métricas de los parámetros esenciales y agruparlos para mostrarse en Dashboards a los que pueden tener acceso los operadores del proveedor de contenido
Un requisito indispensable es que estos flujos incluyan la el cifrado del video desde el origen hasta la entrega al proveedor de TV de paga, esto se logra utilizando el servicio de AWS Secrets Manager. Permite utilizar una llave por ejemplo de 64 Bytes en Hexadecimal que puede ser compartida con el operador para configurarla dentro del dispositivo que recibirá la señal para descifrar el contenido. La granularidad del acceso a los servicios de seguridad de AWS, permite crear una llave para cada uno de los flujos o decidir si se usa una llave común para todos los flujos, eso muestra la flexibilidad para adaptarse a las necesidades del cliente.
Diseño
- Flujo
El primer paso es generar el punto de contribución en AWS Elemental MediaConnect, para esto requerimos crear el flujo decidiendo la región más cercana a la ubicación de nuestro sitio de contribución; para este caso seleccionamos la región us-east-1.
Existe la posibilidad de seleccionar la Zona de Disponibilidad para cada flujo, puedes tomar la decisión de dividir tus flujos en diferentes Zonas cuando necesites crear más de un canal.
- Fuente u Origen
Para este blog estaremos utilizando la configuración de los encoders de Elemental Live con salida Secure Reliable Transport (SRT), incluida la llave de cifrado generada por cualquier herramienta de terceros y que es administrada por el servicio de Secrets Manager el cual permite utilizar una configuración estandarizada en la mayor parte de los equipos de codificación.
Es necesario seleccionar la opción de Standard Source.
Como Source Name es aconsejable incluir alguna diferencia entre fuente principal y fuente de respaldo, para este caso tecleamos: blog-post-source-main
Como protocolo tenemos la opción de utilizar SRT-listener o SRT-Caller, dado que buscamos la menor complejidad para los proveedores contenido, la mejor opción es configurar SRT-Listener.
Si la fuente de origen proviene desde un punto que utilice una IP pública estática, es posible filtrar el acceso a la entrega del contenido solo a través de esa IP usando el CIDR block.
Para decidir el puerto de entrada en la fuente hay que considerar que en caso de utilizar fuentes principales y de respaldo ambos deben ser diferentes.
El bitrate máximo a considerar por cada fuente de origen, dependerá del valor que se asigne desde el encoder que contribuirá la señal.
Latencia mínima dependerá del valor que se utilice en el encoder de origen, la latencia se requiere para poder retransmitir paquetes en caso de que haya una pérdida, entre mayor sea el valor, la resiliencia de la transmisión a posibles fallas será mejor.
Ya solo es necesario presionar el botón de Crear Flujo.
Al crear el flujo se configura automáticamente una IP pública estática asignada para ese flujo.
- Configuración de tipo de redundancia
Existe la posibilidad de crear una fuente de origen de respaldo, esto se logra con los siguientes pasos:
Habilitar la redundancia.
Seleccionar el modelo de redundancia entre Failover o Merge.
Seleccionar la fuente principal seleccionada en caso de falla y recuperación de la señal.
Una vez habilitada la opción de redundancia se habilita el botón para configurar la fuente de origen de respaldo.
- Fuente de origen de respaldo.
Para crear la fuente de origen de respaldo solo se permite utilizar el mismo tipo de protocolo, por lo que solo hay que llenar los datos restantes con información para diferenciarlos de los datos de la fuente de origen principal.
Después de presionar el botón Add Source se generará la segunda fuente de origen:
Se puede ahora iniciar el flujo para la espera de la conexión de las fuentes de origen.
- Cifrado / Descifrado
Entre las soluciones de distribución de contenido por satélite existe la opción de usar una llave de cifrado administrada por el proveedor del contenido para cada equipo que recibe la señal con los operadores. El equivalente para el caso que presentamos en este Blog es el utilizar un Secret Key a través del servicio llamado AWS Secrets Manager
El primer paso es crear el Secret Key en el servicio AWS Secrets manager, te puedes apoyar en cualquier herramienta en línea que pueda genera una cadena de 64 caracteres aleatorios en Hexadecimal.
Para crearla, hay que seleccionar la opción de “Other type of secret”, borrar el contenido actual en el campo “Plain text” y sustituirlo por la llave generada de 64 caracteres, presionar el botón “Next”.
Para este caso estamos considerando una llave de 64 caracteres en Hexadecimal. Este es un ejemplo de una llave hexadecimal que pueden usar para propósitos demostrativos explicados en este blogposts
f371accdb94e6385736c0b85af9ee3af5e00c491f3711246148c5cc41f4f00fc
En el siguiente punto es necesario agregar un nombre para esta llave, presionar el botón “Next”.
No es necesario configurar una rotación porque los equipos de encoding no tienen la capacidad de cambiar esa llave sin detener los servicios.
Al crear la llave hay dos cosas que hay que considerar para los siguientes pasos:
- El ARN de la llave
- La llave en Hexadecimal, la cual se puede consultar en el campo de “Retrieve Secret Value”
Una vez generada esa llave se puede crear una política en AWS Identity and Access Management que agregue la llave como una política y el flujo de MediaConnect como parte del Trust Relationship.
Comenzamos por crear la política que incluya el ARN de la llave, para ello utilizaremos el siguiente JSON, solo es necesario sustituir el valor del ARN de la llave (incluyendo la cuenta):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetResourcePolicy",
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecretVersionIds"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:ACCOUNT:secret:blog-post-key-im7oDA"
]
}
]
}
Una vez creada la política, podemos comenzar con la creación del Role, comenzando por configurar la Trust Relationship usando el JSON siguiente sustituyendo el ARN del flujo incluyendo la cuenta:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "mediaconnect.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "ACCOUNT"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:mediaconnect:us-east-1:ACCOUNT:flow:1-A1UFVwQPV1NfAlNb-9e25612515fc:blog-post-flow"
}
}
}
]
}
Después seleccionamos la política que creamos anteriormente filtrando la lista de Políticas.
Una vez creado el Role, podemos comenzar a utilizarlo en el flujo creado para descifrar el contenido que se configura desde el encoder. Activando el módulo de “Decryption” donde seleccionaremos el Role y la llave que creamos en los pasos anteriores, así ya podemos actualizar la configuración de la fuente de origen con la llave de cifrado / descifrado.
Aplicamos la misma configuración de cifrado para la fuente de origen de respaldo:
Una vez completando los pasos anteriores, ya estamos listos para configurar el o los encoders de contribución. Para este blog, estaremos utilizando la configuración de los encoders de Elemental Live con la salida Secure Reliable Transport incluida la llave de cifrado administrada por el servicio de Secrets Manager.
Dado que la configuración en MediaConnect fe realizada como SRT Listener en el encoder se debe configurar como SRT Caller. La latencia debe coincidir tanto en el encoder como en MediaConnect, el nivel de cifrado debe ser el mismo que en MediaConnect (AES-256), y por supuesto pegar la llave Hexadecimal que se utiliza en MediaConnect.
Se puede utilizar la misma configuración solo cambiando el puerto SRT para subir la señal de respaldo, que puede salir desde el mismo encoder o desde otro encoder.
Después generar las dos fuentes de origen, MediaConnect permite obtener información gráfica del estado de las fuentes como se puede ver en la siguiente gráfica.
Se puede observar que hay dos líneas identificando las fuentes de origen principal y respaldo ambas con el mismo bitrate, así como el estatus de Ambas fuentes (Connected).
En este punto ya podemos distribuir la señal de origen en cualquier protocolo disponible, SRT o Zixi o RTP, a la cantidad de operadores necesarios hasta 50 o hasta utilizar 400 Mbps en conjunto por todas las salidas, todas ellas en protocolos diferentes y cifradas con la misma o una llave por cada operador.
Para lograrlo, podemos crear una salida presionando el botón “Add Output”
Para el propósito de este blog, utilizaremos una salida en SRT, hay que mencionar que se requiere utilizar un puerto diferente a los que se usaron para la contribución de la señal.
Para poder demostrar que la configuración de salida funciona, se puede utilizar un encoder con recepción en IP que pueda recibir flujo en SRT cifrado.
En este caso, estamos considerando los mismos valores de configuración que se utilizaron en la salida de MediaConnect aplicados a la entrada del encoder, como lo hicimos en la contribución, esta vez estamos usando un encoder Elemental Live para recibir esa señal.
También es posible utilizar el software de VLC para confirmar que la señal se está recibiendo de la manera correcta, para esto utilizaremos el siguiente comando:
srt://34.225.49.217:4500?mode=caller&passphrase=f371accdb94e6385736c0b85af9ee3af5e00c491f3711246148c5cc41f4f00fc
Este comando requiere varios componentes:
- Protocolo: En este caso Secure Reliable Transport
- IP asignada por la instancia de Elemental mediaConnect
- Puerto configurado en la salida del flujo de Elemental MediaConnect
- Modo de reproducción: Dado que la configuración en MediaConnect en la salida del flujo fue realizada como SRT Listener, es necesario utilizar el modo Caller en VLC u otros equipos de encoding o software que puede ser utilizado en cualquier servidor compatible con ese protcolo.
- Llave de descifrado capturada en el servicio de Secrets Manager Service
Con todo este flujo End to End podemos corroborar que MediaConnect es un servicio muy útil para los proveedores de TV en Vivo para hacer la transición de la distribución por satélite hacia la distribución por IP de manera eficiente y flexible y con la seguridad que su distribución puede incluir la cifrado.
Acerca de lo autor
Víctor López es un arquitecto de soluciones especializado en Media & Entertainment, ubicado en México, con más de 20 años de experiencia en la industria de la TV de Paga, ha participado en proyectos en Latinoamérica relacionados con servicios de Cable, IPTV, DTH, FTTH. Disfruta el ofrecer soluciones a los clientes donde pueden explotar en potencial entero de los servicios de Media de AWS.