/02 Work
Dubvo.io
Doblar un vídeo de diez minutos con una agencia cuesta entre 200 y 400€ y tarda una semana. Para un creador que publica tres vídeos al mes en varios idiomas, ese coste no es escalable. Las herramientas de traducción automática existentes o producían resultados mecánicos, o no clonaban la voz original, o requerían flujos de trabajo manuales que anulaban el ahorro de tiempo.
Clonación de voz, traducción de audio y subtitulado son tres operaciones distintas que requieren modelos distintos y, en el caso de la clonación y la síntesis, GPU bajo demanda. No se pueden ejecutar en un servidor siempre activo sin costes prohibitivos. Pero tampoco se pueden serializar sin degradar la experiencia del usuario: el pipeline completo tiene que terminar en minutos, no en horas.
Cola de trabajos en Redis con workers especializados: uno en Python para la traducción y clonación de voz, uno en Next.js para el subtitulado y la composición final con FFmpeg. Las instancias de los workers escalan automáticamente cuando hay trabajos en cola y se destruyen cuando la cola está vacía. El usuario solo espera; la infraestructura existe cuando hace falta.
Creadores pueden doblar un vídeo de diez minutos en cuestión de minutos, a una fracción del coste tradicional. El sistema maneja múltiples vídeos en paralelo y ha procesado los primeros proyectos reales de beta.
El problema de escalar contenido
Los creadores que tienen audiencia en un idioma y quieren expandirse a otro se enfrentan a una ecuación que no cierra: el coste de doblar contenido de calidad es tan alto que solo tiene sentido para las producciones más grandes.
Los doblajes de agencia tienen calidad alta pero son lentos y caros. Las herramientas de traducción automática son rápidas y baratas pero producen resultados que suenan mecánicos. Y ninguna de las opciones existentes clonaba la voz del creador original —el resultado sonaba como un narrador genérico, no como el propio creador hablando otro idioma.
Dubvo intenta resolver las tres cosas a la vez: velocidad, coste y calidad de voz.
Por qué la arquitectura importa aquí
El pipeline de dubbing tiene tres etapas con requisitos de cómputo muy distintos:
Transcripción y traducción: relativamente ligera, puede correr en CPU. El texto original se transcribe y se traduce al idioma de destino, preservando la segmentación temporal para sincronizar con el vídeo.
Clonación y síntesis de voz: computacionalmente intensiva, requiere GPU. El modelo clona la voz del creador a partir de la muestra del audio original y sintetiza el audio traducido con esa voz.
Composición final: el audio sintetizado se sincroniza con el vídeo original usando FFmpeg. Los subtítulos se generan a partir de la transcripción y se incrustan o se sirven como archivo separado.
Tener estas tres etapas en un servidor siempre activo con GPU sería prohibitivamente caro. La solución es que la infraestructura de GPU solo existe cuando hay trabajo que hacer.
La cola de Redis como coordinador
Redis actúa como el sistema nervioso del pipeline. Cuando un usuario sube un vídeo, el frontend (Next.js + Supabase para autenticación y estado) encola un trabajo con los parámetros: vídeo, idioma de destino, opciones de salida.
El worker Python escucha la cola, solicita una instancia GPU al proveedor, ejecuta transcripción → traducción → clonación → síntesis, y encola el resultado para la siguiente etapa. El worker Next.js toma ese resultado, ejecuta la composición con FFmpeg y actualiza el estado del trabajo en Supabase.
El usuario ve el progreso en tiempo real vía polling del estado. Cuando el pipeline termina, el vídeo doblado está disponible para descarga directa.
El autoscaling se configura a nivel de proveedor de infraestructura: si la cola tiene trabajos y no hay workers disponibles, se levanta una instancia; si la cola lleva más de N minutos vacía, la instancia se destruye. El coste es proporcional al uso real.
Lo que aprendí
Distribuir un pipeline de ML en producción real es diferente a hacerlo en un notebook. Los modelos fallan de formas que no documentan, la sincronización de audio con vídeo tiene casos edge que solo aparecen con vídeos reales, y las estimaciones de tiempo de los usuarios son siempre más optimistas que los tiempos reales de cómputo.
El sistema actual funciona. Los primeros vídeos de beta se han procesado. La siguiente iteración es mejorar la interfaz de cola para dar estimaciones de tiempo más precisas y reducir la latencia de la primera etapa (la transcripción, que es la que el usuario percibe primero).