¿Qué es un pipeline de vídeo?
Los especialistas en TI conocen desde hace mucho tiempo el concepto de “pipeline”:
- Los administradores de sistemas saben cómo ensamblar una cadena de utilidades de consola en un comando de una sola línea “poderosa”. La salida de un comando fluye hacia la entrada de otro programa, formando una canalización de procesamiento de datos perfecta.
- Los desarrolladores ensamblan un CI/CD que describe la forma de construir y entregar la aplicación a los servidores de prueba y producción.
- Los especialistas en redes comienzan a estudiar el trabajo de la red con el funcionamiento de los protocolos TCP/IP y OSI. Luego ensamblan sus propias redes, eligiendo los equipos necesarios, canales físicos de comunicación, protocolos. La red es también un “transportador” de transmisión de datos: por un lado entraba y por otro salía.
Este artículo de Wikipedia describe otros tipos de pipelines: en informática, gráficos, ventas, logística, cualquier producción industrial e incluso tuberías de agua.
La transmisión de video también es un transportador. En nuestro trabajo, a menudo mencionamos este término: presentamos a los clientes el “el pipeline de video” que estamos construyendo.
¿Dónde comienza el pipeline de video?
La transmisión de video en vivo se asemeja a una corriente de agua. O más bien, un río que baja de una montaña. El flujo de datos es grande y hay muchos procesos asociados con su procesamiento. Sin embargo, cuando lo construyes tú mismo, calculas y piensas en la ubicación de cada nodo. Y el flujo ya se parece a una tubería real: con un montón de ramas, “grúas”, “bombas”, indicadores, reservas y automatización.
El “video transportador” comienza (igual como termina) siempre en el mismo lugar:
En la entrada: la lente de la cámara captura la imagen
A la salida: el espectador mira con sus propios ojos desde la pantalla del dispositivo
Desde la lente hasta el ojo: está es la tubería completa. El espectador ve y escucha el contenido que se ha preparado para él.
Los elementos principales de un pipeline de video.
- Captura de video sin procesar
- Compresión de video
- Empaquetado en un contenedor de medios
- Entrega en línea
- Desempacado del contenedor de medios
- Descompresión de video
- Reproducción
Veamos estos pasos usando el ejemplo de una cámara IP y un reproductor VLC:
- La matriz digitaliza la señal de la lente, convirtiendo la luz en un flujo de bytes divididos en marcos separados. Esto es conocido como video en bruto: una secuencia de fotogramas sin comprimir.
- El procesador de la cámara comprime video utilizando uno de los códecs (H264, H 265), lo que reduce la cantidad de datos que se transmiten a través de Internet.
- El servidor RTSP de la cámara empaqueta fotogramas H264 mediante RTP.
- Los paquetes RTP pasan por la red a través de TCP o UDP.
- El receptor acumula un búfer de tramas del flujo RTP.
- El reproductor descomprime el video.
- La imagen se muestra en la ventana del reproductor.
No podríamos mostrar todos estos pasos usando el ejemplo de Flussonic Media Server, porque sus tareas no incluyen reproducir y mostrar contenido. La ruta completa con Flussonic será más grande y más complicada; así es como sucede en los servicios reales.
Más grande y más complicado
La reproducción directamente desde la cámara, como en el ejemplo anterior, es una de las canalizaciones más simples. En cuanto a Flussonic, tiene otros roles. Por ejemplo, es posible que no haya captura de video sin procesar, pero a cambio se requerirá recibir video ya comprimido a través de la red. En general, es posible reducir las tareas de Flussonic a cambiar los parámetros del códec, los parámetros del contenedor, la grabación y la multiplexación.
Veamos la canalización de video de Flussonic usando el ejemplo de un servicio OTT, donde las transmisiones recibidas por la estación principal se usan como fuente.
Entonces, en la entrada tenemos UDP Multicast con códecs H264 (entrelazados) + Audio MPEG-2, a veces ac3 en canales HD. Necesitamos dar multibitrate HLS y DASH a la salida.
Cómo se verá dentro de un solo servidor:
- Captura UDP
- Desempaquetar contenedores, leer MPEG-TS y extraer "fotogramas" (en este caso, los paquetes de audio y video se pueden nombrar como una sola palabra)
- Desempaquetar códecs originales (obtener video y audio sin procesar)
- Codificación a varias calidades (1080, 720, 576, 480) con el códec H264 con barrido progresivo (hay un entrelazado en la entrada, ¡pero no lo necesitamos!). El sonido está codificado en AAC
- El video comprimido, estrictamente de acuerdo con GOP, se empaqueta en contenedores MPEG-TS y MP4
- Generación de manifiestos HLS y DASH (m3u8 y xml)
- Distribución de contenido en vivo a suscriptores a través del protocolo HTTP
Sin embargo, en realidad, es imposible hacer todo el trabajo en un servidor. Por un lado, hay muchos canales, por el otro, hay muchos suscriptores. Dividiremos un servidor en dos, asignándoles diferentes roles: “Captura y transcodificación” y “Distribución” (resaltados en diferentes colores):
- Captura UDP
- Desempaquetar los códecs originales (obtener video y audio sin procesar)
- Codificación a varias calidades (1080, 720, 576, 480) con el códec H264 con escaneo progresivo; el audio está codificado en AAC
- Marcos de empaquetado en M4F, contenedor independiente de códec para transferencia entre servidores Flussonic
- Transmisión de video sobre protocolo HTTP
- Recepción M4F, extracción de tramas
- El video comprimido, estrictamente de acuerdo con GOP, se empaqueta en contenedores MPEG-TS y MP4
- Generación de manifiestos HLS y DASH (m3u8 y xml)
- Distribución de contenido en vivo a suscriptores a través del protocolo HTTP
Puedes ir más allá y agregar el grabado del archivo al servidor. Entonces quedan tres roles: Ingest+Transcoder, DVR, Edge
Y no olvides que la transcodificación es una tarea que requiere muchos recursos, por lo que necesitamos varios transcodificadores. También hay muchos espectadores, y también se necesitarán varios servidores para atender sus solicitudes. La grabación se puede hacer en un servidor:
- Captura UDP
- Desempaquetar los códecs originales (obtener video y audio sin procesar)
- Codificación a varias calidades (1080, 720, 576, 480) con el códec H264 con escaneo progresivo (hay un entrelazado en la entrada, ¡no lo necesitamos!); el audio está codificado en AAC
- Marcos de empaquetado en M4F – contenedor independiente de códec para la transferencia entre servidores Flussonic
- Transmisión de video sobre protocolo HTTP
- Recepción M4F
- Escritura de datos en el disco, agrupados por intervalos de una hora
- Transmisión de video sobre protocolo HTTP
- Recepción M4F
- Almacenamiento en caché de solicitudes de archivo en SSD
- El video comprimido, estrictamente de acuerdo con GOP, se empaqueta en contenedores MPEG-TS y MP4
- Generación de manifiestos HLS y DASH (m3u8 y xml)
- Distribución de contenido en vivo y DVR a suscriptores a través del protocolo HTTP
Como resultado, construimos una cadena de 13 pasos (en el ejemplo con una cámara IP, teníamos 7 en total). Además, esto es solo un “pedazo” del camino que sigue el video. De alguna manera, los cuadros llegaron a Flussonic vía satélite, comprimidos con un códec, empaquetados en un contenedor de medios, lo que significa que aún quedaban entre 5 y 15 pasos antes de Flussonic.
Nuestra tarea se ha completado: hemos multiplicado la señal de un cable coaxial a Internet, adaptándola simultáneamente a la banda y los requisitos de los dispositivos finales. Además, la ruta del video tampoco termina: nuevamente está esperando desempaquetar y decodificar en el dispositivo final. Y posiblemente, la retransmisión posterior, por parte de otros servidores de medios a otras redes. Tal vez incluso por cable.
Por lo tanto, el pipeline de vídeo se parece a una tubería industrial con cientos de kilómetros de “tubos” y conexiones: decenas de uniones entre programas, protocolos, entornos físicos, servidores, códecs. Un mismo vídeo pasa por varias etapas de compresión, recorre miles de kilómetros a través de diferentes entornos, cambia varios códecs y contenedores.