FFmpeg 9.1'in yeni AAC kodlayıcısı

 (hydrogenaudio.org)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • FFmpeg'in yerleşik AAC kodlayıcısı, rate control, RDO ve PNS·TNS·I/S·M/S dahil olmak üzere baştan sona yeniden yazıldı; hedef, harici AAC kodlayıcılarla doğrudan karşılaştırılabilecek bir kalite sunmak
  • Yeni uygulama katı CBR'e yakın çalışıyor ve -q:a tabanlı gerçek VBR modu önerilmiyor
  • Zimtohrli·ViSQOL karşılaştırmalarında yeni nmr kodlayıcısı 64~256kbps aralığında genelde fdk-aac ve Apple AAC'den daha iyi sonuç verdi; ancak Opus, ayrı karşılaştırmalarda hâlâ üstün kaldı
  • PNS·TNS·I/S·M/S, RDO döngüsü içinde seçiliyor; downmix bekleniyorsa fazı korumak için -aac_is 0 -aac_pns 0 kullanılması öneriliyor
  • 128kbps ve üzerinde iyileşme değerlendirmeleri çoktu; ancak 64kbps stereo, bazı TNS örnekleri ve konuşma içeriği ek doğrulama gerektiren alanlar olarak kaldı

FFmpeg AAC kodlayıcısının baştan sona yeniden yazılması

  • FFmpeg'in AAC kodlayıcısı, rate control, RDO, PNS, TNS, I/S, M/S dahil olmak üzere baştan sona yeniden yazıldı
  • Yeniden yazım PR'ı birleştirme adayı olarak paylaşıldı ve daha sonra başlık altında gerçekten birleştirildiği doğrulandı
  • Testler kaynak koddan derleyerek veya BtbN nightly builds güncellendikten sonra yapılabiliyor
  • Yeni kodlayıcı aac codec'i ile kullanılabiliyor
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • I/S devre dışı bırakma: -aac_is 0
    • PNS devre dışı bırakma: -aac_pns 0

Kalite metrikleri ve karşılaştırma hedefleri

  • Karşılaştırmalarda Google'ın Zimtohrli, ViSQOL araçları ve dinleme testleri kullanıldı
    • Zimtohrli'de düşük değer daha iyi
    • ViSQOL'da yüksek değer daha iyi
  • Tabloda yeni kodlayıcı nmr olarak gösterildi ve eski FFmpeg 8.1 fast·twoloop, fdk-aac, Apple AAC, libopus ile karşılaştırıldı
  • Temsili sonuçlar:
    • 64kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • Yüksek bitrate'te Zimtohrli doygunluğa ulaştığı için tie-breaker olarak ViSQOL kullanıldı; bu ölçüte göre Opus hariç karşılaştırmalarda yeni kodlayıcı önde çıktı

CBR odaklı tasarım ve kodlama araçları

  • Yeni kodlayıcı neredeyse yalnızca CBR için tasarlandı ve bitrate dalgalanması çok küçük
    • Bit bütçesi hedefi, kodlama kalitesine yardımcı oluyor
    • -q:a tabanlı gerçek VBR modu önerilmiyor
  • Karşılaştırmada diğer kodlayıcıların TNS dışındaki kodlama araçlarını neredeyse hiç kullanmadığı görüldü; yeni kodlayıcı önce yalnızca TNS ile karşılaştırıldı, ardından PNS, I/S, M/S yeniden uygulandı
  • qaac, tersine mühendislik sonuçlarına göre algısal optimizasyon yapmıyor; yüksek frekansları tercih eden bir bit dağıtım eğrisi ve bant enerjileri kullanıyor
    • Yeni kodlayıcı, benzer bir eğriyle birlikte masked band energy'yi RDO içinde kullanıyor
  • PNS, TNS, I/S, M/S dahil tüm kodlama araçları RDO döngüsü içinde seçiliyor
    • Sabit heuristikler veya keyfi bitrate cutoff'ları kullanılmıyor
    • Kullanılabilecek araçlar RDO kararına göre uygulanıyor
  • Yüksek bitrate'te kodlayıcının kendisi yeterince iyi çalışıyorsa I/S ve PNS gibi araçlar bitrate'i korumak için kendiliğinden devreden çıkıyor

Kod çözücü uyumluluğu ve downmix uyarıları

  • FFmpeg'in AAC decoder'ında stereo PNS işleme sorunu var ve aynı hata başka AAC decoder'larında da bulunabileceği için kodlayıcı tarafında geçici çözüm uygulanıyor
    • Mevcut kodlayıcılar PNS kullanmadığı için bu sorun şimdiye kadar görünür olmamıştı
  • Downmix planlanıyorsa veya çıktının downmix edilme ihtimali varsa -aac_is 0 -aac_pns 0 kullanılması öneriliyor
    • Amaç, özgün sinyalin fazını korumak
  • Spektrogramda çok sayıda boşluk görünmesi kasıtlı bir davranış
    • Maskelenmiş bantlar 0 yapılıyor veya PNS uygulanıyor
    • Komşu bantlar yeterince güçlüyse ve eksik bantların fark edilmesi zorsa, tüm bantları kötü kodlamak yerine duyulabilir bantları daha iyi kodlama yolu seçiliyor

Örnekleme hızı ve cutoff politikası

  • Kodlayıcı öncelikle 48kHz ses için optimize edildi
    • 44.1kHz ve 96kHz de çalışıyor
    • En yüksek kalite için 48kHz kullanılması öneriliyor
  • Yayınlanan benchmark'lar çoğunlukla 44.1kHz'te yapıldı, kulakla ayarlanan veriler ise 48kHz'ti
    • Bazı windowing/transient mantıkları 48kHz'e bağlı
    • 44.1kHz'te de zamanlama farkı büyük olmadığı için aynı şekilde bırakıldı
  • Sonrasında bant genişliği politikası ayarlandı
    • 128kbps, 16kHz ile sınırlandı
    • 160kbps ve üzeri, 18kHz ile sınırlandı
    • Kanal başına 192kbps'te 20kHz üzeri dahil tüm spektrumun kodlanması için değişiklik yapıldı
  • 64kbps stereo'da yapılabilecekler sınırlı ve PNS'yi daha fazla artırmak stereo görüntüyü bozabiliyor
    • 64kbps'te 15kHz bile fazla yüksek olabilir; 12kHz cutoff ile yeniden test talep edildi
    • Mono'da decoder hatasını aşma gereği olmadığından PNS çok daha fazla kullanılabiliyor

Test kapsamı ve debug istatistikleri

  • Geliştirici tarafındaki testler 3000 parçalık bir müzik koleksiyonunda yapıldı
    • Konuşma içeriği çok az test edildiği için ek optimizasyon gerekebilir
  • Kodlayıcı kapanışta ek istatistikler yazdırıyor
    • Örnek: 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%
  • İstatistiklerin anlamı:
    • Qavg: ortalama lambda değeri; ne kadar yüksekse rate'i korumak o kadar zor
    • Tr: short blocks
    • TNS(L): long frame'lerde TNS kullanım oranı
    • TNS(S): short frame'lerde TNS kullanım oranı
    • M/S: Mid/Side coding kullanım oranı
    • I/S: intensity stereo coding kullanım oranı
    • PNS: perceptual noise substitution kullanım oranı
  • Rahatsız edici artifact'ler bulunursa, analiz için özgün giriş örneğiyle birlikte bu istatistik satırının da paylaşılabileceği belirtiliyor

İlk kullanıcı testleri ve kalan sorunlar

  • Bir kullanıcı yalnızca Burn the Boats parçasıyla 64kbps, 134kbps, 200kbps testleri yaptı
    • 64kbps iyi ama hafif artifact'ler var
    • 134kbps ve 200kbps kulağa çok iyi geliyor
  • Başka bir testte 64kbps The Tower örneğinde yeni nmr kodlayıcısının eski twoloop'a göre daha smeary ve metallic duyulduğu geri bildirildi
    • Eski twoloop'ta da başlangıçta collapse, genel noise ve roughness sorunları var
  • fatboy_30sec örneğinde 192kbps'te 6.836 saniye ve 10.480 saniyede ticking sound duyuldu; 48kHz'e yeniden örneklemeden sonra 14.125 saniyede ek bir tick oluştu
    • -aac_tns 0 ile TNS kapatılınca ticking kayboldu
    • libavcodec/aacenc_tns.c içindeki TNS_PG_C1_SHORT değerinin 3.2, 4.2, 5.0'a yükseltilerek kontrol edilmesi istendi
  • Bir kullanıcı, 64kbps ve 16kHz cutoff koşulunda Fraunhofer AAC'nin kulağa daha iyi geldiğini, yeni kodlayıcının ise metallic duyulduğunu değerlendirdi
    • Aynı kullanıcı, 128kbps üzerindeki yüksek bitrate'lerde yeni kodlayıcının iyi çalıştığını da belirtti
    • Ayrıca yerleşik FFmpeg içinde geniş erişime sahip bir AAC kodlayıcısının artık yeterince kullanılabilir hale geldiği yorumu yapıldı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • Opus’un ne kadar güçlü olduğunu gösteren bir örnek
    Bu çalışmanın kendisi de değerli ve eski bir codec için encoder’ın iyileşmesi kesinlikle kazanç, ama bu benchmark’ta Opus değerlerine bakınca 64 kbps’te bile tüm AAC encoder’larını geride bırakıyor

    • İyi bir AAC encoder’ının en büyük avantajı verimlilik değil, uyumluluk
      Yaklaşık 20 yıldır gerçek zamanlı video akışının fiilî standardı H.264 video ve AAC ses kullanan RTMP oldu; diğer codec destekleri ise neredeyse yok
      YouTube veya Twitch’e stream göndermek istiyorsanız sonunda H.264 ve AAC göndermiş oluyorsunuz; OBS de streaming modunda başka video/ses codec seçimine hiç izin vermiyor ve yayıncının H.264 ile AAC kullanacağını varsayıyor
    • Yazıya girmeden önce Opus’un bir modeli değil, encoder’ı kastettiğini bir an karıştırdım
    • Kayıplı ses codec’i seçimi artık neredeyse düşünmeyi gerektirmiyor
      Sadece Opus kullanın, bitti; herhangi bir nedenle Opus kullanamıyorsanız uyumluluk için AAC’yi çok yüksek bitrate ile kullanın
      İyi kalite elde etmek için hangi encoder’ı ve modu seçeceğinizi araştırmanız gerekmiyor
      Yine de kaliteli bir varsayılan AAC encoder’ının gelmesi harika, ama neden ağırlıklı olarak sabit bitrate olduğunu pek anlayamıyorum
    • [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)
    • Bence Opus’un en büyük sorunu spesifikasyonunun yetersiz olması: https://nothings.org/stb/stb_opus.html
      Bu yüzden belirli lisans sorunları doğurabilecek oyunlarda veya mağaza dağıtımlarında Opus neredeyse hiç kullanılmıyor

  • Gerçek performansının nasıl olacağını merakla bekliyorum
    FFmpeg’in mevcut AAC encoder’ının çıktı kalitesi kötüydü ve rahatsız edici cıvıltı benzeri artefaktlar sık görülüyordu; düzgün ses elde etmek için video kaydı yapılan her bilgisayara Apple Core Audio encoder’ını kurmak gerekiyordu
    A/B/X karşılaştırması yapınca 320 kbps MP3, FFmpeg ile encode edilmiş 320 kbps AAC’den daha iyiydi ve Core Audio ile encode edilmiş 256 kbps AAC’ye yakındı
    Artık Core Audio kurulumu gerekmeyecekse bu büyük bir iyileşme; OBS gibi araçlarla ekran kaydı veya streaming yapan kişiler bir sonraki güncellemede ses kalitesinde ciddi bir artış görebilir

    • Apple Core Audio tarafında qaac kullanışlı
      iTunes Windows DLL’ini sarıp CLI’ı olan bağımsız bir encode aracına dönüştürüyor; bildiğim kadarıyla Linux’ta Wine üzerinde de çalışıyor: https://web.archive.org/web/20250814194428/https://www.andre...
      Yüksek kaliteli AAC encode için Mac ya da tam iTunes kurulumu şart değil
    • Ben FDK AAC encoder’ını kullanıyordum; Apple encoder’ının Apple dışı sistemlerde de mümkün olduğunu bilmiyordum
      Eskiden 192 kbps’te FDK AAC ile Apple AAC’yi karşılaştırdığımda fark duymamıştım, ama mevcut FFmpeg AAC encoder’ı bu bitrate’te dağılıyordu
    • Hydrogenaudio tartışma başlığındaki metrik tablosunda yeni encoder, Core Audio’dan daha iyi puan alıyor
      Ancak bu sabit bitrate ölçütüne göre
      Core Audio’da yeni encoder’da olmayan değişken bitrate modu TVBR de var
      Bu yüzden TVBR kullanılabildiğinde Core Audio hâlâ en iyisi olabilir; ama daha çok kişi sorunlu örnekler bulup katkı vererek ayarları iyileştirirse yeni FFmpeg encoder’ının da gayet iyi hâle geleceğini umuyorum
    • Kaliteyi önemsiyorsanız neden kayıpsız codec kullanmadığınızı merak ediyorum
      Ya da Opus kullanabilirsiniz; konuşma için de iyi ve bugünlerde neredeyse her yerde çalışıyor
    • Apple’ın tescilli codec’lere takılıp kalmasını anlamıyorum
      Apple H.265’i benimsememiş olsaydı belki de AV1 ütopyasında yaşıyor olurduk

  • “FFmpeg’in AAC decoder’ında stereo PNS işleme konusunda bir bug var; başka AAC decoder’larında da olabilir, bu yüzden encoder tarafında etrafından dolaşılıyor. Diğer encoder’lar PNS kullanmadığı için bug bugüne kadar keşfedilmemişti” kısmı ilginç
    PNS’nin ne olduğunu bilmiyorum ama birilerinin çok özel kullanım senaryosunu 20 yıldır rahatsız etmiş gibi duruyor

    • Sorun iki taneydi
      Birincisi, PNS üzerine TNS kullanıldığında eklenen gürültü TNS ile şekillendiriliyor; oysa gürültüyü oluşturan taraf encoder değil decoder olduğu için bu mantıksız
      Bu PNS’yi bozuyordu; daha büyük sorun ise PNS bazı stereo araçlarla birlikte kullanıldığında gürültünün iki kanala da aynı şekilde sızıp stereo görüntülemeyi bozmasıydı
      Bu yüzden PNS’yi yalnızca iki kanaldaki ilgili bantların ikisi de gürültü olduğunda ya da yeterince tonsuz olup maskelendiğinde açmak en iyisi
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Ayrıntıları iyi düzenlenmiş harika bir güncelleme
    Opus harika ve kendi yeri var, ama AAC ortadan kaybolmayacak

  • “Kodlayıcı esas olarak 48 kHz sese optimize edildi. Kabullenin. 2026’dayız; yeniden örnekleme bedava ve 48 kHz standart. 44,1 kHz de çalışır, 96 kHz de çalışır; ama en iyi kaliteyi istiyorsanız 48 kHz kullanın” diye bir bölüm var; günümüzde gerçekten 48 kHz standart mı?

    • Gerçek “standart”a en yakın şeyin AES5-2018, “Profesyonel dijital ses için önerilen uygulama” olduğunu düşünüyorum
      Özetinde, PCM kullanan ses programlarının üretimi, işlenmesi ve değişimi için 48 kHz örnekleme frekansı öneriliyor; bazı tüketici dijital uygulamalarında 44,1 kHz, iletimle ilgili uygulamalarda 32 kHz, daha yüksek bant genişliği veya daha gevşek anti-aliasing filtresi gerektiren uygulamalarda da 96 kHz kabul ediliyor
      Kişisel olarak 44,1 kHz bana miras kalmış küçük bir zahmet gibi geliyor
    • AAC’nin örnekleme hızına göre pencere boyutunun değiştiği tuhaf bir özelliği var
      Bu yüzden 20 ms’lik pencere ile 60 ms’lik pencere insan kulağına çok farklı geldiğinden, her örnekleme hızı için kodlayıcının tüm psikoakustik parametrelerini baştan tamamen optimize etmek gerekiyor
      Opus’ta doğal olarak bu sorun çözülmüş durumda
    • 48 kHz, görüntü ile sesi hizalamayı çok daha kolaylaştırıyor
      Örneğin düzenleme sonrası dudak senkronizasyonu kolaylaşıyor
    • Bildiğim kadarıyla Opus kodeği tüm girdileri 48 kHz kabul ediyor ve girdiyi buna yeniden örnekliyor
    • Neredeyse tüm DAC’ler, işletim sistemi makul varsayılan değer olarak onu seçtiği için varsayılan olarak 48 kHz çalışıyor

  • Daha iyi yeni FFmpeg AAC kodlayıcısı memnuniyet verici, ama ayrıntılarda oldukça büyük iki çekince var
    Yalnızca sabit bit hızını destekliyor ve yalnızca 48 kHz örneklemeye optimize edilmiş
    Kalite odaklı değişken bit hızlı kodlama yapamaması büyük bir boşluk; dünyadaki CD seslerinin 44,1 kHz olduğu düşünülünce bu da büyük bir eksik gibi görünüyor

    • Ses kodlamada neden değişken bit hızı gerektiğini bilmiyorum
      Değişken bit hızlı ses berbat duyuluyor ve bit hızından da o kadar çok tasarruf etmiyor
    • -q:a kullanırsanız “gerçek” değişken bit hızını kullanabilirsiniz, ama metrikler birkaç yüzde daha düşük
      Yine de algılaması zor ve bence hâlâ kazanıyor
      Karşılaştırmalar çoğunlukla 44,1 kHz’de yapıldı; kulakla ayarlanan veriler ise 48 kHz olduğu için bazı pencereleme ve transient mantığı 48 kHz’e bağlı
      Ancak 44,1 kHz’e de yeterince iyi taşındı ve zamanlama farkı büyük olmadığı için olduğu gibi bırakıldı

  • Bu kadar çok şeyin geliştiricinin kendi kulağına bağlı olması ilginç
    Aynı anda hem tedirgin edici hem de epey havalı; ses kalitesi değerlendirmesi bu kadar öznel

    • Tablolarda ve karşılaştırmalarda “Google’ın yeni Zimtohrli’si, ViSQOL ve benim işitmem” kullanılmış
    • Seste genelde işler böyle
      Musepack de bir dönem niş çevrelerde popülerdi; basit ama çok iyi ayarlanmış bir kodekti
      Hoparlörler ve kulaklıklar için de aynı şey geçerli: insanlar bunun parça kalitesiyle ilgili olduğunu sanıyor, ama gerçekte genel ses fiziğini anlama ve iyi ayar yapabilme becerisi çoğunu belirliyor

  • Çok sevindirici bir ekleme
    Umarım artık fdk-aac’ın yerini alabilir

  • Biri gelmiş tüm zamanların en iyi AAC kodlayıcısını yapmış, ilk tepkinin ise bir yöneticinin 48 kHz mi 44 kHz mi diye tartışması olması gerçekten eski internet ruhu

    • Bunu o kadar alaycı görmeye gerek yok
      Yazar gerçekten de en yaygın kullanılan örnekleme hızında test etmemiş; dolayısıyla ciddi herhangi bir projenin onlarca yıllık çalışan bir pipeline’ı komple değiştirmesi saçma olur
      Yeterli doğrulama bitene kadar beklemek tamamen makul

  • Eskiden ffmpeg ile iPod nano için şarkı kodladığımda dosya bozuluyordu
    Çalma sırasında birkaç saniyede bir araya patlama ve klik sesleri giriyordu; şimdi düzeltilip düzeltilmediğini merak ediyorum