Existem várias maneiras de obter um AVI "não compactado" ffmpeg, mas suspeito que você realmente queira dizer "sem perdas". Ambos os termos têm bastante espaço de manobra em suas definições, como você verá.
Vou ancorar essa discussão com a versão 720p em HD do Big Buck Bunny , já que é um vídeo disponível gratuitamente, com o qual todos podemos testar e obter resultados que podemos comparar. A taxa de dados brutos do vídeo de 1280 × 720p a 24 qps é quase igual à meta estabelecida de 1024 × 768 a 29,97 qps, então meus resultados devem ser um bom guia para as taxas de dados que você pode esperar nas suas imagens.
Listagem automática de opções disponíveis
O seguinte comando POSIX¹ fornece uma lista que² corresponde principalmente ao que discutimos abaixo:
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
Você pode querer executar esse comando em sua própria máquina para ver o que sua compilação do FFmpeg suportará. O FFmpeg raramente é criado com todos os codificadores possíveis ativados.
Agora vamos discutir essas opções.
Totalmente descomprimido
Se a sua definição de "descomprimido" é a forma que o vídeo está em direito antes de ser virou-se para fótons por um display digital, o mais próximo que eu vejo na ffmpeg -codecslista são -c:v r210, r10k, v410, v308, ayuve v408. Estas são todas substancialmente a mesma coisa, diferindo apenas na intensidade da cor , o espaço de cor , e alfa canal de apoio.
R210 e R10K são 4: 4: 4 RGB a 10 bits por componente (bpc), portanto, ambos exigem cerca de 708 Mbit / s para 720p em meus testes. (Isso é cerca de ⅓ TB por hora, amigos!)
Esses codecs incluem os componentes de cores de 3 x 10 bits por pixel em um valor de 32 bits para facilitar a manipulação por computadores, como tamanhos de potência de 2. A única diferença entre esses codecs é em qual extremidade da palavra de 32 bits estão os dois bits não utilizados. Essa diferença trivial é sem dúvida porque eles vêm de empresas concorrentes, Blackmagic Design e AJA Video Systems , respectivamente.
Embora sejam codecs triviais, você provavelmente precisará fazer o download dos codecs Blackmagic e / ou AJA para reproduzir arquivos usando-os no seu computador. Ambas as empresas permitirá que você baixar seus codecs sem ter comprado o seu hardware primeiro, pois eles sabem que você pode estar lidando com arquivos produzidos por clientes que fazem tem algum do seu hardware.
V410 é essencialmente apenas a versão YUV do R210 / R10K; suas taxas de dados são idênticas. No entanto, esse codec pode codificar mais rapidamente, porque ffmpegé mais provável que haja um caminho de conversão acelerada do espaço de cores entre o espaço de cores dos quadros de entrada e esse espaço de cores.
Entretanto, não posso recomendar esse codec, pois não consegui reproduzir o arquivo resultante em qualquer software que tentei, mesmo com os codecs AJA e Blackmagic instalados.
O V308 é a variante de 8 bpc do V410, portanto chega a 518 Mbit / s nos meus testes. Assim como na V410, não consegui reproduzir esses arquivos no software normal do player de vídeo.
AYUV e V408 são essencialmente a mesma coisa que V308, exceto que incluem um canal alfa, se é necessário ou não! Se o seu vídeo não usar transparência, isso significa que você paga a penalidade de tamanho dos codecs R210 / R10K de 10 bpc acima, sem obter o benefício do espaço de cores mais profundo.
O AYUV tem uma virtude: é um codec "nativo" no Windows Media, portanto não requer software especial para ser reproduzido.
O V408 deveria ser nativo do QuickTime da mesma maneira, mas o arquivo V408 não seria reproduzido no QuickTime 7 ou 10 no meu Mac.
Então, reunindo tudo isso, se seus PNGs tiverem nome frame0001.pnge assim por diante:
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
Observe que eu especifiquei AVI no caso do AYUV, já que é praticamente um codec apenas para Windows. Os outros podem funcionar no QuickTime ou no AVI, dependendo de quais codecs estão na sua máquina. Se um formato de contêiner não funcionar, tente o outro.
Os comandos acima - e também os abaixo - assumem que os quadros de entrada já têm o mesmo tamanho que você deseja para o seu vídeo de saída. Caso contrário, adicione algo parecido -s 1280x720ao comando, antes do nome do arquivo de saída.
RGB compactado, mas também sem perdas
Se, como suspeito, você quer dizer "sem perdas" em vez de "não compactado", uma escolha muito melhor do que qualquer uma das opções acima é o Apple QuickTime Animation , via-c:v qtrle
Sei que você disse que queria um AVI, mas o fato é que você provavelmente precisará instalar um codec em uma máquina Windows para ler qualquer um dos formatos de arquivo baseados em AVI mencionados aqui, enquanto no QuickTime há uma chance do vídeo O aplicativo de sua escolha já sabe como abrir um arquivo de animação do QuickTime. (O codec AYUV acima é a única exceção que eu conheço, mas sua taxa de dados é muito alta, apenas para obter o benefício do AVI.)
ffmpegirá encher qtrleum contêiner AVI para você, mas o resultado pode não ser muito compatível. Nos meus testes, o QuickTime Player se queixa um pouco desse arquivo, mas ele é reproduzido. Estranhamente, porém, o VLC não o reproduz, embora seja baseado em parte ffmpeg. Eu me ateria aos contêineres QT desse codec.
O codec do QuickTime Animation usa um esquema RLE trivial ; portanto, para animações simples, ele deve funcionar tão bem quanto o Huffyuv abaixo. Quanto mais cores em cada quadro, mais se aproximará da taxa de bits das opções totalmente descompactadas acima. Nos meus testes com Big Buck Bunny, consegui ffmpegme fornecer um arquivo de 165 Mbit / s no modo RGB 4: 4: 4, via -pix_fmt rgb24.
Embora esse formato seja compactado, ele fornecerá valores de pixel de saída idênticos aos seus arquivos de entrada PNG, pelo mesmo motivo que a compactação sem perdas do PNG não afeta os valores de pixel.
A ffmpegimplementação do QuickTime Animation também suporta -pix_fmt argb, o que permite obter RGB 4: 4: 4: 4, o que significa que possui um canal alfa. De uma maneira bastante grosseira, é o equivalente do QuickTime -c:v ayuvmencionado acima. Devido à compressão sem perdas, porém, chega a apenas 214 Mbit / s , menos que ⅓ a taxa de dados do AYUV com perda zero de qualidade ou recursos.
Existem variantes do QuickTime Animation com menos de 24 bits por pixel, mas elas são melhor usadas para estilos de animação progressivamente mais simples. ffmpegparece suportar apenas um dos outros formatos definidos pela especificação -pix_fmt rgb555be, o que significa RGB big-endian de 15 bpp. É tolerável para alguns vídeos e é bom para a maioria das capturas de tela e animações simples. Se você pode aceitar a dizimação do espaço de cores, a taxa de dados de 122 Mbit / s pode ser atraente.
Juntando tudo isso:
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
Efetivamente sem perdas: o truque do YUV
Agora, o problema do RGB e do 4: 4: 4 YUV é que essas codificações são muito fáceis de processar pelos computadores, mas ignoram um fato sobre a visão humana, que é que nossos olhos são mais sensíveis às diferenças de preto e branco do que às diferenças de cores .
Portanto, os sistemas de armazenamento e entrega de vídeo quase sempre usam menos bits por pixel para informações de cores do que para informações de luminância. Isso é chamado de subamostragem de croma . Os esquemas mais comuns são 4: 2: 0 e 4: 2: 2.
A taxa de dados de 4: 2: 0 YUV é apenas 50% superior à do vídeo não compactado em preto e branco (somente Y) e ½ da taxa de dados de 4: 4: 4 RGB ou YUV.
4: 2: 2 é um tipo de ponto intermediário entre 4: 2: 0 e 4: 4: 4. É duas vezes a taxa de dados do vídeo somente em Y e ⅔ a taxa de dados de 4: 4: 4.
Às vezes, você também vê 4: 1: 1, como no antigo padrão da câmera DV . 4: 1: 1 tem a mesma taxa de dados não compactada que 4: 2: 0, mas as informações de cores são organizadas de maneira diferente.
O ponto de tudo isso é que, se você estiver iniciando com um arquivo H.264 4: 2: 0, recodificá-lo para RGB descompactado 4: 4: 4, não comprará absolutamente nada sobre YUV sem perdas 4: 2: 0 compactado. Isso é verdade mesmo se você souber que seu fluxo de trabalho é de 4: 4: 4 RGB, pois é uma conversão trivial; O hardware e o software de vídeo fazem essas conversões dinamicamente rotineiramente.
Você realmente só precisa de 4: 4: 4 quando está espiando os pixels ou está fazendo alterações de cor no nível de pixel no vídeo e precisa preservar os valores exatos dos pixels. O trabalho de efeitos visuais (VFX) é mais fácil de fazer com um formato de pixel 4: 4: 4, por exemplo, portanto, as casas VFX de alta qualidade geralmente estão dispostas a tolerar as taxas de dados mais altas necessárias.
Efetivamente sem perdas: opções de codec
Depois que você se abre para os codecs YUV com dizimação de cores, suas opções também se abrem. ffmpegpossui muitos codecs efetivamente sem perdas .
Huffyuv
A opção mais amplamente compatível é o Huffyuv . Você consegue isso via -c:v huffyuv.
O codec original do Windows Huffyuv suporta apenas dois formatos de pixel: RGB24 e YUV 4: 2: 2. (Na verdade, ele suporta dois tipos de YUV 4: 2: 2, diferindo apenas na ordem dos bytes no disco.)
As versões mais antigas do codec FFmpeg Huffyuv não incluíam suporte a RGB24; portanto, se você tentar e o FFmpeg diz que usará o yuv422pformato de pixel, é necessário atualizar.
O FFmpeg também possui um codec da variante Huffyuv chamado FFVHuff, que suporta YUV 4: 2: 0. Essa variante não é compatível com o codec do Windows DirectShow Huffyuv, mas deve ser aberta em qualquer software baseado em libavcodec, como o VLC.
RGB24 - RGB 4: 4: 4 é essencialmente a mesma coisa que a opção de espaço de cores RGB24 do QuickTime Animation. Os dois codecs diferem um pouco na compactação de um determinado arquivo, mas geralmente estarão próximos.
Também é essencialmente a mesma coisa que o modo YUV 4: 4: 4 usado pela opção V308 acima. A diferença do espaço de cores não faz diferença prática, pois é fácil fazer a conversão do espaço de cores em tempo real.
Devido à compactação sem perdas do Huffyuv, consegui um vídeo de teste para comprimir cerca de 251 Mbit / s no modo RGB24, com qualidade visual idêntica à que você obteria do V308 ou do AYUV. Se AVI é um absoluto must para você, instalar o codec Huffyuv é provavelmente menos doloroso do que pagar o custo da taxa de dados 3 × de AYUV.
YUV 4: 2: 2 - Esse modo é muito mais prático para o vídeo do que o RGB24, o que é sem dúvida o motivo pelo qual os ffmpegdesenvolvedores escolheram implementá-lo primeiro. Como seria de esperar da redução teórica discutida acima, meu arquivo de teste foi codificado para 173 Mbit / s . Isso é exatamente ⅔, se você levar em conta o fato de que a faixa de áudio permaneceu inalterada entre esses dois testes.
YUV 4: 2: 0 - Esta opção dizima as informações de cores mais do que 4: 2: 2, reduzindo a taxa de dados para 133 Mbit / s nos meus testes.
Juntando tudo isso:
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
Embora o ffvhuffcodec seja padronizado como 4: 2: 0 enquanto escrevo isso, e de fato suporte apenas o formato de pixel na versão de lançamento que estou usando, isso está mudando ; portanto, você deve incluir o sinalizador caso este padrão mude.
Ut Video
Uma opção mais recente, no mesmo espírito que Huffyuv e FFVHuff, é o Ut Video . Como o Huffyuv, existe um codec de vídeo do Windows, o que significa que qualquer programa do Windows que possa reproduzir um filme pode reproduzir vídeos usando esse codec com o codec instalado. Ao contrário do Huffyuv, também há um codec de vídeo para Mac, portanto você não está restrito ao software baseado no FFmpeg ou libavcodecpara ler esses arquivos nos Macs.
Esse codec é muito flexível em termos de espaços de cores, portanto, darei apenas alguns exemplos de espaços de cores comuns:
4: 4: 4 RGB via -f avi -c:v utvideo -pix_fmt rgb24fornece saída de 178 Mbit / s
4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444pdá 153 Mbit / seg saída
4: 2: 2 YUV via -f avi -c:v utvideo -pix_fmt yuv422pdá 123 Mbit / seg saída
4: 2: 0 YUV via -f avi -c:v utvideo -pix_fmt yuv420pfornece saída de 100 Mbit / s
Eu suspeito que o YUV 4: 4: 4 é melhor que o RGB 4: 4: 4 neste teste, apesar de esses dois serem tecnicamente equivalentes porque o vídeo de origem é YUV 4: 2: 0, portanto, organizar os dados no formato YUV permite uma melhor compactação sem perdas agrupando os canais U e V parcialmente redundantes no arquivo.
FFV1
Outra opção interessante nesse espaço é o FFV1codec do FFmpeg . Isso é usado principalmente como um codec de arquivamento, em vez de um codec de reprodução ou edição, mas como tanto software é baseado na libavcodecbiblioteca subjacente ao FFmpeg ou pode ser amarrado libavcodecatravés de ferramentas como ffdshowessa, pode ser útil para você de qualquer maneira.
Por padrão, ffmpegpreservará o espaço de cores dos arquivos de entrada ao usar um codec flexível como o FFV1, de modo que, se você alimentá-lo com um dos arquivos MP4 Big Buck Bunny oficiais, que usam YUV 4: 2: 0, é isso que você obtém a menos que você dê uma -pix_fmtbandeira para ffmpeg. Isso resulta em um arquivo de saída de 63 Mbit / s .
Se você forçar o FFV1 a usar um espaço de cores YUV 4: 4: 4 -pix_fmt yuv444p, o tamanho do arquivo será de apenas 86 Mbit / s , mas não nos comprará nada neste caso, pois estamos codificando um original 4: 2: 0 . No entanto, se você alimenta em um conjunto de PNGs em vez disso, como na pergunta original, o arquivo de saída é provável que use o bgraou bgr0espaço de cor, que são apenas rearranjos dos argbe rgb24cor espaços levantadas acima.
H.264 sem perdas
Outra alternativa interessante é o Lossless H.264 . Isso é praticamente uma coisa apenas de x264 no momento da redação deste documento, mas aqueles que usam FFmpeg no lado da codificação provavelmente estão usando outro software que também inclui libx264o lado da decodificação , como o VLC.
A maneira mais simples de obter esse arquivo é:
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
O -qp 0sinalizador é a chave: valores mais altos causam compactação com perdas. (Você também pode dar -crf 0para obter o mesmo efeito.)
Assim como o FFV1, ffmpegtentará adivinhar o melhor espaço de cores de saída, considerando o espaço de cores de entrada. Portanto, para comparação com os resultados acima, executei várias passagens de codificação no arquivo de origem Big Buck Bunny com diferentes espaços de cores:
yuv444p : É isso ffmpegque você escolhe quando você fornece um fluxo PNG RGB, como na pergunta original, e resulta em um arquivo de 44 Mbit / s com nosso arquivo de teste
yuv422p : Isso é semelhante ao espaço de cores padrão do Huffyuv, mas temos um arquivo de 34 Mbit / s nesse caso, uma grande economia!
yuv420p : Esse é o padrão para os MP4s oficiais do Big Buck Bunny com os quais estou testando e resulta em um arquivo de 29 Mbit / s .
Lembre-se de que você está negociando muita compatibilidade para obter tamanhos de arquivo tão pequenos. É por isso que eu nem tentei colocar isso em um contêiner AVI ou MOV. Está tão intimamente ligado ao x264 que você também pode usar seu tipo de contêiner padrão (MP4). Você também pode usar algo como Matroska para isso.
Você pode trocar parte dessa taxa de bits por um tempo de codificação mais rápido adicionando -preset ultrafast. Isso aumentou a taxa de bits do meu arquivo de teste para 44 Mbit / s no modo YUV 4: 2: 2, mas codificou muito mais rapidamente, conforme prometido. Os documentos afirmam que -preset veryslowtambém vale a pena, mas resultou em um tempo de codificação muito mais longo, economizando apenas um pouquinho de espaço; Eu não posso recomendar.
Outras
ffmpegtambém suporta o modo somente decodificação para Lagarith e o modo somente codificação para JPEG sem perda . Esses dois codecs são realmente um pouco semelhantes e devem fornecer arquivos um pouco menores que o Huffyuv com a mesma qualidade. Se os ffmpegdesenvolvedores adicionarem a codificação Lagarith, seria uma alternativa forte ao Huffyuv. Porém, não posso recomendar o JPEG sem perda, pois ele não possui amplo suporte à decodificação.
Perceptualmente sem perdas: Ou, você provavelmente pode se safar com alguma perda
Depois, existem os codecs que são perceptivamente sem perdas. A menos que você esteja espiando pixels, você quase certamente não pode dizer que eles oferecem resultados visuais diferentes dos dois grupos anteriores. Ao desistir da ideia de uma mudança absolutamente nula entre o sensor de captura de vídeo e o dispositivo de exibição, você obtém economias consideráveis:
Apple ProRes :-c:v proresou-c:v prores_ks- ProRes é um codec baseado em perfil, o que significa que existem várias variantes, cada uma com uma troca de qualidade versus espaço diferente:
O ProRes 4444 codifica nosso vídeo de teste usando apenas 114 Mbit / s , mas é de qualidade VFX . Atualmente, existem trêsprores*codecsdiferentesno FFmpeg, mas apenasprores_kssuporta o ProRes 4444, enquanto escrevo isso, através da-profile:v 4444opção.
Se você está se perguntando por que se incomodaria em usar o ProRes 4444 em vez do Lossless H.264, tudo se resume à compatibilidade, velocidade de decodificação, previsibilidade e canal alfa.
O ProRes 422 economiza ainda mais espaço, precisando de apenas 84 Mbit / s para obter um resultado que você pode ver no ProRes 4444 apenas pela visualização de pixels. A menos que você precise do canal alfa oferecido pelo ProRes 4444, provavelmente não há motivo para insistir no ProRes 4444.
O ProRes 422 é um concorrente mais próximo da opção Lossless H.264 acima, pois nenhum dos dois suporta um canal alfa. Você desejará tolerar a taxa de bits mais alta do ProRes se precisar de compatibilidade com aplicativos de vídeo profissionais da Apple, uma sobrecarga de CPU mais baixa para codificação e decodificação ou taxas de bits previsíveis. Este último é importante com codificadores de hardware, por exemplo. Por outro lado, se você conseguir lidar com os problemas de compatibilidade do Lossless H.264, terá a opção de usar o espaço de cores 4: 2: 0, o que não é uma opção de nenhum perfil ProRes.
Todos os três codificadores ProRes no FFmpeg suportam o perfil ProRes 422; portanto, a opção mais simples é usar -c:v prores, em vez de -c:v prores_ks -profile hq, ou depender do recurso de perfil automático prores_kspara fazer a coisa certa.
Existem perfis ProRes ainda mais parcimoniosos, mas são destinados a vídeos em SD ou como proxies para arquivos de resolução completa.
O principal problema do ProRes é que ele ainda não possui amplo suporte fora dos mundos Apple e Pro Video.
O DNxHD da Avid é um codec semelhante ao ProRes, mas não está vinculado ao mundo dos vídeos profissionais da Apple. A Avid oferece codecs para download gratuito para Windows e Macintosh, e o FFmpeg agora é compatível com ele-c:v dnxhd.
Como o DNxHD é um codec baseado em perfil como o ProRes, você escolhe o perfil no conjunto predefinido e informa ao codec qual tamanho de quadro, taxa de quadros e taxa de bits usar. Para o arquivo de teste Big Buck Bunny, o -b:v 60Mperfil é mais apropriado. Sem surpresa, o arquivo resultante é de cerca de 59 Mbit / s .
MJPEG de baixa perda :-vcodec mjpeg -qscale:v 1- Isso é muito mais comum que o JPEG sem perda. Na verdade, esse era um codec de edição de vídeo bastante comum, e ainda é frequentemente usado por coisas como câmeras de vídeo em rede. Toda essa história significa que é fácil encontrar um software que o suporte.
Espere uma grande variabilidade nas taxas de dados desse codec. Um teste que acabei de fazer aqui me deu 25 Mbit / s para vídeo em 720p. Essa compressão é alta o suficiente para me deixar nervoso com perdas, mas me pareceu muito bom. Com base apenas na taxa de dados, eu diria que provavelmente está no nível da qualidade de 12 Mbit / s MPEG-2 ou 6 Mbit / s H.264.
Juntando tudo isso:
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
O ponto principal desses métodos é que, a menos que você esteja fazendo algo muito exigente, "bom o suficiente" realmente é bom o suficiente.
Notas de rodapé e digressões
O comando deve funcionar como indicado no Linux, macOS, BSDs e Unix. Se você estiver no Windows, poderá obter uma linha de comando do POSIX via Cygwin ou WSL .
Há várias razões pelas quais a lista produzida por esse comando não corresponde perfeitamente ao conjunto de codecs que escolhi discutir acima:
O segundo grepdestina-se a filtrar codificadores inapropriados, como os bmpque não são codecs de "vídeo", apesar de serem marcados Vnesta lista. Embora tecnicamente você possa colocar muitos deles em um contêiner como AVI, MP4 ou MKV para obter um vídeo de arquivo único, esse arquivo provavelmente não poderá ser lido por qualquer coisa, exceto por um programa baseado em ffmpegou libavcodec.
Existem algumas exceções, como a que -f avi -c:v ljpegpode ser chamada de "MJPEG sem perdas", mas, como regra, não estamos interessados em colocar muitos arquivos de imagens estáticas em um contêiner A / V aqui para fazer um filme. Queremos codecs de vídeo amplamente reconhecidos aqui, não truques semânticos.
O comando falha atualmente para filtrar alguns codificadores inadequados, como GIF, porque eles não estão descritos na ffmpeg -codecssaída como bitmapou imageformatos de arquivo.
O GIF é um caso interessante: ele suporta vários quadros de imagem em um único arquivo GIF com informações de tempo para reprodução de movimento, mas por vários motivos, é totalmente inadequado para a nossa discussão aqui.
A algumas das opções que são mostrados são obsoletos ou nunca realmente tem muita tração, tais como flashsv, dirace snow, por isso, não vale a pena discuti-los acima.
Algumas das opções nessa lista destinam-se apenas ao uso em pipelines entre ffmpeginstâncias ou entre ffmpege outro programa, como rawvideoe wrapped_avframe, e, portanto, são inadequadas para nossos propósitos aqui.
Perto do final da discussão acima, amplio criteriosamente o escopo da pergunta para incluir algumas opções com perdas cuidadosamente escolhidas, para que elas não passem o primeiro grepfiltro no comando acima.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.