Programa de conversão de vídeo open source HandBrake 1.7.0

 (forum.handbrake.fr)
3 pontos por GN⁺ 2023-11-21 | 1 comentários | Compartilhar no WhatsApp

Aviso de atualização do HandBrake 1.7.0

  • Antes de atualizar o HandBrake, verifique se não há codificações pendentes e recomenda-se fazer backup dos presets personalizados e das preferências do aplicativo.
  • Usuários do Windows devem instalar obrigatoriamente a Microsoft .NET Desktop Runtime versão 6.0.x, e mesmo que o .NET 7 esteja instalado, ainda é necessário instalar o .NET 6.

Notas de lançamento do HandBrake 1.7.0

  • A lista completa de melhorias e correções de bugs pode ser consultada nas notas de lançamento no GitHub.

Relato de problemas e envio de feedback

  • Se você encontrou um bug ou problema reproduzível, ou deseja enviar feedback, pedem que informe isso por meio do rastreador de issues no GitHub.
  • Também é possível entrar em contato pelo canal de suporte da comunidade no IRC.
  • Como o aplicativo HandBrake é desenvolvido por uma pequena equipe de voluntários no tempo livre, respostas imediatas podem ser difíceis, mas todos os comentários são verificados e feedback construtivo é bem-vindo.

Agradecimentos e contribuições

  • Alguns recursos desta versão foram fornecidos por usuários ou empresas do HandBrake, e as traduções são realizadas com a participação ativa de uma comunidade global de voluntários.
  • Para quem tem interesse em contribuir, mas ainda não participou, recomenda-se ler o guia de contribuição.
  • Há várias maneiras de contribuir mesmo sem ser desenvolvedor.

Opinião do GN⁺

  • A atualização para o HandBrake 1.7.0 exige backup das configurações personalizadas e a instalação de um novo runtime do .NET.
  • Esta atualização inclui melhorias e correções de bugs, e é um projeto baseado na comunidade com contribuições de usuários e empresas.
  • Este texto informa o lançamento de uma nova versão do HandBrake, um transcodificador de vídeo open source, e é interessante por destacar a importância da colaboração e da contribuição dentro da comunidade técnica.

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-21
Comentários do Hacker News

  • Se a frustração é que o HandBrake não calcula automaticamente o resto quando você define o tamanho final do arquivo, a conta em si é simples
    Bitrate médio [kbps] = tamanho alvo [quilobits] ÷ duração [segundos]
    Por exemplo, para deixar um arquivo de 2 horas e 48 minutos com menos de 5 GB, 2 horas e 48 minutos são 10.080 segundos e 5 GB são 40.000.000 kb, então o bitrate médio fica em 40.000.000 kb ÷ 10.080 s = 3.968 kbps
    Se o áudio estiver em 256 kbps, então o bitrate médio de vídeo precisa ser de 3.712 kbps ou menos

    • Esse cálculo só funciona quando se codifica com bitrate constante
      Normalmente se codifica com qualidade constante, e o tamanho de saída depende bastante do vídeo de entrada
      Então fiz um wrapper em Python para analisar a saída do HandBrakeCLI e estimar o tamanho final com base no percentual concluído e no tamanho atual do arquivo de saída
      Se parecer que o arquivo vai ficar grande demais, ou que a qualidade de saída está ruim a ponto de precisar aumentar o fator de qualidade, dá para interromper cedo

  • É legal ver que a mensagem “Put that cocktail down. Your HandBrake encode is complete!” continua ali mesmo depois de tantos anos

    • Gosto desse tipo de detalhe. Dá a sensação de recolocar um pouco de alma ou fantasma na máquina, e acho isso bacana

  • Antigamente, mesmo depois de o pipeline do HandBrake virar 10-bit, muitos filtros ainda eram 8-bit, então era fácil degradar a qualidade da codificação sem perceber se você escolhesse o filtro errado
    Agora parece que a maioria, talvez todos os filtros, suportam 10-bit
    Além disso, por causa da licença do FDK-AAC, ele não podia ser incluído, então o codec AAC das versões lançadas ficava em desvantagem, mas ouvi dizer que hoje esse codec já não é tão ruim quanto antes
    Fico curioso se ainda há alguma grande armadilha nesse ótimo app na versão atual

    • Desde a 1.6, todos os filtros suportam alta profundidade de bits. A qualidade do codificador AAC agora também é bem razoável, e no macOS dá para usar o codificador AAC da Apple, então isso não é problema
      De qualquer forma, a questão principal é falta de gente. Há muitos recursos desejáveis parados no cemitério de funcionalidades
      Mas todo projeto open source é mais ou menos assim

  • Hoje em dia eu peço para o ChatGPT me dar um comando de terminal ffmpeg
    É muito mais rápido que qualquer app e pode ser ajustado do jeito que eu quiser

    • Você pode clicar no arquivo, escolher “open with handbrake” e apertar “convert”. Não consigo imaginar como isso poderia ser mais rápido
    • Dizer que pode ser “ajustado do jeito que eu quiser” significa, na prática, entender as opções do ffmpeg e como elas interagem
      Não dá para dizer que ficar testando coisas ou lendo páginas de manual é “muito mais rápido” do que escolher um preset no HandBrake e clicar em caixas de seleção ou mover sliders
    • Mas o ChatGPT não sabe qual é o formato do arquivo. A menos que você também coloque no prompt a saída do ffprobe, claro
      Se a fonte for um DVD, há muita coisa a considerar, como proporção da imagem, desentrelaçamento, tratamento de legendas etc.
    • O ffmpeg é justamente o único programa ao qual eu gostaria que aplicassem uma interface visual no-code
      Hoje em dia me pego procurando uma opção --chatgpt, tipo um --help, que deixe navegar por qualquer página de manual
    • É mais rápido, mas também mais propenso a erros. E aplicativos também podem ser ajustados do jeito que você quiser, então nesse ponto fica empatado

  • A lista de recursos parece boa. Estou especialmente ansioso pelas melhorias de desempenho nas arquiteturas arm64 / aarch64 / Apple Silicon, pela decodificação HEVC mais rápida no FFmpeg mais recente e pelo filtro bwdif 30% mais rápido, pelas novas otimizações em assembly do SVT-AV1 com ganho de até 4x, e pela remoção de cópias de frames desnecessárias para melhorar a eficiência de memória e acelerar a conversão de vídeo

  • Minha única reclamação sobre o HandBrakeCLI é que ele não consegue codificar entrada enviada por pipe via stdin
    O FFmpeg suporta isso, e eu achava que o HandBrake também usava FFmpeg internamente

    • O HandBrake usa libavformat, libavcodec e libavfilter, que fazem parte das bibliotecas do FFmpeg
      Mesmo assim, é um aplicativo completamente diferente. Os decodificadores, alguns demuxers e alguns filtros são os mesmos, mas a forma como tudo isso é conectado é totalmente diferente do aplicativo de linha de comando do FFmpeg
    • Named pipes não funcionam?
      Ou talvez alguma mágica de Bash como handbrake-cli -i <(cat video-file.mp4) funcione
      Nunca usei o HandBrakeCLI, só a interface gráfica, então não sei ao certo
    • Quando conheci o HandBrake, fiquei surpreso ao descobrir que ele constrói muitos componentes por conta própria em vez de simplesmente usar o FFmpeg
      Claro que em outras partes ele usa bastante as bibliotecas do FFmpeg
      É um dos poucos transcodificadores que não se limitam a ser um wrapper para FFmpeg, o que é ao mesmo tempo vantagem e desvantagem

  • Alguém consegue explicar de forma simples por que o HandBrake diz que não pode implementar uma opção de tamanho de arquivo alvo?
    Em apps Android de compressão de vídeo esse recurso funciona bem, mas num pedido relacionado no GitHub do HandBrake um dos mantenedores disse que na prática isso é difícil

    • Isso é literalmente um recurso oferecido por todos os codificadores subjacentes. Dá até para fazer em cadeias de filtros exóticas com ffmpeg/vapoursynth
      Então não consigo imaginar por que diriam que não dá
      Se for no Windows, eu recomendaria simplesmente o Staxrip: https://github.com/staxrip/staxrip
      Também existe um app para Linux baseado em vapoursynth, mas não lembro o nome
      Ou talvez seja uma das GUIs do AV1an. Todas essas ferramentas suportam tamanho de arquivo alvo e oferecem muito mais recursos do que o HandBrake

  • Por que até hoje não existe uma função simples de “limitar o vídeo X ao tamanho Y”?
    Eu só quero um arquivo de vídeo de 5 GB, mas o HandBrake parece se importar mais com um entre 50 presets obscuros do Vimeo que eu mal entendo

    • Não entendo por que você quer justamente um limite de 5 GB. Você tem uma gaveta cheia de pendrives de 5 GB para preencher?
      5 GB é obviamente maior que um CD e, a menos que você esteja tentando colocar exatamente 10 arquivos em um Blu-ray, é pequeno demais para uso em Blu-ray
      Assim como os presets do Vimeo parecem estranhos para você, para o resto do mundo o seu caso de uso também parece estranho

  • Exceto quando preciso lidar com vídeo HDR, quase sempre prefiro ffmpeg ao HandBrake
    Não consegui encontrar um comando adequado do ffmpeg para copiar os metadados HDR da fonte de entrada para a saída
    Da última vez que verifiquei, isso não era possível, e eu precisava extrair os metadados manualmente com uma ferramenta como o MediaInfo e depois passar cada valor como argumento do ffmpeg
    Alguém sabe se isso ainda é assim?

    • Já tentou -movflags e use_metadata_tags?
      ffmpeg -i $input_file -movflags use_metadata_tags -crf 22 $output_file
      Fonte: https://video.stackexchange.com/a/26076
    • Sim, parece que ainda é preciso extrair os metadados diretamente e inseri-los manualmente
      Explicando um pouco melhor, os dois padrões mais comuns de vídeo HDR são Dolby Vision e HDR10. Ambos exigem suporte separado dentro do codificador, e isso é mais uma questão do libx265 do que do libavformat/ffmpeg
      Felizmente, se o vídeo de origem for HDR10, dá para extrair a função de transferência e o tone mapping, que não mudam globalmente, e aplicá-los diretamente aos metadados de saída. O FFmpeg consegue passar esses valores para o codificador, mas por padrão não os copia da origem para o destino
      Um texto explicando o método está em https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...
      Já recodifiquei um vídeo codificado em HDR10 para outro formato mantendo os metadados, e o comando final que ficou no histórico do shell era mais ou menos ffmpeg -i Movie-with-HDR.mkv -c:v libx265 -map_metadata:s:0 0:s:0 -map_metadata:g:0 0 -x265-params crf=21:master-display=\"G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)\":max-cll=1000,240 Movie-output.mkv
      Aqui, as configurações master-display e max-cll eram a função de transferência de cor que eu precisei extrair do primeiro vídeo com outra ferramenta. Essas opções estão documentadas na documentação de parâmetros do libx265 em https://x265.readthedocs.io/en/master/cli.html
      Dolby Vision é mais complicado. Como os metadados são dinâmicos, não sei ao certo como obtê-los da origem, mas é possível fornecê-los ao libx265 por meio de argumentos de linha de comando. Infelizmente, isso só está exposto na linha de comando e não na API, então o ffmpeg ainda não consegue cuidar disso sozinho
      Como referência relacionada, o processo de extrair a função de transferência e passá-la ao ffmpeg está em https://medium.com/@yllanos/how-to-encode-a-4k-hdr-movie-usi... e https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f... , e um post em que várias pessoas reuniram informações sobre a mesma tarefa está em https://www.reddit.com/r/ffmpeg/comments/g3uucr/how_do_i_enc...
      Sobre conversão de Dolby Vision para HDR10 e questões envolvendo HLG e PQ, veja https://www.reddit.com/r/ffmpeg/comments/nkxbay/how_to_conve... , e as sutilezas do Dolby Vision estão em https://www.reddit.com/r/ffmpeg/comments/a32yv4/deleted_by_u...

  • O próprio release talvez tivesse sido um link melhor
    Ele contém o changelog que a maioria vai querer ver
    https://github.com/HandBrake/HandBrake/releases/tag/1.7.0