Montar un servidor multimedia avanzado sobre Azure es una de las formas más flexibles y potentes de emitir vídeo en directo y bajo demanda sin tener que comprar, mantener ni sobredimensionar tu propia infraestructura. La plataforma de Microsoft pone a tu alcance la misma tecnología que se ha usado para eventos gigantescos (como unos Juegos Olímpicos) pero con un modelo de pago por uso que te permite empezar con muy poco y escalar hasta donde haga falta.
En las próximas líneas vas a ver cómo funciona realmente un servidor multimedia en Azure, qué piezas técnicas intervienen (canales, programas, orígenes, activos, CDN, protección de contenidos, precios, etc.) y cómo encajan en un caso muy realista: un concierto en directo que se quiere retransmitir a miles de personas, y que además se desea conservar para verlo después como vídeo bajo demanda (VOD). Todo explicado con lenguaje llano, pero sin escatimar en detalle técnico.
Crea tu servidor multimedia avanzado con Azure: visión general
Cuando hablamos de “servidor multimedia” en Azure, en realidad hablamos de un conjunto de Servicios multimedia de Azure (Azure Media Services) que se encargan de recibir tu señal de vídeo, codificarla o procesarla si hace falta, almacenarla, protegerla, empaquetarla en los formatos que necesitan los dispositivos y distribuirla a gran escala, normalmente apoyándose en una red de entrega de contenido (CDN).
El punto fuerte de este enfoque es que todo el esfuerzo duro de infraestructura (servidores físicos, redundancia, conmutación por error, escalado, acuerdos con proveedores de CDN, etc.) lo asume Microsoft, y tú te centras en producir el contenido y en orquestar la emisión mediante una API y unas pocas piezas clave que hay que conocer bien.
Para que el concepto de servidor multimedia avanzado tenga sentido, es fundamental entender que Azure permite tanto streaming bajo demanda (VOD) como streaming en directo. El servicio de vídeo a petición se basa en ficheros ya codificados y almacenados, mientras que la emisión en vivo añade la noción de “canal” que recibe una señal continua y va generando salidas adaptativas listísimas para llegar a miles de clientes.
En el caso de los eventos en directo, Azure ofrece una capa de transmisión en vivo muy afinada para grandes escalas. No es teoría: la plataforma se ha utilizado para retransmitir acontecimientos del calibre de los Juegos de Sochi 2014, con múltiples centros de datos, codificación redundante, varios orígenes, múltiples niveles de backup y acuerdos con grandes CDN. De ahí heredas tú la robustez cuando montas tu propio servidor multimedia.
Componentes clave: canales, programas, activos, orígenes y localizadores
Para explotar al máximo Azure como servidor multimedia tienes que manejar una serie de conceptos básicos de Media Services que aparecen una y otra vez en la documentación y en el desarrollo de la solución: canal, programa, activo, origen, localizador, URIs de introducción y vista previa.
Canales
El término “canal” (Channel) describe todo el recorrido extremo a extremo de una señal de vídeo en directo desde que entra en Azure hasta que se pone a disposición de los dispositivos de los usuarios. El canal puede estar, básicamente, en dos estados: “detenido” y “en ejecución”. Al arrancarlo, la plataforma asigna recursos, levanta puntos de entrada, equilibra carga y prepara todo para que el vídeo fluya con redundancia.
Cada canal expone una URI de introducción (ingest) que actúa como punto donde el codificador de vídeo envía la señal, normalmente en RTMP o MPEG-TS. Esta dirección solo debería estar accesible desde las IP de tus codificadores o sistemas de producción, de ahí que se suela restringir mucho el acceso mediante listas de IP permitidas o mecanismos de autenticación.
Al mismo tiempo, el canal ofrece una URI de vista previa. Esa salida refleja la señal tal y como la recibe Azure (antes de exponerla al público) y sirve para que el equipo técnico pueda hacer comprobaciones, validar audio y vídeo, o monitorizar la calidad sin afectar a los usuarios finales. De nuevo, lo lógico es que esta vista previa esté limitada a ciertas IP o entornos internos.
Programas
Para organizar el tiempo dentro de un canal se definen uno o varios programas (Programs). Cada programa representa un tramo temporal de la transmisión en directo que se va a conservar y tratar como un activo independiente: por ejemplo, el concierto principal, la actuación de teloneros, un bloque VIP, etc. Cada programa se asocia a un activo en almacenamiento de blobs y se puede arrancar y detener de manera independiente, incluso solapándose.
Activos y localizadores
El activo (Asset) es la pieza que representa los datos almacenados: puede contener uno o varios archivos de vídeo, audio, imágenes, miniaturas y el manifiesto necesario para el streaming adaptativo. Los activos tienen vida propia: pueden seguir existiendo aunque ya hayas eliminado el programa que los originó, lo que resulta clave para el VOD posterior.
Sobre un activo se crean localizadores (Locators), que son básicamente URIs de acceso que se asocian con un origen (Origin) y una política de acceso. Ese localizador es el punto de salida que se usa para que aplicaciones y CDN obtengan el contenido en los formatos de streaming adaptativo necesarios (Smooth Streaming, HLS, DASH, etc.).
El origen (Origin) representa el servicio de salida escalable que se encarga de entregar las secuencias de vídeo a los clientes o a la CDN. Cuando se habilita un origen, estás levantando un punto de publicación capaz de servir de forma dinámica las distintas variantes de calidad y protocolo en función del manifiesto y de la petición del cliente.
De la señal SDI a Azure: codificador, protocolos y formatos
El equipo de TI necesita entender con claridad qué tipos de señal entra y sale del sistema. Recibe una señal SDI HD y tiene que convertirla en flujos preparados para Internet (RTMP o MPEG-TS) que Azure Media Services acepte en la URI de introducción del canal en directo.
Al mismo tiempo, es imprescindible asegurarse de que los diferentes dispositivos de los usuarios puedan reproducir el streaming sin problemas. La estrategia típica pasa por usar protocolos de streaming adaptativo bien soportados: Smooth Streaming para entornos Windows clásicos, HLS para iOS y gran parte de Android, y DASH para Windows 8.1, Windows Phone y Xbox One.
Con esto claro, el equipo selecciona un codificador o PC para streaming profesional que sea capaz de recibir la señal SDI HD y producir streams en múltiples bitrates (MBR) hacia Azure. Ese codificador se configurará para enviar la señal a la URI de ingestión del canal, empleando RTMP o MPEG-TS, y será el intermediario entre el mundo “broadcast” (SDI) y el mundo IP (HTTP, streaming adaptativo, etc.).
Una vez elegida la pieza de codificación, los técnicos descubren que los Servicios multimedia de Azure se integran muy bien con este esquema: reciben el flujo en tiempo real, lo procesan, generan las distintas variantes de calidad y lo ponen a disposición de los clientes finales mediante URLs específicas para cada protocolo y dispositivo, sin que tú tengas que preocuparte de reempaquetar a mano.
Otro detalle importante es que la plataforma está preparada para exponerse a redes de entrega de contenido (CDN) como Akamai u otras, de forma segura. Los puntos de salida de Azure (orígenes) ya contemplan este uso y facilitan el acceso autenticado de la CDN a tu contenido para que después se replique alrededor del mundo y minimice latencias y cuellos de botella.
Preparando la cuenta de Azure y los servicios multimedia
El segundo sprint del proyecto se centra en que los desarrolladores pongan en marcha todo el entorno en la nube. Lo primero es crear una suscripción de Azure y una cuenta de Servicios multimedia. Durante el proceso de alta de Azure se configura una cuenta (generalmente asociada a un usuario de Microsoft) que servirá para administrar los recursos.
Antes de crear la cuenta de Media Services es necesario definir una cuenta de Almacenamiento de Azure, ya que todos los activos de vídeo que se generen durante el evento (grabaciones, archivos de salida, etc.) se guardarán en almacenamiento de blobs.
Con esto configurado, llega el momento de escribir código. Se suele crear un proyecto base en Visual Studio, añadir los paquetes de NuGet correspondientes a Azure Media Services y empezar por inicializar un objeto CloudMediaContext con las credenciales de la cuenta. Ese contexto será el punto de entrada para crear canales, orígenes, activos, programas y localizadores desde tu aplicación.
Los desarrolladores implementan primero la lógica para verificar si existe o no un origen (Origin) con un nombre concreto y, en caso contrario, crearlo de forma asíncrona. El origen se configura con una determinada capacidad (por ejemplo, dos unidades) y se arranca si estaba detenido. De este modo, el servicio de salida queda operativo para servir vídeo en directo y VOD a los proveedores de CDN.
El siguiente paso en el código es la creación de un canal de transmisión en directo con un nombre exclusivo. Una vez definido el objeto de configuración del canal, se llama a la creación asíncrona del mismo indicando su tamaño (pequeño, mediano, grande) y una descripción. Al completarse la operación, se obtiene la referencia al canal, que luego se utilizará para arrancarlo y gestionar los programas asociados.
Diseño de la línea temporal del evento: programas y activos
La planificación del concierto se traduce en una línea de tiempo de programas dentro del canal. Por ejemplo, se puede asignar todo el tramo del evento (de 17:00 a 2:00) al canal en estado de ejecución, pero subdividirlo en programas: uno principal que cubre todo el concierto, otro para el contenido VIP previo, varios para actuaciones intermedias, etc.
En el código se configura un array de tuplas con el nombre del programa, la ventana DVR y la duración estimada en minutos. Aunque en ciertas versiones previas del servicio se manejaba un valor de ventana DVR explícito, la idea práctica es que cada programa tendrá sus propias dimensiones temporales y se asociará con un activo que capture el vídeo mientras el programa esté en marcha.
Para cada entrada de esa configuración se crea un activo específico al que se le asocia el contenido del programa. Se decide mediante una bandera si el programa debe ser archivado permanentemente para VOD o no, lo que permite que algunos bloques se borren automáticamente y otros se conserven para su explotación posterior. En el ejemplo se fuerza esa captura para casi todos los programas excepto uno, pero la lógica se puede ajustar a tus necesidades.
A continuación, se lanza la creación asíncrona del programa dentro del canal indicando nombre, descripción, si se habilita el archivo, la ventana de DVR y la duración estimada, junto con el identificador del activo. Tras crearlo, se generan localizadores con una política de acceso que puede, por ejemplo, permitir acceso durante 30 días al archivo de manifiesto. De este modo ya se obtiene la URL de salida que la CDN o el reproductor utilizarán para el streaming.
Arranque, parada y costes de los canales en directo
El código necesario para arrancar un canal es muy sencillo: se llama al método asíncrono StartAsync del objeto canal y se espera hasta que finalice. Ahora bien, lo delicado no es la llamada en sí, sino el momento en el que se hace y las implicaciones económicas.
Desde que se envía la orden para pasar el canal de estado detenido a en ejecución, Azure tarda típicamente entre 10 y 20 minutos en tenerlo completamente operativo. En ese intervalo se están aprovisionando todos los recursos de introducción, redundancia y equilibrio de carga necesarios. Por tanto, para no pillarse los dedos, hay que iniciar el canal con suficiente antelación respecto a la hora real de inicio del evento.
En cuanto un canal está en ejecución, comienza la facturación asociada al servicio de streaming. Si tu caso no requiere tener ese canal activo las 24 horas del día, lo lógico es detenerlo en cuanto finalice el evento, y del mismo modo parar los programas que no se estén utilizando para evitar costes innecesarios.
El arranque de un programa es aún más directo: basta con invocar su método StartAsync. A partir de ese momento, el programa empieza a capturar vídeo en el activo asociado y a exponerlo a los clientes finales mediante el localizador correspondiente.
Desde el punto de vista de la experiencia de usuario, conviene dotar a los operadores de una interfaz sencilla que permita crear el evento completo, arrancar y detener el canal, y controlar cada programa con botones muy claros. Internamente, esa UI no hace más que llamar a los métodos que ya hemos comentado, pero al equipo de producción le ahorra dolores de cabeza y reduce el riesgo de errores durante el directo.
Modelos de streaming, precios y ejemplo de cálculo
En Azure, el servicio de streaming se factura como una combinación del uso del servicio de streaming y la transferencia de datos. Al activar Azure Content Delivery Network desde la API o desde el portal para un punto de conexión de streaming, se aplican los precios estándar de la CDN a todos los datos que salgan a través de ese punto. Si no se habilita la CDN, el tráfico se cobra según las tarifas de transferencia de datos de Azure.
Los clientes pueden elegir entre un punto de conexión de streaming estándar y unidades de streaming Premium. El punto de conexión estándar es suficiente para la mayoría de escenarios y escala automáticamente el ancho de banda de salida en función de la demanda. Ofrece las mismas características que las unidades Premium, pero sin necesidad de gestionar la capacidad de forma manual.
Cuando se necesitan cargas de trabajo especialmente exigentes (por ejemplo, emisiones masivas con requisitos de ancho de banda garantizado), entran en juego las unidades de streaming Premium. Cada unidad Premium añade capacidad de ancho de banda dedicada y se pueden “apilar”: cuantas más unidades habilites, más ancho de banda total tendrás disponible para tus emisiones. A diferencia del punto estándar, en las Premium eres tú quien decide cuántas unidades activar.
No hay que olvidar, además, que el streaming propiamente dicho suma otro componente: el uso del servicio de streaming (punto estándar o unidades Premium activas) más el volumen de datos transferidos. Ambos se controlan fácilmente monitorizando las horas que los servicios están encendidos y los gigabytes o terabytes servidos hacia Internet o hacia la CDN.
Protección de contenido y licenciamiento
En muchos casos no basta con emitir; también hace falta proteger el contenido y controlar quién puede verlo. Para eso, Azure Media Services ofrece integración con varios sistemas de protección de contenido y DRM que se cobran según el número de licencias o claves emitidas.
Entre las opciones disponibles se encuentran PlayReady (DRM de Microsoft), Widevine Modular (DRM de Google), Apple FairPlay Streaming y cifrado estándar mediante AES para escenarios donde se facilita la clave de descifrado al cliente final de forma controlada. Cada vez que se emite una licencia o se genera una clave, se registra en el sistema y se factura conforme a la tabla de precios correspondiente.
Si en tu servidor multimedia avanzado necesitas, además, combinar estos servicios de streaming con máquinas virtuales o hosts dedicados para otras piezas de la solución, entra en juego el licenciamiento de Windows Server y SQL Server. En entornos con Azure Dedicated Host, por ejemplo, puedes optar a virtualización ilimitada de SQL Server si dispones de edición Enterprise y Software Assurance activo, o licencias de suscripción adecuadas.
Para Windows Server se requiere la edición Datacenter para beneficiarse de derechos de virtualización ilimitada. Las licencias compradas antes del 1 de octubre de 2019 conceden ese derecho directamente por licencia; las adquiridas a partir de esa fecha lo proporcionan solo mediante la Ventaja híbrida de Azure (Azure Hybrid Benefit). En la práctica, cuando asignas licencias a un host dedicado usando esa ventaja, solo necesitas licenciar los núcleos físicos disponibles (por ejemplo, 32 núcleos en un host tipo 1 de cierta serie).
