Read in English

Contexto técnico

Comprender una tecnología y validar su caso de uso mediante un prototipo es uno de los mayores retos de la ingeniería. Aunque existen servicios comerciales consolidados, decidí desarrollar una prueba de concepto (PoC) para demostrar la transferencia de audio y video en vivo. El diseño considera conceptos críticos como la transferencia adaptativa según las restricciones de red, así como la codificación en el emisor y la decodificación en el receptor.

Para minimizar la dependencia de frameworks pesados, el stack se basa en Node.js y Express.js para el backend, y JavaScript puro para el frontend. La arquitectura aprovecha la Web Audio API para la decodificación, la Media Recorder API para la captura de fragmentos (chunks) y WebSockets para la distribución bidireccional de mensajes multimedia.

Lógica del emisor

El primer desafío fue la captura de medios. El emisor puede integrar video y audio de archivos locales, dispositivos en vivo (cámara/micrófono) o una combinación de ambos. Mediante MediaRecorder, capturamos el flujo en intervalos de un segundo para generar los chunks de audio.

Para el video, simplificamos la PoC mediante la captura de instantáneas (snapshots). De este modo, enviamos al receptor tanto fragmentos de audio como cuadros de video sincronizados. Para evitar saltos audibles entre fragmentos, el emisor genera grabaciones con un solapamiento de 250 milisegundos, permitiendo realizar transiciones suaves (fades) que garantizan una experiencia auditiva continua.

Implementación de Web Workers

Dada la disparidad en la capacidad de cómputo entre dispositivos (smartphones frente a laptops), el uso de Web Workers es fundamental. Delegamos al hilo de procesamiento en segundo plano las operaciones de gestión de arrays temporales, el formateo de datos y el cálculo de tiempos de creación (timestamps). Al liberar al hilo principal de estas tareas, aseguramos que el sitio web mantenga su fluidez mientras se procesan los flujos de media.

Lógica del servidor y distribución

El servidor recibe los datos del Worker del emisor. Su función es gestionar tanto los metadatos como el contenido multimedia. La potencia de procesamiento, el número de instancias y la memoria RAM son los factores críticos que limitan la concurrencia de usuarios.

Optamos por MongoDB para el almacenamiento temporal, pero con un enfoque de eficiencia: evitamos que cada receptor consulte la base de datos de forma independiente. En su lugar, una única instancia activa consulta los fragmentos disponibles y los distribuye a los canales correspondientes según el timing requerido. Finalmente, implementamos un proceso de limpieza automática para eliminar datos que superen un umbral de antigüedad, evitando el desbordamiento del caché y del almacenamiento.

Lógica del receptor

Al recibir el contenido, el sistema garantiza unos segundos de buffering antes de iniciar la reproducción programada. Los array buffers se transfieren como cadenas de texto a través del servidor y se reconvierten en el receptor.

El audio se decodifica mediante la Web Audio API, permitiendo una planificación precisa de la reproducción. Una vez establecido el tiempo del primer fragmento, los siguientes se encadenan según su duración (1 segundo en este prototipo). Los cuadros de imagen se sincronizan mediante un canvas que actualiza la visualización de forma coordinada con el flujo de audio.

Gestión de red y resiliencia

Ante problemas de conectividad o latencia excesiva, el sistema activa un modo de calidad adaptativa. El receptor notifica al servidor la necesidad de reducir la carga de datos, disminuyendo la tasa de cuadros por segundo (FPS) o incluso priorizando exclusivamente el audio. Una vez estabilizada la red, el sistema incrementa progresivamente la calidad hasta alinearse con el emisor. Si la degradación persiste, se reinicia el buffering para asegurar la continuidad de la reproducción.

Posibilidades de innovación

Este enfoque personalizado abre un abanico de funciones avanzadas:

• Mezcla de flujos: Combinar archivos locales con dispositivos en vivo, utilizando nodos de retardo en la Web Audio API para corregir latencias de sincronización.

• Streaming colaborativo: La capacidad de combinar flujos de dos emisores geográficamente distantes en una única señal, creando la ilusión de una producción conjunta en el mismo espacio.

• Interactividad: Integración de sistemas de chat en tiempo real y feedback directo entre emisor y receptor.

Desafíos y optimización futura

El modelo actual valida la viabilidad de la tecnología, pero presenta áreas de mejora:

• Optimización de datos: Evaluar la reducción de la calidad de los cuadros (frame quality) en lugar de solo reducir la tasa de FPS.

• Latencia de base de datos: El paso intermedio por MongoDB introduce un retardo inevitable que limita la comunicación instantánea.

• Políticas de reproducción: El sistema debe respetar las restricciones de la Web Audio API, requiriendo una interacción del usuario (clic) para iniciar el audio.

• Propiedad intelectual: La implementación de servicios de detección de copyright es una prioridad para proteger los derechos de los creadores.

• Carga del dispositivo: Idealmente, la decodificación debería migrar al servidor para reducir el estrés en el hardware del cliente.

Aunque esta es una solución desarrollada in-house, la exploración de servicios de terceros y la posible migración a aplicaciones nativas permitirían resolver problemas de inactividad del sistema y latencias de dispositivos Bluetooth.