9 pontos por GN⁺ 2025-01-15 | 1 comentários | Compartilhar no WhatsApp
  • O trabalho com FFmpeg tende a ficar complexo com a combinação de opções, e o FFmpeg By Example é um site de documentação que ajuda a encontrar rapidamente os métodos de processamento de mídia necessários por meio de exemplos reais de comandos
  • Também oferece um repositório no GitHub, uma comunidade no Discord e uma página de contribuições para que os usuários possam enviar diretamente novas ideias de uso do FFmpeg
  • Como no exemplo do filtro testsrc, ele mostra em um único comando a fonte de entrada, a resolução, a taxa de quadros e o arquivo de saída, permitindo reproduzir a estrutura do comando exatamente como está
  • Os exemplos cobrem todo o conjunto de tarefas de processamento de mídia, incluindo cálculo de bitrate, redimensionamento de imagens, redução de ruído em áudio, efeitos de transição, mapeamento de streams, aceleração por hardware e tratamento de metadados
  • Cada exemplo é dividido por tags e páginas individuais, facilitando explorar os comandos do FFmpeg necessários com base em um filtro específico ou no objetivo da conversão

Site de documentação do FFmpeg centrado em exemplos

  • FFmpeg By Example é um site que organiza diferentes formas de usar o FFmpeg em exemplos individuais
  • Também fornece links para participação da comunidade e contribuições

Exemplo de geração de vídeo de teste com testsrc

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

Codificação, conversão e aceleração por hardware

Processamento de áudio

Imagens e animação

Filtros e efeitos visuais

Extração, análise e metadados

Fontes geradas e saída por pipe

1 comentários

 
GN⁺ 2025-01-15
Opiniões no Hacker News
  • A alegria de usar ffmpeg aumentou uns 1000%
    Antes eu ficava procurando respostas do Stack Overflow no Google e juntando tudo para montar comandos, mas agora o ChatGPT escreve os comandos por mim, o que ficou muito mais prático

    • Graças aos LLMs, uso ffmpeg várias vezes por semana
      É o melhor caso de uso da minha ferramenta llm cmd:

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • Por muito tempo eu coloquei o ffmpeg na mesma caixa das expressões regulares: aquela sensação de “eu realmente deveria aprender isso, mas acho que vou odiar muito”
      Aí o ChatGPT apareceu e resolveu os dois

    • Comigo é igual. Esse tipo de coisa a IA assumiu completamente, e eu sou só o intermediário que copia e cola os rastros de erro

    • Já surgiram muitas outras ferramentas, mas acabei de criar um script que simplifica bastante esses comandos encadeados: llmpeg https://github.com/jjcm/llmpeg
      Se o ffmpeg estiver instalado e a chave de API estiver configurada nas variáveis de ambiente da OpenAI, deve funcionar direto

      Demo: https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • Depois que aprendi como os filtros complexos funcionam, a experiência de usar ffmpeg ficou melhor

  • Lembrei que deveria organizar e publicar um método para transformar fitas de vídeo caseiras digitalizadas em clipes usando detecção de cenas
    Como alguém pode acabar procurando por isso, deixo aqui um gist que funcionou bem [0]. Mas ele às vezes era enganado por flashes de câmera ou tremidas, então eu precisava fornecer arquivos de início/fim separadamente e juntar tudo de novo com ffmpeg [1]

    O estranho é que, nas atualizações mais recentes do Mac, o desempenho ficou melhor sem -c:v h264_videotoolbox. Pode ser uma regressão de desempenho no Sequoia, não tenho certeza. A flag correspondente em uma máquina Windows com GPU Nvidia é -c:v h264_nvenc. Fico me perguntando por que o ffmpeg não detecta isso automaticamente. Com isso, tive uma melhora de desempenho de cerca de 8 vezes
    O único momento em que realmente fiz jus ao meu salário na empresa foi quando descobri que o ffmpeg instalado tinha sido compilado sem aceleração por GPU, bem quando estavam prestes a gastar mais em servidores de nuvem caros com GPU para processamento de vídeo

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • O problema das CPUs de nuvem é que elas não têm os codificadores de vídeo por hardware presentes nas CPUs de consumidor, então você precisa ir para máquinas com GPU, que são bem mais caras
      Para ser sincero, nunca fiz uma comparação de preços adequada usando aceleração por hardware na nuvem, então fico curioso se você de fato testou isso e quer dizer que valeu a pena pelo custo

    • Já usei ffmpeg para fazer detecção de cenas vazias
      Tenho uma câmera apontada para a rota de voo de SFO; removi todos os quadros sem movimento e fiquei apenas com um vídeo contínuo dos aviões passando, sem as partes entediantes

    • -c:v h264_nvenc é útil para codificação em lote, ao codificar vários vídeos de uma vez, porque permite aumentar a vazão de codificação
      Mas, nos testes limitados que fiz no passado, a qualidade de saída era um pouco pior que a do libx264. Não sei se há uma forma de contornar isso, mas não fui o único a passar por isso

    • O motivo de o ffmpeg não detectar isso automaticamente é que a codificação por hardware geralmente tem uma faixa de configuração mais estreita, envolve mais concessões do que codecs de software mais sofisticados e não produz exatamente o mesmo resultado mesmo com os mesmos parâmetros
      Além disso, muitas vezes há várias APIs de hardware disponíveis no sistema, e os recursos delas também diferem

      O FFmpeg é uma ferramenta de linha de comando complexa e voltada a usuários dispostos a aprender os detalhes, então não sei se faria sentido definir padrões com base em suposições

    • Olhando o snippet, parece que ele não faz desentrelaçamento
      Tudo bem se o clipe já tiver sido desentrelaçado antes da digitalização, mas, se não, você está estragando a qualidade ao codificar material entrelaçado como progressivo. Seria bom tentar adicionar o filtro bwdif para que conteúdo 30i seja codificado como 60p. Deve ficar mais parecido com a fita de vídeo original

  • Com o tempo, fiquei bem familiarizado com várias partes do ffmpeg. A CLI tem sua própria lógica e é dependente da ordem. Nem toda CLI Unix é assim
    Ultimamente tenho mexido em recursos um pouco mais obscuros. Por exemplo, salvar diretamente o vídeo bruto de uma câmera de vídeo em uma máquina bem lenta. Construí um microscópio e leio da câmera, a 120 FPS, quadros em formato de vídeo bruto (YUYV 1280x720); se eu simplesmente salvar isso no disco, cresce na casa dos gigabytes por minuto. Disco é barato, mas parece desperdício, então fui olhar técnicas quase sem perdas que conseguissem comprimir e salvar imagens precisas rapidamente

    Descobri que a conversão RGB24 no ffmpeg é muito lenta, então, depois de mexer bastante na linha de comando, cheguei a isto:

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

Vídeo bruto não tem contêiner, portanto não traz metadados como “formato de pixel” ou “tamanho da imagem”, então é preciso fornecê-los manualmente. Como a ordem importa, tudo antes de -i test.raw serve para decodificar a entrada, e tudo depois serve para escrever a saída. Faz apenas uma conversão de formato de pixel bem pequena (que o ffmpeg consegue processar muito rapidamente) e grava os dados em um formato quase sem perdas que tem contêiner. Na maioria dos casos, o melhor contêiner foi .mkv

Como não gosto de linha de comando, acabei usando ffmpeg-python e deixei o código abaixo montar a linha de comando:

self.process = (
ffmpeg.
input(
"pipe:",
format="rawvideo",
pix_fmt="yuyv422",
s="{}x{}".format(1280, 720),
threads=8
)
.output(
fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
)
.overwrite_output()
.global_args("-threads", "8")
.run_async(pipe_stdin=True)
)

E, na prática, faço write() dos frames na entrada padrão desse processo. Como a máquina tem 12 núcleos e sempre uso pelo menos 2 para acionar o microscópio, precisei limitar o número de threads

Ainda estou procurando uma codificação YUV sem perdas melhor e mais rápida

  • Faz sentido depender da ordem. Pipelines Unix também dependem da ordem dos componentes, e chamadas complexas ao FFMpeg fazem algo parecido
    Muita gente gosta da estética de uma “interface fluente” como a do ffmpeg-python, mas em Python isso muitas vezes é considerado pouco pythônico. Pelo que entendo, o ffmpeg-python foi projetado para refletir de perto a ordem da linha de comando

    A preferência reforçada pelo design da biblioteca padrão e dos tipos embutidos é uma forte https://en.wikipedia.org/wiki/Command%E2%80%93query_separati.... Seguindo esse princípio, ficaria mais ou menos assim:

    ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

    Fazer da entrada uma etapa de configuração separada criaria outro tipo em tempo de execução e também poderia sinalizar ao código de processamento que ele deve ler da entrada padrão

  • Não precisa procurar mais: FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

  • Quero recomendar uma palavra só: ramdisk
    Se você tem arquivos para processamento intermediário, mas não quer armazená-los, use ramdisk. É muito bom

  • Achei que seria um site que reunisse e mantivesse o conhecimento acumulado por usuários experientes de FFmpeg, mas fiquei decepcionado logo no primeiro exemplo em que cliquei
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    Não se deve chamar mais duas ferramentas só para fazer processamento de string. Só o FFprobe já consegue devolver diretamente a duração ou o valor que você quiser:

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    Não pare na primeira coisa que funciona; depois que funcionar, pense se há uma forma melhor de fazer

    • Sou o autor do post original. Acho meio exagerado chamar isso de “loucura”
      Ainda assim, gosto mais da solução que você apresentou
  • Bom. Isso me lembrou a cheatsheet de ffmpeg que eu uso. Imagino que todo mundo que usa ffmpeg com frequência tenha uma coleção parecida de anotações
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg é uma daquelas ferramentas que uso tão raramente que a sintaxe exata simplesmente nunca fica na cabeça. No fim, peço a LLMs a linha de comando de que preciso
    A única ferramenta igualmente difícil de que me lembro foi o MegaCLI da LSI Logic, com cara de anos 1990. Também era algo que eu quase nunca usava de um ano para o outro, mas precisava usar corretamente sob pressão

    • Uso FFMPEG há mais de 15 anos e ainda quase não lembro os comandos. Mesmo assim, LLMs são incríveis para usar FFMPEG
      Se eu disser ao ChatGPT e ao Claude “remuxe o vídeo para mkv, inclua subtitle.srt no arquivo e quero só de 0:00:05 a 0:01:00”, eles resolvem muito bem. Caso você esteja curioso, o resultado foi: ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      Fico curioso para saber quão pequeno poderia ser um LLM cujo único objetivo fosse gerar comandos ffmpeg. Talvez desse para ficar pequeno o bastante para colocar em uma página estática e rodar localmente?

    • Há 15 anos mantenho um documento pessoal de anotações com as sintaxes que uso com frequência. Quando nem isso resolve, dou grep no histórico do bash

    • Comigo é igual. O que fica na cabeça é só converter do formato X para .mp4. O resto eu preciso procurar de novo toda vez
      XKCD relacionado https://xkcd.com/1168/

    • Alguns dias atrás eu disse, meio brincando meio falando sério, que se um LLM simplesmente me dissesse quais flags do ffmpeg eu quero, talvez valesse a pena queimar todas as florestas tropicais

  • Não dá para esquecer que também existe o GStreamer. Como ele é baseado em pipelines, a linha de comando e a documentação são um pouco mais fáceis de entender do que as do ffmpeg, e as combinações também são um pouco mais sensatas
    Para trabalhos pesados com vídeo, abandonei completamente o ffmpeg e uso só o GStreamer

    • O GStreamer pode dar mais controle e uma API mais amigável quando você cria pipelines por programação
      Mas, para tarefas pontuais, o ffmpeg parece muito mais amigável. Por exemplo, o ffmpeg tem padrões razoáveis para x264, mas com gst-launch, para fazer uma codificação x264 de boa qualidade, você precisa realmente saber o que está fazendo
    • Eu achava que o FFmpeg também era baseado em pipelines. Ele não tem grafos de filtros? Estou deixando passar alguma coisa?
      Dá para compor grafos complexos de fontes, sinks e filtros de transformação
    • O GStreamer parece um projeto abandonado. Houve uma vulnerabilidade grande recentemente, e a documentação também está bastante quebrada
  • Há um repositório no GitHub de um livro sobre ffmpeg que pode ser um bom complemento para este site:
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • O ffmpeg sempre me pareceu uma aplicação GUI enfiada à força em formato TUI
    Também usei a API em C algumas vezes de forma desagradável; ela é intuitiva em vários aspectos, mas é fácil demais representar um estado inválido. Seria bom ter um framework de codificação AV1 em tempo real que “simplesmente funcione”

    • É basicamente a única ferramenta em que quase sempre procuro primeiro o HandBrake, que é uma alternativa com GUI. A exceção é quando faço processamento em lote
      Também existem algumas GUIs puras para ffmpeg. Há algo no trabalho com vídeo que não combina bem com a forma como minha cabeça processa a linha de comando

    • Como API, posso recomendar o GStreamer. Usei os bindings de Rust, então não sou muito familiarizado com a API em C, mas ela me pareceu boa
      Há partes que ficam verbosas por causa do GObject, mas, depois que você entende, consegue interagir de forma consistente com todos os objetos da API. Há muita complexidade necessária (vídeo é difícil), mas o design, a implementação e a documentação são muito bons

      Para casos de uso comuns, os Bins (decodebin, transcodebin, playbin) facilitam bastante. Mesmo casos de uso mais complexos são possíveis graças à flexibilidade do design

    • Gosto da percepção, mas TUI é algo gráfico, e ffmpeg é simplesmente CLI
      Seria legal se houvesse uma ferramenta TUI. Algo como https://github.com/Twinklebear/fbed, mas com recursos mais completos

  • Em sistemas Linux, gosto de fazer build estático do ffmpeg. Às vezes a versão da distribuição é velha demais ou não inclui os módulos que prefiro
    Esta versão conteinerizada foi muito útil: https://github.com/wader/static-ffmpeg