Novo codificador AAC do FFmpeg 9.1

 (hydrogenaudio.org)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O codificador AAC nativo do FFmpeg foi reescrito por completo, incluindo rate control, RDO e PNS·TNS·I/S·M/S, com o objetivo de atingir uma qualidade diretamente comparável à de codificadores AAC externos
  • A nova implementação se comporta de forma próxima a CBR estrito, e o modo VBR real baseado em -q:a não é recomendado
  • Nas comparações com Zimtohrli e ViSQOL, o novo codificador nmr mostrou resultados geralmente melhores que fdk-aac e Apple AAC na faixa de 64~256 kbps, mas o Opus continua superior em uma comparação separada
  • PNS·TNS·I/S·M/S são escolhidos dentro do loop de RDO; se houver previsão de downmix, recomenda-se usar -aac_is 0 -aac_pns 0 para preservar a fase
  • Em 128 kbps ou mais, houve muitas avaliações positivas, mas estéreo a 64 kbps, algumas amostras com TNS e conteúdo de voz continuam sendo áreas que exigem validação adicional

Reescrita completa do codificador AAC do FFmpeg

  • O codificador AAC do FFmpeg foi reescrito por completo, incluindo rate control, RDO, PNS, TNS, I/S e M/S
  • O PR da reescrita foi compartilhado como alvo de merge, e a incorporação efetiva foi confirmada depois na thread
  • Os testes são possíveis por build a partir do código-fonte ou após a atualização dos nightly builds da BtbN
  • O novo codificador pode ser usado com o codec aac
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • Desativar I/S: -aac_is 0
    • Desativar PNS: -aac_pns 0

Métricas de qualidade e alvos de comparação

  • Foram usados nas comparações o Zimtohrli, do Google, o ViSQOL e testes de audição
    • No Zimtohrli, quanto menor, melhor
    • No ViSQOL, quanto maior, melhor
  • Nas tabelas, o novo codificador apareceu como nmr e foi comparado com fast e twoloop do FFmpeg 8.1 anterior, fdk-aac, Apple AAC e libopus
  • Resultados representativos:
    • 64 kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128 kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256 kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • Em bitrates altos, o Zimtohrli fica saturado, então o ViSQOL foi usado como critério de desempate; por esse critério, o novo codificador ficou à frente nas comparações, exceto contra Opus

Design centrado em CBR e ferramentas de codificação

  • O novo codificador foi projetado de forma próxima a ser exclusivo para CBR, com variação de bitrate muito pequena
    • A meta de orçamento de bits ajuda na qualidade da codificação
    • O modo VBR real baseado em -q:a não é recomendado
  • Na comparação, outros codificadores quase não usavam ferramentas de codificação além de TNS; o novo codificador foi comparado primeiro apenas com TNS e depois reimplementou PNS, I/S e M/S
  • Segundo engenharia reversa, o qaac não faz otimização perceptual e usa uma curva de alocação de bits que favorece altas frequências, além da energia das bandas
    • O novo codificador usa uma curva semelhante com energia de banda mascarada no RDO
  • Todas as ferramentas de codificação — PNS, TNS, I/S e M/S — são escolhidas dentro do loop de RDO
    • Não usa heurísticas fixas nem cortes arbitrários por bitrate
    • As ferramentas disponíveis são aplicadas conforme o julgamento do RDO
  • Em bitrates altos, se o próprio codificador já funciona bem o bastante, ferramentas como I/S e PNS se desativam sozinhas para manter o bitrate

Compatibilidade do decodificador e cuidados com downmix

  • O decodificador AAC do FFmpeg tem um problema no tratamento de stereo PNS, e o mesmo bug pode existir em outros decodificadores AAC, então o codificador faz um contorno
    • Como os codificadores anteriores não usavam PNS, esse problema não havia aparecido até agora
  • Se houver downmix planejado ou possibilidade de a saída ser convertida para downmix, recomenda-se usar -aac_is 0 -aac_pns 0
    • O objetivo é preservar a fase do sinal original
  • Ver muitos buracos no espectrograma é um comportamento intencional
    • Bandas mascaradas são zeradas ou processadas com PNS
    • Se bandas vizinhas forem fortes o suficiente para dificultar a percepção da banda ausente, a escolha é codificar melhor as bandas audíveis em vez de codificar todas as bandas de forma pior

Taxa de amostragem e política de cutoff

  • O codificador foi otimizado principalmente para áudio a 48 kHz
    • 44,1 kHz e 96 kHz também funcionam
    • Para obter a melhor qualidade, recomenda-se usar 48 kHz
  • Os benchmarks publicados foram realizados principalmente em 44,1 kHz, enquanto os dados ajustados de ouvido estavam em 48 kHz
    • Parte da lógica de windowing/transient está vinculada a 48 kHz
    • Como a diferença de timing em 44,1 kHz não é grande, ela foi mantida assim
  • Depois, a política de largura de banda foi ajustada
    • 128 kbps é limitado a 16 kHz
    • 160 kbps ou mais é limitado a 18 kHz
    • Em 192 kbps por canal, foi alterado para codificar todo o espectro acima de 20 kHz
  • Em estéreo a 64 kbps, não há muito que se possa fazer, e aumentar mais o PNS pode prejudicar a imagem estéreo
    • Em 64 kbps, até 15 kHz pode ser alto demais, então foi solicitado retestar um cutoff de 12 kHz
    • Em mono, não é preciso contornar o bug do decodificador, permitindo usar muito mais PNS

Escopo de testes e estatísticas de debug

  • Os testes do lado do desenvolvimento foram feitos em uma coleção musical com 3.000 faixas
    • Conteúdo de voz foi testado muito pouco, então pode exigir otimização adicional
  • Ao encerrar, o codificador imprime estatísticas adicionais
    • Exemplo: Qavg: 207.975 Tr: 5.3% TNS(L): 4.8% TNS(S): 36.9% M/S: 3.9% I/S: 10.0% PNS: 5.1%
  • Significado das estatísticas:
    • Qavg: valor médio de lambda; quanto maior, mais difícil é manter o rate
    • Tr: short blocks
    • TNS(L): taxa de uso de TNS em long frames
    • TNS(S): taxa de uso de TNS em short frames
    • M/S: taxa de uso de Mid/Side coding
    • I/S: taxa de uso de intensity stereo coding
    • PNS: taxa de uso de perceptual noise substitution
  • Se encontrar artefatos incômodos, é possível analisá-los fornecendo a amostra de entrada original junto com essa linha de estatísticas

Testes iniciais de usuários e problemas restantes

  • Um usuário testou 64 kbps, 134 kbps e 200 kbps com uma faixa, Burn the Boats
    • 64 kbps é bom, mas tem alguns artefatos
    • 134 kbps e 200 kbps soam muito bem
  • Em outro teste, no sample The Tower a 64 kbps, houve feedback de que o novo codificador nmr parece mais smeary e metálico que o twoloop antigo
    • O twoloop antigo também tem problemas de collapse no início, ruído geral e aspereza
  • No sample fatboy_30sec, foi ouvido um ticking sound em 6,836 s e 10,480 s a 192 kbps; após reamostragem para 48 kHz, um tick adicional apareceu em 14,125 s
    • Desativar o TNS com -aac_tns 0 faz o ticking desaparecer
    • Em seguida, foi solicitado verificar elevando o valor de TNS_PG_C1_SHORT em libavcodec/aacenc_tns.c para 3.2, 4.2 e 5.0
  • Um usuário avaliou que, em 64 kbps e com cutoff de 16 kHz, o Fraunhofer AAC soava melhor, enquanto o novo codificador soava metálico
    • O mesmo usuário avaliou que, em bitrates altos acima de 128 kbps, o novo codificador funciona bem
    • Também houve a avaliação de que um codificador AAC amplamente acessível dentro do FFmpeg nativo ficou bom o suficiente para uso

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • É um exemplo de como o Opus é forte
    Esse tipo de trabalho em si também tem valor, e melhorar encoders para codecs antigos certamente é um ganho, mas, olhando os números do Opus nesse benchmark, mesmo a 64 kbps ele supera todos os encoders AAC

    • A maior vantagem de um bom encoder AAC não é a eficiência, e sim a compatibilidade
      Por quase 20 anos, o padrão de fato para vídeo em streaming ao vivo foi RTMP usando vídeo H.264 e áudio AAC, com quase nenhum suporte a outros codecs
      Se você vai enviar uma transmissão para o YouTube ou a Twitch, no fim das contas vai enviar H.264 e AAC; o OBS também, no modo de streaming, nem permite escolher outros codecs de vídeo e áudio, assumindo que o streamer usará H.264 e AAC
    • Até entrar no artigo, por um momento fiquei confuso achando que Opus se referia a um modelo, não a um encoder
    • A escolha de codec de áudio com perdas praticamente deixou de exigir reflexão
      Basta usar Opus e pronto; se por algum motivo não puder usar Opus, use AAC com um bitrate bem alto por compatibilidade
      Dá para obter boa qualidade sem pesquisar qual encoder e qual modo escolher
      Ainda assim, é ótimo ter um encoder AAC padrão de boa qualidade, mas não entendo muito bem por que o foco é principalmente em bitrate constante
    • [https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...](https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_bitrate+latency_comparison.svg)
    • Acho que o maior problema do Opus está na falta de especificação: https://nothings.org/stb/stb_opus.html
      Por causa disso, o Opus acaba sendo pouco usado em jogos ou distribuições por lojas em que possam surgir certos problemas de licenciamento

  • Estou ansioso para ver como será o desempenho real
    O encoder AAC antigo do FFmpeg tinha qualidade de saída ruim e frequentemente apresentava artefatos incômodos, como chilreios; para conseguir um som decente, era preciso instalar o encoder Apple Core Audio em cada computador usado para gravação de vídeo
    Em comparações A/B/X, MP3 a 320 kbps era melhor do que AAC a 320 kbps codificado pelo FFmpeg, e ficava parecido com AAC a 256 kbps codificado pelo Core Audio
    Se agora não for mais necessário instalar o Core Audio, isso é uma grande melhoria, e quem grava tela ou faz streaming com ferramentas como o OBS pode ter uma melhora significativa na qualidade de áudio na próxima atualização

    • Em relação ao Apple Core Audio, o qaac é útil
      Ele envolve as DLLs do iTunes para Windows e as transforma em uma ferramenta de codificação independente com CLI; pelo que sei, também funciona no Wine no Linux: https://web.archive.org/web/20250814194428/https://www.andre...
      Não é obrigatório ter um Mac nem instalar o iTunes inteiro para codificar AAC em alta qualidade
    • Eu usava o encoder FDK AAC e não sabia que o encoder da Apple podia ser usado em sistemas que não fossem da Apple
      Quando comparei FDK AAC e Apple AAC a 192 kbps no passado, não percebi diferença, mas o encoder AAC antigo do FFmpeg desmoronava nesse bitrate
    • Na tabela de métricas do tópico de discussão do Hydrogenaudio, o novo encoder recebe uma pontuação melhor que o Core Audio
      Mas isso é com bitrate constante
      O Core Audio também tem o TVBR, um modo de bitrate variável que o novo encoder não possui
      Então, nos casos em que é possível usar TVBR, o Core Audio talvez continue sendo o melhor, mas espero que, com mais pessoas encontrando amostras problemáticas e contribuindo para o ajuste fino, o novo encoder do FFmpeg também fique bom o suficiente
    • Se a qualidade importa, fico curioso por que não usar um codec sem perdas
      Ou então é só usar Opus; ele também vai bem para voz e hoje funciona praticamente em qualquer lugar
    • Não entendo por que a Apple insiste em codecs proprietários
      Se a Apple não tivesse adotado o H.265, talvez estivéssemos vivendo em uma utopia do AV1

  • Achei interessante a parte que diz: “O decodificador AAC do FFmpeg tem um bug no tratamento de PNS estéreo, e outros decodificadores AAC também podem ter, então o encoder contorna isso. Como outros encoders não usavam PNS, o problema não tinha sido descoberto até agora”
    Não sei o que é PNS, mas imagino que tenha atormentado o caso de uso muito específico de alguém por 20 anos

    • O problema tinha duas partes
      Uma era que, quando se usa TNS sobre PNS, o ruído inserido é moldado pelo TNS, mas quem cria o ruído é o decodificador, não o encoder, então isso não faz sentido
      Isso quebrava o PNS, e o problema maior era que, quando o PNS era usado junto com certas ferramentas estéreo, o ruído vazava de forma idêntica para os dois canais, prejudicando a imagem estéreo
      Por isso, o melhor é ativar PNS somente quando as bandas correspondentes dos dois canais forem inteiramente ruído, ou forem suficientemente não tonais e estiverem mascaradas
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Uma excelente atualização, com os detalhes bem organizados
    Opus é excelente e tem seu lugar, mas o AAC não vai desaparecer

  • Há um trecho que diz: “O codificador foi otimizado principalmente para áudio em 48 kHz. Aceite. Estamos em 2026, reamostragem é de graça e 48 kHz é o padrão. 44,1 kHz funciona e 96 kHz também funciona, mas, se quiser a melhor qualidade, use 48 kHz”; hoje em dia 48 kHz é mesmo o padrão?

    • Acho que o mais próximo de um “padrão” real é a AES5-2018, “prática recomendada para áudio digital profissional”
      O resumo recomenda uma frequência de amostragem de 48 kHz para a produção, o processamento e a troca de programas de áudio que usam PCM, e também reconhece 44,1 kHz para algumas aplicações digitais de consumo, 32 kHz para aplicações relacionadas a transmissão e 96 kHz para aplicações que exigem maior largura de banda ou filtros anti-aliasing mais suaves
      Pessoalmente, 44,1 kHz me parece um pequeno incômodo herdado do passado
    • O AAC tem uma característica estranha em que o tamanho da janela muda conforme a taxa de amostragem
      Por isso, janelas de 20 ms e 60 ms soam muito diferentes ao ouvido humano, então é preciso reotimizar completamente todos os parâmetros psicoacústicos do codificador para cada taxa de amostragem
      No Opus, obviamente esse problema foi resolvido
    • 48 kHz facilita muito o alinhamento entre vídeo e áudio
      Por exemplo, fica mais fácil sincronizar o movimento dos lábios depois da edição
    • Pelo que sei, o codec Opus assume que toda entrada é 48 kHz e reamostra a entrada para esse valor
    • Quase todos os DACs operam por padrão em 48 kHz, porque o sistema operacional escolhe isso como um valor padrão razoável

  • Um novo codificador AAC melhor no FFmpeg é bem-vindo, mas há duas ressalvas bem grandes nos detalhes
    Ele só dá suporte a bitrate constante e é otimizado apenas para amostragem em 48 kHz
    Não conseguir fazer codificação com bitrate variável baseada em qualidade é uma grande lacuna e, considerando que o áudio de CD no mundo todo é 44,1 kHz, isso também parece uma grande omissão

    • Não sei por que bitrate variável seria necessário em codificação de áudio
      Áudio com bitrate variável soa horrível e nem economiza tanto bitrate assim
    • Com -q:a, dá para usar bitrate variável “de verdade”, mas as métricas ficam alguns por cento mais baixas
      Ainda assim, acho que é difícil de perceber e continua vencendo
      Os benchmarks foram feitos principalmente em 44,1 kHz, e os dados ajustados de ouvido eram em 48 kHz, então parte da lógica de janelamento e transientes está vinculada a 48 kHz
      Mesmo assim, ela foi portada suficientemente bem para 44,1 kHz, e a diferença de timing não é grande, então foi deixada como está

  • É interessante que tanta coisa dependa do ouvido do próprio desenvolvedor
    Ao mesmo tempo, é meio preocupante e também bem legal, porque o julgamento de qualidade de áudio é tão subjetivo

    • Nas tabelas e comparações foram usados “o novo Zimtohrli do Google, ViSQOL e a minha audição”
    • Em áudio, normalmente é assim mesmo
      O Musepack também teve certa popularidade em um nicho por um tempo; era um codec simples, mas muito bem ajustado
      Com caixas de som e fones de ouvido é a mesma coisa: as pessoas acham que é qualidade dos componentes, mas, na prática, o que mais pesa é a compreensão geral da física do áudio e a capacidade de fazer um bom ajuste

  • Uma adição muito bem-vinda
    Agora espero que dê para substituir o fdk-aac

  • Alguém apareceu com aquele que pode ser o melhor codificador AAC de todos os tempos, e a primeira reação é um administrador discutir se é 48 kHz ou 44 kHz; isso é muito internet antiga mesmo

    • Não é algo para encarar com tanto cinismo
      Como o autor não testou na taxa de amostragem mais usada de fato, seria absurdo qualquer projeto sério substituir de uma vez pipelines em funcionamento há décadas
      É totalmente razoável esperar até que haja validação suficiente

  • Antigamente, quando eu codificava músicas para o iPod nano com ffmpeg, os arquivos ficavam corrompidos
    Durante a reprodução, surgiam pops e cliques entrecortados a cada poucos segundos; fico curioso para saber se isso foi corrigido agora