Le nouvel encodeur AAC de FFmpeg 9.1

 (hydrogenaudio.org)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • L’encodeur AAC natif de FFmpeg a été entièrement réécrit, du rate control au RDO en passant par PNS, TNS, I/S et M/S, avec pour objectif une qualité directement comparable aux encodeurs AAC externes
  • La nouvelle implémentation se comporte presque comme un CBR strict, et le vrai mode VBR basé sur -q:a n’est pas recommandé
  • Dans les comparaisons Zimtohrli et ViSQOL, le nouvel encodeur nmr a généralement obtenu de meilleurs résultats que fdk-aac et Apple AAC entre 64 et 256 kbps, mais Opus reste supérieur dans une comparaison séparée
  • PNS, TNS, I/S et M/S sont choisis dans la boucle RDO ; si un downmix est prévu, il est recommandé d’utiliser -aac_is 0 -aac_pns 0 afin de préserver la phase
  • Au-dessus de 128 kbps, les évaluations sont souvent positives, mais le stéréo à 64 kbps, certains échantillons TNS et les contenus vocaux restent des zones qui nécessitent des validations supplémentaires

Réécriture complète de l’encodeur AAC de FFmpeg

  • L’encodeur AAC de FFmpeg a été entièrement réécrit, notamment le rate control, le RDO, PNS, TNS, I/S et M/S
  • La PR de réécriture a été partagée comme candidate à la fusion, puis sa fusion effective a été confirmée plus tard dans le fil
  • Les tests sont possibles via une compilation depuis les sources ou après mise à jour des nightly builds BtbN
  • Le nouvel encodeur peut être utilisé avec le codec aac
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • Désactiver I/S : -aac_is 0
    • Désactiver PNS : -aac_pns 0

Indicateurs de qualité et éléments de comparaison

  • Les comparaisons utilisent Zimtohrli de Google, ViSQOL et des tests d’écoute
    • Pour Zimtohrli, plus le score est bas, mieux c’est
    • Pour ViSQOL, plus le score est élevé, mieux c’est
  • Dans le tableau, le nouvel encodeur est indiqué comme nmr, et il est comparé aux anciens fast et twoloop de FFmpeg 8.1, à fdk-aac, Apple AAC et libopus
  • Résultats représentatifs :
    • 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
  • Aux bitrates élevés, Zimtohrli sature ; ViSQOL a donc servi de critère de départage, et selon ce critère le nouvel encodeur devance les autres, à l’exception d’Opus

Conception centrée sur le CBR et outils de codage

  • Le nouvel encodeur est conçu comme quasiment dédié au CBR, avec des variations de bitrate très faibles
    • L’objectif de budget de bits contribue à la qualité du codage
    • Le vrai mode VBR basé sur -q:a n’est pas recommandé
  • Les autres encodeurs ont été comparés comme n’utilisant pratiquement pas d’outils de codage en dehors de TNS ; le nouvel encodeur a d’abord été comparé avec TNS seul, avant de réimplémenter PNS, I/S et M/S
  • D’après les résultats de rétro-ingénierie, qaac n’effectue pas d’optimisation perceptuelle et utilise une courbe d’allocation de bits privilégiant les hautes fréquences ainsi que l’énergie des bandes
    • Le nouvel encodeur utilise une courbe similaire avec la masked band energy dans le RDO
  • Tous les outils de codage, PNS, TNS, I/S et M/S, sont choisis dans la boucle RDO
    • Il n’utilise pas d’heuristiques fixes ni de seuils arbitraires de bitrate
    • Les outils disponibles sont appliqués selon la décision du RDO
  • Aux bitrates élevés, si l’encodeur fonctionne suffisamment bien par lui-même, les outils comme I/S et PNS se désactivent d’eux-mêmes afin de maintenir le bitrate

Compatibilité des décodeurs et précautions pour le downmix

  • Le décodeur AAC de FFmpeg a un problème dans le traitement du stereo PNS, et le même bug pourrait exister dans d’autres décodeurs AAC ; l’encodeur le contourne donc
    • Comme les anciens encodeurs n’utilisaient pas PNS, ce problème n’avait pas été mis en évidence jusqu’ici
  • Si un downmix est prévu ou si la sortie risque d’être downmixée, il est recommandé d’utiliser -aac_is 0 -aac_pns 0
    • Le but est de préserver la phase du signal d’origine
  • La présence de nombreux trous dans le spectrogramme est un comportement intentionnel
    • Les bandes masquées sont mises à zéro ou traitées avec PNS
    • Si les bandes voisines sont suffisamment fortes pour que les bandes manquantes soient difficiles à percevoir, l’encodeur préfère mieux coder les bandes audibles plutôt que de mal coder toutes les bandes

Sample rate et politique de cutoff

  • L’encodeur est principalement optimisé pour l’audio 48 kHz
    • 44,1 kHz et 96 kHz fonctionnent aussi
    • Pour obtenir la meilleure qualité, l’usage de 48 kHz est recommandé
  • Les benchmarks publiés ont été principalement réalisés à 44,1 kHz, tandis que les données réglées à l’oreille étaient en 48 kHz
    • Une partie de la logique de windowing/transient est liée au 48 kHz
    • Elle est conservée telle quelle en 44,1 kHz, car l’écart de timing n’est pas important
  • La politique de bande passante a ensuite été ajustée
    • 128 kbps est limité à 16 kHz
    • 160 kbps et plus sont limités à 18 kHz
    • À 192 kbps par canal, l’encodeur a été modifié pour coder tout le spectre au-delà de 20 kHz
  • En stéréo à 64 kbps, les marges de manœuvre sont limitées, et augmenter davantage PNS peut dégrader l’image stéréo
    • À 64 kbps, même 15 kHz peut être trop élevé ; un nouveau test avec un cutoff à 12 kHz a été demandé
    • En mono, il n’est pas nécessaire de contourner le bug du décodeur, ce qui permet d’utiliser beaucoup plus PNS

Périmètre de test et statistiques de debug

  • Les tests côté développement ont été effectués sur une collection musicale de 3 000 morceaux
    • Les contenus vocaux ont été très peu testés et pourraient nécessiter une optimisation supplémentaire
  • À la fin de l’encodage, l’encodeur affiche des statistiques supplémentaires
    • Exemple : 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%
  • Signification des statistiques :
    • Qavg : valeur lambda moyenne ; plus elle est élevée, plus il est difficile de tenir le rate
    • Tr : short blocks
    • TNS(L) : taux d’utilisation de TNS sur les long frames
    • TNS(S) : taux d’utilisation de TNS sur les short frames
    • M/S : taux d’utilisation du codage Mid/Side
    • I/S : taux d’utilisation du codage intensity stereo
    • PNS : taux d’utilisation de la perceptual noise substitution
  • Si vous découvrez des artefacts gênants, il est possible de fournir l’échantillon d’entrée original avec cette ligne de statistiques afin de permettre l’analyse

Premiers tests utilisateurs et problèmes restants

  • Un utilisateur a testé un morceau, Burn the Boats, à 64 kbps, 134 kbps et 200 kbps
    • À 64 kbps, le résultat est bon, mais avec quelques artefacts
    • À 134 kbps et 200 kbps, le rendu est jugé très bon
  • Dans un autre test, sur l’échantillon The Tower à 64 kbps, un retour indique que le nouvel encodeur nmr paraît plus smeary et metallic que l’ancien twoloop
    • L’ancien twoloop présente aussi des problèmes de collapse au début, ainsi qu’un noise et une roughness généraux
  • Sur l’échantillon fatboy_30sec, des ticking sounds ont été entendus à 6,836 s et 10,480 s en 192 kbps, puis un tick supplémentaire à 14,125 s après rééchantillonnage en 48 kHz
    • Désactiver TNS avec -aac_tns 0 fait disparaître le ticking
    • Il a ensuite été demandé de tester en augmentant la valeur TNS_PG_C1_SHORT dans libavcodec/aacenc_tns.c à 3.2, 4.2 et 5.0
  • Un utilisateur a estimé qu’à 64 kbps avec un cutoff à 16 kHz, Fraunhofer AAC sonnait mieux, tandis que le nouvel encodeur avait un rendu metallic
    • Le même utilisateur juge que le nouvel encodeur fonctionne bien aux bitrates élevés, au-delà de 128 kbps
    • Il estime aussi qu’un encodeur AAC largement accessible dans FFmpeg natif est désormais suffisamment utilisable

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Hacker News

  • Un exemple qui montre à quel point Opus est solide
    Ce travail a de la valeur en soi, et c’est clairement bénéfique que les encodeurs pour d’anciens codecs s’améliorent, mais quand on regarde les chiffres d’Opus dans ce benchmark, il écrase tous les encodeurs AAC même à 64 kbps

    • Le principal avantage d’un bon encodeur AAC n’est pas l’efficacité, mais la compatibilité
      Pendant près de 20 ans, le standard de fait pour la vidéo en streaming en direct a été RTMP avec de la vidéo H.264 et de l’audio AAC, avec très peu de prise en charge d’autres codecs
      Si l’on veut envoyer un flux vers YouTube ou Twitch, on finit par envoyer du H.264 et de l’AAC, et OBS, en mode streaming, ne permet même pas de choisir d’autres codecs vidéo ou audio, partant du principe que les streamers utiliseront H.264 et AAC
    • Avant d’entrer dans l’article, j’ai brièvement cru qu’Opus désignait un modèle et non un encodeur
    • Le choix d’un codec audio avec perte ne demande désormais presque plus de réflexion
      Il suffit d’utiliser Opus, point ; et si, pour une raison quelconque, on ne peut pas utiliser Opus, on prend de l’AAC à très haut débit pour la compatibilité
      On peut obtenir une bonne qualité sans devoir chercher quel encodeur et quel mode choisir
      Cela dit, c’est excellent d’avoir un encodeur AAC par défaut de bonne qualité, mais je ne comprends pas bien pourquoi c’est surtout en débit constant
    • [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)
    • À mon avis, le plus gros problème d’Opus est le manque de spécifications : https://nothings.org/stb/stb_opus.html
      À cause de cela, Opus est très peu utilisé dans les jeux ou les distributions via des stores où certains problèmes de licence pourraient apparaître

  • J’ai hâte de voir ses performances réelles
    L’encodeur AAC existant de FFmpeg produisait une qualité médiocre, avec souvent des artefacts gênants de type gazouillis, si bien qu’il fallait installer l’encodeur Apple Core Audio sur chaque machine dédiée à l’enregistrement vidéo pour obtenir un son correct
    En comparaison A/B/X, du MP3 320 kbps était meilleur que de l’AAC 320 kbps encodé avec FFmpeg, et comparable à de l’AAC 256 kbps encodé avec Core Audio
    Si l’installation de Core Audio n’est plus nécessaire, c’est une grosse amélioration, et les personnes qui enregistrent leur écran ou streament avec des outils comme OBS pourraient voir la qualité audio nettement s’améliorer à la prochaine mise à jour

    • À propos d’Apple Core Audio, qaac est utile
      Il encapsule les DLL Windows d’iTunes pour en faire un outil d’encodage autonome avec CLI, et il me semble qu’il fonctionne aussi sous Wine sur Linux : https://web.archive.org/web/20250814194428/https://www.andre...
      Pour encoder de l’AAC de haute qualité, il n’est pas forcément nécessaire d’avoir un Mac ni d’installer iTunes en entier
    • J’utilisais l’encodeur FDK AAC, et je ne savais pas que l’encodeur Apple pouvait aussi être utilisé sur des systèmes non Apple
      Quand j’avais comparé FDK AAC et Apple AAC à 192 kbps, je n’avais pas perçu de différence, mais l’ancien encodeur AAC de FFmpeg s’effondrait à ce débit
    • Dans le tableau de métriques du fil de discussion Hydrogenaudio, le nouvel encodeur obtient un meilleur score que Core Audio
      Cela dit, c’est sur la base d’un débit constant
      Core Audio dispose aussi de TVBR, un mode à débit variable que le nouvel encodeur n’a pas
      Donc, lorsque TVBR est utilisable, Core Audio pourrait rester le meilleur, mais j’espère que, si davantage de personnes trouvent des échantillons problématiques et contribuent au réglage, le nouvel encodeur FFmpeg deviendra largement satisfaisant
    • Si la qualité est importante, je me demande pourquoi ne pas utiliser un codec sans perte
      Sinon, on peut utiliser Opus ; il convient aussi à la voix et fonctionne aujourd’hui presque partout
    • Je ne comprends pas pourquoi Apple s’accroche aux codecs propriétaires
      Si Apple n’avait pas adopté H.265, nous vivrions peut-être dans une utopie AV1

  • Le passage disant que « le décodeur AAC de FFmpeg a un bug dans le traitement PNS stéréo, qui pourrait aussi exister dans d’autres décodeurs AAC, donc l’encodeur le contourne. Les autres encodeurs n’utilisaient pas PNS, c’est pourquoi il n’avait pas été découvert jusqu’ici » est intéressant
    Je ne sais pas ce qu’est PNS, mais cela a probablement empoisonné pendant 20 ans le cas d’usage très particulier de quelqu’un

    • Il y avait deux problèmes
      Le premier, c’est que si l’on utilise TNS par-dessus PNS, le bruit inséré est modelé par TNS, ce qui n’a pas de sens puisque ce n’est pas l’encodeur mais le décodeur qui crée le bruit
      À cause de cela, PNS était cassé ; et le problème plus important était que, lorsque PNS est utilisé avec certains outils stéréo, le bruit fuit de manière identique dans les deux canaux et détériore l’image stéréo
      Le mieux est donc de n’activer PNS que lorsque les bandes concernées des deux canaux sont toutes deux du bruit, ou suffisamment non tonales et masquées
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Une excellente mise à jour, avec des détails bien présentés
    Opus est excellent et a sa place, mais AAC ne va pas disparaître

  • Il y a ce passage : « L’encodeur est principalement optimisé pour de l’audio à 48 kHz. Faites avec. Nous sommes en 2026, le rééchantillonnage ne coûte rien et le 48 kHz est la norme. Le 44,1 kHz fonctionne, le 96 kHz aussi, mais si vous voulez la meilleure qualité, utilisez du 48 kHz » ; de nos jours, le 48 kHz est-il vraiment la norme ?

    • Ce qui se rapproche le plus d’une vraie « norme », c’est à mon avis AES5-2018, « Pratique recommandée pour l’audio numérique professionnel »
      Dans le résumé, il est recommandé d’utiliser une fréquence d’échantillonnage de 48 kHz pour la production, le traitement et l’échange de programmes audio en PCM, tout en reconnaissant aussi le 44,1 kHz pour certaines applications numériques grand public, le 32 kHz pour des applications liées à la transmission, et le 96 kHz pour les applications nécessitant une bande passante plus élevée ou des filtres anti-repliement moins contraignants
      Personnellement, le 44,1 kHz me donne l’impression d’être un petit héritage pénible
    • L’AAC a cette caractéristique étrange : la taille de fenêtre varie selon la fréquence d’échantillonnage
      Du coup, comme des fenêtres de 20 ms et de 60 ms sonnent très différemment à l’oreille humaine, il faut réoptimiser entièrement tous les paramètres psychoacoustiques de l’encodeur pour chaque fréquence d’échantillonnage
      Dans Opus, ce problème a évidemment été résolu
    • Le 48 kHz facilite beaucoup l’alignement entre la vidéo et la voix
      Par exemple, la synchronisation labiale après montage devient plus simple
    • À ma connaissance, le codec Opus suppose que toutes les entrées sont en 48 kHz et les rééchantillonne vers cette fréquence
    • Presque tous les DAC fonctionnent par défaut en 48 kHz, parce que le système d’exploitation choisit cette valeur comme réglage raisonnable par défaut

  • Un nouvel encodeur AAC FFmpeg de meilleure qualité est une bonne nouvelle, mais il y a deux réserves assez importantes dans les détails
    Il ne prend en charge que le débit constant et il est optimisé uniquement pour l’échantillonnage à 48 kHz
    Ne pas pouvoir faire d’encodage à débit variable basé sur la qualité est un gros manque, et vu que l’audio CD dans le monde entier est en 44,1 kHz, cela ressemble aussi à un oubli important

    • Je ne vois pas pourquoi l’encodage audio aurait besoin d’un débit variable
      L’audio à débit variable sonne affreusement mal et ne fait pas économiser tant de débit que ça
    • Avec -q:a, on peut utiliser du « vrai » débit variable, mais les métriques sont quelques pourcents plus basses
      Cela dit, c’est difficilement perceptible et, à mon avis, il gagne toujours
      Les benchmarks ont surtout été faits en 44,1 kHz, tandis que les données réglées à l’oreille étaient en 48 kHz ; une partie de la logique de fenêtrage et de gestion des transitoires est donc liée au 48 kHz
      Mais elle a été suffisamment bien transposée au 44,1 kHz, et comme l’écart de timing n’est pas très grand, elle a été laissée telle quelle

  • Il est intéressant de voir à quel point tout cela dépend de l’oreille du développeur
    C’est à la fois inquiétant et assez génial, tant le jugement de la qualité audio est subjectif

    • Les tableaux et comparaisons utilisent « le nouveau Zimtohrli de Google, ViSQOL et mon audition »
    • En audio, c’est généralement comme ça
      Musepack aussi a eu pendant un temps une popularité de niche : c’était un codec simple, mais extrêmement bien réglé
      C’est pareil pour les enceintes et les casques : les gens pensent qu’il s’agit de qualité des composants, alors qu’en réalité tout dépend surtout de la compréhension globale de la physique audio et de la capacité à bien régler l’ensemble

  • C’est un ajout très bienvenu
    J’espère qu’il pourra désormais remplacer fdk-aac

  • Quelqu’un arrive avec le meilleur encodeur AAC jamais créé, et la première réaction, c’est qu’un responsable pinaille sur 48 kHz contre 44 kHz : c’est vraiment l’Internet d’autrefois

    • Ce n’est pas forcément à voir de façon aussi cynique
      L’auteur ne l’ayant pas testé à la fréquence d’échantillonnage la plus couramment utilisée, il serait absurde, pour n’importe quel projet sérieux, de remplacer d’un coup tout un pipeline vieux de plusieurs décennies et encore fonctionnel
      Il est tout à fait légitime d’attendre qu’il ait été suffisamment validé

  • Quand j’encodais autrefois des morceaux pour iPod nano avec ffmpeg, les fichiers étaient corrompus
    Pendant la lecture, des pops et des clics s’intercalaient toutes les quelques secondes ; je me demande si c’est corrigé maintenant