Versión 26.09

Flussonic 26.09: DRM y escaparate propio en Catena, SDI, ST 2110 y RIST en Mcaster, y el NVR de Watcher migra al nuevo núcleo con un botón

Cuatro productos, un núcleo

Catena, Mcaster, Agora y Watcher son cuatro productos distintos con cuatro clientes distintos: un operador de OTT, un ingeniero de cabecera, un difusor corporativo y un integrador de seguridad. Por dentro comparten el mismo motor: Sapsan, nuestro núcleo de streaming escrito en Rust.

Por eso estas notas empiezan por el núcleo. Todo lo del primer apartado llegó a los cuatro productos a la vez, y es también la razón por la que un hallazgo en un grabador de nueve mil cámaras acaba haciendo que un canal de televisión arranque antes.

Esto es lo que hicimos para el núcleo de streaming Sapsan

Sesenta veces más espectadores WebRTC. WebRTC era nuestra vía de entrega más débil. Un nodo aguantaba 200–300 sesiones WHEP simultáneas y unos 0,9 Gbit/s, y a partir de ahí dejaba de aceptar espectadores: con quinientas sesiones, 448 de 500 se caían por tiempo de espera mientras el proceso usaba el 330% de los 7200% que tenía la máquina. No le faltaba potencia: todo el subsistema WebRTC era una sola tarea que recorría todas las sesiones bajo un único cerrojo, de modo que crear una sesión hacía cola detrás de la entrega a todas las demás.

Ahora las sesiones viven repartidas en fragmentos con sus propios ciclos, y las cifras cambiaron de orden de magnitud. Un nodo sostiene 18 000 espectadores simultáneos a 32 Gbit/s, o 16 000 más pesados a 42,9 Gbit/s, en régimen estable y sin caídas. La memoria por espectador bajó de 3,8 MB a 0,6–0,7 MB, y la cola tiene ahora un límite duro: antes seis mil espectadores ocupaban 53 GB y llevaban la máquina al swap.

Una nota práctica por si va a medir su propio equipo: la disciplina de cola fq que Linux trae por defecto se come unos 8 Gbit/s de esa cifra, y cambiarla por pfifo_fast los devuelve.

Aparte: las sesiones WHEP abandonadas vivían para siempre. Un espectador que cerraba la pestaña dejaba una sesión que seguía quemando CPU y creciendo en memoria a 80 MB/s hasta que mataban el proceso. Ahora esas sesiones se recogen solas.

Más de 100 Gbit/s de HLS desde una máquina. Nos propusimos sacar 100 Gbit/s por la tarjeta de red y lo conseguimos; a partir de ahí el límite fue la ranura PCIe 3.0 del banco de pruebas, no el software. Por loopback, sin el cable de por medio, el mismo servidor entregó 376 Gbit/s de HTTP en claro y 242 Gbit/s sobre TLS. La lectura práctica no es la cifra: es que en hardware corriente la vía de entrega no será lo primero que se le agote.

Lectura de fMP4. El ticket #5350 —«captura de fuentes MPEG-DASH / HLS fMP4»— se abrió en marzo de 2018 y acumuló medio centenar de peticiones de clientes, la lista más larga de nuestro sistema. Lo que pide es una cosa, no dos: una fuente moderna que se entrega por lista de reproducción mete en sus segmentos MP4 fragmentado, no MPEG-TS, y era precisamente fMP4 lo que no sabíamos leer. Todo agregador, toda CDN ajena y todo contribuidor al que no le abren un puerto UDP o SRT publica CMAF, y hasta ahora no teníamos nada que responder.

Una sola regla gobierna el arranque, y conviene conocerla. La captura empieza por el primer segmento que aparece después de conectar: todo lo que ya estaba en la ventana de la lista es historia. Si no, una fuente con una ventana de un minuto volcaría un minuto de medio pasado en su canal en unos segundos, y lo repetiría en cada reconexión. La misma regla cubre una fuente muerta: una lista dejada por una emisión que ya terminó no genera nunca un segmento nuevo, así que la captura sencillamente no arranca, en vez de que el flujo se quede ahí aparentando estar sano sobre una ventana caducada.

Los subtítulos, terminados. En 26.08 sacamos los subtítulos ocultos CEA-608/708 como WebVTT y prometimos el reconocimiento de subtítulos DVB para la siguiente versión. Aquí está, y con él el teletexto: la segunda forma de subtítulo de la emisión europea y la única en la que el texto llega ya como texto.

Todo ello sigue ahora un mismo diseño: cada productor de texto —el decodificador de teletexto, el OCR de DVB, los subtítulos ocultos, el reconocimiento de voz— escribe en una única capa canónica, y el espectador siempre recibe una pista WebVTT normal. Venga como venga en el canal, el abonado de su aplicación ve el mismo menú de subtítulos que un espectador de cable, y los requisitos de accesibilidad se cumplen sin una segunda entrada ni una cadena distinta por formato. De paso, el decodificador de teletexto se arregló en dos puntos que lo hacían inútil: un error en el orden de bits del código Hamming (la página 888 se leía como 811) y la ausencia de juegos de caracteres nacionales, que convertía diéresis y cirílico en basura.

Transcodificación por hardware en NVIDIA. Toda la ruta de vídeo —decodificar, escalar, codificar— se traslada a la tarjeta, elegida de forma explícita o automática, de modo que cuántos canales lleva un servidor deja de ser una cuestión de cuántos núcleos de CPU compró.

Por el camino dimos por fin con un fallo que nos venía molestando desde los tiempos de Flussonic. Resultó no ser nuestro: es un defecto del propio controlador de NVIDIA, y NVIDIA lo ha registrado como Bug 6610402. Mientras no se corrija en origen, entregamos un rodeo, así que deja de llegar a su instalación.

Un repartidor que hace el trabajo que, si no, hace usted a mano. Decidir qué nodo ejecuta qué flujo es una tarea que alguien tiene que hacer, y rehacer cada vez que se añade, se vacía, se sobrecarga o se pierde una máquina. Con unos pocos servidores cabe en la cabeza. Con cien ya no, y el precio de equivocarse es un canal fuera del aire. Ahora el repartidor de Catena lo decide con 129 reglas, escritas en un documento de política antes que en código, y las pruebas se contrastan con ese mismo documento.

Qué cubre, en términos del operador. Requisitos que una ubicación no puede violar: espacio de nombres, etiquetas obligatorias, un flujo que necesita tarjeta gráfica solo a un nodo que la tiene, un flujo con archivo solo a un nodo con almacenamiento de archivo, un límite de flujos por nodo. Preferencias que deshacen los empates. Reasignación cuando un nodo se cae, se vacía o abandona el clúster, mientras que un nodo congelado a propósito conserva exactamente lo que lleva. Sobrecarga con un orden de alivio definido: procesador por encima del 90%, red por encima del 95% del límite del nodo, archivo por encima de su umbral; primero se alivia la red, las copias de archivo se mueven antes que la captura, el flujo más pesado va primero. Y los papeles más allá de la captura: copias de archivo, restos de archivo en máquinas que ya no ejecutan el flujo, entrega en directo en las bordes, flujos con desfase colocados cerca del archivo que reproducen.

Una cifra merece decirse sin rodeos: en el último año, el 96% de los avisos de clientes que recibimos sobre el repartidor resultaron ser un error de configuración del lado del cliente, no un defecto del repartidor. El motor rara vez era el problema; lo que faltaba era poder ver por qué había decidido lo que decidió. Esa mitad es la que cierra esta versión: cada asignación lleva ahora el motivo por el que se tomó, y la consola tiene una página con las ejecuciones, las asignaciones y las restricciones que no se pudieron satisfacer.

Administradores, roles y una revocación que revoca. Hasta ahora el acceso de gestión era una contraseña compartida y una clave estática: no se podía añadir un segundo administrador, limitarlo, ni cortarle el acceso a una persona sin cambiarle el secreto a todo el mundo. Ahora hay un registro real de cuentas de administrador con roles. Y desactivar una cuenta detiene el trabajo de inmediato: antes solo se revocaba el inicio de sesión, mientras un token ya emitido seguía creando flujos y editando nodos hasta quince minutos más.

Se ve más de lo que ocurre. El gráfico de errores del flujo se desglosa en líneas por tipo de error, y los fallos a nivel de conexión —una sesión SRT que se corta, una petición HTTP rechazada por una fuente HLS— se cuentan por primera vez, así que una caída completa de la fuente por fin se ve en el gráfico y no solo en el registro. A Retroview llegan ahora la telemetría de calidad de las fuentes, las estadísticas del servidor, el inventario y la carga de las GPU y los contadores del transcodificador. Cuando un nodo se niega a aplicar la configuración que usted guardó, el motivo llega a la consola en lugar de quedarse en el registro local de la máquina. Y en instalaciones con decenas de discos, el espacio ocupado se desglosa en archivo vigente, grabaciones huérfanas y el resto, de modo que «adónde se fue el espacio» tiene respuesta.

Esto es lo que hicimos para Catena

DRM y, por tanto, emisión de pago. Es la mayor carencia que mantenía a los operadores en Flussonic Media Server. Catena sabía descifrar una entrada protegida, pero no proteger lo que entregaba, así que no sustituía a Flussonic en ningún canal de pago. Ahora sí. Los flujos se cifran con CMAF cbcs, y una única copia cifrada sirve a HLS/fMP4 para FairPlay y a DASH para Widevine y PlayReady: no hay que empaquetar dos veces. Las claves llegan de su propio servidor de claves por SPEKE v1 o v2, o de la configuración para pruebas.

El diseño de clúster importa aquí tanto como la criptografía. El cifrado ocurre a la salida del nodo que capturó la fuente, no al escribir en disco: el archivo se guarda en claro, así que el rebobinado, las miniaturas, la transcodificación y la analítica siguen funcionando. Los nodos de borde reciben solo texto cifrado: la clave y las credenciales del servidor de claves nunca salen del nodo de captura ni aparecen en la configuración de un borde. Y al importar una configuración de Flussonic v3, un flujo con sección drm llega desactivado, para que una migración masiva no empiece en silencio a emitir en abierto un canal premium.

Un escaparate con guía de programación real. La aplicación de espectador de Catena —la que sus abonados abren en el televisor o en el navegador— se trasladó al nuevo núcleo junto con el backend que necesita. El abonado entra con su propio token, recibe la lista de canales a los que tiene derecho con direcciones listas para reproducir, y con la lista llega un billete de reproducción: así funcionan el límite de dispositivos simultáneos y la revocación, sin que el escaparate sepa nada de claves internas.

Detrás hay una guía de programación que antes no existía en ninguna forma. Central posee ahora las fuentes XMLTV, las descarga según una planificación, guarda la parrilla y se la entrega tanto al escaparate como a la salida MPEG-TS en forma de EIT. Dos notas prácticas: la importación filtra los programas a los canales que usted realmente vinculó —el fichero real de un proveedor con el que probamos tenía un millón y medio de programas repartidos en 4054 canales, de los cuales nadie leería jamás el 95%— y el fichero descargado se conserva, así que vincular un canal nuevo reimporta al momento.

Si ya tiene un middleware. Muchos de nuestros clientes venden el suyo, y Catena no compite con ellos. En ese montaje Catena es aquello a lo que apunta su middleware: una única dirección de reproducción, con el balanceo redundado dentro del clúster, de modo que no hay delante un balanceador de hardware aparte que comprar, montar y mantener vivo. El escaparate de arriba es para operadores que todavía no tienen middleware y prefieren no empezar construyendo uno.

Canales con desfase horario. «Canal +2» como canal de pleno derecho. El rebobinado ya existía, pero el rebobinado es un parámetro en la URL del reproductor: la versión desplazada no tenía nombre propio, ni línea en la lista de canales, ni sesiones ni estadísticas, y no se podía enviar, proteger ni asignar a una zona CDN. Ahora un canal con desfase es un flujo normal con una fuente peculiar, de modo que hereda gratis sus URL de espectador, sus sesiones, su DRM y sus envíos. Una captura y un archivo profundo cubren sus husos horarios, en lugar de recibir una señal regional por huso.

Las dos últimas carencias de formato. Catena captura fuentes DASH: es la otra mitad del mismo ticket, funcionando sobre el mismo lector de fMP4 descrito arriba. Entre HLS y DASH quedan cubiertos los orígenes CMAF, las pasarelas DVB-I y los empaquetadores en la nube que solo publican uno de los dos. DASH se diferencia en una cosa, y es honesta: un manifiesto no enumera lo que existe, sino que da una hora de inicio y una plantilla, así que qué segmento está ya disponible se calcula desde el reloj de pared en lugar de leerse de una lista. Y a la salida, HLS se sirve también en contenedor MPEG-TS, en su propia dirección, para reproductores y descodificadores antiguos que no aceptan otra cosa. Juntos eliminan las dos últimas respuestas del tipo «Flussonic sabía hacerlo y Catena no», tanto a la entrada como a la salida.

El VOD dejó de ser trabajo manual. Un catálogo VOD de clúster sabía aceptar un fichero y reproducirlo, pero todo lo que convierte un fichero subido en un servicio —la escalera de calidades para MBR, el descriptor SMIL, el destino del original— se hacía a mano en cada nodo. Ahora se asocia una plantilla de transcodificación al recurso, la tarea nace al confirmarse la subida, central elige el nodo que la ejecuta y el resultado vuelve al catálogo como un fichero más. Las plantillas, las tareas y su progreso están en la consola y no en curl. Y el MBR construido a partir de ficheros vecinos, más los subtítulos externos recogidos junto al vídeo, hacen que un cliente que migra no tenga que reempaquetar su biblioteca.

Los bordes se volvieron bordes de verdad. Un nodo de borde servía solo archivo: el directo y el rebobinado se le mantenían lejos, porque un flujo en un borde habría tirado del origen eternamente, lo mirara alguien o no. Ambas razones desaparecieron. Los flujos en un borde se levantan bajo demanda cuando llega un espectador y se apagan por inactividad, y los nodos se intercambian el directo por nuestro propio protocolo interno, sin degradar a RTMP o SRT con un remultiplexado de más. Así toda la carga de espectadores, directo incluido, se va del nodo de captura a los bordes.

Lo que gana al migrar de Flussonic Media Server a Catena

Catena está construida como clúster desde el principio: usted añade un flujo en lugar de elegirle una máquina, el archivo y el catálogo VOD son de todo el clúster, y la instalación entera se ve desde un solo sitio. Ese argumento lo desarrollamos en 26.08 y sigue igual. Lo que cambió en 26.09 es que la lista de cosas que Flussonic hacía y Catena no se ha quedado prácticamente vacía:

Esto es lo que hicimos para Mcaster

Las entradas de difusión, todas. Mcaster es la cabecera: la señal llega de un receptor de satélite, de una red vecina, de un socio o de su propia continuidad. Esta versión cierra las entradas que solo tenía el Flussonic en Erlang.

El SDI desde tarjetas DekTec funciona como un proceso aparte por puerto de tarjeta, que habla con el streamer por memoria compartida: un fallo a nivel de controlador tumba una captura y no el servidor de medios entero, lo que dado el historial de caídas de DTAPI no es una preocupación teórica. Desincrusta audio multicanal, extrae VANC y calcula por sí mismo marcas de tiempo alineadas. La consola muestra ahora qué tarjetas hay realmente en la máquina, cuántos puertos tiene cada una, en qué variante de firmware están y qué flujos las han tomado. No es decoración: en una DTA-2178 cada canal se asigna por firmware como entrada o salida, y un puerto que ahora mismo es salida responde a un intento de captura con «ocupado», tras lo cual el ingeniero se va a buscar un proceso ajeno que no existe.

SMPTE ST 2110 se recibe completo: vídeo 2110-20, audio 2110-30 y datos auxiliares 2110-40, más un nodo NMOS que publica los receptores por IS-04 e IS-05 para que un controlador ajeno pueda conmutarlos. La recepción corre en un hilo del sistema dedicado que lee paquetes por lotes: HD entrelazado a 10 bits son 130 MB/s y unos 90 000 paquetes por segundo en una sola pista, y eso no es trabajo para un planificador de tareas de propósito general. MXL, la capa de intercambio por memoria compartida de la EBU, también se lee, para instalaciones donde las funciones vecinas de la cadena entregan la señal así.

RIST llega como implementación propia: recepción y envío, unidifusión y multidifusión, con retransmisión y los contadores necesarios para demostrar que el enlace se comporta. El valor es más comercial que técnico: RIST es el único protocolo de entrega fiable publicado por un organismo del sector y no por un fabricante, así que aparece en los pliegos como línea de requisito, y hasta ahora no podíamos responder a un pliego así en absoluto.

Un transporte que se puede entregar por contrato. El MPEG-TS saliente era antes «tómalo o déjalo»: número de programa fijado en 1, PID asignados automáticamente y ninguna SDT. Ahora puede fijar el mapa de PID, el número de programa y el nombre del servicio por destino. El caso inmediato fue un cliente que recibe un canal nuestro y de un proveedor de respaldo, cuyo conmutador de reserva exige que los PID de ambos flujos coincidan. Pero ese mismo control es lo que piden un múltiplex, un IRD, la monitorización de un NOC o el pliego técnico de un contrato de contribución.

Acceso condicional. Cifrado Simulcrypt en la salida SPTS: sin tarjeta no hay imagen, con tarjeta la hay. Solo se configuraba editando un documento a mano, donde un campo hexadecimal equivocado significa «la tarjeta ignora los EMM en silencio» y cuesta días de banco de pruebas. Ahora tiene un formulario en condiciones.

Clientes, y qué compró cada uno. Es lo que los operadores de Mcaster pidieron de forma más directa. Usted no vende un flujo, vende un servicio: este canal, entregado así, a esta empresa. La configuración y la monitorización solo conocían flujos, así que cuando llamaba un cliente no había dónde mirar: qué compró, qué parte está caída y de quién es esta avería.

Ahora la venta queda registrada donde vive la entrega. Un envío unidifusión o un puerto SRT de reproducción llevan el identificador del cliente al que pertenecen, y un token estático por flujo permite dar un enlace al comprador una sola vez y atribuirle su consumo. Los envíos multidifusión, deliberadamente, no llevan dueño: los receptores del grupo son varios, la conmutación es de red y un solo campo no describe eso honestamente. Encima va la estadística de entrega por destino: estado con motivo de fallo nombrado, tasa, bytes, reconexiones, retransmisiones. De paso se arregló algo peor: un envío que fallaba se declaraba a veces en marcha, con error vacío y contador de reconexiones subiendo, de modo que la consola aseguraba al operador que la entrega estaba viva cuando no salía ni un byte.

Quién cambió qué. Central guarda el estado deseado de la instalación —configuración de flujos y nodos, zonas CDN, cuentas de administrador, ciclo de vida de los nodos— y hasta ahora no registraba quién lo cambiaba. Con más de un operador de turno, eso deja una incidencia sin resolver: preguntas como «quién borró este flujo» o «cuándo y quién revocó este nodo» no tenían respuesta alguna. Ahora la tienen: actor, acción, momento.

Su propio paquete, y un clúster que sigue siendo un producto. Ya existe un paquete mcaster-streamer. Antes el único paquete de nodo era el de Catena, y la consola de Mcaster mostraba una orden de incorporación con las rutas de Catena, de modo que el operador que la seguía instalaba un nodo del producto equivocado sin que nada protestara por el camino. Un clúster con máquinas de dos productos no es exótico: es una avería silenciosa de la que uno se entera mucho después. Ahora la incorporación de un nodo de otro producto se rechaza con un motivo claro.

Lo que gana al migrar de Flussonic Media Server a Mcaster

A una cabecera se la juzga por lo que puede recibir y por lo que puede demostrar sobre lo que entregó. Ahí es exactamente donde aterriza 26.09:

Esto es lo que hicimos para Agora

Agora es televisión corporativa: sus propios canales internos, señales de estudio preparadas para emisión, reuniones generales y seminarios entregados a los empleados por la red corporativa. En 26.09 gana rostro propio sobre la plataforma común —su consola, su conjunto de secciones, su identidad de producto—, mientras las funciones de dominio se trasladan al nuevo núcleo en las versiones siguientes.

Dos piezas del trabajo de núcleo caen de lleno en su caso de uso.

Entrega de baja latencia que escala. El trabajo de WebRTC descrito arriba es justo lo que necesita la difusión corporativa: una reunión general son unos miles de personas viendo lo mismo a la vez, con latencia inferior a un segundo, dentro de una red. Pasar de 200–300 sesiones simultáneas por nodo a 18 000 cambia lo que le cuesta a una empresa una emisión para toda la plantilla: de un rack a una máquina.

Publicación por SRT. Un estudio, una sala de reuniones o un portátil con OBS pueden ahora publicar en el clúster por SRT, con recepción en el nodo al que llaman y con cifrado y recuperación de pérdidas a la entrada. Es la forma normal en la que un evento interno llega a la plataforma.

Esto es lo que hicimos para Watcher

El grabador migra al nuevo núcleo, y no hace falta un ingeniero. En 26.08 la capa de medios recibió nombre propio, el paquete watcher-streamer, tras el cual se podía sustituir el motor. Esta versión lo sustituye, y lo hace por el único canal que un grabador en campo tiene realmente: el botón de actualización de la nube.

Hasta ahora, cambiar el servidor de medios de un grabador significaba un ingeniero por SSH ejecutando un script de migración que leía la distribución de discos, generaba una configuración y rehacía la pila de contenedores a mano. Eso nunca llega a la caja de un cliente. Ahora el nuevo servidor de medios viaja igual que todo lo demás: se pulsa actualizar, el grabador se trae la pila nueva, y un fallo en cualquiera de los pasos revierte automáticamente a la anterior. Los valores propios de cada caja que lo hacían difícil —clave de clúster, credenciales de administración, nombre del streamer, distribución de discos— se componen ahora en la propia caja, en vez de cocerse en un fichero servido a toda la flota desde una dirección pública.

Lo que gana a cambio es densidad. El nuevo núcleo es el que graba veinte gigabits por segundo y servidor, y a medida que avance la migración esperamos una reducción de recursos de varias veces para la misma instalación: menos máquinas para las mismas cámaras, menos espacio en rack y menos factura eléctrica.

La captura de cámaras se volvió mucho más fiable, y lo encontramos por casualidad. Persiguiendo pérdidas de grabación en un grabador de diez mil flujos, vimos que algunos producían fragmentos diez veces más pequeños que el resto, fuimos a mirar la cámara y la cámara estaba bien. El problema estaba en cómo ensamblábamos paquetes RTP fragmentados en fotogramas en la ruta RTSP.

Las mediciones son contundentes. Con la misma cámara y el mismo banco, la compilación de julio producía 438 453 fotogramas rotos de 4 600 555, un 9,55%. Tras la corrección: 6 errores de 272 591 fotogramas, un 0,002%. En el grabador receptor, con 10 000 flujos durante una hora, la pérdida mediana de archivo bajó de 15 236 a 2 fragmentos por segundo, y el número de flujos que perdían algo pasó de 2815 a 2.

Si usted tiene cámaras por RTSP —es decir, si tiene cámaras—, esta es la línea más valiosa de la versión.

La grabación dejó de tirar datos teniendo memoria libre. Un fragmento cerrado vivía en un solo sitio, y la ventana de entrega desalojaba fragmentos por número de unidades. Si el escritor de disco se retrasaba unos pocos, el dato se perdía para siempre. En un grabador de nueve mil cámaras eran 898 501 fragmentos perdidos en diez minutos, con 42 GB de los 125 de la máquina sin usar. Ahora la entrega y la durabilidad tienen presupuestos separados, la cola de escritura guarda sus propias referencias y está limitada en bytes, y un fragmento solo puede perderse cuando la memoria se agota de verdad. De paso, alinear las escrituras a límites de bloque de 4 KB redujo por sí solo las pérdidas de 5524 a 8.

El grabador es dueño de sus cámaras. La configuración se sincronizaba en dos direcciones asimétricas, y ambas dolían a usuarios reales: una cámara creada en el grabador no aparecía en la nube hasta que alguien encontraba el botón «sincronizar», y una lectura de fondo desde la nube cada sesenta segundos sobrescribía en silencio las ediciones locales. La arquitectura queda ahora enunciada con claridad: el grabador es la única fuente de verdad de la configuración de sus cámaras, y la nube es un espejo no destructivo. Con el enlace en pie se puede editar desde la nube; sin enlace, no, en lugar de hacer ediciones que después se descartan en silencio.

La API v2 queda desactivada. Dijimos en 26.08 que lo estaría, y lo está: los puntos de v2 responden con un aviso. Como sabemos que algunos sistemas de facturación siguen ahí, queda una bandera de configuración para reactivarla durante la transición. Tómela como un plazo, no como un indulto.

Todo lo que ofrecía v2 ya está en v3. Lo que aprendimos de quienes intentaron migrar es que el problema no es un endpoint que falte, sino una secuencia: crear un usuario, una organización y una carpeta es una cadena de llamadas en la que cada identificador sale de la respuesta anterior, y un paso omitido da o bien un 403 o bien un abonado con permisos de administrador. Por eso estamos escribiendo esa guía de «cómo pasar a v3» para integraciones de facturación. Si tiene una integración propia en v2, escríbanos y revisamos sus llamadas con usted.

El nuevo reproductor, y lo demás. El reproductor ganó calendario, cambio de calidad, selección en la línea de tiempo con exportación del intervalo elegido, soporte de mosaicos y un panel de depuración separado del propio reproductor; en los grabadores ya es el predeterminado. Junto a eso: la lista completa de organizaciones de un usuario se muestra entera y no recortada, el diálogo de información del archivo da cifras reales, en la página de mosaicos se arreglaron la paginación y el botón de borrado, se retiró una previsión de uso de disco que central no puede calcular en realidad en vez de dejarla induciendo a error, y un planificador que dejaba de ejecutar en silencio todas las tareas periódicas tras un reinicio de Redis ahora lo detecta y se restaura solo.

Villapass. El producto de control de accesos para urbanizaciones construido sobre Watcher maduró en esta versión. Los residentes se agrupan por parcela en lugar de existir sueltos, así que una restricción —esta parcela no puede emitir pases de invitado— se pone donde corresponde. El residente entra con su número de teléfono y un código por SMS, y no con un correo y una contraseña que nadie le dio. El sistema de barrera informa de vuelta: qué coche pasó, cuándo, en qué sentido y con qué pase, que es lo que hace posible un registro de pasos, y ahora hay una pantalla que lo muestra, con búsqueda por matrícula y por pase. El presidente puede alternar entre sus propios pases y los de toda la comunidad en lugar de ver siempre los de todos. Y el panel del operador muestra por fin cómo va cada urbanización —residentes, parcelas, pases emitidos esta semana y cuándo fue el último intercambio con la barrera— en lugar de una lista pelada de nombres.

Flussonic Media Server

Nada nuevo, y es deliberado. Como dijimos en 26.08, la fase de desarrollo activo de Flussonic Media Server ha terminado: el producto sigue soportado y publicamos actualizaciones mínimas de seguridad, pero todo el desarrollo va a los productos sobre el nuevo núcleo.

Esta versión es un buen momento para empezar a planificar el traslado, porque los motivos para esperar prácticamente se agotaron. Si hace televisión y OTT, eso es Catena, que desde 26.09 tiene DRM, guía de programación, un middleware propio si lo quiere, canales con desfase, captura de fMP4 por HLS y DASH, salida MPEG-TS para descodificadores antiguos y una herramienta que lee su archivo actual en su sitio. Si tiene una cabecera, eso es Mcaster: SDI, ST 2110, MXL, RIST, control completo de PSI/SI y acceso condicional. Si hace videovigilancia, eso es Watcher, cuyos grabadores empezaron a migrar al nuevo núcleo en esta misma versión.

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 mueve primero y cómo se verifica la emisión por el camino.