Tenía dos máquinas. Un ThinkPad — modelo de 2015, dos núcleos, ocho gigabytes — con una cámara Akaso conectada. Y un MacBook con OBS funcionando. Ambos en la misma red Tailscale.

La tarea estaba clara: llevar la imagen de la cámara por la red y meterla en OBS.

Aparecieron cinco obstáculos. Cada uno en una capa distinta.

El primer intento fue el más directo: capturar la cámara, comprimir, lanzarlo por UDP.

Los paquetes salieron. No llegó nada.

UDP es el tráfico que menos gusta a los cortafuegos y a las redes virtuales. En vez de buscar dónde se perdía, cambiamos de carretera: TCP. SSH ya funcionaba sobre TCP, así que ese camino estaba abierto.

Pasamos a TCP, abrimos un puerto, añadimos una regla al cortafuegos. Conexión rechazada.

La razón era sutil. Al conectarme por SSH, el usuario tenía derechos de administrador — pero la sesión no estaba elevada. En Windows no son lo mismo. La regla del cortafuegos había fallado en silencio.

En lugar de forzar el muro, lo rodeamos por completo: un túnel SSH. Empujamos el vídeo por un canal que ya funcionaba.

Con el túnel en pie, ffmpeg arrancó y murió a los cuatro segundos.

El error era explícito: búfer en tiempo real demasiado lleno, fotograma descartado.

Como nadie le había dicho otra cosa, la cámara había vuelto a su valor por defecto: 3840×2160. Comprimir 4K en tiempo real no es asunto de un procesador de dos núcleos de 2015.

La solución tenía dos partes. Fijamos la resolución en 1920×1080. Y trasladamos la compresión del procesador a Intel Quick Sync — el codificador por hardware dentro del chip gráfico.

La cámara sabía producir H.264 por sí misma. Pasémoslo tal cual, sin tocarlo. Carga de procesador: cero.

El otro extremo no pudo descodificarlo. El registro repetía una línea: referencia a un PPS 0 inexistente.

La cámara no colocaba al principio del flujo las cabeceras que describen la imagen — SPS y PPS. Un flujo de vídeo sin cabeceras es un texto sin alfabeto.

Lo tomamos como MJPEG y lo recodificamos con Quick Sync. Un paso más, pero las cabeceras en su sitio.

Todo funcionaba. La imagen llegó. Luego desapareció.

Comprobé: el proceso que había lanzado no estaba. El registro de errores, vacío. El programa no se había colgado — lo habían matado.

La causa era el propio SSH. En Windows, una sesión SSH ata los procesos que inicia a un objeto de trabajo; al cerrarse la sesión, los hijos se van con ella. Al cortar mi conexión, cortaba también la cámara.

Convertimos la emisión en una tarea programada. Ya no depende de una sesión: vive por su cuenta y se reinicia tras cada corte.

La imagen llegó. Sentado a mi mesa, me vi a mí mismo en mi propia pantalla — pero esa imagen había salido del portátil de al lado, había atravesado un túnel cifrado y había vuelto.

Y este era el hallazgo de verdad: un portátil de dos núcleos, de diez años, comprime vídeo 1080p30 mientras su procesador permanece casi inactivo. Gracias a Quick Sync. Creía que esa máquina era débil. Débiles eran mis ajustes.

Ninguno de los cinco obstáculos fue una limitación de hardware. Los cinco fueron configuración, protocolo y comportamiento del sistema operativo.

Si hubiera comprado una máquina nueva y potente, los cinco habrían aparecido igual.

Construir un sistema no es comprar piezas potentes. Es averiguar, una a una, por qué las piezas se niegan a hablarse.