FFmpeg 9.1 का नया AAC encoder

 (hydrogenaudio.org)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FFmpeg के native AAC encoder को rate control, RDO और PNS·TNS·I/S·M/S तक पूरी तरह फिर से लिखा गया है, और इसका लक्ष्य external AAC encoders के साथ सीधे तुलना लायक quality हासिल करना है
  • नया implementation strict CBR के काफ़ी करीब काम करता है, और -q:a आधारित वास्तविक VBR mode की सिफारिश नहीं की जाती
  • Zimtohrli·ViSQOL तुलना में नया nmr encoder 64~256kbps रेंज में आम तौर पर fdk-aac·Apple AAC से बेहतर नतीजे दिखाता है, लेकिन अलग तुलना में Opus अब भी आगे है
  • PNS·TNS·I/S·M/S का चयन RDO loop के अंदर किया जाता है, और अगर downmix होने की संभावना हो तो phase बनाए रखने के लिए -aac_is 0 -aac_pns 0 इस्तेमाल करने की सिफारिश है
  • 128kbps या उससे ऊपर पर सुधार के कई अच्छे आकलन मिले, लेकिन 64kbps stereo, कुछ TNS samples और speech content अब भी ऐसे क्षेत्र हैं जहाँ आगे validation की ज़रूरत है

FFmpeg AAC encoder का पूर्ण पुनर्लेखन

  • FFmpeg के AAC encoder को rate control, RDO, PNS, TNS, I/S, M/S सहित पूरी तरह फिर से लिखा गया है
  • rewrite PR merge के लिए साझा किया गया था, और बाद की thread में वास्तविक merge की पुष्टि हुई
  • testing source build से या BtbN nightly builds update के बाद की जा सकती है
  • नया encoder aac codec के रूप में इस्तेमाल किया जा सकता है
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • I/S disable: -aac_is 0
    • PNS disable: -aac_pns 0

quality metrics और तुलना के लक्ष्य

  • तुलना के लिए Google का Zimtohrli, ViSQOL, और listening tests इस्तेमाल किए गए
    • Zimtohrli में कम score बेहतर है
    • ViSQOL में ज़्यादा score बेहतर है
  • तालिका में नए encoder को nmr के रूप में दिखाया गया, और इसकी तुलना मौजूदा FFmpeg 8.1 fast·twoloop, fdk-aac, Apple AAC, libopus से की गई
  • प्रमुख नतीजे:
    • 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
  • high bitrate पर Zimtohrli saturation तक पहुँच जाता है, इसलिए ViSQOL को tie-breaker की तरह इस्तेमाल किया गया, और इस मानक पर Opus को छोड़कर नई encoder implementation आगे रही

CBR-केंद्रित design और coding tools

  • नया encoder लगभग CBR-only सोच के साथ design किया गया है, और bitrate variation बहुत कम है
    • bit budget का लक्ष्य coding quality में मदद करता है
    • -q:a आधारित वास्तविक VBR mode की सिफारिश नहीं की जाती
  • तुलना में पाया गया कि दूसरे encoders TNS के अलावा coding tools का लगभग इस्तेमाल नहीं करते, और नए encoder ने पहले सिर्फ TNS के साथ तुलना की, फिर PNS, I/S, M/S को दोबारा implement किया
  • qaac के reverse engineering से पता चला कि वह perceptual optimization नहीं करता, बल्कि high frequency को प्राथमिकता देने वाली bit allocation curve और band energy का उपयोग करता है
    • नया encoder ऐसी ही curve के साथ masked band energy को RDO में इस्तेमाल करता है
  • सभी coding tools PNS, TNS, I/S, M/S का चयन RDO loop के भीतर होता है
    • fixed heuristics या मनमाने bitrate cutoffs का इस्तेमाल नहीं होता
    • उपलब्ध tools को RDO के निर्णय के अनुसार लागू किया जाता है
  • high bitrate पर अगर encoder खुद पर्याप्त अच्छा काम कर रहा हो, तो I/S और PNS जैसे tools अपने-आप बंद हो जाते हैं ताकि bitrate बना रहे

decoder compatibility और downmix सावधानियाँ

  • FFmpeg के AAC decoder में stereo PNS handling की समस्या है, और यही bug दूसरे AAC decoders में भी हो सकती है, इसलिए encoder में workaround किया गया है
    • पुराने encoders PNS का इस्तेमाल नहीं करते थे, इसलिए यह समस्या अब तक सामने नहीं आई थी
  • अगर downmix की योजना है या output के downmix होने की संभावना है, तो -aac_is 0 -aac_pns 0 इस्तेमाल करने की सिफारिश है
    • उद्देश्य मूल signal का phase बनाए रखना है
  • spectrogram में बहुत से holes दिखना इरादतन behavior है
    • masked bands को 0 कर दिया जाता है या PNS से process किया जाता है
    • अगर पास के bands काफ़ी मज़बूत हों और गायब band को पहचानना मुश्किल हो, तो सभी bands को खराब encode करने की बजाय सुनाई देने वाले bands को बेहतर encode करना चुना जाता है

sample rate और cutoff policy

  • encoder मुख्य रूप से 48kHz audio के लिए optimize किया गया है
    • 44.1kHz और 96kHz भी काम करते हैं
    • highest quality के लिए 48kHz इस्तेमाल करने की सिफारिश है
  • प्रकाशित benchmarks ज़्यादातर 44.1kHz पर किए गए, जबकि कान से tune किया गया data 48kHz का था
    • कुछ windowing/transient logic 48kHz से बंधी हुई है
    • 44.1kHz पर भी timing का फ़र्क बड़ा नहीं है, इसलिए इसे वैसे ही रखा गया
  • बाद में bandwidth policy को adjust किया गया
    • 128kbps को 16kHz तक सीमित किया गया
    • 160kbps या उससे ऊपर को 18kHz तक सीमित किया गया
    • 192kbps per channel पर 20kHz से ऊपर पूरे spectrum को code करने के लिए बदला गया
  • 64kbps stereo में करने लायक चीज़ें सीमित हैं, और PNS को ज़्यादा बढ़ाने पर stereo image बिगड़ सकती है
    • 64kbps पर 15kHz भी बहुत ज़्यादा हो सकता है, इसलिए 12kHz cutoff के साथ retest का अनुरोध किया गया
    • mono में decoder bug workaround की ज़रूरत नहीं होती, इसलिए PNS का कहीं अधिक इस्तेमाल संभव है

test coverage और debug statistics

  • development-side testing 3000 tracks के music collection पर की गई
    • speech content पर बहुत कम test हुआ, इसलिए अतिरिक्त optimization की ज़रूरत पड़ सकती है
  • encoder बंद होते समय अतिरिक्त statistics print करता है
    • उदाहरण: 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%
  • statistics का अर्थ:
    • Qavg: औसत lambda value, और जितनी ऊँची हो rate बनाए रखना उतना कठिन होता है
    • Tr: short blocks
    • TNS(L): long frame में TNS usage rate
    • TNS(S): short frame में TNS usage rate
    • M/S: Mid/Side coding usage rate
    • I/S: intensity stereo coding usage rate
    • PNS: perceptual noise substitution usage rate
  • अगर कोई परेशान करने वाला artifact मिले, तो analysis के लिए original input sample और यह statistics line साथ में देने को कहा गया है

शुरुआती user tests और बाकी समस्याएँ

  • एक user ने Burn the Boats नाम के एक track पर 64kbps, 134kbps, 200kbps test किया
    • 64kbps अच्छा है लेकिन थोड़े artifacts हैं
    • 134kbps और 200kbps बहुत अच्छे सुनाई देते हैं
  • दूसरे test में 64kbps के The Tower sample पर feedback मिला कि नया nmr encoder पुराने twoloop की तुलना में ज़्यादा smeary और metallic लगता है
    • पुराना twoloop भी शुरुआत में collapse और overall noise व roughness की समस्या दिखाता है
  • fatboy_30sec sample में 192kbps पर 6.836 सेकंड और 10.480 सेकंड पर ticking sound सुनाई दी, और 48kHz resampling के बाद 14.125 सेकंड पर एक अतिरिक्त tick जुड़ गया
    • -aac_tns 0 से TNS बंद करने पर ticking गायब हो जाती है
    • libavcodec/aacenc_tns.c में TNS_PG_C1_SHORT value को 3.2, 4.2, 5.0 तक बढ़ाकर जाँचने का अनुरोध आगे आया
  • एक user ने 64kbps और 16kHz cutoff की शर्त में Fraunhofer AAC को बेहतर बताया, और नए encoder को metallic sounding कहा
    • उसी user ने 128kbps से ऊपर high bitrate पर नए encoder को अच्छा काम करने वाला बताया
    • साथ ही यह आकलन भी आया कि native FFmpeg के भीतर व्यापक रूप से उपलब्ध AAC encoder अब काफ़ी उपयोगी हो गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की टिप्पणियां

  • यह दिखाने वाला उदाहरण है कि Opus कितना मजबूत है
    यह काम अपने-आप में भी मूल्यवान है, और पुराने कोडेक के लिए encoder का बेहतर होना निश्चित रूप से फायदेमंद है, लेकिन इस benchmark में Opus के आंकड़े देखें तो 64kbps पर भी यह सभी AAC encoders पर भारी पड़ता है

    • अच्छे AAC encoder का सबसे बड़ा फायदा efficiency नहीं, compatibility है
      लगभग 20 सालों तक real-time streaming video का de facto standard H.264 video और AAC audio वाला RTMP रहा है, और दूसरे codec support लगभग न के बराबर हैं
      अगर YouTube या Twitch पर stream भेजनी है, तो आखिरकार आप H.264 और AAC ही भेजेंगे; OBS भी streaming mode में दूसरे video/audio codec चुनने की अनुमति देता ही नहीं और मान कर चलता है कि streamer H.264 और AAC इस्तेमाल करेगा
    • article में जाने से पहले एक पल के लिए मुझे भ्रम हुआ कि Opus model नहीं, encoder की बात कर रहा है
    • lossy audio codec चुनना अब लगभग सोचने वाली बात नहीं रह गई है
      बस Opus इस्तेमाल करें और बात खत्म; और किसी वजह से Opus इस्तेमाल नहीं कर सकते तो compatibility के लिए AAC को बहुत high bitrate पर इस्तेमाल करें
      अच्छे quality पाने के लिए यह research करने की जरूरत नहीं कि कौन-सा encoder और mode चुनना है
      फिर भी अच्छी quality वाला default AAC encoder मिलना शानदार है, लेकिन समझ नहीं आता कि यह मुख्य रूप से constant bitrate क्यों है
    • [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)
    • मेरे हिसाब से Opus की सबसे बड़ी समस्या इसकी specification की कमी है: https://nothings.org/stb/stb_opus.html
      इसी वजह से कुछ खास licensing issues आ सकने वाले games या store distributions में Opus लगभग इस्तेमाल नहीं होता

  • असली performance कैसी होगी, इसका इंतजार है
    FFmpeg का मौजूदा AAC encoder खराब output quality देता था और अक्सर चुभने वाली चहचहाहट जैसे artifacts होते थे, इसलिए ठीक-ठाक sound पाने के लिए video recording वाले हर computer पर Apple Core Audio encoder install करना पड़ता था
    A/B/X comparison करने पर 320kbps MP3, FFmpeg से encoded 320kbps AAC से बेहतर था, और Core Audio से encoded 256kbps AAC के करीब था
    अगर अब Core Audio install करने की जरूरत खत्म हो जाए तो यह बड़ा सुधार होगा, और OBS जैसे tools से screen recording या streaming करने वालों की audio quality अगले update में काफी बेहतर हो सकती है

    • Apple Core Audio के मामले में qaac उपयोगी है
      यह iTunes Windows DLL को wrap करके CLI वाला standalone encoding tool बना देता है, और मेरी जानकारी में Linux पर Wine में भी चलता है: https://web.archive.org/web/20250814194428/https://www.andre...
      high-quality AAC encoding के लिए Mac या पूरा iTunes install करना जरूरी नहीं है
    • मैं FDK AAC encoder इस्तेमाल कर रहा था, और मुझे पता नहीं था कि Apple encoder Apple के अलावा दूसरे systems पर भी संभव है
      पहले 192kbps पर FDK AAC और Apple AAC की तुलना की थी तो फर्क महसूस नहीं हुआ था, लेकिन पुराना FFmpeg AAC encoder इस bitrate पर टूट जाता था
    • Hydrogenaudio discussion thread की metrics table में नया encoder Core Audio से बेहतर score करता है
      हालांकि यह constant bitrate के आधार पर है
      Core Audio में TVBR भी है, जो नया encoder में नहीं मौजूद variable bitrate mode है
      इसलिए जहां TVBR इस्तेमाल किया जा सकता है, वहां Core Audio शायद अभी भी best रहे, लेकिन उम्मीद है कि ज्यादा लोग problematic samples ढूंढकर contribute करेंगे और tuning होगी तो नया FFmpeg encoder भी काफी अच्छा हो जाएगा
    • अगर quality की चिंता है तो lossless codec क्यों नहीं इस्तेमाल करते, यह समझ नहीं आता
      या फिर Opus इस्तेमाल करें; voice के लिए भी ठीक है और आजकल लगभग हर जगह चलता है
    • Apple का proprietary codecs से चिपके रहना समझ नहीं आता
      अगर Apple ने H.265 adopt नहीं किया होता तो शायद हम AV1 utopia में रह रहे होते

  • “FFmpeg के AAC decoder में stereo PNS handling में bug है, और यह दूसरे AAC decoders में भी हो सकता है, इसलिए encoder में workaround किया जाता है। दूसरे encoders PNS इस्तेमाल नहीं करते थे, इसलिए यह अब तक पकड़ा नहीं गया” वाला हिस्सा दिलचस्प है
    PNS क्या है, मुझे नहीं पता, लेकिन लगता है यह 20 साल से किसी के बेहद niche use case को परेशान करता रहा होगा

    • समस्या दो तरह की थी
      पहली, PNS के ऊपर TNS इस्तेमाल करने पर inserted noise TNS से shape होता है, जबकि noise बनाने वाला encoder नहीं बल्कि decoder है, इसलिए यह बात बेमानी है
      इससे PNS खराब हो गया, और बड़ी समस्या यह थी कि PNS को किसी stereo tool के साथ इस्तेमाल करने पर noise दोनों channels में एक जैसा leak होकर stereo imaging बिगाड़ देता था
      इसलिए PNS को तभी enable करना सबसे बेहतर है जब दोनों channels के संबंधित bands noise हों, या पर्याप्त non-tonal और masked हों
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • बारीकियां अच्छी तरह समेटने वाला शानदार update है
    Opus बेहतरीन है और उसकी अपनी सही जगह है, लेकिन AAC गायब नहीं होने वाला

  • “encoder मुख्य रूप से 48kHz audio के लिए optimize किया गया है। इसे स्वीकार करें। 2026 है, resampling मुफ्त है और 48kHz standard है। 44.1kHz भी काम करता है और 96kHz भी काम करता है, लेकिन अगर best quality चाहिए तो 48kHz इस्तेमाल करें” वाला हिस्सा है; क्या आजकल सच में 48kHz standard है?

    • असल “standard” के सबसे करीब AES5-2018, “professional digital audio recommended practice” है, ऐसा लगता है
      इसके abstract में कहा गया है कि PCM इस्तेमाल करने वाले audio programs के production, processing और exchange के लिए 48kHz sampling frequency की सिफारिश की जाती है, और कुछ consumer digital applications के लिए 44.1kHz, transmission-related applications के लिए 32kHz, और ज्यादा bandwidth या relaxed anti-aliasing filters की जरूरत वाली applications के लिए 96kHz को भी मान्यता दी गई है
      निजी तौर पर 44.1kHz legacy में बची एक छोटी-सी झंझट जैसा लगता है
    • AAC में sampling rate के हिसाब से window size बदलने वाली एक अजीब खासियत है
      इसलिए 20ms window और 60ms window इंसानी कानों को बहुत अलग सुनाई देते हैं, इसलिए हर sampling rate के लिए encoder के सारे psychoacoustic parameters को पूरी तरह फिर से optimize करना पड़ता है
      Opus में जाहिर है यह समस्या हल हो चुकी है
    • 48kHz video और audio को align करना कहीं आसान बना देता है
      उदाहरण के लिए edit के बाद lip-sync आसान हो जाता है
    • मेरी जानकारी में Opus codec सभी input को 48kHz मानता है और input को उसी तरफ resample करता है
    • लगभग सभी DAC default रूप से 48kHz पर चलते हैं, क्योंकि operating system इसे reasonable default के तौर पर चुनता है

  • बेहतर नया FFmpeg AAC encoder स्वागतयोग्य है, लेकिन details में दो काफी बड़े caveat हैं
    यह केवल fixed bitrate support करता है, और केवल 48kHz sampling के लिए optimize किया गया है
    quality-based variable bitrate encoding न कर पाना बड़ा gap है, और यह देखते हुए कि दुनिया भर का CD audio 44.1kHz है, यह भी बड़ी कमी लगती है

    • audio encoding में variable bitrate की जरूरत क्यों है, समझ नहीं आता
      variable bitrate audio की sound बहुत खराब होती है और bitrate भी इतना ज्यादा नहीं बचता
    • -q:a इस्तेमाल करें तो “असली” variable bitrate इस्तेमाल कर सकते हैं, लेकिन metric कुछ percent कम है
      फिर भी इसे perceive करना मुश्किल है और मेरे हिसाब से यह अब भी जीतता है
      benchmark मुख्य रूप से 44.1kHz पर किए गए थे, और कान से tune किया गया data 48kHz था, इसलिए कुछ windowing/transient logic 48kHz से बंधी हुई है
      हालांकि यह 44.1kHz पर भी काफी अच्छी तरह port हो गया और timing difference बड़ा नहीं था, इसलिए इसे वैसे ही छोड़ दिया गया

  • यह दिलचस्प है कि इसका इतना बड़ा हिस्सा developer के अपने कानों पर निर्भर है
    साथ ही थोड़ा असहज भी और काफी cool भी है, क्योंकि audio quality judgment इतना subjective है

    • tables और comparisons में “Google का नया Zimtohrli, ViSQOL, और मेरी hearing” इस्तेमाल किए गए थे
    • audio में आम तौर पर ऐसा ही होता है
      Musepack भी कुछ समय तक niche में popular था; वह simple लेकिन बहुत अच्छी तरह tuned codec था
      speakers और headphones के साथ भी यही है: लोग इसे component quality समझते हैं, लेकिन असल में overall audio physics की समझ और अच्छी tuning की क्षमता ही ज्यादातर फर्क डालती है

  • बहुत अच्छा addition है
    उम्मीद है अब fdk-aac को replace कर सकेगा

  • किसी ने अब तक का best AAC encoder बनाकर लाया है, और पहली प्रतिक्रिया यह है कि 48kHz है या 44kHz, इस पर maintainer बहस कर रहा है—वाकई old internet जैसा

    • इसे इतना cynical तरीके से देखने की जरूरत नहीं है
      author ने सच में सबसे ज्यादा इस्तेमाल होने वाले sampling rate पर test नहीं किया है, इसलिए कोई भी serious project दशकों पुराने working pipeline को पूरा बदल दे, यह बेतुका होगा
      पर्याप्त validation पूरा होने तक इंतजार करना पूरी तरह valid है

  • पहले जब मैंने ffmpeg से iPod nano के लिए गाने encode किए थे, तो files corrupt हो गई थीं
    playback के दौरान हर कुछ सेकंड में pops और clicks की आवाज बीच-बीच में आती थी; सोच रहा हूं कि अब यह fix हुआ है या नहीं