- Metaは低速ネットワークや旧型デバイスでもWhatsApp、Instagram、Messengerのリアルタイム通話品質を維持するため、新しい低ビットレート音声コーデックMLowを構築した
- 既存のOpusは6 kbpsでNarrowBandとして動作するため、音声周波数を十分に収めにくく、ビデオ通話中にネットワークが悪化すると音声に割り当てられるビットレートはさらに減る
- MLベースの音声コーデックは低ビットレートで高品質を実現できるが、計算コストが大きく、最新の高性能モバイル端末に適している場合が多い
- MLowは6 kbps WideBand基準でPOLQA MOS 3.9と、Opusの1.89より約2倍高い品質を示し、計算複雑度はOpusより10%低い
- InstagramとMessengerの通話にはすでに全面適用されており、WhatsAppにも展開中で、低ビットレートでFECをより効率的に組み込めるため、パケット損失時の音声復元に有利
Metaが新しいコーデックを作った理由
- WhatsApp、Instagram、Messengerを含むMetaのアプリは、数十億人に**リアルタイム通信(RTC)**機能を提供している
- RTCにおいて音声・動画コーデックは、キャプチャしたデータを圧縮してインターネット経由で送信し、通話をリアルタイムに維持する中核コンポーネントである
- 一般的な通話の生オーディオは、48kHzサンプリング、16ビット、モノラル基準で768 kbpsであり、現代のコーデックはこれを25〜30 kbpsまで圧縮できる
- 圧縮過程では情報損失による品質低下が生じうるが、優れたコーデックは音声信号の特性と心理音響の知識を活用し、品質・ビットレート・複雑度の間でバランスを取る
- Opusは2012年に公開された広く知られるオープンソースコーデックであり、MetaはこれまでRTC要件にOpusを使ってきた
低ビットレートと旧型デバイスの制約
- Metaの大規模なRTC環境では、多様なネットワーク条件が通話体験に与える影響を直接確認できる
- かなりの数の通話が、全体または一部区間で悪いネットワーク接続を経験する
- 帯域幅推定モジュール(BWE)がネットワーク品質を検知する
- ネットワーク品質が悪化すると、輻輳を避けて音声ストリームを維持するため、コーデックのビットレートを下げる必要がある
- ビデオ通話では、悪いネットワーク条件下で音声に使える余裕がさらに小さくなる
- Opusの最低動作点は6 kbpsで、このときNarrowBandモードの0〜4kHzで動作する
- この範囲では、人の声が生み出すすべての周波数を十分に捉えられない
- 結果として、音声は明瞭さと自然さに欠けて聞こえる
- 2022年10月にMetaが公開したEncodecのようなMLベースの音声コーデックは、非常に低いビットレートでも明瞭な音質を提供する
- ただし計算コストが大きく、高性能・高価格のモバイル端末でしか安定して動作しないことが多い
- 低性能デバイスの利用者は、低ビットレート条件で依然として音質の問題を経験する
- Metaの通話の20%以上はARMv7デバイスで行われており、WhatsAppでは10年以上前のデバイスで毎日数千万件の通話が発生している
MLowの性能と展開状況
- Metaは2021年末に新コーデックの開発を開始し、ほぼ2年にわたる開発とテストを経て、Meta Low Bitrate audio codec、すなわちMLowを発表した
- 6 kbps WideBand基準の品質はPOLQA MOS 3.9で、Opusの1.89より約2倍高い
- 計算複雑度はOpusより10%低い
- MOS(Mean Opinion Score)の1〜5点尺度で比較すると、MLowは低ビットレート帯でOpusに対して大きな優位を示し、Opusより速く品質が飽和する
- InstagramとMessengerの通話全体にはすでに適用されており、WhatsAppにも積極的に展開中である
- より良い音声品質がユーザーエンゲージメントの改善につながる効果も確認されている
パケット損失時のFEC
- 低ビットレートで高品質音声をエンコードできれば、**Forward Error Correction(FEC)**戦略もより効果的に使える
- MLowはOpusと比べ、より低いビットレートでもFECを組み込む余地がある
- この特性はパケット損失時の音声品質改善に役立つ
- 14 kbpsで受信側のパケット損失が**30%**に達する厳しい状況のサンプル比較がある
- OpusはそのビットレートではインバンドFECをエンコードできない
- Opusが10%のパケット損失でインバンドFECをエンコードするには、最低19 kbpsが必要である
- この制約は音声復元に不利に働く
MLowの内部構造
- MLowは従来の**CELP(Code Excited Linear Prediction)**コーデックの概念を基盤としている
- 主な改善点は、励振生成、パラメータ量子化、コーディング方式にある
- エンコーダは入力信号である生PCM音声を受け取り、低周波帯域と高周波帯域に分ける
- 各帯域は個別にエンコードされるが、より良い圧縮のため共有情報を活用する
- 出力は範囲エンコーダ(range encoder)を経て追加圧縮され、エンコード済みペイロードが生成される
- デコーダはペイロードを受け取り、逆の過程を行って出力音声信号を作る
- MLowは分割帯域最適化によって高周波帯域を非常に少ないビットでエンコードできる
- この構造により、さらに低いビットレートでもSuperWideBand、すなわち32kHzサンプリング音声を提供できる
今後の取り組み
- MLowは低性能デバイスで音声品質を大きく高めつつ、通話のエンドツーエンド暗号化を維持する
- 低ビットレートで余剰の音声データを効率的に組み込めるため、激しいパケット損失が発生するネットワークでの音声復元を改善する作業が継続している
1件のコメント
Hacker News の意見
新しい低ビットレートコーデックは驚くべきものだが、Meta が使おうとしている大半のシナリオでは、実際にはそれほど有用ではないかもしれないように見える
リアルタイム通信で遅延を低く抑えるには、パケット送信頻度をかなり高くする必要があり、ある時点からは実際のペイロードよりも UDP、IP、下位レイヤーのオーバーヘッドが支配的になる
たとえば UDP/IP 上の (S)RTP では、RTP が最小 12 バイト、UDP が 8 バイト、IPv4 が 20 バイトなので、合計 40 バイトのオーバーヘッドが付く。秒間 50 パケット、つまりシリアライズ遅延 20ms の場合、オーバーヘッドだけで 16kbps になる
秒間 25 パケットに減らせばオーバーヘッドは 8kbps になるが、それでも全体の伝送レートに占めるオーバーヘッドの割合は大きい
こうしたコーデックが本当に輝くのは、一部の衛星電話のように 2kbps 前後を使う回線交換通信や、LTE/5G IMS のようにフレームあたり 40 バイトの大半が予測可能なヘッダー圧縮を使う、プロトコルを認識した VoIP システムだ
100ms パケットは遅延をかなり増やすが、そのくらいになるとコーデックによる削減効果に意味が出てくる。より洗練されたシステムなら、現在の条件に応じてコーデックとパケットあたりのサンプル数を調整できる
私が扱っているシステムは固定コーデックで、パケットあたり 60ms の音声なので理想的ではないが、20ms パケットより低帯域でずっとよく動作する
Meta はフォワーディングサーバーの分布が非常に広いため、サンプリング遅延をもう少し追加する余裕もある。複数の ISP 内に置かれたコンテンツ機器からフォワーディングできるので、世界中でのフォワーディングホスティング能力が限られる競合サービスよりネットワーク遅延を減らせる。P2P が常に動作するわけでもなく、近くのフォワーディングサーバーを経由するより常に遅延が低いわけでもない
特に WhatsApp の音声メッセージと通話は、断続的で信頼性の低いネットワーク環境の国々でかなりのシェアを持っている。パケット損失やジッターにより強ければ、誤り訂正、分割、受信応答のオーバーヘッドが少ないプロトコルにも依存できる
この技術は、信頼性と体感品質を維持または改善しながら、オーディオ由来の総帯域消費をかなり減らせると見ても無理はない
Wireshark でアクティブな WhatsApp 通話を見たところ、1 分間の通話で送信者から受信者へ UDP パケットが約 380 個、WhatsApp サーバーへ TCP パケットが数個送信されていた。これなら伝送オーバーヘッドは約 2.2kbps 程度だ
理由を補足すると、ここで開始時の ptime、つまりパケットあたりの音声サイズは 20ms に設定されるが、maxptime は 150ms に設定される。クライアントは双方の遅延と利用可能帯域を考慮し、これを機会的に使って送信パケット数を減らせる
画像: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
無線システムでよく使われる AMBE+2 のような音声コーデックは音がかなりひどく、新しいコーデックに比べてパケット損失にも優雅に対処できない
大げさな宣伝かもしれないが、Meta が低帯域デバイスで音声・ビデオ通話を提供する最大級の事業者の一つであることを考えると、その可能性は低そうだ
Meta がずっと内輪で勘違いしてきたと見る根拠が何なのか分からない
たとえばエンドツーエンド暗号化のためにサーバーでミキシングしてはいけない場合、1 つのパケットに複数ストリームのデータを入れられる。エンドツーエンド暗号化された音声通話は今ではかなり広く普及しており、Facebook は自社製品でカスタム多重化を行うのに良い位置にいるように見える
Meta が研究やオープンソース、あるいは公開重みの取り組みを多く共有するようになって、また格好よくなった感じがするのは私だけだろうか
Facebook の評判は底を打っていたが、今ではある程度取り戻したように見える
ソーシャルネットワークとしての Facebook の評判は輝かしいものではないかもしれないが、エンジニアリング企業 Metaの評判はかなり高いと思う
IBM ともある程度似ている。ハードウェアやソフトウェアソリューションの提供者としては非常に優れているようには見えないかもしれないが、研究部門やマイクロエレクトロニクス部門は今でもかなり格好いい
Microsoft Research も本当に素晴らしいものを出しているが、だからといって同じ Microsoft が OS のスタートメニューに広告を表示しないという意味ではない
数年前、10 代の頃に Microsoft でこうした興味深い乖離を見たし、Facebook の中に zstandard のような素晴らしい仕事をする部門と、まったく別の目標に向かって働く完全に別の人たちが同時に存在するのは少しも驚きではない。おそらく数百人を超える会社の大半には、こうした部門間の乖離があるはずだ
だがプライバシー、セキュリティ、社会的責任に対する Meta の姿勢には非常に否定的だ
CassandraDB と (Py)Torch が思い浮かぶ
Codec2 への言及や比較がまったくないため、この取り組みの実際の価値と動機がすぐに疑わしく見えてくる
この領域に、知的財産権に縛られたオーディオコーデックがもう一つ必要だとは思えない
https://jmvalin.ca/demo/lpcnet_codec/
これが Google Meet で使われているものと比べて優れているのか気になる
ほとんど使いものにならないほど途切れる遅いインターネット環境でも、Google Meet は音声通話という目的を達成できたが、他の競合サービスは失敗した。たとえばフィリピンの離島にある非常に悪いインターネット環境でテストした
ただし Google Meet の技術は、私の知る限りどこにも公開されていない
公開されているいくつかの例だけを見ても、こちらも同じ程度にしか判断できない
Pied Piper とも比較していない
少し話題から外れるが、最近の普通の電話通話が、90年代の 8kHz 8ビット μ-law や ADPCM より聞き取りにくいのはなぜだろう
修正: 「音が悪い」を「聞き取りにくい」に変更
音楽にはあまり向かないが音声にはそれなりに良く、何より非常に一貫している。90年代の通話は最後の区間のほぼすべてが回線交換で、デジタル回線ではサンプル単位で多重化されていた。T1 以上はそういう方式だった
そのため遅延は非常に低く、ジッターは0だった。両端がアナログの回線交換通話と比べれば測定可能な遅延はあるが、実際には感じにくく、両端の近くでデジタルサンプリングするためノイズはずっと少なかった。回線交換はサンプルが失われないことも意味する。接続できるか、できないかのどちらかで、ときどき片方向だけになる場合はある
現代の通話は通常、20ms サンプルをパケット交換網上で使うため、サンプリング遅延、ジッター、ジッターバッファが追加される。コーデック自体も、単にログ特性付きの ADC/DAC 以上のことをするので、エンコード・デコード遅延がある。ほとんどのコーデックは μ-law よりサンプルあたりのビット数がはるかに少なく、その代償は無料ではない
HD Voice（G.722.2 AMR-Wideband）は通過周波数帯域がはるかに広いため、GSM、Opus、大半の低帯域幅コーデックよりずっと良く聞こえる。それでも遅延は残る。20〜100ms の遅延は体感できないと言う人もいるだろうが、0ms と 20ms の遅延の通話を A/B で聞かせれば、0ms の通話のほうが良いと言うはずだ
2013年に折りたたみ携帯から iPhone に替えたが、差はものすごかった。すぐにイヤホンかスピーカーフォンを使うようになったし、当時の私は10代だった
90年代の通話の大半は ADPCM ではなく、単なる PCM を使っていた。おそらくそこで混同しているのだと思う
そして無線も使っていなかった。自分のマイクから相手の受話器まで、しっかりした銅線がつながっていた。無線、つまり携帯電話・Wi-Fi・コードレス電話は本質的に信頼性が低い
昔の電話機には側音（sidetone）があったが、多くの VoIP アプリにはない
最後に、今ではスピーカーフォンの利用が広く普及しているが、スピーカーフォンは側音と相性が悪く、音声のマルチパスフェージングを大きく増やす
NoLACE への言及がないため、比較サンプルの有用性が少し下がる: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Meta がこれを世の中に寄贈してくれれば、特許トロールによる足止めが減り、私たちが享受すべき未来へ移行できるので良いと思う
これは公開するのか、それとも単なるエンジニアリング自慢なのか？ このブログ記事以外に MLow に関する別のリファレンスは見つけられない
Facebook/Meta AI Research は素晴らしい仕事をしており、そのかなりの部分を公開している。Facebook は嫌いだが、AI 分野で非常に革新的であることは認めざるを得ない
記事には「過去2年間で新しいコーデックを開発し、世界中の数十億人のユーザーに成功裏に展開するまでに達成した成果を非常にうれしく思う」と書かれている
率直な疑問なのですが、なぜ 10kbps未満に最適化する必要があるのでしょうか
6kbpsでこの程度を達成したのは本当に印象的ですが、LTEでもすでに32kbps以上をサポートしており、その帯域にはAMR-WBやOpusがあります。Opusはこのビットレートで帯域内前方誤り訂正もあるので、パケットロスがそれほど致命的ではありません
衛星から携帯電話への直接通信のような用途には有用かもしれません
32kbps超の帯域幅があると仮定するのは悪い前提です
使用するオーディオコーデックのビットレートを下げれば、同じデータプランで1か月により長く通話できます
ただしこの領域では、RTP、UDP、IPのオーバーヘッドのために効果は逓減します。詳しくは私が付けた別のコメントにあります
この領域は現在 AMBE ががっちり押さえていますが、AMBEは測定可能なあらゆる指標でひどく、地獄の最も深い炎で焼かれて歴史から消し去られるべきレベルです
電話通話のように安定した低遅延が必要な場合、得られるスループットは非常に小さくなります
例えば、到達範囲ぎりぎりのWi-Fiや、アンテナ1本のLTE接続などです
このような場合、速度測定では数メガビット出ると言われるかもしれませんが、安定した低遅延を求めるなら、実際に使える帯域幅はおそらくキロビット級でしょう
G.729と比べるとどんな音になるのか気になります
20年前に勤めていた会社には、8kbpsを下回ってもかなり良く聞こえる修正版の G.729コーデック がありました。ダイヤルアップインターネット上のVoIPで使っていたので、本当に低帯域でした
どうやら、より興味深い部分の一部はジッタバッファとバッファ管理の方法にあったようです。不安定な接続は可能なときにパケットを届けるものであり、ネットワーク体験とユーザー体験の差を管理するには技術が必要です。通信ではユーザー体験を適切に管理しなければなりません