Por que a predefinição "muito rápida" no FFmpeg gera o arquivo mais compactado em comparação com todas as outras predefinições?

A compactação com perdas é uma compensação entre taxa de bits (tamanho do arquivo) e qualidade, não apenas para obter os arquivos menores. Se isso é tudo o que você queria, use-preset veryslow -crf 51(e opcionalmente reduza para 256x144) para obter um arquivo muito pequeno que é basicamente apenas bolhas desfocadas sem detalhes.

A codificação é uma compensação de 3 vias de tempo de CPU em relação à qualidade em relação à taxa de bits, muito diferente da compactação sem perdas, como ziponde o tamanho do arquivo é como você mede a "melhor" compactação e é o que você troca em relação ao tempo em uma compensação de 2 vias. ¹ ou 3 vias se a velocidade de compressão e descompressão forem independentes...

-preset veryslowoferece a melhor compensação que o x264 pode oferecer ² , gastando mais tempo de CPU procurando maneiras de representar mais detalhes por bit. (ou seja, melhor compensação de taxa por distorção ).

Isso é principalmente ortogonal ao controle de taxa, que decide quantos bits totais serão gastos. x264' o controle de taxa padrão é CRF 23 ( ffmpeg -crf 23); se quiser arquivos menores, use -preset veryslow -crf 26ou algo assim para gastar menos bits para a mesma complexidade, resultando em mais desfoque. É logarítmico, portanto, aumentar o CRF em alguns números pode alterar a taxa de bits por um fator de 2. Para uma qualidade quase transparente, -crf 18ou 20geralmente é bom, mas custa mais taxa de bits.

O modo CRF não é verdadeiro de qualidade constante (SSIM, PSNR ou qualquer outra métrica). Com predefinições de codificação mais rápidas, o x264 usa um processo de tomada de decisão mais simples para decidir como/onde gastar bits, resultando em alguma variação na taxa de bits para a mesma configuração de CRF.

Com diferentes ferramentas de pesquisa para encontrar redundância, como explica @szatmary, uma predefinição mais alta pode encontrar uma maneira muito menor de codificar algo que parece apenas um pouco pior. Ou uma maneira de codificar alguns blocos que parece muito melhor , mas é apenas um pouco maior. Dependendo de como essas coisas acontecem em média, o mesmo CRF em diferentes predefinições de qualidade terá qualidade e taxa de bits diferentes.

É por isso que você não obtém arquivos progressivamente menores com qualidade idêntica; -preset veryfastnormalmente parece pior. -preset ultrafastgeralmente é visivelmente ruim mesmo em alta taxa de bits, mas outras predefinições podem parecer tão boas quanto veryfastse você gastasse muito mais taxa de bits.

Arquivo menor não significa "melhor compactação". Lembre-se que a qualidade também é variável . Se você costumava ffmpeg -i in.mp4 -ssim 1 -tune ssim -preset veryslow out.mkvobter libx264 para calcular a métrica de qualidade visual do SSIM, descobrirá que veryslow tem melhor qualidade por taxa de bits do que veryfast. (Se você estiver comparando a qualidade, faça-o em taxa de bits fixa, ou seja, 2 passagens, não CRF. Consulte https://trac.ffmpeg.org/wiki/Encode/H.264 )

Lembre-se de que as otimizações psicovisuais que fazem as imagens parecerem melhores para os humanos (como -psy-rd=1.0:0.15) podem pontuar pior em algumas métricas de qualidade; portanto, para uso real, você não deseja -tune ssim. Psy-rd significa levar em consideração a percepção humana ao otimizar a relação entre taxa e distorção. AQ (quantização adaptativa) é outra otimização psy, mas que o SSIM é sofisticado o suficiente para reconhecer como benéfica, ao contrário da métrica de qualidade PSNR mais simples.

Os humanos tendem a perceber o ruído de alta frequência (espacial) como detalhe se for de pequena escala, mesmo que não seja o mesmo detalhe da imagem de origem. E nossos olhos gostam de detalhes em vez de borrar. por exemplo, artefatos de franja e toque de quantização = arredondar os coeficientes DCT pode realmente parecer melhor do que apenas borrar tudo, se forem menores. Coisas que parecem piores quando você pausa e aumenta o zoom podem enganar seus olhos agradavelmente quando você apenas assiste normalmente. (o h.264 possui um filtro de desbloqueio em loop, aplicado antes dos quadros serem exibidos e usados ​​como referências, portanto, evita mais facilmente o bloqueio do que os codecs anteriores, como DivX / h.263. Aumentar isso pode apenas desfocar tudo em baixa taxa de bits).

A ideia aqui é semelhante ao que o MP3 e outros codecs de áudio avançados fazem para o som, exceto que há mais espaço para otimização psicoacústica porque sons altos realmente impedem que os ouvidos ouçam coisas silenciosas em frequências próximas.

Se você estiver codificando uma vez para manter o resultado por muito tempo e/ou distribuí-lo pela Internet, use -preset veryslow. Ou pelo menos -preset medium . Você paga o custo da CPU uma vez e colhe a economia no tamanho do arquivo (para uma determinada qualidade) repetidamente.

Mas se você for assistir a uma codificação apenas uma vez, por exemplo, para colocar um vídeo em um dispositivo móvel onde você o assistirá uma vez e depois o excluirá, -preset faster -crf 20faz sentido se você tiver espaço de armazenamento. Basta gastar bits extras.

Nota de rodapé 1 : Na compactação sem perdas, você troca o tamanho do arquivo pela velocidade de compactação e/ou descompactação (que pode ser diferente; alguns codecs são muito rápidos para descompactar, mesmo que permitam uma boa compactação lenta). Na verdade, o uso de RAM / pegada de cache também pode ser uma variável se você quiser entrar nesse nível de detalhe. Na compactação sem perdas, a qualidade é fixada em "perfeita", como x264-qp 0

O desempenho de decodificação h.264 pode variar um pouco com o número de quadros de referência, mais tendo uma pegada de memória maior e, portanto, talvez mais faltas de cache para um decodificador de CPU. Mas muitas vezes o h.264 é decodificado pelo hardware. Assim como em muitos esquemas de compactação sem perdas, grandes mudanças no desempenho de decodificação só ocorrem com codecs totalmente diferentes (como h.265), não com opções diferentes para o mesmo codec. O tempo extra de codificação é gasto procurando maneiras diferentes de codificar os mesmos bits, mas há apenas uma maneira de decodificar.

E sim, h.264 tem um modo sem perdas, como parte do perfil Hi444PP . Não, você não deseja usá-lo pela Internet; muitos decodificadores além do FFmpeg não têm suporte para esse recurso especial e a taxa de bits é enorme, como 100 a 200 Mbit/s para 1080p30 YUV 4:2:0 ou RGB 4:4:4. Como criar um AVI descompactado a partir de uma série de 1000 imagens PNG usando FFMPEG tem alguns resultados de teste do trailer Sintel.

Nota de rodapé 2: Outros codecs como h.265 (com o codificador x265) ou VP9 podem oferecer compensações de distorção de taxa ainda melhores, mas ao custo de muito mais tempo de CPU para codificar. Por um tempo de codificação fixo, não tenho certeza se há alguma vantagem em x265 sobre x264. Mas a compatibilidade do decodificador com h.265 é muito menos difundida do que h.264.

A compatibilidade de decodificação é muito boa para o perfil principal h.264 e, com sorte, também para o perfil alto atualmente. (8x8 DCT é mais útil para altas resoluções como 1080p e especialmente 4k.) O padrão de x264 é alto perfil. Alguns dispositivos móveis obsoletos podem ter apenas decodificação de hardware para o perfil de linha de base h.264, mas isso é uma qualidade significativamente pior por taxa de bits (sem quadros B e sem CABAC, apenas o CAVLC menos eficiente para a etapa final de codificação sem perdas de estruturas em um fluxo de bits. )

As predefinições não controlam a velocidade da codificação. Eles ativam ou desativam os recursos de compactação (geralmente chamados de "ferramentas"). Ao usar uma predefinição mais lenta, mais ferramentas são habilitadas. Mas como cada vídeo é diferente, é impossível obter o equilíbrio perfeito para cada vídeo todas as vezes.

No caso do seu conteúdo específico, uma dessas ferramentas está consumindo mais CPU e mais bits, mas gerará vídeo de maior qualidade enquanto ainda se ajusta ao envelope da taxa de bits.