Zenn
😺

RTC@Scale2024の要約

2024/05/13に公開
WebRTC
tech

https://atscaleconference.com/events/rtc-scale-2024/

RTC@Scale は、Meta が主催するリアルタイムコミュニケーションに関する技術イベントです。
このタイムテーブルの各セッションの中に、セッション内容をまとめたものがあるので、時間がない方はこちらを読むことをお勧めします。

また、blogeek.me では英語での要約記事も投稿されています。別の視点でのレポートになるため、こちらも興味があれば読んでみてください。
https://bloggeek.me/rtcscale-2024/

Revamping Audio Quality for RTC Part 1: Beryl Echo Cancellation | Sriram Srinivasan and Hoang Do

https://www.youtube.com/watch?v=lapq9zvUd-k&ab_channel=@Scale

このセッションは、WebRTC で使われているエコーキャンセルよりも高性能なエコーキャンセルがテーマになっています。
作成したライブラリは Beryl と呼ばれており、性能比較では 10〜40%ほど向上しているようです。

精度比較では以下の結果が報告されています。1000 以上の音声サンプルで評価されており、最終的なスコアがかなり向上していることが分かります。

beryl_aec_parformance

https://www.youtube.com/watch?v=lapq9zvUd-k&ab_channel=%40Scale より引用

Revamping Audio Quality for RTC: MLow Audio Codec | Sriram Srinivasan, Jatin Kumar, Bikash Agarwalla

https://www.youtube.com/watch?v=3ypsZUNRjI4&ab_channel=@Scale

このセッションは、WebRTC で一般的に使われている音声コーデックである Opus と、最先端な機械学習をベースとした音声コーデック(MLow)の比較について発表されています。
プロトタイプは Julia で書かれ、C/C++へ変換することで C から呼び出せるようにしているようです。

精度評価では、Opus と MLow を比較して、各種ビットレートにおいて体感品質(MOS)がどの程度違うかが示されています。25kbps 以下であれば、常に MLow が上回っています。動画内ではデモもありますが、4.2kbps 程度であっても音声が聞き取れたため、このくらいのビットレートでも実用性がありそうです。

MLow

https://www.youtube.com/watch?v=3ypsZUNRjI4&ab_channel=%40Scale より引用

Improving International Calls | Yi Zhang and Saish Gersappa

https://www.youtube.com/watch?v=PgQMjFcSZuE&ab_channel=@Scale

このセッションは、Meta が国際的な通話における通話品質を向上させるために何を行なったかが発表されています。

映像の中継サーバーでは、パケロスが発生した時に受信者側が NACK パケットを送ることでメディアを再送信させています。
しかし、中継サーバーでメディアパケットを保持しておくことで、送信者側まで NACK パケットを中継することなく再送信が可能である(半分の時間で復旧できる)ということが話されていました。

relays_and_downstream_packet_loss

https://www.youtube.com/watch?v=PgQMjFcSZuE&ab_channel=%40Scale より引用

また、送信者と中継サーバー間でパケロスが発生した場合には、中継サーバーが NACK パケットを送信することで、こちらも高速にメディアの復旧が行えます。

relays_and_upstream_packet_loss

https://www.youtube.com/watch?v=PgQMjFcSZuE&ab_channel=%40Scale より引用

個々のクライアントが、最も近い中継サーバーを選択しそれを繋げることで、NACK パケットをより高速に送信・検知でき、より通話品質を向上させることができます。

さらに、中継サーバー間の通信は Meta のインフラを利用でき、これは公共のインターネット回線よりも安定しています。個々のクライアントが最も近いサーバーを選択することで、公共のネットワーク回線を通る距離をクライアント・中継サーバー間に限定できます。
これによって、安定したネットワーク回線を通る距離が長くなることで通話品質が向上すると発表されています。

cross-relay_routing

https://www.youtube.com/watch?v=PgQMjFcSZuE&ab_channel=%40Scale より引用

これらのアーキテクチャ変更で通話品質が著しく向上したようです。

  • 遅延が 40%低下
  • 利用可能な帯域幅が 5%向上
  • 映像の停止が 15%減少

international_calls_result

https://www.youtube.com/watch?v=PgQMjFcSZuE&ab_channel=%40Scale より引用

Improving Video Quality for RTC | Shyam Sadhwani

https://www.youtube.com/watch?v=zWvteeEkjJg&ab_channel=@Scale

このセッションは、Meta が通話の映像品質を向上させるために行った取り組みについて紹介されています。

Meta のプロダクトを利用しているユーザーは、多くのユーザーが 300kbps 未満の帯域しかないそうです。そのため、高ビットレートな映像を流すことで品質を向上させるアプローチはできません。

  • 25%は 250kbps 未満
  • 50%は 400kbps 未満
  • 95%は 450kbps 未満
    define_as_poor_network

https://www.youtube.com/watch?v=zWvteeEkjJg&ab_channel=%40Scale より引用

映像コーデックの歴史は下図に示されていました。AV1 はリアルタイムコミュニケーション分野において非常に注目されている映像コーデックです。現状では、CPU 使用率の高さがボトルネックになっています。

video_code_history

https://www.youtube.com/watch?v=zWvteeEkjJg&ab_channel=%40Scale より引用

似たように高品質なコーデックとして、H.265 などもあります。H.265 に関する処理は多くのデバイスのハードウェアチップに搭載されており、負荷をチップにオフロードできます。そのため、非常に良い選択肢に見えますが、この H.265 チップは、リアルタイムコミュニケーションにおいてはあまり品質が高くないということが発表されています。

こういった理由から、Meta は AV1 のソフトウェアエンコーダを選択しています。

needs_for_sw_encoder

https://www.youtube.com/watch?v=zWvteeEkjJg&ab_channel=%40Scale より引用

AV1 は、H264 と比較して、PSNR(ピーク信号対雑音比)で 2db ほど上回っており、元の画像を綺麗に再現できていることがわかります。同じ品質では、AV1 は H.264 よりも 30%ほど bitrate を削減できます(下図 BD-Rate 参照)

av1_improvements

https://www.youtube.com/watch?v=zWvteeEkjJg&ab_channel=%40Scale より引用

Enhanced RTC Network Resiliency w/ Long Term Reference & Reed Solomon Code | Fengdeng Lyu & Fan Zhou

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=@Scale

このセッションは、ネットワーク品質が悪い場合に有効なパケットロス対策について、改善を試みた事例が紹介されています。

LTR は、Key Frame に比べて、オーバーヘッドが小さく、より大きなロスを復旧させることができます。
そして、Reed Solomon Code FEC は XOR FEC に比べて、オーバーヘッドが小さく、より大きなロスを復旧させることができます。

ltr_fec

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=%40Scale より引用

従来の仕組みでは、前回のフレームからの差分を送信しますが、この技術では参照フレームが 1 つ前のフレームではなく、少し前のフレームを使用しています。1 つ前のフレームがなければデコードできないため、フレームのロスが許されません。
Long Term Reference は、特定のフレームを LTR フレームとして参照し、LTR フレームを元にエンコードして送信する技術です。そのため、1 つ前のフレームがなくとも LTR フレームがあればデコードできます。

what_is_ltr

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=%40Scale より引用

Keyframe を利用した場合と、LTR を利用した場合では、LTR が PSNR スコアで上回っているとわかります。

ltr_performance

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=%40Scale より引用

また、フレームサイズも LTR-P は削減できています。特に、低ビットレートの際の削減効果が大きいようです。

ltr_performance_size

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=%40Scale より引用

Reed Solomon Code FEC についても発表がありました。

Messenger ではすでに導入済みで、映像や音声のフリーズを 2~3%ほど削減できたようです。従来の XOR FEC よりもパケロス耐性が高く、これによって通話品質が向上されます。

しかし、常に Reed Solomon Code FEC が優れているわけではなく、帯域幅が狭い場合には従来の XOR FEC の方が優れているそうです。これは、従来の XOR FEC は部分的な復旧が可能な一方で、Reed Solomon Code FEC は出来ないためだそうです。

rs_code_fec

https://www.youtube.com/watch?v=GYJgQVxq6SA&ab_channel=%40Scale より引用

The Past and Future of WebRTC, 2024 Edition | Tsahi Levent-Levi

https://www.youtube.com/watch?v=GnGjvWJHPE0&ab_channel=@Scale

このセッションは、WebRTC の歴史について紹介されています。

WebRTC という分野で非常に重要視されている分野の 1 つとして、「Externalize」があります。
WebRTC の内部は複雑な一方で、ブラウザの API などによって、非常にシンプルな API に抽象化されています。一方で、抽象化されていることによって、カスタマイズができないという欠点もあります。
そのため、WebTransport や WebCodecs, WebAssembly, Insertable Streams など、カスタマイズ性を向上させる取り組みが多く行われています。

externalize

https://youtube.com/watch?v=GnGjvWJHPE0&ab_channel=%40Scale より引用

次に重要視されている分野として、「Collaborate」があります。
WebRTC を使った通話の最中に、複数のアプリケーションを操作することがあります。
例えば、PowerPoint を表示しているタブを画面共有する場合、Web ブラウザでは別のタブとの連携は難しく、通話用のタブと PowerPoint 用のタブを行き来することが多々あります。こう言った際に、タブ間の連携性が高まると、UX の向上に繋がります。
現在はセキュリティやプライバシーの観点で議論が残っているため、今後どのような形になるかはわからない状況のようです。

collaborate

https://youtube.com/watch?v=GnGjvWJHPE0&ab_channel=%40Scale より引用

最後に、「Optimize」があります。
WebRTC では、映像は H.264 や VP8、音声では Opus というコーデックが主流ですが、今後は他のコーデックが主流になる可能性もあります。
AV1 は従来の映像コーデックよりも CPU 使用率は高いものの、より高品質な映像で通話が可能になります。(特に、文字に関しては従来のコーデックよりもはるかに綺麗です)
また、Lyra は従来の音声コーデックよりも低い bitrate での通話が可能で、ネットワーク状況が悪い場合に有効です。
音声コーデックは Cisco, Dolby, Microsoft なども独自のコーデックを研究しており、複数のコーデックを WebRTC で利用できるようにする必要があります。(そして、Meta のエンジニアによるセッションでは Meta が開発した MLow という音声コーデックについても言及されました)

optimize

https://youtube.com/watch?v=GnGjvWJHPE0&ab_channel=%40Scale より引用

RTC Observability | Mandeep Deol Ishan Khot

https://www.youtube.com/watch?v=cgcfAedblAs&ab_channel=@Scale

Meta 社内では、Call Dive というエンジニア向けデバッグツールが用意されています。WebRTC では、クライアントログ・サーバーログを含めると非常に多くのログが取得できるため、Call Dive にも非常に多くの情報が表示されています。

CPU 使用率や、充電中かどうかといった端末的な情報も取れているようです。
ブラウザ利用の場合はこう言った端末情報を取るのは難しいですが、Whats App や Messenger はネイティブアプリで提供しているので、こういった情報も取れているのだと思われます。

call_dive

https://www.youtube.com/watch?v=cgcfAedblAs&ab_channel=%40Scale より引用

Open Source from One to At Scale | Sean DuBois

https://www.youtube.com/watch?v=2ZPI5LsqL1c&ab_channel=@Scale

このセッションでは、Pion や LiveKit の開発者、そして WebRTC for the curios の著者でもある Sean 氏が取り組んできた OSS やその経験について発表されています。

WebRTC の技術的な内容は少なかったため割愛しますが、どのように OSS に熱中していったのか、どうやって OSS に関わっていたのかについて興味がある方は見てみることをお勧めします。

ML Based Bandwidth Estimation and Congestion Control for RTC | Liyan Liu and Santhosh Sunderrajan

https://www.youtube.com/watch?v=0FRKp_TWyPs&ab_channel=@Scale

本セッションでは、帯域幅推定に機械学習を採用して得られた結果が発表されています。

実際に機械学習による予測は高い数値を出しています。

bwe_model_performance

https://www.youtube.com/watch?v=0FRKp_TWyPs&ab_channel=%40Scale より引用

そして、この帯域幅推定モデルは Messenger や WhatsApp に導入されています。これにより、映像のフリーズは 2%減少したようです。

bwe_model_result

https://www.youtube.com/watch?v=0FRKp_TWyPs&ab_channel=%40Scale より引用

一緒に WebRTC Platform SkyWay を作る方を募集しています

NTT Com では、ソフトウェアエンジニア・マネージャーを募集しています。ご応募お待ちしております。

https://hrmos.co/pages/nttcom0033/jobs/1692872
https://hrmos.co/pages/nttcom0033/jobs/1692867
https://hrmos.co/pages/nttcom0033/jobs/1692869

Discussion