- Meta ने धीमे नेटवर्क और पुराने डिवाइसों पर भी WhatsApp, Instagram, Messenger की रीयल-टाइम कॉल क्वालिटी बनाए रखने के लिए नया low bitrate audio codec MLow बनाया है
- मौजूदा Opus, 6 kbps पर NarrowBand में काम करता है, इसलिए आवाज़ की फ़्रीक्वेंसी रेंज को पर्याप्त रूप से कैप्चर करना मुश्किल होता है, और वीडियो कॉल के दौरान नेटवर्क खराब होने पर ऑडियो के लिए आवंटित bitrate और भी कम हो जाता है
- ML-आधारित audio codec कम bitrate पर अच्छी क्वालिटी दे सकते हैं, लेकिन उनकी computational cost अधिक होती है, इसलिए वे अक्सर नए high-performance mobile devices के लिए ही उपयुक्त होते हैं
- MLow, 6 kbps WideBand मानक पर POLQA MOS 3.9 देता है, जो Opus के 1.89 की तुलना में लगभग 2 गुना बेहतर क्वालिटी है, और इसकी computational complexity, Opus से 10% कम है
- यह Instagram और Messenger कॉल्स में पहले ही पूरी तरह लागू हो चुका है और WhatsApp पर भी रोलआउट हो रहा है, साथ ही कम bitrate पर FEC को अधिक कुशलता से शामिल कर packet loss की स्थिति में audio recovery को बेहतर बनाता है
Meta ने नया codec क्यों बनाया
- WhatsApp, Instagram, Messenger सहित Meta के apps अरबों लोगों को रीयल-टाइम कम्युनिकेशन (RTC) फीचर्स देते हैं
- RTC में audio और video codec, कैप्चर किए गए डेटा को compress करके इंटरनेट पर भेजते हैं और कॉल को रीयल-टाइम में बनाए रखने वाले मुख्य घटक होते हैं
- एक सामान्य कॉल का raw audio, 48kHz sampling, 16-bit, mono मानक पर 768 kbps होता है, और आधुनिक codec इसे 25~30 kbps तक compress कर सकते हैं
- compression प्रक्रिया में सूचना हानि के कारण क्वालिटी कम हो सकती है, लेकिन अच्छे codec audio signal की विशेषताओं और psychoacoustics के ज्ञान का उपयोग करके क्वालिटी, bitrate और complexity के बीच संतुलन बनाते हैं
- Opus, 2012 में जारी किया गया एक प्रसिद्ध open source codec है, और Meta अब तक RTC आवश्यकताओं के लिए Opus का उपयोग करता रहा है
कम bitrate और पुराने डिवाइसों की सीमाएँ
- Meta के बड़े पैमाने के RTC वातावरण में यह सीधे देखा जा सकता है कि विभिन्न नेटवर्क परिस्थितियाँ कॉल अनुभव को कैसे प्रभावित करती हैं
- काफी संख्या में कॉल्स पूरे या आंशिक समय में खराब नेटवर्क कनेक्शन का सामना करती हैं
- bandwidth estimation module (BWE) नेटवर्क क्वालिटी का पता लगाता है
- नेटवर्क क्वालिटी खराब होने पर congestion से बचने और audio stream बनाए रखने के लिए codec bitrate कम करनी पड़ती है
- वीडियो कॉल में खराब नेटवर्क स्थिति के दौरान ऑडियो के लिए उपलब्ध अतिरिक्त क्षमता और भी कम हो जाती है
- Opus की सबसे निचली operating point 6 kbps है, और इस समय यह NarrowBand मोड 0~4kHz में काम करता है
- यह रेंज मानव आवाज़ द्वारा उत्पन्न सभी फ़्रीक्वेंसी को पर्याप्त रूप से कैप्चर नहीं कर पाती
- नतीजतन, आवाज़ कम स्पष्ट और कम प्राकृतिक सुनाई देती है
- Meta ने अक्टूबर 2022 में Encodec जैसे ML-आधारित audio codec पेश किए थे, जो बहुत कम bitrate पर भी साफ़ audio quality देते हैं
- लेकिन उनकी computational cost अधिक होती है, इसलिए वे अक्सर केवल high-performance और महंगे mobile devices पर ही स्थिर रूप से चल पाते हैं
- low-end devices के उपयोगकर्ताओं को कम bitrate की स्थिति में अब भी audio quality समस्याओं का सामना करना पड़ता है
- Meta की 20% से अधिक कॉल्स ARMv7 डिवाइसों पर होती हैं, और WhatsApp पर 10 साल से अधिक पुराने डिवाइसों से हर दिन करोड़ों कॉल्स होती हैं
MLow की performance और deployment स्थिति
- Meta ने 2021 के अंत में नया codec विकसित करना शुरू किया और लगभग 2 साल के विकास और परीक्षण के बाद Meta Low Bitrate audio codec, यानी MLow, पेश किया
- 6 kbps WideBand मानक पर इसकी क्वालिटी POLQA MOS 3.9 है, जो Opus के 1.89 की तुलना में लगभग 2 गुना बेहतर है
- इसकी computational complexity, Opus से 10% कम है
- MOS (Mean Opinion Score) के 1~5 स्केल की तुलना में MLow, कम bitrate रेंज में Opus पर बड़ा बढ़त दिखाता है और Opus की तुलना में अधिक तेज़ी से quality saturation तक पहुँचता है
- यह Instagram और Messenger कॉल्स में पहले ही पूरी तरह लागू हो चुका है, और WhatsApp पर सक्रिय रूप से रोलआउट किया जा रहा है
- यह भी पुष्टि हुई है कि बेहतर audio quality से user engagement में सुधार होता है
packet loss की स्थिति में FEC
- कम bitrate पर high-quality audio encode कर पाने से Forward Error Correction(FEC) रणनीति को भी अधिक प्रभावी तरीके से इस्तेमाल किया जा सकता है
- MLow, Opus की तुलना में और कम bitrate पर भी FEC शामिल करने की गुंजाइश देता है
- यह विशेषता packet loss की स्थिति में audio quality सुधारने में मदद करती है
- 14 kbps पर receiver side packet loss 30% तक होने की गंभीर स्थिति का sample comparison भी दिया गया है
- Opus उस bitrate पर in-band FEC encode नहीं कर सकता
- Opus को 10% packet loss पर in-band FEC encode करने के लिए कम-से-कम 19 kbps चाहिए
- यह सीमा audio recovery के लिए प्रतिकूल साबित होती है
MLow की आंतरिक संरचना
- MLow पारंपरिक CELP(Code Excited Linear Prediction) codec अवधारणा पर आधारित है
- मुख्य सुधार excitation generation, parameter quantization और coding method में किए गए हैं
- encoder, input signal यानी raw PCM audio लेकर उसे low-frequency band और high-frequency band में बाँटता है
- हर band को अलग से encode किया जाता है, लेकिन बेहतर compression के लिए shared information का उपयोग किया जाता है
- output, range encoder से होकर अतिरिक्त compress होता है और encoded payload तैयार होता है
- decoder, payload लेकर उलटी प्रक्रिया करता है और output audio signal बनाता है
- MLow, split-band optimization के माध्यम से high-frequency band को बहुत कम bits में encode कर सकता है
- इसी संरचना की वजह से यह और कम bitrate पर भी SuperWideBand, यानी 32kHz sampling audio प्रदान कर सकता है
आगे का काम
- MLow, low-end devices पर audio quality को काफी बढ़ाते हुए भी कॉल्स की end-to-end encryption बनाए रखता है
- कम bitrate पर अतिरिक्त audio data को कुशलता से शामिल किया जा सकने के कारण, तेज़ packet loss वाले नेटवर्क में audio recovery सुधारने का काम जारी है
1 टिप्पणियां
Hacker News की राय
नए low-bitrate codecs प्रभावशाली हैं, लेकिन ऐसा लगता है कि जिन ज़्यादातर scenarios में Meta इन्हें इस्तेमाल करना चाहेगा, वहाँ ये वास्तव में बहुत उपयोगी न हों
real-time communication में latency कम रखने के लिए packet transmission frequency काफ़ी ऊँची रखनी पड़ती है, और एक बिंदु के बाद actual payload से ज़्यादा UDP, IP और lower layers का overhead हावी होने लगता है
उदाहरण के लिए UDP/IP पर (S)RTP में RTP कम-से-कम 12 bytes, UDP 8 bytes, और IPv4 20 bytes लेता है, यानी कुल 40 bytes overhead जुड़ता है. अगर 50 packets per second हों, यानी 20ms serialization delay के हिसाब से, तो सिर्फ overhead ही 16kbps हो जाता है
इसे 25 packets per second तक घटाने पर overhead 8kbps हो जाता है, लेकिन फिर भी कुल transmission rate में overhead का हिस्सा बड़ा रहता है
जहाँ ऐसे codecs सच में चमकते हैं, वह है circuit-switched communication जो कुछ satellite phones की तरह लगभग 2kbps इस्तेमाल करता है, या protocol-aware VoIP systems जैसे LTE/5G IMS, जहाँ प्रति frame 40 bytes में से अधिकांश predictable header compression का उपयोग करते हैं
100ms packets latency बहुत बढ़ा देते हैं, लेकिन उस स्तर पर codec की बचत सार्थक होने लगती है. इससे अधिक परिष्कृत systems मौजूदा conditions के अनुसार codec और प्रति packet samples की संख्या को समायोजित कर सकते हैं
जिस system पर मैं काम करता हूँ, उसमें fixed codec और प्रति packet 60ms audio है, इसलिए वह आदर्श नहीं है, लेकिन 20ms packets की तुलना में कम bandwidth पर बहुत बेहतर काम करता है
Meta के forwarding servers का distribution बहुत व्यापक है, इसलिए उसके पास थोड़ा अतिरिक्त sampling delay जोड़ने की गुंजाइश भी है. वह कई ISP के भीतर मौजूद content equipment से forward कर सकता है, इसलिए उन competing services की तुलना में network latency घटा सकता है जिनकी global forwarding hosting capability सीमित है. P2P हर बार काम भी नहीं करता, और न ही वह हमेशा पास के forwarding server से होकर जाने की तुलना में कम latency देता है
खासकर WhatsApp voice messages और calls की हिस्सेदारी उन देशों में काफ़ी है जहाँ network conditions intermittent और unreliable होती हैं. अगर packet loss और jitter के प्रति मज़बूती बढ़े, तो ऐसे protocols पर भी निर्भर हुआ जा सकता है जिनमें error correction, fragmentation और acknowledgement overhead कम हो
यह मानना अनुचित नहीं होगा कि यह तकनीक reliability और perceived quality को बनाए रखते हुए या सुधारते हुए, audio से होने वाली कुल bandwidth खपत को काफ़ी कम कर सकती है
Wireshark में active WhatsApp call देखने पर 1 मिनट की call में sender से receiver तक लगभग 380 UDP packets और WhatsApp server को कुछ TCP packets जाते दिखे. इस हिसाब से transmission overhead लगभग 2.2kbps बनता है
कारण जोड़ूँ तो, यहाँ initial ptime यानी प्रति packet audio size 20ms पर set है, लेकिन maxptime 150ms पर set है. client दोनों तरफ़ की latency और उपलब्ध bandwidth को देखते हुए इसका opportunistically उपयोग करके transmission packets की संख्या घटा सकता है
इमेज: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
radio systems में आम तौर पर इस्तेमाल होने वाले voice codecs जैसे AMBE+2 की sound quality काफ़ी खराब होती है, और नए codecs की तुलना में वे packet loss को भी उतनी सहजता से handle नहीं कर पाते
यह डींग भी हो सकती है, लेकिन यह देखते हुए कि Meta low-bandwidth devices पर voice और video calls देने वाले सबसे बड़े operators में से एक है, इसकी संभावना कम लगती है
मुझे समझ नहीं आता कि यह मानने का आधार क्या है कि Meta इतने समय से बस अपनी ही ग़लतफ़हमी में जी रहा है
उदाहरण के लिए, अगर end-to-end encryption की वजह से server-side mixing नहीं की जा सकती, तो एक ही packet में कई streams का data रखा जा सकता है. end-to-end encrypted audio calls अब काफ़ी आम हो चुकी हैं, और Facebook अपनी products में custom multiplexing करने के लिए अच्छी स्थिति में दिखता है
क्या सिर्फ़ मुझे ही लगता है कि Meta, research और open source, या open weights वाले काम को इतनी मात्रा में साझा करके, फिर से काफ़ी cool लगने लगा है
Facebook की reputation बिल्कुल नीचे जा चुकी थी, लेकिन अब लगता है उसने कुछ हद तक वापसी की है
social network के रूप में Facebook की reputation भले चमकदार न हो, लेकिन engineering company Meta की reputation काफ़ी ऊँची लगती है
यह कुछ हद तक IBM जैसा भी है. hardware या software solutions provider के रूप में वह बहुत शानदार न दिखे, लेकिन research और microelectronics divisions अब भी काफ़ी cool हैं
Microsoft Research भी बहुत कमाल की चीज़ें निकालता है, लेकिन इसका यह मतलब नहीं कि वही Microsoft अपने operating system के Start Menu में ads नहीं दिखाता
कुछ साल पहले teenage में मैंने Microsoft में यह दिलचस्प disconnect देखा था, और Facebook के भीतर zstandard जैसे बढ़िया काम करने वाले divisions के साथ-साथ पूरी तरह अलग goals पर काम करने वाले बिल्कुल अलग लोग भी हों, यह बिल्कुल भी चौंकाने वाली बात नहीं है. शायद सैकड़ों कर्मचारियों से बड़ी अधिकांश companies में departments के बीच ऐसा disconnect होता ही है
लेकिन privacy, security, और social responsibility को लेकर Meta के रवैये के प्रति मैं बहुत नकारात्मक हूँ
CassandraDB और (Py)Torch याद आते हैं
Codec2 का कोई उल्लेख या तुलना बिल्कुल नहीं है, इसलिए इस काम की असली उपयोगिता और प्रेरणा पर तुरंत संदेह होने लगता है
इस क्षेत्र में बौद्धिक संपदा से बंधा हुआ एक और audio codec चाहिए भी नहीं
https://jmvalin.ca/demo/lpcnet_codec/
यह Google Meet के इस्तेमाल वाले सिस्टम से बेहतर है या नहीं, यह जानने की उत्सुकता है
बहुत धीमे इंटरनेट पर, जहाँ यह लगभग इस्तेमाल लायक भी नहीं रहता, वहाँ भी Google Meet ने audio call का काम पूरा कर लिया, जबकि दूसरी प्रतिस्पर्धी सेवाएँ विफल रहीं। उदाहरण के लिए, फ़िलिपींस के एक दूरदराज़ द्वीप पर बहुत खराब इंटरनेट में इसका परीक्षण किया गया था
हालांकि, मेरी जानकारी में Google Meet की तकनीक कहीं भी सार्वजनिक नहीं है
सार्वजनिक किए गए कुछ उदाहरणों को देखकर हम भी बस उतना ही आकलन कर सकते हैं
Pied Piper से भी तुलना नहीं की गई
थोड़ा विषय से हटकर, लेकिन आजकल सामान्य फोन कॉल 90 के दशक की 8kHz 8-bit μ-law और ADPCM की तुलना में समझने में अधिक कठिन क्यों लगती हैं
संपादन: “आवाज़ और खराब है” को बदलकर “समझने में अधिक कठिन है” किया
संगीत के लिए यह अच्छा नहीं, लेकिन आवाज़ के लिए किसी हद तक ठीक है, और सबसे बढ़कर यह बहुत consistent है। 90 के दशक की कॉलों में last mile लगभग पूरी तरह circuit-switched होती थी, और digital circuit में उन्हें sample स्तर पर multiplex किया जाता था। T1 और उससे ऊपर ऐसे ही काम करते थे
इसलिए latency बहुत कम होती थी और jitter शून्य होता था। दोनों सिरों पर analog circuit-switched कॉल की तुलना में मापी जा सकने वाली latency ज़रूर थी, लेकिन व्यवहार में उसे महसूस करना मुश्किल था, और क्योंकि digital sampling दोनों सिरों के पास होती थी, noise भी बहुत कम होता था। Circuit switching का मतलब यह भी था कि sample खोते नहीं थे। या तो कनेक्शन बनता था या नहीं बनता था, हालांकि कभी-कभी सिर्फ एक दिशा में ऑडियो पहुँचता था
आधुनिक कॉल आम तौर पर packet-switched नेटवर्क पर 20ms sample का इस्तेमाल करती हैं, इसलिए sampling latency, jitter, और jitter buffer जुड़ जाते हैं। Codec खुद भी सिर्फ log के साथ ADC/DAC से अधिक काम करता है, इसलिए encoding/decoding latency भी होती है। ज़्यादातर codec, μ-law की तुलना में sample पर बहुत कम bit इस्तेमाल करते हैं, और इसकी कीमत मुफ्त में नहीं मिलती
HD Voice(G.722.2 AMR-Wideband) का frequency passband बहुत बड़ा है, इसलिए यह GSM, Opus, और अधिकांश low-bandwidth codec से कहीं बेहतर सुनाई देता है। फिर भी latency बनी रहती है। कोई कह सकता है कि 20~100ms latency महसूस नहीं होती, लेकिन अगर 0ms और 20ms latency वाली कॉल A/B में सुनाई जाए, तो लोग 0ms वाली कॉल को बेहतर बताएँगे
2013 में मैंने feature phone से iPhone पर बदला था, और फर्क बहुत बड़ा था। उसके तुरंत बाद मुझे earbud या speakerphone इस्तेमाल करना पड़ा, और तब मैं किशोर था
90 के दशक की ज़्यादातर कॉलें ADPCM नहीं, बल्कि साधारण PCM का इस्तेमाल करती थीं। शायद भ्रम वहीं से आया है
और वायरलेस का भी इस्तेमाल नहीं होता था। मेरे माइक्रोफोन से सामने वाले के handset तक ठोस copper wire जुड़ी होती थी। Wireless, यानी mobile phone·Wi‑Fi·cordless phone, मूल रूप से कम विश्वसनीय हैं
पुराने टेलीफोन में sidetone होता था, लेकिन बहुत से VoIP app में यह नहीं होता
अंत में, अब speakerphone का उपयोग बहुत फैल गया है, लेकिन speakerphone sidetone के साथ अच्छी तरह मेल नहीं खाता और audio multipath fading बहुत बढ़ा देता है
NoLACE का उल्लेख नहीं है, इसलिए comparison sample की उपयोगिता थोड़ी कम हो जाती है: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
अगर Meta इसे दुनिया को दान कर दे, तो patent troll की रुकावटें कम होंगी और हम उस भविष्य की ओर बढ़ सकेंगे जिसके हकदार हैं
क्या इसे वास्तव में सार्वजनिक किया जा रहा है, या यह बस engineering शेख़ी है? इस blog post के अलावा MLow के बारे में कोई और reference नहीं मिल रहा
Facebook/Meta AI Research शानदार काम करता है, और उसका काफ़ी हिस्सा सार्वजनिक भी करता है। मुझे Facebook पसंद नहीं, लेकिन AI क्षेत्र में उसके बहुत innovative होने की बात माननी पड़ेगी
लेख में लिखा है, “पिछले 2 वर्षों में नया codec विकसित करने और उसे दुनिया भर के अरबों उपयोगकर्ताओं तक सफलतापूर्वक तैनात करने तक जो उपलब्धियाँ हासिल हुईं, उससे हम बहुत प्रसन्न हैं”
ईमानदार सवाल है, 10kbps से कम के लिए ऑप्टिमाइज़ करने की ज़रूरत क्यों है?
6kbps पर यह स्तर हासिल करना वाकई प्रभावशाली है, लेकिन LTE पहले से ही 32kbps या उससे अधिक सपोर्ट करता है और उस रेंज में AMR-WB या Opus मौजूद हैं। Opus में इस bitrate पर in-band forward error correction भी है, इसलिए packet loss इतना घातक नहीं होता।
direct-to-cell satellite जैसे उपयोग मामलों में यह काम आ सकता है
32kbps से अधिक bandwidth मान लेना एक खराब धारणा है
इस्तेमाल होने वाले audio codec की bitrate कम कर दें तो उसी data plan में महीने भर ज़्यादा देर तक कॉल की जा सकती है।
हालांकि इस क्षेत्र में RTP, UDP, IP overhead की वजह से लाभ घटते जाते हैं। इसकी अधिक जानकारी मैंने एक दूसरे कमेंट में दी है
इस क्षेत्र पर अभी AMBE का क़ब्ज़ा है, और AMBE हर मापे जा सकने वाले मानक पर भयानक है, और इसे इतिहास से मिटा देने लायक मानना चाहिए
अगर आपको फ़ोन कॉल की तरह स्थिर low latency चाहिए, तो हासिल की जा सकने वाली throughput बहुत कम हो जाती है।
उदाहरण के लिए coverage के आख़िरी छोर पर Wi‑Fi या एक-bar signal वाला LTE connection।
ऐसे मामलों में speed test कह सकता है कि कुछ megabits मिल रहे हैं, लेकिन अगर स्थिर low latency चाहिए तो वास्तव में उपयोगी bandwidth शायद kilobits के स्तर की ही होगी
यह G.729 की तुलना में कैसा सुनाई देगा, यह जानने की जिज्ञासा है।
20 साल पहले जिस कंपनी में मैं काम करता था, वहाँ एक modified G.729 codec था जो 8kbps से नीचे जाने पर भी काफ़ी अच्छा सुनाई देता था। इसे dial-up internet पर VoIP के लिए इस्तेमाल किया जाता था, इसलिए bandwidth सचमुच बहुत कम थी।
बाद में पता चला कि अधिक दिलचस्प हिस्सों में से कुछ jitter buffer और buffer management के तरीके थे। अस्थिर कनेक्शन जब संभव हो तभी packets पहुँचाते हैं, और network experience तथा user experience के बीच के अंतर को संभालने के लिए कौशल चाहिए। संचार में user experience को ठीक से प्रबंधित करना ज़रूरी है