MLow: Meta’nın düşük bit hızlı ses codec’i
(engineering.fb.com)- Meta, yavaş ağlarda ve eski cihazlarda bile WhatsApp, Instagram ve Messenger’da gerçek zamanlı arama kalitesini korumak için yeni düşük bit hızlı ses codec’i MLow’u geliştirdi
- Mevcut Opus, 6 kbps’de NarrowBand olarak çalıştığı için ses frekanslarını yeterince kapsamakta zorlanıyor; görüntülü arama sırasında ağ kötüleştiğinde sese ayrılan bit hızı daha da azalıyor
- ML tabanlı ses codec’leri düşük bit hızlarında iyi kalite sunabilir, ancak hesaplama maliyetleri yüksek olduğundan çoğu zaman yeni ve yüksek performanslı mobil cihazlara daha uygun oluyor
- MLow, 6 kbps WideBand için POLQA MOS 3.9 ile Opus’un 1.89 değerine göre yaklaşık 2 kat daha yüksek kalite gösteriyor; hesaplama karmaşıklığı ise Opus’tan %10 daha düşük
- Instagram ve Messenger aramalarında şimdiden tamamen uygulanmış durumda; WhatsApp’a da dağıtılıyor. Düşük bit hızlarında FEC’i daha verimli ekleyerek paket kaybı durumlarında ses kurtarma açısından avantaj sağlıyor
Meta neden yeni bir codec geliştirdi
- WhatsApp, Instagram ve Messenger dahil Meta uygulamaları milyarlarca kişiye gerçek zamanlı iletişim (RTC) özellikleri sunuyor
- RTC’de ses ve video codec’leri, yakalanan veriyi sıkıştırıp internet üzerinden ileten ve aramayı gerçek zamanlı tutan temel bileşenlerdir
- Tipik bir aramanın ham sesi 48 kHz örnekleme, 16 bit, mono için 768 kbps’dir; modern codec’ler bunu 25~30 kbps’ye kadar sıkıştırabilir
- Sıkıştırma sürecinde bilgi kaybı nedeniyle kalite düşüşü yaşanabilir; ancak iyi bir codec, ses sinyalinin özelliklerinden ve psikoakustik bilgisinden yararlanarak kalite, bit hızı ve karmaşıklık arasında denge kurar
- Opus, 2012’de yayımlanan yaygın bilinen bir açık kaynak codec’tir ve Meta bugüne kadar RTC gereksinimleri için Opus’u kullanmıştır
Düşük bit hızı ve eski cihazların kısıtları
- Meta’nın büyük ölçekli RTC ortamında, farklı ağ koşullarının arama deneyimine etkisi doğrudan gözlemlenebiliyor
- Aramaların önemli bir bölümü, tamamında veya bazı kısımlarında kötü ağ bağlantısı yaşıyor
- Bant genişliği tahmin modülü (BWE) ağ kalitesini algılar
- Ağ kalitesi kötüleştiğinde, tıkanıklığı önlemek ve ses akışını sürdürmek için codec bit hızını düşürmek gerekir
- Görüntülü aramalarda kötü ağ koşullarında ses için kullanılabilecek pay daha da azalır
- Opus’un en düşük çalışma noktası 6 kbps’dir ve bu durumda NarrowBand modu olan 0~4 kHz aralığında çalışır
- Bu aralık, insan sesinin ürettiği tüm frekansları yeterince yakalayamaz
- Sonuç olarak ses daha az net ve daha az doğal duyulur
- Meta’nın Ekim 2022’de duyurduğu Encodec gibi ML tabanlı ses codec’leri, çok düşük bit hızlarında bile net ses kalitesi sunar
- Ancak hesaplama maliyetleri yüksek olduğundan çoğu zaman yalnızca yüksek performanslı ve pahalı mobil cihazlarda kararlı biçimde çalışır
- Düşük özellikli cihaz kullanıcıları düşük bit hızı koşullarında hâlâ ses kalitesi sorunları yaşar
- Meta aramalarının %20’den fazlası ARMv7 cihazlarda gerçekleşiyor; WhatsApp’ta ise 10 yıldan daha eski cihazlarda her gün on milyonlarca arama yapılıyor
MLow’un performansı ve dağıtım durumu
- Meta, 2021’in sonunda yeni codec geliştirmeye başladı ve yaklaşık 2 yıllık geliştirme ve test sürecinin ardından Meta Low Bitrate audio codec, yani MLow’u duyurdu
- 6 kbps WideBand için kalite POLQA MOS 3.9; bu, Opus’un 1.89 değerinin yaklaşık 2 katı
- Hesaplama karmaşıklığı Opus’tan %10 daha düşük
- MOS (Mean Opinion Score) 1~5 puan ölçeğindeki karşılaştırmada MLow, düşük bit hızı aralığında Opus’a göre büyük üstünlük gösteriyor ve kalite Opus’a kıyasla daha hızlı doygunluğa ulaşıyor
- Instagram ve Messenger aramalarının tamamında şimdiden uygulanmış durumda; WhatsApp’a ise aktif olarak dağıtılıyor
- Daha iyi ses kalitesinin kullanıcı etkileşiminde iyileşmeye yol açtığı da doğrulandı
Paket kaybı durumlarında FEC
- Düşük bit hızında yüksek kaliteli ses kodlanabildiğinde Forward Error Correction (FEC) stratejileri de daha etkili kullanılabilir
- MLow, Opus’a kıyasla daha düşük bit hızlarında bile FEC eklemek için alan bırakır
- Bu özellik, paket kaybı durumlarında ses kalitesini iyileştirmeye yardımcı olur
- Alıcı tarafındaki paket kaybının %30 gibi yüksek olduğu 14 kbps’lik bir durum için örnek karşılaştırma bulunuyor
- Opus bu bit hızında bant içi FEC kodlayamaz
- Opus’un %10 paket kaybında bant içi FEC kodlayabilmesi için en az 19 kbps gerekir
- Bu kısıt, ses kurtarma açısından dezavantaj yaratır
MLow’un iç yapısı
- MLow, geleneksel CELP (Code Excited Linear Prediction) codec kavramını temel alır
- Başlıca iyileştirme noktaları uyarım üretimi, parametre nicemleme ve kodlama yöntemindedir
- Kodlayıcı, giriş sinyali olan ham PCM sesi alıp düşük frekans bandı ve yüksek frekans bandı olarak ayırır
- Her bant ayrı ayrı kodlanır, ancak daha iyi sıkıştırma için paylaşılan bilgilerden yararlanılır
- Çıktı, range encoder’dan geçirilerek ek olarak sıkıştırılır ve kodlanmış payload oluşturulur
- Çözücü, payload’u alıp ters işlemi uygulayarak çıkış ses sinyalini üretir
- MLow, bölünmüş bant optimizasyonu sayesinde yüksek frekans bandını çok az bitle kodlayabilir
- Bu yapı sayesinde daha düşük bit hızlarında bile SuperWideBand, yani 32 kHz örneklemeli ses sunabilir
Sonraki çalışmalar
- MLow, düşük özellikli cihazlarda ses kalitesini önemli ölçüde artırırken aramaların uçtan uca şifrelemesini korur
- Düşük bit hızında yedek sesi verimli biçimde ekleyebildiği için, yoğun paket kaybı yaşanan ağlarda ses kurtarmayı iyileştirme çalışmaları sürüyor
1 yorum
Hacker News görüşleri
Yeni düşük bit hızlı kodekler etkileyici, ancak Meta’nın kullanmak istediği senaryoların çoğunda pratikte çok da faydalı olmayabilir gibi görünüyor
Gerçek zamanlı iletişimde gecikmeyi düşük tutmak için paket gönderim sıklığının epey yüksek olması gerekir ve belli bir noktadan sonra asıl payload’dan çok UDP, IP ve alt katmanların ek yükü baskın hale gelir
Örneğin UDP/IP üzerindeki (S)RTP’de RTP en az 12 bayt, UDP 8 bayt, IPv4 20 bayt olduğundan toplam 40 bayt ek yük oluşur. Saniyede 50 paket, yani 20 ms serileştirme gecikmesi baz alındığında, yalnızca ek yük 16 kbps eder
Saniyede 25 pakete düşürülürse ek yük 8 kbps olur ama yine de toplam aktarım hızında ek yük büyük bir pay kaplar
Bu tür kodeklerin gerçekten parladığı yerler, bazı uydu telefonlarında olduğu gibi yaklaşık 2 kbps kullanan devre anahtarlamalı iletişim ya da LTE/5G IMS gibi çerçeve başına 40 baytın çoğunda öngörülebilir başlık sıkıştırması kullanan, protokol farkındalıklı VoIP sistemleridir
100 ms’lik paketler gecikmeyi çok artırır, ancak o seviyede kodeğin sağladığı tasarruf anlamlı hale gelir. Daha gelişmiş sistemler, mevcut koşullara göre kodeği ve paket başına örnek sayısını ayarlayabilir
Benim uğraştığım sistem sabit kodek ve paket başına 60 ms ses kullanıyor; ideal değil ama 20 ms paketlere göre düşük bant genişliğinde çok daha iyi çalışıyor
Meta’nın iletme sunucularının dağılımı çok geniş olduğu için örnekleme gecikmesini biraz daha artırma lüksü de var. Birçok ISP’nin içine yerleştirilmiş içerik ekipmanlarından iletme yapabildiği için, dünya çapında iletme barındırma kapasitesi daha sınırlı rakip hizmetlere göre ağ gecikmesini azaltabilir. P2P de her zaman çalışmıyor ve her zaman yakındaki bir iletme sunucusundan geçmekten daha düşük gecikme sunmuyor
Özellikle WhatsApp sesli mesajları ve aramaları, kesintili ve güvenilirliği düşük ağ koşullarının bulunduğu ülkelerde ciddi bir paya sahip. Paket kaybına ve jitter’a daha dayanıklı olmak, hata düzeltme, parçalama ve alındı onayı ek yükü daha az olan protokollere dayanmayı da mümkün kılabilir
Bu teknolojinin, güvenilirliği ve algılanan kaliteyi korurken veya iyileştirirken, sesten kaynaklanan toplam bant genişliği tüketimini kayda değer biçimde azaltabileceğini düşünmek gayet makul
Wireshark ile etkin bir WhatsApp aramasına baktığımda, 1 dakikalık arama boyunca göndericiden alıcıya yaklaşık 380 UDP paketi ve WhatsApp sunucularına birkaç TCP paketi gönderildiğini gördüm. Bu durumda aktarım ek yükü yaklaşık 2.2 kbps oluyor
Açıklamak gerekirse burada başlangıç ptime’ı, yani paket başına ses boyutu, 20 ms olarak ayarlanıyor ama maxptime 150 ms olarak ayarlı. İstemci, iki tarafın gecikmesini ve kullanılabilir bant genişliğini dikkate alarak bunu fırsatçı biçimde kullanıp gönderilen paket sayısını azaltabiliyor
Görsel: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Telsiz sistemlerinde yaygın kullanılan AMBE+2 gibi konuşma kodekleri kulağa oldukça kötü geliyor ve yeni kodeklere kıyasla paket kaybını da zarif biçimde ele alamıyor
Palavra da olabilir ama Meta’nın düşük bant genişlikli cihazlarda sesli ve görüntülü arama sunan en büyük işletmecilerden biri olduğu düşünülürse bu pek olası görünmüyor
Meta’nın bunca zaman kendi kendini kandırdığını düşünmek için ne tür bir dayanak olduğunu bilmiyorum
Örneğin uçtan uca şifreleme nedeniyle sunucuda miksleme yapılmaması gereken durumlarda, tek bir pakete birden fazla akışın verisi konabilir. Uçtan uca şifreli sesli aramalar artık oldukça yaygın ve Facebook, kendi ürünlerinde özel çoklama yapabilecek iyi bir konumda gibi görünüyor
Meta, araştırma ve açık kaynak ya da açık ağırlık çalışmalarını bu kadar çok paylaşınca yeniden havalı gelmeye başlayan tek kişi ben miyim
Facebook’un itibarı dibe vurmuştu ama şimdi bunu bir ölçüde telafi etmiş gibi görünüyor
Sosyal ağ olarak Facebook’un itibarı parlak olmayabilir ama mühendislik şirketi Meta’nın itibarı bence oldukça yüksek
Bir bakıma IBM’e de benziyor. Donanım ya da yazılım çözümü sağlayıcısı olarak çok etkileyici görünmeyebilir ama araştırma ve mikroelektronik tarafı hâlâ oldukça havalı
Microsoft Research de gerçekten harika şeyler çıkarıyor ama bu, aynı Microsoft’un işletim sistemi başlangıç menüsünde reklam göstermediği anlamına gelmiyor
Yıllar önce gençken Microsoft’ta bu ilginç ayrışmayı görmüştüm; Facebook içinde zstandard gibi harika işler yapan birimler ile tamamen farklı hedeflere çalışan bambaşka insanların aynı anda bulunması hiç de şaşırtıcı değil. Muhtemelen birkaç yüz kişiyi aşan şirketlerin çoğunda böyle bölümler arası kopukluk vardır
Ama Meta’nın gizlilik, güvenlik ve toplumsal sorumluluk konularındaki tutumuna çok olumsuz bakıyorum
CassandraDB ve (Py)Torch akla geliyor
Codec2 hakkında hiç bahsedilmemiş ya da karşılaştırma yapılmamış; bu da bu çalışmanın gerçek değeri ve motivasyonu konusunda hemen şüphe uyandırıyor
Bu alanda fikri mülkiyetle bağlı bir ses kodeğine daha ihtiyacımız yok
https://jmvalin.ca/demo/lpcnet_codec/
Bunun Google Meet'in kullandığı şeyden daha iyi olup olmadığını merak ediyorum
Google Meet, neredeyse kullanılamayacak kadar kopan yavaş internette bile sesli arama amacını yerine getirdi; diğer rakip hizmetler ise başarısız oldu. Örneğin Filipinler'deki uzak bir adada çok kötü bir internette test ettim
Ancak bildiğim kadarıyla Google Meet'in teknolojisi hiçbir yerde yayımlanmadı
Açıkça paylaşılan birkaç örneğe bakarak biz de ancak aynı ölçüde değerlendirme yapabiliriz
Pied Piper ile de karşılaştırılmamış
Konudan biraz sapıyor ama günümüzde sıradan telefon görüşmelerinin neden 90'lardaki 8kHz 8-bit μ-law ve ADPCM'den daha zor anlaşılır olduğunu merak ediyorum
Düzeltme: “ses daha kötü” ifadesini “anlaşılması daha zor” olarak değiştirdim
Müzik için pek iyi değil ama konuşma için fena sayılmaz ve her şeyden önce çok tutarlıdır. 90'lardaki aramaların son kısmı neredeyse tamamen devre anahtarlamalıydı ve dijital hatlarda örnek bazında çoklanıyordu. T1 ve üstü böyle çalışıyordu
Bu yüzden gecikme çok düşüktü ve jitter sıfırdı. Her iki uçta analog devre anahtarlamalı aramalarla karşılaştırıldığında ölçülebilir bir gecikme vardı ama pratikte fark etmek zordu; ayrıca dijital örnekleme her iki uca yakın yapıldığı için gürültü çok daha azdı. Devre anahtarlama aynı zamanda örneklerin kaybolmaması demektir. Ya bağlantı kurulur ya da kurulmaz; bazen tek yönlü durumlar olabilir
Modern aramalar ise genelde paket anahtarlamalı ağ üzerinde 20ms örnekler kullanır; bu da örnekleme gecikmesi, jitter ve jitter tamponu ekler. Kodeğin kendisi de sadece log eşlikli bir ADC/DAC'ten fazlasını yaptığı için kodlama ve kod çözme gecikmesi vardır. Çoğu kodek, μ-law'a göre örnek başına çok daha az bit kullanır ve bunun bedeli bedava değildir
HD Voice (G.722.2 AMR-Wideband) çok daha geniş bir frekans geçiş bandına sahip olduğu için GSM, Opus ve çoğu düşük bant genişlikli kodekten çok daha iyi duyulur. Yine de gecikme kalır. Birileri 20~100ms gecikmenin hissedilemeyeceğini söyleyebilir ama 0ms ile 20ms gecikmeli görüşmeyi A/B olarak dinletirseniz 0ms olanın daha iyi olduğunu söylerler
2013'te kapaklı telefondan iPhone'a geçtim ve fark çok büyüktü. Hemen kulaklık ya da hoparlörlü görüşme kullanmaya başladım; o zamanlar ergendim
90'lardaki aramaların çoğu ADPCM değil, doğrudan PCM kullanıyordu. Sanırım kafa karışıklığı oradan geliyor
Ayrıca kablosuz da kullanılmıyordu. Benim mikrofonumdan karşı tarafın ahizesine kadar sağlam bir bakır tel uzanıyordu. Kablosuz, yani cep telefonu, Wi‑Fi ve telsiz telefonlar doğası gereği daha az güvenilirdir
Eski telefonlarda sidetone vardı ama birçok VoIP uygulamasında yok
Son olarak artık hoparlörlü görüşme çok yaygın ve hoparlörlü görüşme sidetone ile uyumlu değil, ayrıca çok fazla ses çok yollu sönümleme ekliyor
NoLACE'den bahsedilmemesi karşılaştırma örneklerinin faydasını biraz azaltıyor: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Meta bunu dünyaya bağışlarsa patent trollerinin ayak bağı azalır ve hak ettiğimiz geleceğe geçebiliriz; bu güzel olur
Bunu yayımlıyorlar mı, yoksa sadece mühendislik gösterisi mi? Bu blog yazısı dışında MLow hakkında başka bir referans bulamıyorum
Facebook/Meta AI Research harika işler yapıyor ve bunların önemli bir kısmını yayımlıyor. Facebook'tan hoşlanmıyorum ama yapay zeka alanında çok yenilikçi olduğunu kabul etmek gerekir
Yazıda “Son 2 yılda yeni bir kodek geliştirip bunu dünya çapında milyarlarca kullanıcıya başarıyla dağıtmaya kadar elde ettiğimiz başarıdan büyük mutluluk duyuyoruz” deniyor
Dürüst bir soru: neden 10 kbps altı için optimize etmek gerekiyor?
6 kbps'te bunu başarmış olmaları gerçekten etkileyici, ancak LTE zaten 32 kbps ve üstünü destekliyor ve o aralıkta AMR-WB ile Opus var. Opus'un bu bitrate'te bant içi ileri hata düzeltmesi de var, bu yüzden paket kaybı o kadar ölümcül değil.
Uydu-doğrudan-telefona gibi kullanım alanları için faydalı olabilir.
32 kbps üstü bant genişliği olduğunu varsaymak kötü bir varsayım.
Kullanılan ses codec'inin bitrate'ini düşürürseniz, aynı veri paketiyle ay boyunca daha uzun süre konuşabilirsiniz.
Yine de bu alanda RTP, UDP ve IP overhead'i nedeniyle kazanç giderek azalıyor. Ayrıntılar başka bir yorumumda var.
Bu alan şu anda AMBE tarafından domine ediliyor, ama AMBE ölçülebilir her metrikte korkunç ve tarihten silinmek üzere cehennemin en derin alevlerinde yakılması gereken bir şey.
Telefon görüşmesinde olduğu gibi istikrarlı düşük gecikme gerektiğinde, elde edebileceğiniz throughput çok azalır.
Örneğin kapsama alanının sınırındaki Wi‑Fi ya da tek çubuk çeken LTE bağlantısı gibi.
Böyle durumlarda hız testi birkaç megabit gösterse bile, istikrarlı düşük gecikme istiyorsanız gerçekte kullanabileceğiniz bant genişliği muhtemelen kilobit seviyesindedir.
G.729 ile karşılaştırınca nasıl duyulacağını merak ediyorum.
20 yıl önce çalıştığım şirkette, 8 kbps'in altına inse bile oldukça iyi duyulan değiştirilmiş bir G.729 codec vardı. Çevirmeli internet üzerinden VoIP için kullanıyorduk, yani gerçekten çok düşük bant genişliğiydi.
Meğerse daha ilginç kısımlardan bazıları jitter buffer ve buffer yönetiminin nasıl yapıldığıymış. Kararsız bağlantılar paketleri mümkün olduğunda teslim eder ve ağ deneyimiyle kullanıcı deneyimi arasındaki farkı yönetmek için beceri gerekir. İletişimde kullanıcı deneyimini doğru yönetmek gerekir.