Com -crf , você não consegue atingir o mesmo tamanho. CRF significa "Fator de Taxa Constante" - é um valor sem unidade (ou seja, sem%, sem kb / s, ...) entre 0 (sem perda) e 51 (pior qualidade) (valor padrão para x264: 23). O objetivo do CRF é alcançar uma certa qualidade visual sem precisar definir taxas de bits. O Guia H.264 do FFmpeg afirma:
[...] a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same [...] as the input but it isn't technically lossless. The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate.
(Observe que diferentes codificadores podem ter diferentes faixas de valores de CRF: por exemplo, CRF padrão do x265 -value é 28 , que deve ser visualmente igual a 23 de x264.
É claro que você pode mexer com -crf até obter o tamanho de arquivo desejado, mas isso geralmente significa muito teste & erro.
Agora pode-se perguntar "mas se a qualidade for a mesma e x264 for um bom codificador, então por que o CRF não tornará o arquivo menor? "
A resposta para essa pergunta é fácil: o x264 (como praticamente todos os outros codificadores do mercado) não tem como detectar a eficiência do arquivo de entrada codificado. Pode saber que tem um ABR (Average Bit Rate) de 2 Mb / s, mas isso não diz nada sobre a qualidade. E se o seu arquivo de entrada foi codificado de forma insatisfatória (baixa taxa de bits e / ou configurações de codificador muito rápidas), então ele pode ter artefatos (blocos, ...). Você pode vê-los, mas o x264 não pode (realmente) fazê-lo [1] - portanto, ao declarar -crf , ele supõe que você deseja conservar todos os artefatos em seu novo arquivo na extensão seu valor (0-51) é capaz, o que leva a taxas de bits mais altas porque os artefatos (como o ruído) não são fáceis de prever.
[1] Imagine que é como ver uma parede de tijolos - enquanto você pode reconhecê-la assim por causa da cor vermelha dos tijolos em forma de quadrado e do argamassa cinza entre eles, tudo o que o codificador vê são vermelho e cinza pixels.
Assim, a maneira de obter um determinado tamanho de arquivo é via ABR , que é o -b:v -parameter no libx264 do FFmpeg. A ABR trabalha com taxas de bits variáveis (VBR), mas tenta alcançar uma taxa de bits média conforme especificado em todo o arquivo. Para fazer com que esse princípio funcione bem, deve-se usar dois passos para que o FFmpeg possa primeiro olhar para o arquivo, calcular as taxas de bits e depois codificá-lo em uma segunda etapa.
Se o seu objetivo é ter um arquivo resultante com o mesmo tamanho do arquivo de entrada, você pode Calcule sua taxa de bits dessa maneira :
(<FILESIZE_INPUT-FILE> [MiB] * 8192) / <DURATION_INPUT-FILE> [seconds] = ~XYZ [kBit/s total bitrate]
XYZ [kBit/s total bitrate] - <DESIRED_AUDIO_BITRATE> [kBit/s] = ___ [kBit/s video bitrate]
Anotações em [brackets] , valores para você preencher em <ANGLE_BRACKETS> e seu resultado como ___ linha de sublinhados.
Com a sintaxe resultante:
ffmpeg -y -i <INPUT-FILE-PATH> -c:v libx264 -b:v ___k -preset slower <OTHER_COMMANDS_LIKE_AUDIO> -pass 1 -f <OUTPUT-FILE-FORMAT> /dev/null && \
ffmpeg -y -i <INPUT-FILE-PATH> -c:v libx264 -b:v ___k -preset slower <OTHER_COMMANDS_LIKE_AUDIO> -pass 2 <OUTPUT-FILE-PATH>
Em x264, o CRF e o ABR são mutuamente exclusivos - você pode usar um ou outro, portanto, sua escolha com x264 sempre terá qualidade garantida x tamanho de arquivo garantido. Tanto quanto eu sei, outros codificadores ( como x265 ) pode usar uma combinação de ABR e CRF, para que você possa especificar uma taxa de bits e uma faixa de qualidade que o codificador tente alcançar. Mas você sempre pode ter apenas uma prioridade mais alta: qualidade visual ou tamanho do arquivo de destino (ou velocidade de codificação). Com muita experiência, pode-se atingir "o equilíbrio perfeito" para qualquer trabalho, mas ainda assim seria um compromisso.
Um último comentário sobre os parâmetros no ffmpeg:
Se você não precisa de parâmetros ( e há muitas ocasiões em que alguém precisaria deles ), não os especifique. -loglevel info é o padrão, então por que você especificou? O melhor que pode fazer é quebrar seu código se você tiver um erro de digitação (o mesmo vale para -trellis ). Além disso, libx264 faz um bom trabalho ao especificar GOPs, portanto, -g pode não ser necessário, a menos que você precise de um mecanismo específico de reprodução / ... (o mesmo vale para -cmp e -csubcmp ). p>
Os desenvolvedores de codificadores geralmente tentam facilitar o uso de seus produtos e, portanto, valores padrão na maioria das vezes são muito melhores do que digitar cegamente em parâmetros aleatórios que alguém na internet encontrou há 10 anos na primeira documentação disponível. .
Apesar de, claro, se você fez sua pesquisa e você tem a experiência (ou simplesmente quer experimentá-la), não há como eu impedir que você vá para o limite de caracteres do console de comando com ffmpeg!