“Automatizar la edición de video” abarca tres trabajos distintos, y la mayor parte de la decepción que genera proviene de confundirlos. Precisar a cuál te refieres es gran parte del trabajo.
Tres trabajos, una frase
Transformaciones mediante scripts. ffmpeg, moviepy, un bucle de shell. Cambiar el tamaño del contenido de una carpeta, concatenar, normalizar la sonoridad, incrustar un archivo de subtítulos. Es determinista, no requiere criterio y lleva veinte años funcionando. Si solo necesitas eso, no necesitas un modelo.
Un entorno que planifica y ejecuta. Algo lee tu material grabado, propone una edición y la lleva a cabo después de que aceptes. Esa es la parte nueva y la que aborda este artículo.
Controlar el editor que ya tienes. Premiere, Resolve, Final Cut, mediante la API que exponga la aplicación. Aquí el límite lo pone el proveedor, no tus herramientas: puedes automatizar exactamente lo que permita su interfaz de scripting, y esa interfaz cambia entre versiones y entre modalidades gratuitas y de pago.
Fallan por motivos distintos, y una herramienta que hace bien lo primero no necesariamente hace bien lo segundo.
El límite que marcan los propios editores
Vale la pena leer lo que dicen los editores cuando surge este tema, porque son más precisos que la publicidad. La respuesta con más votos en un hilo reciente de r/VideoEditing sobre edición con IA lo expresó claramente: el valor que aportas es saber qué editar, no controlar el software. En un hilo paralelo de DaVinci Resolve, la persona que más se quejaba de que se introdujera IA en las herramientas de edición marcó su propio límite sin que nadie se lo pidiera: transcripción, rotoscopia, eliminación de objetos, limpieza de audio, seguimiento, tareas aburridas y repetitivas: bien, si ahorra tiempo.
Esa es una especificación útil. La parte mecánica se automatiza. Las decisiones —qué cortar, cuándo hacerlo, qué toma transmite mejor el momento— no, y una herramienta que afirma lo contrario produce trabajo que tendrás que rehacer.
Información antes de los cortes
El fallo habitual es pedir directamente un resultado: “haz un resumen con los mejores momentos de esto”. El modelo no ha visto el material; está deduciendo la estructura a partir de tu frase.
El paso que lo soluciona no es vistoso. Antes de cualquier corte, extrae lo que realmente contiene el archivo:
- Transcripción con marcas de tiempo — y etiquetas de hablante cuando habla más de una persona.
- Límites de escena — dónde cambia realmente el plano.
- Intervalos de silencio — dónde no habla nadie, con un umbral que tú estableces.
- Indicadores de calidad — audio saturado, tramos mal expuestos, fotogramas congelados.
Ahora una lista de cortes es una decisión basada en datos en lugar de una conjetura y, lo que importa más, se puede revisar. Puedes leer por qué se eligió un segmento antes de dedicar tiempo a renderizarlo.
Planificar, aprobar, montar
La segunda característica que separa una automatización útil de un truco de demostración es que el plan constituye un documento separado de la ejecución.
En concreto: la ejecución genera primero una lista de decisiones de edición: cada segmento, su archivo de origen, sus puntos de entrada y salida, y lo que ocurre sobre él. Tú lees esa lista. No se renderiza nada hasta que la apruebas. De esa separación se derivan tres cosas. Un error te cuesta una lectura en vez de un renderizado. La lista permite ver las diferencias, de modo que una segunda pasada cambia cuatro segmentos en lugar de rehacerlo todo. Y cuando el resultado es incorrecto, puedes saber si falló el plan o la ejecución: errores distintos con soluciones distintas.
Si una herramienta renderiza directamente a partir de una instrucción sin un resultado intermedio que puedas revisar, ha automatizado las conjeturas en lugar de la edición.
Lo que no se automatiza
- La narrativa y el gusto. Dos editores con el mismo material cuentan dos historias distintas. Esa diferencia es el trabajo.
- Cualquier cosa que requiera percibir el ambiente. Qué toma es más graciosa, qué pausa justifica su duración.
- Entregables solo de audio o solo de transcripción. Conviene decirlo claramente porque es una confusión habitual: un flujo de procesamiento de video no es un servicio de transcripción, y usar uno como si fuera el otro da un resultado peor que una herramienta específica.
La cuestión del costo, con sinceridad
Los editores plantean esto antes que la calidad, y tienen razón. Todo lo que depende de un modelo tiene un costo por ejecución, y analizar material largo es caro. Extraer la información una vez y reutilizarla en distintas pasadas no solo es más ordenado: explica gran parte de la diferencia entre un flujo de trabajo que conservas y uno que abandonas tras la primera factura. Prefiere un paso determinista siempre que sea suficiente.
Ejecutarlo en Orkas
Orkas incluye VideoStudio, que funciona exactamente en este orden: información extraída del material, después una lista de decisiones de edición que combina modalidades, luego un punto de aprobación y, por último, un montaje determinista: imagen, superposiciones, narración, subtítulos y comprobaciones de sonoridad. Es de código abierto y se ejecuta en tu equipo, y la misma aplicación de escritorio controla las CLI de programación que ya tienes instaladas, así que una ejecución de edición y una de scripting son el mismo tipo de tarea en lugar de dos herramientas separadas. Encontrarás el recorrido del escenario en el caso de uso del flujo de producción de video.
Lo que deliberadamente no hace: entregar resultados solo de audio o solo de transcripción, ni renderizar nada antes de que hayas aprobado el plan.