Vídeos el doble de rápidos y una barra que no miente
· 3 min de lectura
Pegas una dirección, tu vídeo arranca y la barra salta al 95%. Luego se queda ahí mientras la etapa más larga avanza en silencio. Desde hoy la barra dice la verdad sobre dónde está tu vídeo, y la espera que describe es más o menos la mitad.
Una barra que parecía terminada demasiado pronto
Un vídeo pasa por etapas: leer la página, escribir el guion, grabar la web, grabar la voz y renderizar el vídeo final. Nuestra barra saltaba al final de cada etapa en cuanto empezaba.
En las etapas rápidas no se notaba. En la lenta, sí. Nada más empezar el render, la barra marcaba 95% y se quedaba ahí todo el render, que es la parte más larga de la espera. La estimación de tiempo también podía desaparecer en ese tramo. Una barra casi llena, sin estimación y sin movimiento, parece atascada aunque todo vaya bien.
Un progreso que empieza por el principio
El arreglo era sencillo una vez nombrado. Cada etapa empieza ahora en su inicio, no en su final, y el render ocupa del 35% al 97% de la barra, porque esa es más o menos su parte real de la espera.
La estimación pasó a ser un pequeño modelo en vez de una suposición. Parte de lo que medimos: unos 27 segundos para que arranque el renderizador, más unos seis segundos de trabajo por cada segundo de vídeo. Cuando el render ya está en marcha, la estimación sigue su ritmo real y se queda en pantalla todo el tiempo.
Una máquina a una quinta parte de su fuerza
Una barra honesta planteó la siguiente pregunta: ¿por qué era tan larga esa etapa? Medimos el worker de render mientras trabajaba. Estaba limitado por su procesador y, aun así, de media solo 0,77 de sus cuatro CPU virtuales estaban ocupadas. Remotion dibuja fotogramas en varias pestañas de navegador a la vez, y nosotros usábamos tres.
Así que reunimos todos los ajustes de render en un solo sitio, renderSettings, para probar combinaciones sin tocar código, y las medimos. Con ocho CPU virtuales, seis fotogramas en paralelo y un preset de codificación más rápido, el render iba 2,09 veces más rápido.
Más rápido, con fotogramas idénticos
La velocidad solo es bienvenida si el vídeo se ve exactamente igual de bien. Antes de cambiar, comparamos la salida nueva con la anterior fotograma a fotograma, con una medida estándar de similitud visual. La nota fue 0,996 sobre 1, idéntica a simple vista.
- La memoria queda holgadamente dentro de la máquina, en torno a la mitad de lo que tiene.
- El trabajo termina en la mitad de tiempo, así que cada render ocupa su máquina menos rato.
- En el vídeo no cambia nada: mismos fotogramas, mismo sonido, mismos subtítulos.
Por eso salió ese mismo día: medido, comparado y aprobado.
Pequeños retoques en la misma versión
La versión que hizo honesto el progreso también pulió algunas cosas que ves en el propio vídeo:
- la tarjeta de cierre se lee mejor;
- un vídeo muestra como mucho dos tomas de una misma sección de la página, para avanzar en vez de quedarse;
- cuando la revisión automática pule las palabras de una escena, las mantiene dentro del tiempo de esa escena.
Cada uno es pequeño. Juntos hacen que el vídeo se sienta más intencionado de la primera escena a la última.
Por qué la espera es una cuestión de producto
Un vídeo que termina en la mitad de tiempo tiene más opciones de verse en la misma sesión en que se creó, y con el primer vídeo es cuando casi todo el mundo decide si PageToVid le sirve. Por eso tratamos el tiempo de render como parte del producto, no solo como infraestructura.
La lección que nos quedamos: una barra de progreso honesta es un instrumento de medida. Cuando dijo la verdad, la espera se hizo visible, y una vez visible pudimos medirla y partirla por la mitad. Puedes ver la nueva barra empezando un vídeo desde la página de nuevo vídeo.
Míralo en tu propia web
Pega una página y obtén el vídeo narrado del que habla este blog. El primero es gratis.
Sigue leyendo
