Hice un montón de trabajo para el Editor de Video (VSE) de Blender 4.1, y como nadie revocó mi permiso de publicación de cambios en el programa, continué en la misma área para Blender 4.2. ¿Es usted uno de los aproximadamente siete usuarios de Blender VSE? ¡Entonces siga leyendo!
Blender 4.2 acaba de salir, y las novedades del Editor de Video en esta versión están listados en esta página. Probablemente la mitad de esa lista sea mi culpa trabajo, y como la 4.2 es una versión de soporte a largo plazo (LTS), esto significa que tendré que mantenerla y arreglarle cualquier problema durante tres años más, hurra :)
Actualizaciones visuales y renderización de clips en un sombreador (shader)
Lo que comenzó en algún chat o en una tarea de diseño como una pregunta casual de “¿podríamos tener las esquinas redondeadas en los clips?”, fue creciendo y creciendo hasta convertirse en, bueno, esquinas redondeadas. Las esquinas redondeadas en los controles y widgets de la interfaz de usuario se han vuelto actualmente tan omnipresentes que parece algo trivial. Y lo sería... si contara con un renderizador de gráficos vectoriales completo con recorte/enmascaramiento y anti-aliasing. Pero no lo tengo.
Los «widgets» de la línea de tiempo del Editor de video (VSE) en Blender 4.1 y anteriores son prácticamente sólo «rectángulos y líneas». El «widget de control» es sorprendentemente complejo y puede tener muchas partes - además de las obvias como la miniatura de la imagen, la forma de onda de audio o el título del texto, hay fondo, superposición de etiqueta de color, superposición de curva de animación (volumen o transición), triángulo de transición de desvanecimiento, teclas de retemporización, manejadores de transformación, rectángulos de contenido de los meta-clip, franjas «bloqueadas» y algunos otros. Aquí hay una línea de tiempo de ejemplo que muestra la mayoría de las opciones posibles, en Blender 4.1:
Las miniaturas, las formas de onda, las curvas, las franjas bloqueadas y los textos se dibujan a su manera, pero todo lo demás no es más que un montón de “fusionar un rectángulo semitransparente” o “fusionar una línea semitransparente”.
Entonces, ¿cómo hacer “esquinas redondeadas”? Bueno, un “rectángulo” necesitaría conseguir redondear sus esquinas de alguna manera. Podría ser a través de la sustitución del rectángulo (dos triángulos) por una forma geométrica más compleja, pero entonces también querría que las esquinas redondeadas tuvieran suavizado (anti-aliasing). Y, lo que es más complicado, es que también querría “todo lo demás” redondeado (por ejemplo, el borde de los clips), o enmascarado por la esquina redondeada (por ejemplo, las franjas diagonales que indican el bloqueo, o la miniatura de la imagen que no se “salga” de la forma redondeada).
Otra forma de hacer todo esto, desde que Iñigo Quílez popularizó los Campos de distancia con signo (Singled Distance Fields), sería dibujar cada widget como un simple rectángulo, y hacer toda la evaluación de “esquinas redondeadas”, enmascaramiento y anti-aliasing dentro de un sombreador (shader). Hace tiempo quería probar con mover todos (o la mayoría) de los widget de los clips a un sombreador dedicado, así que esta fue una excusa para hacerlo.
El proceso fue así:
- Paré todo y lo pospuse por un mes, pensando en lo aterrador que sería desenmarañar todo el código actual de dibujado de widgets del Editor de video (VSE) y migrarlo, de alguna manera, a un sombreador. Por mucho tiempo lo seguí posponiendo o encontrando excusas para no hacerlo.
- Finalmente me puse a hacerlo y resultó que sólo insumió un día de trabajo (#122576). ¡Fácil!
- El siguiente mes lo dediqué a una docena más de solicitudes de admisión de código (#122764, #122890, #123013, #123065, #123119, #123221, #123369, #123391, #123431, #123515, #124210, #124965, #125220), para hacer que las esquinas redondeadas funcionaran de verdad. Algunas de ellas eran correcciones (ajuste a la cuadrícula de píxeles, reconocimiento de los DPI, temas de precisión), otras eran retoques del diseño y del aspecto visual.
Todo esto, sumado a otras varias actualizaciones de diseño y UX realizadas por Richard Antalik y Pablo Vázquez, resultaron en el aspecto actual del Editor de video (VSE) de Blender 4.2:
También he implementado una indicación visual de los medios faltantes (clips que refieren a archivos de imagen/video/sonido inexistentes) #116869; también se puede ver en la captura de pantalla sobre estas líneas.
Sombras de texto y contornos
Los clips de texto en el Editor de video tenían una opción de sombra arrojada, pero sin la posibilidad de modificar la distancia y ángulo con respecto al texto, por lo que, en general, no era muy útil.
Hice que la distancia y el ángulo fueran configurables, y añadí la opción de desenfoque de la sombra. De paso, el texto ganó una opción de contorno (#121478).
Los contornos se implementan con el algoritmo Jump-Flooding, maravillosamente descrito por Ben Golus en este artículo: «The Quest for Very Wide Outlines».
Rendimiento
Blender 4.1 trajo muchas y grandes mejoras de rendimiento en el Editor de video. La versión 4.2 no tantas, pero, sin embargo, hay algunas:
“Eliminación de la oclusión” (“Occlusion culling”) para imágenes/videos opacos (#118396). El Editor de video ya tenía una optimización para cuando un clip que se sabe que que es totalmente opaco, cubre toda la pantalla. En ese caso se detiene el procesamiento de todas los clips por debajo de él (ya que, de todos modos, no serían visibles). Ahora la misma optimización se aplica en algunos casos de clips que no cubren toda la pantalla pero sí cubren completamente algún clip debajo de él (el clip inferior no se evalúa ni se renderiza).
El caso típico es el efecto letterboxing: hay un fondo negro que cubre toda la pantalla, pero el “contenido real” sólo cubre un área más pequeña. En las previsualizaciones del Proyecto Gold, esto ahorró alrededor del 7% del tiempo total de renderizado. No es mucho, pero algo es algo.
Optimización de partes de la decodificación de video ffmpeg
- Caché de los contextos de conversión de color de la biblioteca
libswscale (#118130). Antes de este cambio, cada clip de video individual creaba un objeto de “contexto de conversión de color”, que se utiliza principalmente para hacer la conversión YUV ↔ RGB. Sin embargo, la mayoría de ellos terminan siendo exactamente los mismos, por lo que hay que tener un grupo de ellos y reutilizarlos cuando sea necesario. - Dejar de hacer algún trabajo redundante al iniciar la reproducción de un clip de video (#118503). Esto no sólo hace las cosas más rápidas, sino que también elimina alrededor de 200 líneas de código. ¡Ganamos todos!
- (no es de rendimiento en sí, pero igual) Eliminar el soporte al formato AVI que no sea el provisto por
ffmpeg (#118409). Blender tenía un soporte muy limitado del formato de video .avi más allá del de ffmpeg. Era una especie de herencia maldita de dudosa utilidad. Finalmente se ha ido, junto con 3600 líneas de código. 🎉
Cómo sigue
Investigué el soporte para videos de 10/12 bits y HDR, pero no conseguí terminar nada a tiempo para Blender 4.2. No es de mucha ayuda mi ignorancia sobre codecs de video o sobre la ciencia del color lol :) Pero quizás deba continuar con eso.
El dibujado de la línea de tiempo de Editor de Video claramente tiene partes que “no estaría mal completar“, algunas de las cuales también solucionarían problemas de rendimiento. En este momento, la mayor parte de los controles de los clips se dibujan dentro de un sombreador dedicado de la GPU, pero hay partes que todavía se dibujan por separado (miniaturas, las formas de onda de audio, los meta contenidos de las clips, las superposiciones de las curvas de animación). Conseguir que ellos también se dibujen dentro del mismo sombreador (probablemente) simplificaría el trabajo de la CPU.
La funcionalidad en general del Editor de video dentro de Blender podría beneficiarse de miles de pequeñas mejoras, pero quizás también las personas pertinentes deberían discutir cuál es el panorama general y los planes reales para él. Es bueno seguir haciendo mejoras incrementales discrecionales, pero de vez en cuando también es útil discutir y decidir "¿dónde queremos llegar exactamente?". Quizá deberíamos hacerlo pronto.
Eso es todo.
