Lancé un segundo motor de renderizado para que la vista previa coincidiera con la exportación. Empeoró las cosas.

Katto es un recortador de video con IA. Le pasas un video largo, corta los mejores momentos en shorts verticales, y un editor te deja ajustar el encuadre, los subtítulos y la disposición antes de exportar. Lo construyo yo solo, en público. Esta es la historia de un error que cometí en ese editor, y de lo que aprendí, al corregirlo, sobre eso de "lo que ves es lo que obtienes".

El problema que estaba resolviendo

Un editor de clips vive o muere por una sola promesa. Lo que ves en la vista previa es exactamente lo que descargas. Si el subtítulo queda un píxel más arriba en la exportación, si el recorte se desplaza, si un color no coincide, el usuario deja de confiar en la herramienta. Y la confianza es todo el producto.

Mi vista previa es una composición de React renderizada en el navegador. Mis exportaciones se renderizaban en el servidor con FFmpeg. Dos renderizadores distintos dibujando el mismo clip. Divergían, como era de esperar. Las fuentes de los subtítulos, el renderizado de los emojis, el recorte exacto en una pantalla dividida. El clásico "la vista previa no coincide con la exportación".

La solución que parecía correcta (y no lo era)

Así que hice lo obvio. Hice que la misma composición de React que dibuja la vista previa en el navegador renderizara también la exportación en el servidor, a través de un Chromium sin interfaz (Remotion). Un solo componente, una sola fuente de verdad. Vista previa igual a exportación, garantizado.

Esto no es una crítica a Remotion. Es excelente en aquello para lo que fue construido. El error fue mío. Lo enchufé como un segundo motor de exportación al lado de una tubería de FFmpeg que ya existía.

Mis clips iniciales, los que la IA genera antes de que abras siquiera el editor, seguían renderizándose con FFmpeg. Es rápido, está probado, ejecuta toda la tubería. No pensaba arrancarlo de raíz.

Así que ahora tenía dos motores produciendo archivos. FFmpeg para el clip generado, Chromium y Remotion para la reexportación editada. La divergencia exacta que me había propuesto eliminar ahora era peor. El clip que veías en tu lista de resultados (FFmpeg) y el mismo clip reexportado tras una edición mínima (Remotion) podían salir sutilmente distintos. Había convertido un renderizador en dos y lo había llamado paridad.

Encima, el renderizado con Chromium era lento. De tres a cuatro minutos por clip, frente a unos 30 segundos de FFmpeg. Y fallaba de vez en cuando. Cuando fallaba, recurría en silencio a FFmpeg y le entregaba al usuario un archivo con sus ediciones descartadas sin avisar. El peor fallo posible. Incorrecto, y silencioso.

La toma de conciencia

"Vista previa igual a exportación" no se logra haciendo que la vista previa sea el renderizador. Se logra teniendo una sola fuente de verdad para el renderizado, y dejando que la vista previa sea una aproximación fiel a ella.

Un Player de navegador es una gran vista previa. Nunca debió convertirse en un segundo motor de exportación. En el momento en que lo hizo, tuve dos implementaciones de la misma geometría, divergiendo con cada cambio.

Lo que hice

• FFmpeg es el único motor que produce archivos. La generación y la reexportación pasan por la misma tubería. Las exportaciones de un clip típico de menos de 60s bajaron a unos 30 segundos (medí 32s), frente a los tres o cuatro minutos que tomaba la ruta de Chromium.
• El Player del navegador vuelve a lo que hace bien, la vista previa interactiva. No renderiza nada de lo que se entrega.
• Porté a FFmpeg los detalles que solo el navegador podía hacer, los subtítulos con ciclo de color palabra por palabra y la proporción ajustable del reparto en la disposición apilada, para que la ruta rápida cubra los casos comunes.
• El recurso silencioso está muerto. Si un renderizado no puede producirse de forma fiel, el usuario recibe un error visible, nunca un archivo incorrecto sin avisar.
• Un solo conjunto de coordenadas, la última pieza que estoy terminando. Cuando arrastras un recorte en la vista previa, esos rectángulos exactos deberían ser los que usa FFmpeg, y no una segunda geometría que el servidor recalcula por su cuenta. Esta es la sutil. Incluso tras unificar el motor, la vista previa calculaba los rectángulos de recorte de una manera y la exportación los calculaba de otra. La estoy cerrando ahora, haciendo que FFmpeg consuma los rectángulos exactos del estado del editor, porque la lección es la misma un nivel más abajo. Cualquier segundo cálculo de la misma cosa es una fuente de divergencia.

Las lecciones

1. "Haz que la vista previa sea el renderizador" es seductor y casi siempre erróneo. Acabas con dos renderizadores el día que tengas cualquier otra ruta de renderizado. Una sola fuente de verdad para la salida. La vista previa la aproxima.
2. Un segundo motor "por paridad" se convierte en una tercera fuente de divergencia oculta. Si dos rutas de código calculan la misma geometría o formato, van a divergir. La única pregunta es cuándo.
3. Los recursos silenciosos son el pecado capital. Un archivo levemente incorrecto sin advertencia cuesta más confianza que un error honesto. Falla en voz alta.
4. Verifica el artefacto, no los registros. Mis registros decían "disposición apilada renderizada". Solo encontré el bug real sacando el MP4 exportado real del almacenamiento y mirando un fotograma. Los píxeles son la verdad.

Soy un fundador en solitario que lanza rápido, en público. Este me costó un desvío bienintencionado. Si estás construyendo cualquier editor con una vista previa y una exportación, el camino más corto hacia la confianza es aburrido. Un solo renderizador, errores honestos, y revisa los fotogramas.

Katto está en katto.tech. Si construyes herramientas de video, me encantaría de verdad comparar notas sobre la paridad entre vista previa y exportación.