El VSE de Blender que usó por accidente

 (aras-p.info)
1 puntos por GN⁺ 2024-02-09 | 1 comentarios | Compartir por WhatsApp
  • Aras ni siquiera sabía que Blender tenía un Video Sequence Editor (VSE), pero tras visitar Blender HQ contribuyó durante unos dos meses, a medio tiempo, con mejoras de rendimiento y calidad para Blender 4.1
  • El cambio más visible es la capacidad de respuesta de la línea de tiempo: en el proyecto Sprite Fright, donde se ven unos 3000 strips, la interfaz al hacer scroll y paneo pasó de unos 15 fps a más de 60 fps
  • Se aplicaron multithreading, SIMD y simplificación matemática a la conversión RGB↔YUV basada en ffmpeg, al remuestreo de audio de Audaspace, a la transformación y filtrado de imágenes, y al procesamiento de efectos del VSE
  • En tres datasets de Blender Studio, el tiempo de render final de películas en el VSE en la PC del autor se volvió aproximadamente 2 veces más rápido, y el render de Sprite Fright bajó de casi 13 minutos a 7 minutos
  • En total se revisaron y fusionaron 37 pull requests; los cambios ya están entrando en Blender 4.1 y el trabajo posterior del VSE continuará a partir de Blender 4.2

Cómo terminó contribuyendo al VSE de Blender

  • Aras viajó a Ámsterdam para asistir a Unite 2023 de Unity y, aprovechando tiempo libre, visitó Blender HQ
  • Allí Francesco y Sergey le preguntaron si quería contribuir al VSE, y así fue como empezó a meter mano al Video Sequence Editor de Blender
  • Aunque no dominaba edición de video, líneas de tiempo, secuenciadores, corrección de color, ffmpeg ni mezcla de audio, comenzó por la optimización de rendimiento, que daba menos pie a discusión
  • Tras unos dos meses de trabajo a medio tiempo, quedó listo un paquete de mejoras que entraría en Blender 4.1
    • Blender 4.1 ya está en beta y puede descargarse desde las daily builds

Dibujo de la línea de tiempo y respuesta de la UI

  • La línea de tiempo del VSE está en la parte inferior de la pantalla y, al alejar por completo el proyecto entero de Sprite Fright edit, se ven alrededor de 3000 strips al mismo tiempo
  • Antes, con solo hacer scroll o paneo en esa línea de tiempo, la actualización de la UI se quedaba en alrededor de 15 fps
  • Después de los cambios, funciona a más de 60 fps
  • El cuello de botella era una estructura que enviaba draw calls a la API gráfica de dos triángulos en dos triángulos, y en el profiler Superluminal la mayor parte del tiempo se iba en las funciones de “empezar a dibujar un quad” y “terminar de dibujar un quad”
  • En el proceso también corrigió comportamientos extraños en la visualización de waveforms de audio y pulió la UI; la visualización de waveform ahora viene activada por defecto

Mejoras de calidad y velocidad en la visualización de scopes

  • El VSE ofrece opciones habituales de visualización de scopes, como histograma de imagen, waveform y vectorscope
  • El histograma se dibujaba pixelado y con saturación muy fuerte, pero ahora se muestra con polígonos más suaves, grid y menor saturación
  • La opción parade del waveform tenía un problema de saturarse demasiado rápido y, tras aplicar multithreading, ahora es 15 veces más rápida
  • El hexágono de color exterior del vectorscope estaba muy pixelado; se copió y aplicó el design actualizado del vectorscope del editor de imágenes
  • La opción de zebra stripes, equivalente a “mostrar áreas sobreexpuestas”, también se volvió de 2 a 3 veces más rápida
  • También menciona que todos los scopes y los scopes del editor de imágenes deberían procesarse algún día con GPU compute shader

Optimización de la conversión RGB↔YUV en ffmpeg

  • Blender usa principalmente la librería ffmpeg para leer y escribir audio y video
  • Dentro de Blender no se usa la herramienta de línea de comandos de ffmpeg, sino librerías de código como libavcodec, y libswscale se encarga de la conversión RGB↔YUV de los frames de video
  • libswscale soporta conversión multihilo, pero si solo se usan sws_getContext() y sws_scale(), en realidad todo corre en un solo hilo
  • Para usar multithreading, hay que configurar el parámetro "threads" al inicializar, así que fue necesario usar directamente sws_alloc_context(), av_opt_set_int() y sws_init_context()
  • Además, sws_scale() no hace multithreading internamente, por lo que hubo que usar sws_scale_frame(), y en ese proceso también salieron a la luz problemas en la forma de crear AVFrame
  • Como resultado, la conversión RGB→YUV al escribir archivos de video se aceleró bastante
  • En la lectura de archivos de video también se usa conversión multihilo YUV→RGB, y se integró el vertical flip en la misma operación

Remuestreo de audio

  • Al renderizar video en el VSE, se detectó que casi la mitad del tiempo de “generar frame de video o audio” se iba dentro de Audaspace, la librería de audio que usa Blender
  • El cuello de botella no estaba en la codificación de audio, sino en la mezcla previa a la codificación, y la mayor parte se consumía en el remuestreo cuando se mezclaban strips de audio como 44.1 kHz dentro de una película a 48 kHz
  • Audaspace tenía dos modos de remuestreo
    • Reproducción dentro de Blender: Linear resampler, que interpola linealmente entre samples
    • Render de película: un resampler basado en el algoritmo de Julius O Smith
  • La calidad de los resamplers se comparó remuestreando un tono sintético de frecuencia única creciente y observando el spectrogram
    • La meta era un resultado con la menor cantidad posible de frecuencias adicionales, como en el ajuste “best” de Audacity
  • El remuestreo preview de Audaspace era rápido de calcular, pero generaba muchas frecuencias adicionales; el de rendering tenía buena calidad en el spectrogram
  • Se añadió una nueva calidad de remuestreo medium a Audaspace y, según el autor, produce un resultado casi igual pero se calcula unas 3 veces más rápido
  • Blender pasó a usar este ajuste medium al renderizar
    • En una PC Windows Ryzen 5950X, el render de 2000 frames de Sprite Fright bajó de 92 segundos a 73 segundos
    • PR relacionada: #116059

Transformación y filtrado de imágenes

  • En el VSE, los strips que generan resultados visuales —como imagen, video, texto o scene— pueden aplicar posición, rotación, escala y crop
  • Estas transformaciones convierten la imagen generada por el strip en una nueva imagen, y ya antes se procesaban en CPU con multithreading
  • La razón de que se haga en CPU y no en GPU es que todavía no hay implementación en GPU, y por ahora hace falta un fallback en CPU para casos como render farms sin GPU

  • Corrección de errores de medio píxel

    • El código existente tenía varios errores de off by half a pixel y, aunque en muchos casos se compensaban o no se notaban, en ciertas situaciones sí aparecían
    • Al ampliar una imagen pequeña 16 veces, el filtro Bilinear desplazaba la imagen medio píxel respecto a los píxeles originales, y además se colaba el color de fondo magenta
    • A la inversa, al reducir exactamente una imagen al 50 %, el filtro Bilinear no filtraba en absoluto
    • Se corrigieron errores tipo “off by something” tanto en Bilinear como en otros filtros
    • PR relacionada: #116628

  • Manejo del borde transparente en Bilinear

    • En el VSE anterior a Blender 4.0 había tres opciones de filtro: Nearest, Bilinear y Subsampled3x3; de ellas, solo Bilinear añadía transparencia de medio texel de ancho alrededor de la imagen resultante
    • Ese comportamiento se notaba al ampliar medios, y ya nadie recordaba por qué existía esa diferencia
    • Se eliminó del código de filtro Bilinear del VSE el comportamiento de “mezclar con transparencia”
    • Sin embargo, al aplicar solo rotación, ese tratamiento de transparencia anterior generaba una especie de anti-aliasing en los bordes, así que en su lugar se aplicó transparency anti-aliasing a los píxeles de borde de la imagen destino
    • PR relacionada: #117717

  • Filtros Cubic, Box y Auto

    • Las transformaciones generales de strips en el VSE no tenían opción de filtro cúbico; solo existía en el strip especial Transform Effect
    • En Blender, “Bicubic” en realidad se refiere al filtro Cubic B-Spline, equivalente a los coeficientes B=1, C=0 del filtro Mitchell-Netravali
    • El autor lo resume como una opción “sin ringing, pero bastante borrosa”
    • Se añadieron al VSE dos tipos de opciones de cubic filtering
    • PR relacionada: #117100, #117517
    • El filtro “Subsampled 3x3” de Blender 3.5 en realidad era un box filter fijo de 3x3, y empezaba a fallar al reducir con proporciones distintas de 3x3
    • Ese filtro se cambió por un Box filter ajustado, en vez de uno fijo de 3x3
    • PR relacionada: #117584
    • Como ahora había demasiados filtros para que el usuario eligiera, se añadió una opción de filtro Auto como valor por defecto en los strips del VSE
    • PR relacionada: #117853
    • Si no hay escala ni rotación, usa Nearest
    • Si la ampliación supera 2x, usa Cubic Mitchell
    • Si la reducción supera 2x, usa Box
    • En los demás casos, usa Bilinear

  • Mejoras de rendimiento en el filtrado

    • El proceso de filtrado de imágenes también se volvió más rápido
    • Eliminación de virtual function en los loops internos y aplicación parcial de SIMD al filtrado Bilinear: #115653
    • Simplificación del filtrado cúbico y añadido de SIMD: #117100
    • Simplificación matemática del filtro Box: #117125
    • Corrección de un problema donde la optimización de saltarse elementos debajo de una solid image que cubre toda la pantalla no funcionaba cuando había escala: #117786
    • En la PC del autor, en un proyecto 3840x2160 con una imagen 1920x1080 ampliada 2 veces y usando filtro Bilinear, el dibujado completo del preview del secuenciador pasó de 36.8 ms a 15.9 ms
    • También ofrece una página interactiva para comparar filtros de upsampling: aras-p.info/img/misc/upsample_filter_comp_2024

Optimización de efectos del VSE

  • Aunque los datasets reales de películas de Blender Studio no usaban muchos effects, también se optimizaron efectos del VSE centrándose en lo que se veía en el código
  • La mayoría de los cambios consistieron en aplicar multithreading
    • Efecto Glow: se aplicó multithreading y quedó 6 a 10 veces más rápido #115818
    • Efecto Wipe: se aplicó multithreading, se simplificó el exceso de cálculo trigonométrico del Clock wipe y quedó 6 a 20 veces más rápido #115837
    • Efecto Gamma Cross: se reemplazó un enfoque que usaba tablas e interpolación complejas para evitar una sola llamada a raíz cuadrada, y quedó 4 veces más rápido #115801
    • Efecto Gaussian Blur: al evitar cálculos duplicados, quedó 1.5 veces más rápido #116089

Cambio en el tiempo de render final

  • Según tres datasets recibidos de Blender Studio, el tiempo de render final de películas en el VSE en la PC del autor se volvió aproximadamente 2 veces más rápido
  • El render de Sprite Fright edit bajó de casi 13 minutos a 7 minutos
  • El autor espera seguir mejorando la velocidad y lo expresa como que “si se logra una mejora de 2x tres veces más, quedaría bastante bien”

Forma de trabajo y siguientes pasos

  • Además de los cambios visibles para usuarios, hubo pull requests para añadir tests, refactorizar y limpiar código, y en total se completaron, revisaron y fusionaron 37 pull requests
  • El autor considera que habría sido difícil hacer este nivel de trabajo en un “empleo real”
    • Dice que en Unity entre 2015 y 2022 probablemente habría logrado alrededor del 30 % de este trabajo en el mismo tiempo, o quizá menos
    • Añade que tal vez en la Unity “ancient” de alrededor de 2010 sí habría sido posible
  • Considera que factores como el tamaño de la empresa, procesos, expectativas, comunicación y política pueden hacer que, en un entorno empresarial pagado, el mismo trabajo sea más lento o incluso se cancele a mitad de camino
  • Espera que Blender no llegue a un tamaño, complejidad o flujo de trabajo donde los procesos, en vez de ayudar a la gente, le quiten motivación y la vuelvan más lenta
  • Como Blender 4.1 ya está en beta, a nivel funcional está completo, y los cambios del VSE para 4.1 están entrando en el estado actual de las release notes
  • El trabajo en Blender 4.2 está comenzando, y su idea es seguir metiendo mano al VSE sin un plan demasiado definido

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-02-09
Opiniones en Hacker News

  • Creo que no habría podido hacer algo así si hubiera sido un “trabajo real”.
    Si hay algo que no me salió bien en mi carrera, es que se dividió así: en proyectos no remunerados donde resolvía por mi cuenta matemáticas nada convencionales, en dos meses lograba más que en dos años normales; pero en proyectos pagados, mis resultados solían ser bastante promedio.
    Lo intenté con muchas ganas, pero nunca encontré el punto medio, y el año pasado, cuando surgió la posibilidad de cobrar por algo que hacía gratis, terminé sin poder tocarlo en absoluto.

    • No estás solo. Me pasó algo parecido toda la vida, y por eso empecé a desconfiar de todo lo que la gente dice sobre la motivación, por ejemplo la idea de que solo las ganancias y los salarios hacen que el trabajo se termine.
      Luego me encontré con la teoría de la alienación de Marx y empezó a tener mucho más sentido. Él partía de la observación de que el trabajo es una actividad que suelen realizar las personas sanas, pero sostenía que no hay que confundir eso con trabajar para otros y estar alienado del producto del propio trabajo.
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • Ninguno de los trabajos más excelentes o interesantes que hice fue pagado.
    • La gestión de proyectos mata por completo ese tipo de trabajo.
      Algunos lugares tienen un buen sistema con una zona de colchón de 1 o 2 semanas en la que puedes hacer lo que quieras, y eso ayuda a mitigar este problema.
    • Todo el trabajo más gratificante e influyente que hice fue casi sin paga o directamente sin paga. Ahora se siente como algo difícil de evitar, y vuelve un poco deprimente trabajar en software.
    • Es un fenómeno bastante interesante, y creo que en gran parte viene del tamaño del equipo y de la necesidad de ganar dinero.
      En un proyecto por pasión no te pagan, así que las expectativas son bajas, no tienes obligación de hacer algo y, en la práctica, eres libre de hacer lo que quieras. Por eso terminas eligiendo trabajo que te resulta interesante e influyente, como explorar tecnologías o herramientas nuevas que te interesan.
      En cuanto entra dinero, entran también las expectativas de quien paga, y como los intentos nuevos y desconocidos tienen más probabilidades de fallar, todo se vuelve más difícil.
      Al final, cuando hay dinero de por medio, la gente evita los riesgos grandes aunque pueda haber una solución potencialmente mejor, y prefiere resultados predecibles.

  • Es realmente impresionante, y también queda claro que el autor original no simplemente entró caminando desde la calle a la sede de Blender. Su larga experiencia en Unity seguramente ayudó bastante a entender ese ámbito.
    Este cambio [1] me gustó especialmente. Al optimizar la etapa de procesamiento de imágenes, eliminó muchísimas “optimizaciones” basadas en tablas y las reemplazó simplemente por cálculos de punto flotante, y en la máquina del autor original quedó unas 4 veces más rápido. Excelente.
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • No solo eso: si miras el diff, reemplazó 100 a 150 líneas de código por 3 líneas. Un pull request así parece algo que solo podrías hacer en sueños.
    • Es una buena optimización, pero me pregunto si return c * c; de verdad es una buena aproximación de la gamma sRGB.

  • Lo que más me gusta de los últimos años es cómo Aras aparece de la nada en varios proyectos gráficos open source, consigue mejoras y aumentos de velocidad enormes, y luego pasa a otro proyecto gráfico cualquiera para repetir lo mismo.

  • Me gustaría hacer algo así con el reproductor de música que uso, MusicBee.
    Si fuera open source, claro. El creador ya casi no lo toca; fue completamente gratis y siempre lo ha sido, así que no entiendo por qué no es open source.
    Hay demasiados problemitas molestos, partes rotas, lentas o raras que me encantaría arreglar en mi tiempo libre.
    Y a estas alturas migrar a otra cosa como FooBar sería demasiado trabajo. También probé HQPlayer, pero su UI/UX era tan espantosa que no pude cambiarme.

    • Como Steven ya dijo varias veces en 2013, no tenía planes de convertir MusicBee en open source en el futuro cercano.
      Dijo que publicar el código fuente sería una de las opciones a considerar cuando ya no quisiera seguir con el proyecto, pero que este era un proyecto de hobby que hacía porque disfrutaba programar, y que jamás lo gestionaría de forma profesional.
      También dijo que ya pasa suficiente tiempo gestionando personas en su trabajo principal como para querer hacerlo también aquí, y que quienes tengan preocupaciones del tipo “¿qué pasa si lo atropella un autobús?” deberían usar otra app.
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • Porque cuando conviertes un proyecto de software en open source, en ese momento se vuelve un proyecto de gestión de personas.
    • Escribir código como proyecto open source exige un nivel de pulido mucho más alto de lo que la gente cree. Es muchísimo más trabajo que simplemente hacer que el programa funcione bien.
    • Hay una alternativa: reescribirlo completo como open source.
    • MusicBee fue el único software que seguí extrañando después de dejar de usar Windows.
      Si se estuviera manteniendo, habría considerado correrlo con Wine, pero ahora abandoné por completo el concepto de gestor de música y simplemente reproduzco los álbumes que escucho con mpv. Y siempre escucho por álbum. No acepto playlists.

  • Desde 2020 uso Blender VSE para toda mi edición de video, y me alegra mucho ver cómo mejora.
    Por su estabilidad y conjunto de funciones, ya lo consideraba el mejor editor de video en Linux. También es una ventaja poder usar todas las herramientas de animación existentes de Blender.

  • VSE realmente necesita mucho cariño. Quería usar todas las herramientas open source para mi podcast, pero al renderizar en Blender una secuencia mp4 con chroma key, un video de 1.5 horas tardó 10 horas
    Al final me pasé a la versión gratuita de DaVinci Resolve

    • Actualmente Blender VSE no tiene aceleración por GPU para renderizar video, así que la CPU se encarga de todo el trabajo
      Además, incluso cuando no hace falta recodificar, no puede saltárselo como DaVinci Resolve y renderiza todos los frames uno por uno. Si esto mejora, ayudaría mucho al rendimiento y la eficiencia de Blender
    • Hay un problema con el renderizado multihilo de Blender: no escala bien para trabajos de VSE. Está enfocado en dividir cada frame, así que no aprovecha bien varios núcleos
      Hace tiempo experimenté con un plugin [1] que iniciaba varios trabajos de renderizado como procesos separados en distintos puntos de la línea de tiempo, y pude acelerar mucho el renderizado
      Ahora también me pasé a Resolve en Linux, porque uso cámaras Blackmagic y eso encaja mejor con ese flujo
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • Usé VSE en un proyecto. Fue doloroso, pero logré sacar el resultado, y en ese momento definitivamente era el mejor editor de video de software libre
      Ahora estoy trabajando en una nueva versión con Final Cut Pro

  • Hacer que cualquier parte del programa 3D Blender sea más rápida parece bastante difícil. Ya es, por mucho, la aplicación 3D que arranca más rápido, y también la que tiene la GUI más responsiva
    Houdini queda segundo, pero no es un segundo puesto cercano

    • Sorprendentemente, todavía hay mucha fruta al alcance de la mano
      Hace unos años toqué el código de un generador “blobby” y, al agregar multihilo, lo hice mucho más lento. Sí se volvía más rápido al superar el overhead del multihilo, pero si no recuerdo mal eso no entraba bien en los casos de uso comunes, así que lo dejé. Seguramente también cometí algunos errores
    • Vi parte del código y creo que todavía hay mucho margen de mejora. Como se menciona en el artículo, hay una cantidad sorprendente de código que, bajo el nombre de optimización, usa enfoques muy complejos pero con una probabilidad similar de terminar haciéndolo más lento
      Por ejemplo, texture painting hace algo así como tres indirecciones de puntero por cada píxel, y en mi PC también se traba bastante
    • Hay muchísimo margen de mejora en las herramientas de animación, y parece que efectivamente están trabajando en ello. La migración a Vulkan también parece que va a ayudar mucho

  • Dice: “¿Sabían que Blender tiene un conjunto de herramientas de edición de video? Yo no lo sabía :)”, pero creo que la mayoría de quienes hacen animación con Blender sí lo saben
    Porque es la forma básica de convertir los frames renderizados en un archivo de video

    • Se puede renderizar directamente a un archivo de video (opciones de ffmpeg), y creo que muchos principiantes o usuarios casuales lo hacen así
      También se puede usar el compositor para convertir una secuencia de frames prerenderizados en un archivo de video
      Aun así, creo que la mayoría prefiere editar video en otro programa como Resolve, y siento que VSE queda en un nicho estrecho de “necesito cortes básicos, pero no transformaciones, títulos ni efectos”, por eso no se usa mucho
      Ojalá alguien siga mejorando las transformaciones y los efectos, y algún día también agregue edición de tres puntos

  • Ah, era Aras. Es impresionante. Recuerdo que su nombre completo era algo como el gran, gran Aras
    Es excelente en programación gráfica y cosas por el estilo, y también parece tener un buen estado de flow cuando programa
    Sus textos son agradables y entretenidos de leer. Se siente como escuchar a una persona hablar. Incluso frases en medio como “However!”
    También me identifico con la parte final, donde dice que si en una empresa típica te aplastan las expectativas estándar de cultura y procesos, tu productividad baja al 30%. El costo de mantener a los empleados atados a “su trabajo” realmente incluye una caída enorme de productividad
    Espero que, al seguir viendo casos así, los tecnólogos aprendan mejores formas de organizar personas y actividades, confíen en ese aprendizaje y empiecen a integrar la alta productividad/alta inmersión en la forma real de organizarse
    Como sugiere el texto, eso podría hacer que trabajar en tecnología sea más disfrutable. Quizás casi tan divertido como jugar con la tecnología

  • Para agregar algo sobre https://projects.blender.org/blender/blender/pulls/116089, inline afecta antes que nada a la regla de definición única
    En pocas palabras, si defines una función en un header y la llamas desde varios archivos .cc, tendrás un error del linker a menos que la marques como inline
    Su efecto sobre la optimización de inlining real va desde “ninguno” hasta “el compilador podría ponderarlo de otra manera por la forma de enlazado” o “sí lo toma como una pista”, y en la optimización en tiempo de enlace aplican consideraciones similares
    Si quieres darle al compilador una señal mucho más fuerte para hacer inline, sobre todo si la función solo se usa dentro del archivo donde está definida, conviene definirla dentro de un namespace anónimo
    La intención original de ponerle inline a esa función puede haber sido intentar lograr inlining real. No está claro que haya una ganancia medible, pero tampoco es imposible