Versión 26.08

Flussonic 26.08: Catena se migra sola desde Flussonic v3 y Watcher deja de callar sobre un archivo que falta

Por qué Catena no es «Flussonic con un clúster»

Flussonic Media Server se escribió como software para un servidor. Todo en él gira alrededor de la máquina: la configuración vive allí, el stream le pertenece, el archivo se escribe en sus discos. Las funciones de clúster llegaron después y siguieron siendo limitadas — en esencia son un conjunto de acuerdos entre servidores separados, cada uno de los cuales sigue viviendo su propia vida. Una instalación así crece mal: cada máquina nueva es una configuración más que recordar y un servidor más al que entrar para saber qué está pasando.

Catena está construida sobre Sapsan — el nuevo núcleo de streaming de Flussonic escrito en Rust — y está diseñada cluster first. Aquí la unidad de gestión es el clúster, no el servidor, y se nota en cada función:

Lo segundo que distingue a Catena es la introspección del estado a un nivel que nuestros productos nunca han tenido. No «entre en cada servidor y mire los logs», sino una sola interfaz que responde por toda la instalación: un panel de control con gráficas de espectadores y tráfico y un mapa de calor de errores; las sesiones una a una — quién está viendo exactamente ahora y quién veía ayer; el historial de decisiones del layouter con sus motivos; el diagnóstico de la fuente y el diagnóstico del streamer.

Un ejemplo revelador es la monitorización en vivo de las fuentes de respaldo. Pregúntese: ¿cómo se entera hoy de que la entrada de respaldo de un canal está realmente muerta? La respuesta habitual es que no se entera: mientras la fuente principal está al aire nadie toca el respaldo, y su buen estado es una cuestión de fe hasta el momento exacto en que hace falta. Catena comprueba el respaldo mientras espera: la tarjeta de la entrada muestra «Listo» — comprobado y capaz de asumir la carga — o «Sin comprobar», y eso se ve en la pestaña de fuentes de inmediato, no durante la avería. Ahí mismo se ve algo más que «hay cuadros o no»: errores de continuidad MPEG-TS, caída del bitrate, audio perdido, calidad de la línea de tiempo.

Y el plano de control nunca se interpone en el camino del medio: la caída de central es una avería de gestión, no de la emisión — los streams siguen emitiendo.

Y le ayudamos a migrar. El asistente de importación toma la configuración de un Flussonic Media Server en funcionamiento, muestra un plan antes de aplicarlo y un informe después. Pero la herramienta es solo una parte: cuéntenos cómo es su instalación y planificaremos juntos la migración — qué se traslada primero, cómo se verifica la emisión y en qué momento se cambia a los espectadores.

Esto es lo que hicimos para Catena

El paso desde Flussonic v3, con asistente y no a mano. Un cliente con un Flussonic Media Server en funcionamiento no tenía ni procedimiento de migración ni herramienta: trasladar la configuración significaba reescribir cientos de streams con el riesgo de perder en silencio un ajuste cuya pérdida se descubre ya al aire. Ahora la consola de Catena tiene un asistente de importación: lee la configuración de origen por la API y la convierte en streams, secciones de plantilla y backends de autorización del nuevo formato. Primero se muestra un plan — qué se traslada exactamente y qué se pierde — y solo después la aplicación; tras la importación recibe un informe por categorías con el motivo de cada campo no trasladado y el número de streams que realmente arrancaron. La importación se ha verificado con la configuración de un router en producción. Todo el procedimiento, incluido el cambio de los espectadores y la vuelta atrás, está en Paso desde Flussonic Media Server.

Una instalación tras la cual el producto funciona. Antes, entre apt install catena y un servicio funcionando había un muro de trabajo manual: el paquete no creaba el rol ni la base de datos de PostgreSQL, no escribía la cadena de conexión, no creaba la cuenta de operador y ni siquiera arrancaba el servicio en una instalación limpia. Ahora todo eso lo hace el paquete: el inicio rápido lleva una máquina limpia hasta un stream reproduciéndose, y la instalación en producción desglosa qué se entrega, dónde viven los secretos, cómo conectar un PostgreSQL externo y qué puertos se abren. El nodo del clúster se instala con su propio paquete catena-streamer, que pregunta la dirección de central durante la instalación; si la introduce sin esquema verá un error claro en lugar de un nodo que no arranca en silencio — vea añadir un streamer. Y la caja ya se llama por su nombre: systemctl status catena. Para quien despliega en docker hay imágenes de producto construidas por capas: una actualización no vuelve a descargar toda la distribución.

HTTPS sin desplegar certificados a mano. El producto incorpora un cliente ACME: el streamer pide y renueva su certificado Let's Encrypt él mismo, incluido el propio central. Ya no hace falta repartir certificados a mano por 10–100 nodos, y central no guarda claves privadas ajenas. De paso, el puerto y el TLS del nodo local ahora se editan desde la consola y no editando YAML en la máquina. Los requisitos de emisión, la comprobación TLS-ALPN-01 y los motivos por los que un certificado no se emite están en Certificado HTTPS.

Plantillas de streams. «Al tercer stream ya me cansé de ir haciendo clic por los ajustes» — es una cita literal del ticket. Catena recupera la noción de valor por defecto reutilizable: transcodificador, archivo, miniaturas y tiempos de espera de las fuentes se configuran una vez en una plantilla, y los canales iguales se crean a partir de ella. La regla de resolución es simple y sin sorpresas: la sección propia del stream gana entera sobre la de la plantilla.

Autorización de reproducción: como en Flussonic, pero más rápida. Los backends escritos para Flussonic funcionan con Catena sin un solo cambio — la misma petición, las mismas cabeceras, así se conectan. No hay que reescribir su portal para migrar. Y para quien le importa la velocidad de arranque hay un segundo esquema: el portal crea la sesión antes de la reproducción y entrega al espectador un billete que el streamer valida localmente, sin llamar a ningún sitio. Su backend deja de estar en el camino crítico: ni la velocidad de cambio de canal ni la fiabilidad del arranque dependen ya de él. El alcance del billete se expresa con una etiqueta de contenido, así que un billete «para 300 canales» no arrastra una lista de 300 nombres ni se reemite cuando cambia la composición del paquete. Un repaso de ambas formas está en Protección de la reproducción.

Recepción de MPTS: selección de programa y una captura por múltiplex. Antes, MPEG-TS por UDP se leía solo como SPTS: el número de programa se descartaba y los cuadros de todos los programas del múltiplex se mezclaban en una sola papilla — pantalla negra en HLS. Ahora la fuente tiene el campo «Programa (PNR)», y varios streams pueden capturar el mismo multicast: el tronco llega al servidor una vez y no una por canal. En un múltiplex típico eso ahorra cientos de megabits de tráfico de entrada. Cómo se conecta una fuente multicast tiene página propia. Además se ha implementado el análisis del flujo elemental MPEG-2: sin él, los troncos de difusión y satélite simplemente no se podían recibir.

MoQ: emisión por el protocolo hacia el que se mueve la industria. Media over QUIC es lo que el consorcio alrededor del IETF pone en lugar del reparto «HLS para escala, WebRTC para latencia». La idea es tener las dos cosas a la vez: latencia por debajo del segundo y, al mismo tiempo, entrega normal y cacheable por la red, en vez de un camino peer-to-peer aparte para cada espectador. Catena emite en directo por MOQT (draft-19, CMAF/CMSF): el streamer levanta un listener QUIC, el navegador llega por WebTransport y reproduce, sin plugins ni pasarelas. Por dentro el flujo se corta no en fragmentos enteros sino en las mismas partes que en LL-HLS, así que la baja latencia sale del diseño y no de ajustar búferes. Es una primera implementación y por ahora solo emisión: la recepción por MoQ y el reparto relay por el clúster son los siguientes pasos. Pero probarlo en su propio canal ya es posible: se activa con un listener en la configuración del streamer.

Push RTP y entrega del archivo por RTSP. El push de MPEG-TS ya habla RTP y no solo UDP a secas: los receptores de hardware habituales aceptan justo eso, y las redes con pérdidas también lo piden. Aparte, apareció la entrega del archivo por RTSP con Range: clock=: la única forma estandarizada en que los sistemas municipales de videovigilancia de terceros leen un archivo ajeno. Hasta ahora esa integración era imposible por principio.

Subtítulos de difusión como una pista normal. Los subtítulos ocultos CEA-608/708 que viajan dentro de la imagen se convierten ahora en una pista WebVTT que entienden todos los reproductores OTT. El abonado ve en su aplicación los mismos subtítulos que el espectador del mismo canal por cable, y los requisitos de accesibilidad (CVAA en EE. UU., European Accessibility Act en Europa) se cumplen sin una segunda entrada ni trabajo manual. El multilingüismo sale gratis: el difusor suele poner dos o tres servicios de idioma en un canal, y cada uno se convierte en una entrada del menú de subtítulos. En detalle: Subtítulos ocultos de un canal de difusión.

Los subtítulos llegan al aire de varias maneras y nosotros los reducimos a una sola forma. Los closed captions CEA-608/708 dentro de los cuadros de vídeo funcionan hoy. Los subtítulos DVB llegan como imágenes, así que el texto hay que reconocerlo: DVB OCR sale en la próxima versión. El sentido de todo este trabajo es que a la salida la forma es una: vengan de donde vengan los subtítulos, el espectador recibe una pista WebVTT normal, y usted no necesita ni una segunda entrada ni una cadena aparte para cada formato de difusión.

El transcodificador: más denso y sin costuras. Con MBR, un cuadro de entrada se decodificaba tantas veces como calidades de salida tuviera: en un conjunto FHD/HD/SD el worker iba a 0,7–0,8× del tiempo real, el borde en directo se retrasaba y los reproductores hacían búfer. Ahora la entrada se decodifica una vez y el cuadro decodificado se reparte a todos los codificadores. Apareció la codificación en tarjeta gráfica: con NVIDIA toda la cadena de vídeo — decodificación, escalado y codificación — se va a la tarjeta, y la tarjeta se elige de forma explícita o automática, la menos cargada. Y la reconfiguración dejó de ser destructiva: el transcodificador ya no se reconstruye por ruido como el bitrate medido, y cuando de verdad hay que reconfigurar — por ejemplo, la fuente cambió de resolución en directo — ocurre sin cuadros perdidos, sin IDR forzado y sin rotura de DTS. La escalera de calidades, las reglas de audio y los presets están en Transcodificación y MBR.

Menos artefactos para el espectador. El DASH en directo se desmoronaba segundos después de activar el transcodificador: las pistas de un mismo stream se cortaban con rejillas que no concordaban, el error de redondeo se acumulaba y el borde de la emisión oscilaba dentro de un segundo — ahora las rejillas están alineadas. En LL-HLS las discontinuidades se numeran una vez y no se renumeran a posteriori, así que hls.js ya no muere con discontinuity sequence mismatch; la pista de miniaturas dejó de generar discontinuidades falsas que dejaban al reproductor con el búfer vacío. Un flujo cuyo codificador insertaba IDR no previstos ya no se deshace en segmentos de 32–64 ms. Un cambio de descripción de programa en la PAT ya no tira un cuadro a medio montar — antes eso daba un segmento aparentemente sano con un agujero en el GOP, la reproducción detenida en Chromium y un agujero en el archivo para siempre. Y los congelamientos de audio de varios segundos tras cada cambio de entrada también desaparecieron.

Se ve lo que ocurre. El panel de control responde a la pregunta «¿está todo bien?» con mosaicos, gráficas de espectadores y tráfico y un mapa de calor de errores. Las sesiones se ven una a una: no «tantos espectadores», sino quién está viendo este stream ahora mismo y quién lo vio hace poco — el historial ya no se pierde. El diagnóstico de la fuente muestra algo más que «hay cuadros o no»: errores de continuidad MPEG-TS, caídas de bitrate, audio perdido; el respaldo vuelve ahora a la fuente prioritaria solo tras una ventana limpia y no al primer cuadro. Si un disco de DVR está desmontado o hay una errata en la ruta, se ve en la interfaz y no en una línea WARN de un log. Y si un streamer no aplicó los ajustes guardados, el motivo llega a la consola — vea Diagnóstico del streamer.

Treinta mil espectadores desde un solo nodo. Es, probablemente, la cifra de la versión. Por protocolos de baja latencia — HTTP MPEG-TS, RTSP — Flussonic topaba en torno a mil o dos mil clientes simultáneos por servidor: a partir de ahí empezaban las caídas. Catena 26.08 sostiene 30 000 espectadores simultáneos en un nodo por esos mismos protocolos.

La causa estaba en la contabilidad de sesiones. Todas las sesiones del nodo vivían en una tabla bajo un cerrojo común, y por ella pasaban los dos caminos calientes a la vez: las sesiones de socket — que son justamente los protocolos de baja latencia — informan de los bytes transferidos una vez por segundo cada una, mientras que los espectadores HTTP buscan su registro en cada petición de segmento. Con treinta mil sesiones eso daba más de veintiséis mil tomas del cerrojo por segundo. Y el cerrojo estaba haciendo trabajo útil en torno al 13% del tiempo: el sistema no se paraba por falta de fuerzas, sino por hacer cola detrás de sí mismo — la espera llegaba a un segundo de media y a casi doce segundos en el pico.

Quien pagaba la cola no era la monitorización, sino el espectador. Mientras una sesión espera el cerrojo no vacía el anillo de cuadros, y un anillo en un stream en directo dura segundos: el suscriptor atrapado en la cola se caía por completo. En la recepción eso se veía como cortes de 700 ms, y una fuente que debía tirar quince gigabits tiraba tres. Ahora las sesiones se han mudado a un almacenamiento columnar con particiones separadas, la contabilidad de bytes quedó cubierta por pruebas antes del cambio, y la cola desapareció junto con el techo de mil quinientos clientes.

Los logros no son solo en la entrega, también en la grabación. La otra mitad del mismo trabajo es una grabación sostenida de 20 gigabits por segundo y servidor. Traducido a cámaras, son 10 000 cámaras de resolución media en una sola máquina grabando de forma continua — no una cifra pico de demostración, sino el régimen en el que el servidor vive. Para un operador eso cambia la aritmética del proyecto: donde antes el archivo sumaba un rack, ahora bastan unas pocas máquinas, y el estado de los discos y qué ocupa el espacio se ve en todo el clúster de una vez.

El archivo en el clúster. Un stream en un edge tiene ahora caché de archivo: un interruptor aparte que no exige grabar. El origin escribe el archivo y los edges, más cerca de los espectadores, guardan lo que realmente se ve, con lo que las lecturas casi dejan de llegar a los discos del origin. Cuánto ocupó la caché y cuál es la tasa de aciertos está en la sección DVR del clúster, que además responde a «¿dónde se fue el espacio?» en una instalación con decenas de discos. A los espectadores los reparten por geografía las zonas CDN.

El VOD pasó a ser de clúster. Antes el VOD de ficheros vivía a nivel de un solo nodo: para servir un activo había que saber en qué máquina y en qué directorio estaba. Ahora central lleva el catálogo VOD de todo el clúster, y los ficheros se pueden cargar directamente desde el navegador sin elegir nodo ni disco: el activo va al almacenamiento con más espacio libre y los bytes viajan directos al streamer, sin pasar por el plano de control. A los portales que hacen sus propias cargas se les entregan tokens de subida. Y las dos cosas por las que los clientes que migraban reempaquetaban su contenido ahora funcionan tal cual: el MBR se arma con ficheros vecinos y los subtítulos externos se recogen del fichero de al lado — movie.mp4 y movie.srt se reproducen sin conversión.

Watcher se muda a la tecnología de Catena

Lo principal sobre Watcher en esta versión no es una función, sino una dirección. Watcher ha empezado a mudarse al mismo núcleo sobre el que está construida Catena: la capa de medios deja de ser Flussonic Media Server y pasa a ser Sapsan. En 26.08 está hecho el primer paso visible: la capa de medios tiene nombre propio — el paquete y la imagen docker watcher-streamer, detrás de los cuales se puede cambiar el motor sin tocar comandos de instalación, documentación ni sus playbooks.

Para qué le sirve. Sapsan está escrito en Rust y está pensado para densidades de otro orden: una grabación sostenida de 20 gigabits por segundo y servidor son 10 000 cámaras de resolución media en una máquina. A medida que avance la mudanza esperamos una reducción de recursos de varias veces para la misma instalación: menos máquinas para el mismo número de cámaras, menos rack, menos factura de electricidad y mantenimiento. Además de todo lo descrito arriba en la sección de Catena: la introspección del estado y el modelo de clúster que la capa de medios actual no tiene.

La mudanza será gradual y sin sorpresas para las instalaciones en funcionamiento. Pero si quiere un producto de otro nivel antes, le invitamos al programa de adopción temprana: miraremos juntos su instalación, planificaremos la migración y la llevaremos a cabo con nuestra participación.

Esto es lo que hicimos para Watcher

El grabador ya no calla cuando el archivo no se escribe. Es el escenario más desagradable de todos: en la aplicación las cámaras están en verde, hay vídeo en directo, y el archivo lleva días sin escribirse — el disco, el DVR o la grabación se han parado. El cliente se entera en el momento en que hace falta el archivo: tras un robo, una disputa o un «quién pasó por aquí». La diferencia con «el grabador está desconectado» es fundamental: lo desconectado al menos se ve, mientras que «conectado pero sin grabar» es una falsa sensación de seguridad. Ahora Watcher lo vigila y avisa.

Avisos de avería del grabador — y de su recuperación. Antes el usuario se enteraba de que el grabador se había averiado solo al entrar en la lista de grabadores. Ahora los administradores de la organización reciben un push con el motivo — la red entre la nube y el grabador no está disponible, el grabador dejó de responder por la API — y cuando vuelve a levantarse llega una notificación de recuperación. La mecánica de entrega de push en el backend se hizo común para todos los tipos de notificación: la entrega se reintenta en caso de fallo y las suscripciones caducadas ya no atascan la cola.

Se ve adónde va el archivo y cuán íntegro está. De cada cámara del grabador se ve ahora cuánto espacio ocupa su archivo: se puede ajustar la retención en lugar de comprar discos. Y, sobre todo, se ve el estado del archivo: «guardamos 30 días» y «en esos 30 días el archivo sumó 25 con agujeros» son cosas distintas, y ahora la diferencia no se esconde. Apareció la indicación de integridad del archivo, y la profundidad se calcula por cada stream por separado.

La capa de medios de Watcher tiene su propio nombre. Aparecieron el paquete watcher-streamer y la imagen docker flussonic/watcher-streamer. Esto cierra dos cosas. La primera: en los nodos de medios del clúster, que se instalaban con apt install flussonic, la interfaz de administración del servidor de medios quedaba expuesta — ahora está cerrada tanto en la entrega por paquete como en la de docker. La segunda: para un sistema de videovigilancia el motor es un detalle de implementación, y no hay motivo para pronunciarlo en voz alta en los comandos de instalación y en los playbooks. Ahora la capa de medios tiene un nombre permanente detrás del cual el motor puede cambiar.

La primera instalación dejó de fallar y la actualización se volvió verificable. La instalación all-in-one fallaba en el primer apt install y obligaba a lanzar la instalación por segunda vez — reproducido de forma consistente en Ubuntu 22.04 y 24.04 limpios. La causa está encontrada y corregida. Aparte, nos ocupamos de las migraciones de la base: la cadena había crecido hasta 193 revisiones, una primera instalación se llevaba más de cuarenta segundos en ellas y, lo peor, una actualización con datos reales desde versiones antiguas no la verificaba absolutamente nada. Ahora la instalación limpia se hace desde una instantánea del esquema y las propias migraciones están cubiertas con pruebas.

Los recursos ya no se fugan y las listas no se arrastran. El método que devuelve la lista de streams dejaba transacciones sin cerrar en PostgreSQL: las conexiones se quedaban pegadas en idle in transaction, se fugaba memoria, subía la carga de CPU y el servicio caía — corregido. Aparte nos ocupamos de la velocidad de la interfaz en instalaciones grandes: un cliente con más de 1100 cámaras no podía recorrer la lista para comprobar el estado de las cámaras por sus miniaturas — la página dejaba de responder. Se aceleraron la lista de cámaras, la apertura de carpetas, el desplazamiento y la búsqueda por carpetas.

Permisos y cuentas. A los usuarios de organización se les podían conceder menos permisos que a los usuarios normales; ahora ambos sitios funcionan igual. Se puede dejar una nota en un usuario de organización, y se han corregido el cambio de propietario de una organización y el listado de organizaciones según los permisos sobre cámaras.

El nuevo reproductor con panel de depuración. El nuevo reproductor tiene ahora un panel de depuración con gráficas y una línea de tiempo de eventos. Cuando llega una queja de «va a saltos» ya no hay que creerla a ciegas: se ve qué pasó realmente con la reproducción.

26.08 es la última versión con soporte de la API v2. Es, probablemente, el punto más importante para quien tiene integraciones propias: en la siguiente versión la v2 se apaga. El aviso se muestra ahora directamente en la interfaz — los envíos por correo no funcionan para esto, y a nosotros nos importa saber que el administrador lo ha visto.

La buena noticia es que hay adónde pasar ahora mismo: todo lo que había en v2 ya está en la API v3 — no hay que esperar nada ni negociar endpoints que falten. Si tiene una integración propia, una facturación o una aplicación móvil sobre v2, escríbanos: miraremos sus llamadas y le ayudaremos a pasarlas a v3 antes de que termine el soporte.

Flussonic Media Server

Esta versión trae a Media Server un solo cambio, pero útil para quien tiene muchas cámaras: antirrebote de los disparos repetidos del detector de movimiento. Una cámara mal configurada — con la sensibilidad demasiado alta o una zona sobre ramas que se mueven — es capaz de emitir un torrente de eventos «movimiento iniciado» sin parar, y en una instalación grande esas cámaras juntas enterraban el servidor de gestión bajo miles de eventos y lo dejaban clavado en CPU. Ahora los disparos repetidos se agrupan, y se puede resolver la configuración de cada cámara con calma en lugar de a la carrera.

Y algo que conviene decir con claridad: la fase de desarrollo activo de Flussonic Media Server ha terminado. El producto sigue con soporte y continuaremos publicando actualizaciones mínimas de seguridad, pero no habrá nuevas funciones en él: todo el desarrollo va a los productos sobre el núcleo nuevo.

Por eso le invitamos a planificar el cambio. Si hace videovigilancia, le toca Watcher, que en esta misma versión ha empezado a mudarse a ese núcleo; si hace televisión y OTT, le toca Catena, que ya cuenta con un asistente de importación de configuración con plan antes e informe después. Una migración es más que una herramienta, así que participamos en ella nosotros mismos: cuéntenos cómo es su instalación y decidiremos juntos qué se traslada primero y cómo se verifica la emisión por el camino.