Usei o Blender VSE sem querer

 (aras-p.info)
1 pontos por GN⁺ 2024-02-09 | 1 comentários | Compartilhar no WhatsApp
  • Aras nem sabia que o Blender tinha um Video Sequence Editor (VSE), mas depois de visitar a Blender HQ contribuiu em meio período por cerca de dois meses com melhorias de desempenho e qualidade para o Blender 4.1
  • A mudança mais visível foi a responsividade da timeline: no projeto Sprite Fright, com cerca de 3.000 strips visíveis, a UI de rolagem e pan passou de cerca de 15 fps para mais de 60 fps
  • Foram aplicados multithreading, SIMD e simplificação matemática à conversão RGB↔YUV baseada em ffmpeg, ao resampling de áudio do Audaspace, à transformação e filtragem de imagens e ao processamento de efeitos do VSE
  • Em três datasets do Blender Studio, o tempo final de renderização de filmes no VSE ficou cerca de 2x mais rápido no PC do autor, e a renderização de Sprite Fright caiu de quase 13 minutos para 7 minutos
  • No total, 37 pull requests foram revisados e mesclados; as mudanças já estão entrando no Blender 4.1, e o trabalho posterior no VSE deve continuar a partir do Blender 4.2

Como ele acabou contribuindo para o Blender VSE

  • Aras foi a Amsterdã para participar do Unite 2023 da Unity e, no tempo livre, visitou a Blender HQ
  • Lá, Francesco e Sergey perguntaram se ele tinha interesse em contribuir com o VSE, e depois disso ele começou a mexer no Video Sequence Editor do Blender
  • Mesmo sem conhecer bem edição de vídeo, timeline, sequencer, color grading, ffmpeg ou mixagem de áudio, ele começou pelo campo com menos controvérsia: otimização de desempenho
  • Após cerca de dois meses de trabalho em meio período, surgiu um pacote de melhorias para entrar no Blender 4.1
    • O Blender 4.1 entrou em beta e pode ser baixado nos daily builds

Desenho da timeline e responsividade da UI

  • A timeline do VSE fica na área inferior da tela e, ao dar zoom out no projeto completo Sprite Fright edit, cerca de 3.000 strips aparecem de uma vez
  • Antes, só de rolar ou fazer pan nessa timeline a atualização da UI ficava em cerca de 15 fps
  • Depois das mudanças, ela passou a funcionar em mais de 60 fps
  • O gargalo era uma estrutura que enviava draw calls da API gráfica em blocos de dois triângulos, e no profiler Superluminal a maior parte do tempo era gasta dentro das funções “começar a desenhar um quad” e “terminar de desenhar um quad”
  • Nesse processo, ele também corrigiu comportamentos estranhos na exibição da waveform de áudio e refinou a UI; a exibição da waveform agora vem ativada por padrão

Melhorias na qualidade e velocidade da exibição de scopes

  • O VSE oferece opções comuns de exibição de scopes, como histograma de imagem, waveform e vectorscope
  • O histograma era desenhado com aparência pixelada e saturação muito forte, mas agora usa polígonos mais suaves, grid e menor saturação
  • A opção parade da waveform tinha um problema de saturar rápido demais e, após aplicar multithreading, ficou 15x mais rápida
  • O hexágono colorido externo do vectorscope era muito pixelado; ele copiou e aplicou o design atualizado do vectorscope do editor de imagens
  • A opção de zebra stripes, equivalente à exibição de áreas superexpostas, também ficou de 2x a 3x mais rápida
  • Ele também comenta que todos os scopes, assim como os do editor de imagens, deveriam um dia ser processados com compute shaders na GPU

Otimização da conversão RGB↔YUV no ffmpeg

  • O Blender usa principalmente a biblioteca ffmpeg para leitura e escrita de áudio e vídeo
  • Internamente, o Blender não usa a ferramenta de linha de comando do ffmpeg, mas bibliotecas como libavcodec; a libswscale é responsável pela conversão RGB↔YUV dos frames de vídeo
  • A libswscale suporta conversão multithread, mas se você usar apenas sws_getContext() e sws_scale() ela opera totalmente em thread única
  • Para usar multithreading, era preciso definir o parâmetro "threads" na inicialização, usando diretamente sws_alloc_context(), av_opt_set_int() e sws_init_context()
  • Além disso, sws_scale() não faz multithreading internamente, então foi necessário usar sws_scale_frame(), e nesse processo também apareceu um problema na forma como AVFrame era criado
  • Como resultado, a conversão RGB→YUV na gravação de arquivos de vídeo ficou consideravelmente mais rápida
  • Na leitura de arquivos de vídeo, ele também passou a usar conversão multithread de YUV→RGB e integrou o vertical flip à mesma etapa

Resampling de áudio

  • Ao renderizar vídeo no VSE, foi identificado que quase metade do tempo de “gerar frames de vídeo ou áudio” era gasto dentro da biblioteca de áudio Audaspace usada pelo Blender
  • O gargalo não era a codificação de áudio, mas a mixagem antes da codificação; a maior parte do tempo era consumida pelo resampling quando strips de áudio como 44,1 kHz eram misturados em um filme de 48 kHz
  • O Audaspace tinha dois modos de resampling
    • Reprodução dentro do Blender: Linear resampler, com interpolação linear entre amostras
    • Renderização de filme: resampler baseado no algoritmo de Julius O Smith
  • A qualidade dos resamplers foi comparada fazendo resampling de um som sintético de frequência única crescente e analisando o spectrogram
    • O objetivo era obter um resultado com o mínimo possível de frequências extras, como na configuração “best” do Audacity
  • O resampling de preview do Audaspace era rápido de calcular, mas gerava muitas frequências extras; o de renderização tinha boa qualidade no spectrogram
  • Ele adicionou uma nova qualidade média de resampling ao Audaspace e, na visão dele, ela produz resultado quase igual com cálculo cerca de 3x mais rápido
  • O Blender passou a usar essa configuração média durante a renderização
    • Em um PC Windows com Ryzen 5950X, a renderização de 2.000 frames de Sprite Fright caiu de 92 segundos para 73 segundos
    • PR relacionada: #116059

Transformação e filtragem de imagens

  • No VSE, strips que produzem resultado visual — como imagem, vídeo, texto e scene — podem aplicar posição, rotação, escala e crop
  • Essas transformações funcionam convertendo a imagem gerada pelo strip em uma nova imagem, e isso já era processado em multithread na CPU
  • O motivo de isso ser feito na CPU em vez da GPU é que ainda não existe implementação em GPU, e por enquanto também é necessário um fallback em CPU para casos de uso como renderização em render farms sem GPU

  • Correção de erros de meio pixel

    • O código antigo tinha vários erros de off by half a pixel; em muitos casos eles se anulavam ou passavam despercebidos, mas em situações específicas apareciam
    • Ao ampliar uma imagem pequena em 16x, o filtro Bilinear deslocava a imagem em meio pixel do original, e ainda surgia vazamento da cor de fundo magenta
    • No caso oposto, ao reduzir exatamente 2x, o filtro Bilinear não fazia filtragem nenhuma
    • Foram corrigidos erros de “off by alguma coisa” tanto do Bilinear quanto de outros filtros
    • PR relacionada: #116628

  • Tratamento da borda transparente no Bilinear

    • Antes do Blender 4.0, o VSE tinha três opções de filtro: Nearest, Bilinear e Subsampled3x3; entre elas, só o Bilinear adicionava transparência com meia largura de texel ao redor da imagem resultante
    • Esse comportamento ficava visível ao ampliar mídia, e ninguém mais lembrava por que existia essa diferença
    • Ele removeu do código do filtro Bilinear do VSE o comportamento de “misturar com transparência”
    • Porém, ao aplicar apenas rotação, esse tratamento antigo acabava criando uma espécie de antialiasing nas bordas; então ele passou a aplicar transparency anti-aliasing nos pixels de borda da imagem de destino
    • PR relacionada: #117717

  • Filtros Cubic, Box e Auto

    • As transformações normais de strip no VSE não tinham opção de filtro cubic; isso existia apenas no strip especial Transform Effect
    • No Blender, “Bicubic” na prática significa filtro Cubic B-Spline, equivalente aos coeficientes B=1, C=0 do filtro Mitchell-Netravali
    • O autor resume isso como uma opção “sem ringing, mas com bastante blur”
    • Duas opções de filtragem cúbica foram adicionadas ao VSE
    • PRs relacionadas: #117100, #117517
    • O filtro “Subsampled 3x3” do Blender 3.5 era na verdade um box filter fixo de 3x3, e começava a falhar ao reduzir em proporções diferentes de 3x3
    • Esse filtro foi trocado por um Box filter ajustado, em vez de um 3x3 fixo
    • PR relacionada: #117584
    • Como agora há muitos filtros para o usuário escolher, foi adicionada uma opção Auto como padrão para filtros de strips do VSE
    • PR relacionada: #117853
    • Se não houver escala nem rotação, usa Nearest
    • Se houver ampliação maior que 2x, usa Cubic Mitchell
    • Se houver redução maior que 2x, usa Box
    • Nos demais casos, usa Bilinear

  • Melhorias de desempenho na filtragem

    • O processo de filtragem de imagem também ficou mais rápido
    • Remoção de virtual function no loop interno e aplicação parcial de SIMD ao filtro Bilinear: #115653
    • Simplificação do filtro Cubic e adição de SIMD: #117100
    • Simplificação matemática do filtro Box: #117125
    • Correção de um problema em que a otimização para pular itens sob uma imagem sólida cobrindo a tela inteira não funcionava quando havia escala: #117786
    • No PC do autor, em um projeto 3840x2160 com uma única imagem 1920x1080 ampliada em 2x usando filtragem Bilinear, o desenho completo do preview do sequencer caiu de 36,8 ms para 15,9 ms
    • Ele também disponibilizou uma página interativa para comparar filtros de upsampling: aras-p.info/img/misc/upsample_filter_comp_2024

Otimização de efeitos do VSE

  • Os datasets reais de filmes do Blender Studio não usavam muitos effects, mas ele ainda assim otimizou efeitos do VSE com foco no que aparecia no código
  • A maior parte das mudanças foi aplicação de multithreading
    • Efeito Glow: multithread aplicado, 6x a 10x mais rápido #115818
    • Efeito Wipe: multithread aplicado, simplificação do excesso de cálculos trigonométricos no Clock wipe, 6x a 20x mais rápido #115837
    • Efeito Gamma Cross: troca de uma abordagem com tabela complexa e interpolação usada para evitar uma única chamada de raiz quadrada, ficando 4x mais rápido #115801
    • Efeito Gaussian Blur: evita cálculos redundantes e fica 1,5x mais rápido #116089

Mudanças no tempo de render final

  • Com base em três datasets recebidos do Blender Studio, o tempo final de renderização de filmes no VSE no PC do autor ficou cerca de 2x mais rápido
  • A renderização do Sprite Fright edit caiu de quase 13 minutos para 7 minutos
  • O autor diz esperar ganhos adicionais e resume isso com algo como “se eu conseguir melhorar 2x mais três vezes, já fica bem bom”

Forma de trabalho e próximos passos

  • Além das mudanças visíveis para usuários, houve pull requests para adicionar testes, fazer refatoração e limpeza, totalizando 37 pull requests concluídos, revisados e mesclados
  • O autor avalia que teria sido difícil fazer esse tanto de trabalho em um “emprego de verdade”
    • Na Unity entre 2015 e 2022, ele acha que teria feito cerca de 30% disso no mesmo tempo, talvez até menos
    • Ele acrescenta que talvez isso fosse possível na Unity “ancient” por volta de 2010
  • Na visão dele, quando entram em cena fatores como tamanho da empresa, processos, expectativas, comunicação e política, o ambiente corporativo pago pode tornar o mesmo trabalho mais lento ou até levá-lo ao cancelamento no meio do caminho
  • Ele espera que o Blender não siga para um nível de escala, complexidade e workflow em que os processos passem a desmotivar e atrasar as pessoas em vez de ajudá-las
  • Como o Blender 4.1 entrou em beta, a parte funcional já está concluída, e as mudanças do VSE para a versão 4.1 estão entrando no estado atual das release notes
  • O trabalho do Blender 4.2 está começando, e ele pretende continuar mexendo no VSE sem um plano muito definido
    • O andamento pode ser acompanhado na seção de fórum Weekly Updates

Leituras relacionadas

1 comentários

 
GN⁺ 2024-02-09
Opiniões no Hacker News

  • Acho que eu não teria conseguido fazer algo assim se fosse um “emprego de verdade”
    Se há algo que não deu certo na minha carreira, foi essa divisão: em um projeto não remunerado em que eu resolvia matemática nada trivial por conta própria, eu fazia em dois meses mais do que normalmente faria em dois anos; já em projetos pagos, meus resultados tendiam a ser bem medianos
    Tentei muito encontrar um meio-termo, mas não consegui; no ano passado, quando surgiu a possibilidade de receber por algo que eu fazia de graça, acabei simplesmente não conseguindo tocar no assunto

    • Você não está sozinho. Passei por coisas parecidas a vida toda, e isso me fez desconfiar de tudo o que as pessoas dizem sobre motivação, por exemplo a ideia de que só lucro e salário fazem as coisas serem concluídas
      Então encontrei a teoria da alienação de Marx, e ela começou a fazer muito mais sentido. Ele partiu da observação de que o trabalho é uma atividade que pessoas saudáveis costumam realizar, mas achava que isso não deveria ser confundido com trabalhar para outra pessoa e ser alienado do produto do próprio trabalho
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • Nenhum dos trabalhos mais excelentes ou interessantes que já fiz foi pago
    • Gerenciamento de projetos mata todo esse tipo de trabalho
      Alguns lugares têm um bom sistema, com um período de folga de 1 a 2 semanas em que você pode fazer qualquer coisa, e isso ajuda a aliviar esse problema
    • Todo o trabalho mais gratificante e impactante que fiz foi por quase nada ou sem receber nada. Hoje isso parece algo difícil de evitar, e torna o trabalho com software um pouco deprimente
    • É um fenômeno bem interessante, e acho que vem principalmente do tamanho da equipe e da necessidade de ganhar dinheiro
      Em projetos de paixão, como você não é pago, as expectativas são baixas, não há obrigação de fazer algo, e na prática você tem liberdade para fazer o que quiser. Assim, acaba escolhendo trabalhos interessantes e impactantes para si, como explorar uma nova tecnologia ou ferramenta que lhe interessa
      No momento em que dinheiro entra na equação, entram também as expectativas de quem paga, e tentar algo novo e desconhecido fica mais difícil porque a chance de falhar é maior
      No fim, quando há dinheiro envolvido, acho que as pessoas evitam riscos altos mesmo quando pode haver uma solução melhor, e preferem resultados previsíveis

  • É realmente impressionante, e também é claro que o autor do post original não simplesmente entrou andando na sede da Blender vindo da rua. A longa experiência dele na Unity deve ter ajudado bastante a entender essa área
    Gostei especialmente desta mudança [1]. Ao otimizar a etapa de processamento de imagens, ele removeu um monte de “otimizações” baseadas em tabelas e simplesmente as substituiu por cálculos de ponto flutuante, o que ficou cerca de 4 vezes mais rápido na máquina do autor. Excelente
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • Além disso, olhando o diff, ele trocou 100 a 150 linhas de código por 3 linhas. Um pull request desses é coisa de sonho
    • É uma boa otimização, mas fico me perguntando se return c * c; é mesmo uma boa aproximação da gama sRGB

  • Uma das minhas coisas favoritas dos últimos anos tem sido ver o Aras entrar do nada em vários projetos gráficos open source, produzir melhorias e ganhos enormes de velocidade, e então passar para outro projeto gráfico aleatório e repetir o processo

  • Eu queria fazer algo assim no player de música que uso, o MusicBee
    Se ele fosse open source, claro. O criador quase não mexe mais nele, ele sempre foi totalmente gratuito, e não entendo por que não é open source
    Há tantos pequenos incômodos, partes quebradas, lentas ou estranhas, que eu adoraria consertar no meu tempo livre
    E, a esta altura, migrar para outra coisa como FooBar dá trabalho demais. Também experimentei o HQPlayer, mas a UI/UX é tão terrível que não consegui mudar

    • Como o Steven já disse várias vezes em 2013, não há planos de tornar o MusicBee open source no futuro próximo
      Ele disse que liberar o código-fonte quando não quiser mais continuar o projeto é uma das opções que consideraria, mas que este é um projeto de hobby feito porque programar é divertido, e que jamais pretende tocá-lo de forma profissional
      Como já passa tempo suficiente no trabalho principal gerenciando pessoas, não quer fazer isso aqui também; e disse ainda que, se alguém se preocupa com coisas como “e se ele for atropelado por um ônibus?”, o certo é usar outro aplicativo
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • Porque, no momento em que você transforma um projeto de software em open source, ele vira um projeto de gestão de pessoas
    • Escrever código como um projeto open source exige um nível de acabamento muito maior do que as pessoas imaginam. Dá muito mais trabalho do que simplesmente fazer o programa funcionar bem
    • Há uma alternativa. É só reescrever tudo como open source
    • O MusicBee foi o único software de que continuei sentindo falta depois que parei de usar Windows
      Se ainda estivesse sendo mantido, eu consideraria rodá-lo no Wine, mas hoje desisti do próprio conceito de gerenciador de música e simplesmente reproduzo os álbuns que quero ouvir no mpv. E sempre ouço por álbum. Playlists, não obrigado

  • Desde 2020 uso o Blender VSE para toda edição de vídeo, e é muito bom ver as melhorias
    Considerando a estabilidade e o conjunto de recursos, eu já o via como o melhor editor de vídeo no Linux. O fato de poder usar todas as ferramentas de animação existentes do Blender também é uma vantagem

  • O VSE realmente precisa de muito carinho. Eu queria usar todas as ferramentas em código aberto no podcast, mas, ao renderizar no Blender uma sequência mp4 com chroma key, um vídeo de 1,5 hora levou 10 horas
    Acabei migrando para a versão gratuita do DaVinci Resolve

    • Atualmente, o Blender VSE não tem aceleração por GPU na renderização de vídeo, então a CPU processa todo o trabalho
      Além disso, mesmo quando não é preciso recodificar, ele não consegue pular essa etapa como o DaVinci Resolve e renderiza cada quadro, um por um. Se isso for melhorado, vai ajudar muito no desempenho e na eficiência do Blender
    • Há um problema em que a renderização multithread do Blender não escala bem para trabalhos no VSE. Como o foco é dividir cada quadro, ele não aproveita bem vários núcleos
      No passado, experimentei um plugin [1] que iniciava vários trabalhos de renderização em pontos diferentes da timeline como processos separados, e isso conseguia acelerar bastante a renderização
      Hoje migrei para o Resolve também no Linux, porque uso câmeras Blackmagic e ele se encaixa melhor nesse fluxo
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • Usei o VSE em um projeto. Foi sofrido, mas consegui produzir o resultado e, na época, ele certamente era o melhor editor de vídeo de software livre
      Agora estou trabalhando na nova versão no Final Cut Pro

  • Tornar qualquer parte do programa 3D Blender mais rápida parece ser bem difícil. Ele já é, de longe, o aplicativo 3D que inicia mais rápido, e a GUI também é a mais responsiva
    O Houdini fica em segundo lugar, mas não é um segundo lugar nem de perto

    • Surpreendentemente, ainda há muita fruta baixa no pé
      Alguns anos atrás, mexendo no código de um gerador “blobby”, adicionei multithreading e o deixei muito mais lento. Quando passava do overhead do multithreading, ficava mais rápido, mas, pelo que lembro, isso não se encaixava bem nos casos de uso comuns, então desisti. Com certeza também devo ter cometido alguns erros
    • Vi partes do código e acho que ainda há muito espaço para melhorias. Como mencionado no texto, há uma quantidade surpreendente de código parecido, em que abordagens feitas em nome da otimização são muito complexas, mas têm uma probabilidade semelhante de, na prática, deixar tudo mais lento
      Por exemplo, a pintura de texturas faz algo como três indireções de ponteiro por pixel, e mesmo no meu PC dá bastante engasgo
    • Há um espaço enorme para melhorias nas ferramentas de animação, e parece que isso está de fato em andamento. A transição para Vulkan também parece que vai ajudar bastante

  • Ele disse: “Você sabia que o Blender tem um conjunto de ferramentas de edição de vídeo? Eu também não sabia :)”, mas acho que a maioria das pessoas que cria animações com o Blender sabe disso
    Porque é a forma básica de transformar os quadros renderizados em um arquivo de vídeo

    • Dá para renderizar os quadros diretamente como arquivo de vídeo (opções do ffmpeg), e iniciantes ou usuários leves provavelmente fazem bastante isso
      Também dá para usar o compositor para transformar uma sequência de quadros pré-renderizados em um arquivo de vídeo
      Ainda assim, acho que a maioria prefere editar vídeo em outro programa, como o Resolve, e o VSE parece ficar em um nicho estreito de “preciso de cortes básicos, mas não preciso de transformações, títulos nem efeitos”, então não é muito usado
      Seria bom se alguém continuasse melhorando transformações e efeitos e, um dia, também adicionasse edição de 3 pontos

  • Ah, então era o Aras. Ele é incrível. Pelo que lembro, o nome completo dele era realmente o grande Aras
    Ele é excelente em programação gráfica e afins, e parece ter um bom fluxo de imersão quando programa
    Os textos dele são agradáveis e divertidos de ler. Parece que você está ouvindo uma pessoa falar. Inclusive frases no meio como “However!”
    Também me identifiquei com a parte final, sobre a produtividade cair para 30% quando alguém é esmagado pelas expectativas de cultura e processos padrão em uma empresa comum. O custo de manter funcionários presos ao “próprio trabalho” realmente inclui uma enorme queda de produtividade
    Espero que, ao ver cada vez mais casos como esse, tecnólogos aprendam formas melhores de organizar pessoas e atividades, confiem nesse aprendizado e comecem a integrar alta produtividade/alto foco às formas reais de organização
    Como o texto sugere, isso pode tornar trabalhar na indústria de tecnologia mais prazeroso. Talvez quase tão divertido quanto brincar com tecnologia

  • Acrescentando sobre https://projects.blender.org/blender/blender/pulls/116089, inline afeta antes de tudo a regra de definição única
    Em termos simples, se você definir uma função em um header e chamá-la a partir de vários arquivos .cc, terá erro do linker a menos que ela seja marcada como inline
    O efeito sobre a otimização real de inline varia de “nenhum” a “o compilador pode atribuir pesos diferentes por causa do modo de ligação” e “ele realmente trata como uma dica”, e há considerações parecidas em otimização em tempo de link
    Para dar ao compilador um sinal muito mais forte de inline, especialmente se for uma função usada apenas dentro do arquivo em que foi definida, é melhor defini-la dentro de um namespace anônimo
    A intenção original ao colocar inline nessa função pode ter sido tentar obter inlining de fato. Não está claro se há um ganho mensurável, mas também não é impossível