- Meta membangun codec audio bitrate rendah baru MLow untuk menjaga kualitas panggilan real-time di WhatsApp, Instagram, dan Messenger bahkan pada jaringan lambat dan perangkat lama
- Opus yang ada beroperasi dalam mode NarrowBand pada 6 kbps, sehingga sulit menangkap frekuensi suara secara memadai; saat jaringan memburuk selama panggilan video, bitrate yang dialokasikan untuk audio makin berkurang
- Codec audio berbasis ML dapat menghasilkan kualitas baik pada bitrate rendah, tetapi biaya komputasinya besar sehingga sering kali lebih cocok untuk perangkat mobile modern berperforma tinggi
- MLow mencatat POLQA MOS 3.9 pada 6 kbps WideBand, sekitar 2 kali lebih tinggi dibanding Opus yang 1.89, sementara kompleksitas komputasinya 10% lebih rendah daripada Opus
- MLow sudah diterapkan sepenuhnya pada panggilan Instagram dan Messenger, sedang digulirkan ke WhatsApp, dan menguntungkan untuk pemulihan audio dalam kondisi packet loss karena dapat memasukkan FEC dengan lebih efisien pada bitrate rendah
Mengapa Meta membuat codec baru
- Aplikasi Meta, termasuk WhatsApp, Instagram, dan Messenger, menyediakan fitur real-time communication (RTC) bagi miliaran orang
- Dalam RTC, codec audio dan video adalah komponen inti yang mengompresi data yang ditangkap untuk dikirim melalui internet dan menjaga panggilan tetap berlangsung secara real-time
- Audio mentah untuk panggilan umum adalah 768 kbps dengan sampling 48 kHz, 16-bit, mono; codec modern dapat mengompresnya hingga 25–30 kbps
- Dalam proses kompresi, hilangnya informasi dapat menurunkan kualitas, tetapi codec yang baik memanfaatkan karakteristik sinyal audio dan pengetahuan psikoakustik untuk menyeimbangkan kualitas, bitrate, dan kompleksitas
- Opus adalah codec open source yang dikenal luas dan dirilis pada 2012, dan selama ini Meta menggunakan Opus untuk kebutuhan RTC
Batasan bitrate rendah dan perangkat lama
- Dalam lingkungan RTC Meta berskala besar, dampak berbagai kondisi jaringan terhadap pengalaman panggilan dapat diamati secara langsung
- Banyak panggilan mengalami koneksi jaringan buruk pada seluruh atau sebagian sesi
- Modul estimasi bandwidth (BWE) mendeteksi kualitas jaringan
- Saat kualitas jaringan memburuk, bitrate codec harus diturunkan untuk menghindari kemacetan dan menjaga aliran audio
- Pada panggilan video, ruang yang tersedia untuk audio makin berkurang dalam kondisi jaringan buruk
- Titik operasi terendah Opus adalah 6 kbps, dan pada saat itu ia berjalan dalam mode NarrowBand 0–4 kHz
- Rentang ini tidak cukup menangkap semua frekuensi yang dihasilkan suara manusia
- Akibatnya, suara terdengar kurang jernih dan kurang alami
- Codec audio berbasis ML seperti Encodec yang dirilis Meta pada Oktober 2022 menyediakan kualitas audio yang jernih bahkan pada bitrate sangat rendah
- Namun biaya komputasinya besar, sehingga sering kali hanya dapat berjalan stabil pada perangkat mobile berperforma tinggi dan mahal
- Pengguna perangkat berspesifikasi rendah masih mengalami masalah kualitas audio pada kondisi bitrate rendah
- Lebih dari 20% panggilan Meta dilakukan di perangkat ARMv7, dan di WhatsApp puluhan juta panggilan terjadi setiap hari dari perangkat yang berusia lebih dari 10 tahun
Performa MLow dan status penerapannya
- Meta mulai mengembangkan codec baru pada akhir 2021, dan setelah hampir 2 tahun pengembangan serta pengujian, mengumumkan Meta Low Bitrate audio codec, yaitu MLow
- Pada 6 kbps WideBand, kualitasnya adalah POLQA MOS 3.9, sekitar 2 kali lebih tinggi daripada Opus yang 1.89
- Kompleksitas komputasinya 10% lebih rendah daripada Opus
- Dalam perbandingan skala MOS (Mean Opinion Score) 1–5, MLow menunjukkan keunggulan besar dibanding Opus pada rentang bitrate rendah, dan kualitasnya mencapai titik jenuh lebih cepat daripada Opus
- MLow sudah diterapkan pada seluruh panggilan Instagram dan Messenger, dan sedang aktif digulirkan ke WhatsApp
- Efek kualitas audio yang lebih baik dalam meningkatkan keterlibatan pengguna juga telah terkonfirmasi
FEC dalam kondisi packet loss
- Jika audio berkualitas tinggi dapat dienkode pada bitrate rendah, strategi Forward Error Correction(FEC) juga dapat digunakan dengan lebih efektif
- Dibandingkan dengan Opus, MLow masih memiliki ruang untuk memasukkan FEC bahkan pada bitrate yang lebih rendah
- Karakteristik ini membantu meningkatkan kualitas audio dalam kondisi packet loss
- Ada perbandingan sampel pada 14 kbps ketika packet loss di sisi penerima sangat besar, yaitu 30%
- Opus tidak dapat mengenkode in-band FEC pada bitrate tersebut
- Agar Opus dapat mengenkode in-band FEC pada packet loss 10%, diperlukan minimal 19 kbps
- Batasan ini merugikan pemulihan audio
Struktur internal MLow
- MLow didasarkan pada konsep codec CELP(Code Excited Linear Prediction) tradisional
- Titik perbaikan utamanya ada pada pembangkitan eksitasi, kuantisasi parameter, dan metode coding
- Encoder menerima audio PCM mentah sebagai sinyal input, lalu membaginya menjadi pita frekuensi rendah dan pita frekuensi tinggi
- Setiap pita dienkode secara terpisah, tetapi informasi bersama dimanfaatkan untuk kompresi yang lebih baik
- Output dikompresi lebih lanjut melalui range encoder, lalu payload yang sudah dienkode dihasilkan
- Decoder menerima payload dan melakukan proses sebaliknya untuk membuat sinyal audio output
- MLow dapat mengenkode pita frekuensi tinggi dengan bit yang sangat sedikit melalui optimasi split-band
- Berkat struktur ini, MLow dapat menyediakan SuperWideBand, yaitu audio sampling 32 kHz, bahkan pada bitrate yang lebih rendah
Pekerjaan berikutnya
- MLow meningkatkan kualitas audio secara signifikan pada perangkat berspesifikasi rendah sambil tetap mempertahankan enkripsi end-to-end panggilan
- Karena dapat memasukkan audio redundan secara efisien pada bitrate rendah, pekerjaan untuk meningkatkan pemulihan audio pada jaringan dengan packet loss berat terus berlanjut
1 komentar
Opini Hacker News
Codec bitrate rendah baru memang mengagumkan, tetapi tampaknya mungkin tidak terlalu berguna dalam praktik untuk sebagian besar skenario yang ingin dipakai Meta
Untuk menurunkan latensi dalam komunikasi real-time, frekuensi pengiriman paket harus cukup tinggi, dan mulai titik tertentu overhead UDP, IP, dan lapisan bawah menjadi lebih dominan daripada payload sebenarnya
Misalnya (S)RTP di atas UDP/IP menambahkan overhead total 40 byte: RTP minimal 12 byte, UDP 8 byte, dan IPv4 20 byte. Dengan 50 paket per detik, yaitu latensi serialisasi 20 ms, overhead saja menjadi 16 kbps
Jika dikurangi menjadi 25 paket per detik, overhead menjadi 8 kbps, tetapi tetap mengambil porsi besar dari total laju transmisi
Tempat codec seperti ini benar-benar bersinar adalah komunikasi circuit-switched yang memakai sekitar 2 kbps seperti sebagian telepon satelit, atau sistem VoIP yang sadar protokol dan memakai kompresi header, seperti IMS LTE/5G, di mana sebagian besar 40 byte per frame dapat diprediksi
Paket 100 ms memang menambah latensi secara besar, tetapi pada level itu penghematan dari codec menjadi berarti. Sistem yang lebih canggih dapat menyesuaikan codec dan jumlah sampel per paket berdasarkan kondisi saat ini
Sistem yang saya tangani memakai codec tetap dengan audio 60 ms per paket, jadi tidak ideal, tetapi bekerja jauh lebih baik pada bandwidth rendah dibanding paket 20 ms
Meta memiliki distribusi server penerusan yang sangat luas, sehingga masih punya ruang untuk menambahkan sedikit latensi sampling. Mereka bisa meneruskan lewat perangkat konten yang berada di dalam berbagai ISP, sehingga dapat menurunkan latensi jaringan dibanding layanan pesaing yang kemampuan hosting penerusan globalnya terbatas. P2P juga tidak selalu berfungsi, dan latensinya tidak selalu lebih rendah daripada lewat server penerusan yang dekat
Khususnya pesan suara dan panggilan WhatsApp memiliki pangsa yang cukup besar di negara-negara dengan jaringan yang sporadis dan kurang andal. Jika lebih tangguh terhadap kehilangan paket dan jitter, mereka juga bisa lebih sedikit bergantung pada protokol dengan overhead koreksi kesalahan, fragmentasi, dan acknowledgement penerimaan
Tidak berlebihan untuk melihat teknologi ini sebagai cara yang dapat cukup mengurangi konsumsi bandwidth total dari audio, sambil mempertahankan atau meningkatkan keandalan dan kualitas yang dirasakan
Saat saya melihat panggilan WhatsApp aktif dengan Wireshark, selama panggilan 1 menit ada sekitar 380 paket UDP dari pengirim ke penerima, dan beberapa paket TCP ke server WhatsApp. Dengan begitu overhead transmisinya sekitar 2,2 kbps
Sebagai tambahan alasan, di sini ptime awal, yaitu ukuran audio per paket, disetel ke 20 ms, tetapi maxptime disetel ke 150 ms. Klien dapat memanfaatkannya secara oportunistis dengan mempertimbangkan latensi kedua pihak dan bandwidth yang tersedia untuk mengurangi jumlah paket yang dikirim
Gambar: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Codec suara seperti AMBE+2 yang umum dipakai di sistem radio terdengar cukup buruk, dan dibanding codec baru, juga tidak menangani kehilangan paket secara elegan
Bisa saja itu cuma omong besar, tetapi mengingat Meta adalah salah satu penyedia terbesar panggilan suara dan video pada perangkat bandwidth rendah, kemungkinan itu tampak kecil
Saya tidak tahu apa dasar untuk menganggap Meta selama ini hanya salah paham sendiri
Misalnya, jika server tidak boleh melakukan mixing karena enkripsi end-to-end, data dari beberapa stream dapat dimasukkan ke dalam satu paket. Panggilan audio terenkripsi end-to-end kini sudah cukup luas, dan Facebook tampaknya berada pada posisi yang baik untuk melakukan multiplexing kustom di produknya sendiri
Apakah hanya saya yang merasa Meta kembali terlihat keren karena banyak membagikan riset dan open source, atau pekerjaan dengan bobot terbuka
Reputasi Facebook sempat berada di titik terendah, tetapi sekarang tampaknya sudah cukup memulihkannya
Reputasi Facebook sebagai jejaring sosial mungkin tidak gemilang, tetapi menurut saya reputasi Meta sebagai perusahaan engineering cukup tinggi
Ini agak mirip dengan IBM. Sebagai penyedia solusi hardware atau software mungkin tidak terlihat sangat hebat, tetapi divisi riset dan mikroelektronikanya masih cukup keren
Microsoft Research juga menghasilkan hal-hal yang benar-benar keren, tetapi itu bukan berarti Microsoft yang sama tidak menampilkan iklan di menu Start sistem operasinya
Beberapa tahun lalu saat remaja saya melihat kesenjangan menarik seperti ini di Microsoft, dan sama sekali tidak mengejutkan bahwa di dalam Facebook ada divisi yang mengerjakan hal keren seperti zstandard sekaligus orang-orang yang sepenuhnya terpisah dan bekerja menuju tujuan yang sama sekali berbeda. Mungkin di sebagian besar perusahaan yang sudah melewati beberapa ratus orang, kesenjangan antardivisi seperti ini ada
Namun saya sangat negatif terhadap sikap Meta soal privasi, keamanan, dan tanggung jawab sosial
CassandraDB dan (Py)Torch terlintas di benak saya
Sama sekali tidak ada penyebutan atau perbandingan dengan Codec2, jadi nilai nyata dan motivasi pekerjaan ini langsung terasa meragukan
Ranah ini tidak membutuhkan satu lagi codec audio yang terikat hak kekayaan intelektual
https://jmvalin.ca/demo/lpcnet_codec/
Saya penasaran apakah ini lebih baik dibandingkan yang dipakai Google Meet
Bahkan pada internet lambat yang putus-putus sampai hampir tidak bisa dipakai, Google Meet tetap berhasil mencapai tujuan panggilan audio, sementara layanan pesaing lain gagal. Misalnya, saya mengujinya di internet yang sangat buruk di pulau terpencil di Filipina
Namun sejauh yang saya tahu, teknologi Google Meet tidak dipublikasikan di mana pun
Dari beberapa contoh yang dipublikasikan saja, kita juga hanya bisa menilai sampai sejauh itu
Juga tidak dibandingkan dengan Pied Piper
Sedikit keluar topik, tetapi mengapa panggilan telepon biasa sekarang lebih sulit dipahami dibanding 8kHz 8-bit μ-law dan ADPCM era 90-an
Edit: mengubah “suaranya lebih buruk” menjadi “lebih sulit dipahami”
Tidak bagus untuk musik, tetapi cukup oke untuk suara, dan yang terpenting sangat konsisten. Pada panggilan era 90-an, hampir seluruh segmen terakhirnya adalah circuit switching, dan pada jalur digital dimultipleks per sampel. T1 ke atas bekerja seperti itu
Jadi latensinya sangat rendah dan jitternya 0. Dibanding panggilan circuit-switched analog di kedua ujung, ada latensi yang bisa diukur, tetapi sulit dirasakan dalam praktik, dan karena sampling digital dilakukan dekat kedua ujung, noisenya jauh lebih sedikit. Circuit switching juga berarti sampel tidak hilang. Entah tersambung atau tidak; kadang hanya satu arah yang berfungsi
Panggilan modern biasanya memakai sampel 20ms di atas jaringan packet-switched, sehingga menambah latensi sampling, jitter, dan jitter buffer. Codec-nya sendiri juga melakukan lebih dari sekadar ADC/DAC dengan log, jadi ada latensi encoding dan decoding. Sebagian besar codec memakai bit per sampel jauh lebih sedikit daripada μ-law, dan konsekuensinya tidak gratis
HD Voice (G.722.2 AMR-Wideband) punya pita frekuensi yang jauh lebih lebar, sehingga terdengar jauh lebih baik daripada GSM, Opus, dan kebanyakan codec bandwidth rendah. Meski begitu latensi tetap ada. Ada yang mungkin berkata latensi 20–100ms tidak terasa, tetapi jika panggilan dengan latensi 0ms dan 20ms diperdengarkan secara A/B, orang akan bilang panggilan 0ms lebih baik
Pada 2013 saya beralih dari ponsel lipat ke iPhone dan perbedaannya sangat besar. Saya langsung mulai memakai earbud atau speakerphone, padahal saat itu saya masih remaja
Kebanyakan panggilan era 90-an bukan memakai ADPCM, melainkan PCM biasa. Mungkin dari situlah kebingungannya
Dan juga tidak memakai nirkabel. Dari mikrofon saya ke earpiece lawan bicara ada kabel tembaga yang solid tersambung. Nirkabel—yaitu ponsel, Wi-Fi, telepon nirkabel—pada dasarnya kurang andal
Telepon lama memiliki sidetone, tetapi banyak aplikasi VoIP tidak memilikinya
Terakhir, sekarang penggunaan speakerphone sudah meluas, padahal speakerphone tidak cocok dengan sidetone dan menambahkan banyak multipath fading audio
Karena tidak ada penyebutan NoLACE, kegunaan sampel perbandingannya sedikit berkurang: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Akan bagus jika Meta menyumbangkan ini kepada dunia, sehingga hambatan dari patent troll berkurang dan kita bisa bergerak menuju masa depan yang seharusnya kita nikmati
Apakah ini akan dirilis, atau sekadar pamer rekayasa? Selain tulisan blog ini, saya tidak bisa menemukan referensi lain tentang MLow
Facebook/Meta AI Research melakukan hal-hal keren, dan cukup banyak di antaranya mereka buka. Saya tidak suka Facebook, tetapi bisa mengakui bahwa mereka sangat inovatif di bidang AI
Di tulisan itu tertulis, “kami sangat senang dengan pencapaian selama dua tahun terakhir, mulai dari mengembangkan codec baru hingga berhasil menerapkannya kepada miliaran pengguna di seluruh dunia”
Pertanyaan jujur: mengapa harus dioptimalkan untuk di bawah 10kbps?
Mencapai kualitas seperti ini di 6kbps memang sangat impresif, tetapi LTE pun sudah mendukung 32kbps ke atas, dan di rentang itu ada AMR-WB atau Opus. Opus juga memiliki forward error correction in-band pada bitrate ini, sehingga packet loss tidak terlalu fatal
Mungkin berguna untuk penggunaan seperti direct-to-phone lewat satelit
Mengasumsikan ada bandwidth di atas 32kbps adalah asumsi yang buruk
Jika bitrate codec audio yang digunakan dikurangi, pengguna bisa menelepon lebih lama dalam sebulan dengan paket data yang sama
Namun di area ini, manfaatnya makin menurun karena overhead RTP, UDP, dan IP. Detailnya ada di komentar lain yang saya tulis
Area ini saat ini dikuasai penuh oleh AMBE, tetapi AMBE buruk di semua metrik yang bisa diukur dan pantas dibakar dalam api neraka terdalam hingga terhapus dari sejarah
Jika membutuhkan latensi rendah yang stabil seperti panggilan telepon, throughput yang bisa didapat menjadi sangat kecil
Contohnya Wi-Fi di ujung jangkauan atau koneksi LTE dengan sinyal satu bar
Dalam kasus seperti ini, speed test bisa saja menunjukkan beberapa megabit, tetapi jika menginginkan latensi rendah yang stabil, bandwidth yang benar-benar bisa dipakai mungkin hanya di kisaran kilobit
Saya penasaran seperti apa suaranya jika dibandingkan dengan G.729
Di perusahaan tempat saya bekerja 20 tahun lalu, ada codec G.729 yang dimodifikasi dan tetap terdengar cukup bagus meski turun di bawah 8kbps. Dipakai untuk VoIP di atas internet dial-up, jadi benar-benar bandwidth rendah
Ternyata sebagian hal yang lebih menarik ada pada jitter buffer dan cara pengelolaan buffer. Koneksi yang tidak stabil mengirimkan paket saat memungkinkan, dan dibutuhkan teknik untuk mengelola perbedaan antara pengalaman jaringan dan pengalaman pengguna. Dalam komunikasi, pengalaman pengguna harus dikelola dengan benar