投稿日

WebRTCとMedia over QUIC Transportの性能比較

こんにちは、ソラカメチーム エンジニアインターンの八谷（keyboh）です。この記事では、インターンシップ期間中に行った、新興メディアプロトコルMedia over QUIC Transport （MOQT）とWebRTCについて、スループットの出ない環境を想定した映像ストリーミングの性能比較について紹介します。

目的

近年、オンライン会議や各種の動画配信サービスの普及に伴って、動画配信技術が急速に発展しています。特にセルラーなど様々なネットワーク帯域において安定して動画を閲覧できる様各種の対応がされています。理論や数字上様々なネットワーク帯域において良い性能を示すことが知られていますが、一方でサービスを提供する場合には、改善結果をユーザがどの様に感じることができるのかが大切になります。今回の実験では、ネットワーク帯域を変化させた場合の性能はもちろんのこと、配信された動画がユーザにどの様に見えるのかを体験するために、可能な限り実際の環境を模擬して性能比較を行いました。

性能比較の対象として今回選んだのがMOQTとWebRTCです。MOQTはまだ標準化前のプロトコルであり、MOQTは2024年11月現在、ドラフト(標準化前)プロトコルですが、Twitchでの部分的な利用等、一部で使われ始めています。後章で詳しく紹介しますが、MOQTはHLSやDASHなどが持つライブストリーミングにおける遅延の課題を解決することが期待されています。理論的に優れているMOQTと、現状低遅延配信向けのプロトコルとして主流であるWebRTCの両者を比較することで、MOQTが実地的にどの程度パフォーマンスを発揮するのかを検証することがこの実験の目的です。

そもそもMedia over QUIC Transportとは？

MOQTは、2022年からIETFにて議論が進められているプロトコルです。現在、ライブストリーミングにおいてはRTMPとHLSを組み合わせた配信手法、ビデオ会議においては主にWebRTCが用いられますが、QUICの利活用と幅広いユースケースへの対応をもって配信手法の選択肢を増やすべく議論が進んでいます。

プロトコルの柔軟性

MOQTはコンテンツ配信におけるRelay Serverの挙動まで定義したPub/Sub型の包括的なメディアプロトコルです。

図1: MOQTを用いた配信形態とMOQTが定義する範囲

図1にあるように、MOQTはPublisher、Relay Server、Subscriberを含むクライアント・サーバー型を想定して作られています。Publisher/SubscriberとRelay Serverのコミュニケーション、オブジェクトの構造などが定義されていますが、ペイロードの内容自体は意図的に定義されていません。これはプロトコルとしての柔軟性を上げるためで、映像・音声に限らず利用者が望む任意のデータをMOQTの上で運べるようにしているのです。テキストデータやバイナリーデータの送受信も可能かつ、映像・音声データに関してもエンコードとデコードは利用者に任せられ、柔軟なコーデック設定などが可能になります。ブラウザ上でMOQTを利用する場合、映像・音声のエンコードデコード処理はWebCodecsを用いることで簡略化できます。

この柔軟性により、たとえば低スループットでの配信が求められる環境では画質やフレームレートを下げたり、複数映像品質を複数トラックに分けて配信することでAdaptive Bit Rate (ABR)を実現することも可能になります。WebRTCではDatachannelに分けて伝送していたようなテキスト・バイナリーデータも同じコネクション内の別のトラックとして伝送することで優先順位を制御することも可能になるのです。

当然、柔軟性と実装の簡易さはトレードオフの関係にあるわけですが、当初実装の容易さを目指していたlibwebrtcに対して、柔軟性を求めてlibwebrtcの内部に手を入れているようなサービスプロバイダにとっては、このプロトコルが苦痛を解消してくれる可能性を秘めているのです。

QUICを活用した低遅延配信の実現

MOQTのもう一つの特徴として、従来のストリーミングプロトコルと比較して圧倒的な低遅延を実現できる点が挙げられます。

QUICは一つのコネクション内に仮想的に複数のストリームを張ることができます。ストリームには輻輳制御や再送制御の機能があり、TCPのストリームと似通っていますが、TCPと比べると接続確立のコストが非常に低いことがQUICの利点です。

MOQTではこのストリーム確立の容易さを利用して、映像フレーム一つに対して一つのストリームを使って伝送するという実装が可能です（これも自由なペイロードの利点！）。これにより、フレームのエンコードが終わった瞬間に伝送することができ、HLSなど従来のプロトコルにあるような複数フレームをまとめるためのバッファリング遅延が消えるのです。この手法は通常状態で低遅延を実現するだけでなく、ネットワークが混雑している状態でも、Head-of-Line Blocking問題を解消するため、よりリバッファリングの少ない、高品質な映像伝送が可能になります。

MOQTの詳細については、IETFのブログと筆者の個人ブログをご参照ください。

手法

WebRTCの実験環境

  • 配信側クライアント: OpenMomo on Raspberry Pi OS
  • シグナリングサーバー: OpenAyame on Ubuntu 24.04
  • 視聴側クライアント: Mac OS Sonoma, Chrome 128

今回は、Raspberry Pi 4をルーター化し、そこにtcでスループット制限をかけることで実験を行おうと考えました。しかしラズパイを素直にルーター化すると、ラズパイはそこからさらに上位ルーターに接続するため2重NAT問題が発生し、WebRTCはTURN経由になってしまいP2P接続ができません。そこで、ラズパイをブリッジパターンでルーター化し、その上でtcを用いてスループットの制限を行いました。構成としては以下の図2のように、2つのクライアントが、ブリッジルーターと、そのブリッジルーターがつながるルーターの2つを通してP2Pで接続される形になりました。

図2: WebRTCの実験環境（映像伝送時の通信に注目するためシグナリングサーバーは省いています）

商用アプリケーションでWebRTCを利用する場合、SFUなどクライアント・サーバー型の構成が主流ですが、クラウドカメラの場合はカメラとクライアントは1対1で通信を行うため、SFUなどを利用せずにP2Pを利用した通信が最も効率がよくなるため、今回はP2Pで実験を行うことにしました。

MOQTの実験環境

MOQTクライアントについて、実験時、ブラウザ向けの実装はmoq-encoder-playerと筆者の実装であるmedia-over-quic-experimentのみ公開されていました。そのためカスタマイズ性のために筆者の自前実装を用いています。

WebRTC同様にブリッジルーターを構築しましたが、P2PではなくMOQT Realy Serverを介して映像伝送を行う点が異なります。

図3: MOQTの実験環境

映像品質の統一

WebRTC、MOQTともに伝送する映像の品質は現在のソラカメの高画質設定と同じFull HD(1920×1080)、コーデックはH.264でフレームレートは30fpsに統一しました。コーデックに関して、現在の映像配信市場においてH.264は必ずしも先進的なコーデックではありませんが、配信デバイスとして利用したラズパイがH.264ハードウェアエンコーダーを持っているため採用に至りました。

スループットのレベル分け

今回の実験では2mbps、1mbps、500kbps、300kbpsの4つのスループットにレベル分けをして比較を行いました。tcライブラリを用いてrate、ceilを各スループットに設定し、burstの値についてはこちらの記事を参考にスループット/HZの値を設定しています。

一般的に、4G/LTE以上の通信システムであれば数十Mbpsを超える性能が期待されますが、ネットワークが混雑している状況では今回の実験で制限するようなスループットまで落ち込むことも考えられます。今回はモバイル通信かつネットワークが不安定な状況を想定して実験を行いました。

パケットキャプチャ

両プロトコルについて、上でレベル分けしてスループットそれぞれについて60秒間映像伝送を行い、それをtcpdumpでキャプチャしました。図4に示すように、キャプチャした点はMOQTは4点、WebRTCはP2Pであるため2点です。

図4: MOQTおよびWebRTCにおけるパケットキャプチャのポイント

MOQTについては、P1からP2のパケット数の差分、P3からP4のパケット数の差分を測ることで上りと下りそれぞれのパケットロス率を測ることができます。またWebRTCについてもP1からP4のパケット数の差分を測ればパケットロス率が分かります。

ブラウザによる輻輳制御アルゴリズムの制約

先にも述べた通り、今回の実験は最終的に伝送された映像をブラウザ上に表示し、その遅延や映像品質を比較することがゴールです。プロトコルの性能を測る上で輻輳制御アルゴリズムの選択は重要な要素の1つですが、今回検証用ブラウザとして利用したChrome 128では、2024年9月時点でWebTransportの輻輳制御アルゴリズムの選択オプションが実装されていません。

仕様上、WebTransportではロスベースの”low-latency”、遅延ベースの”throughput”の2種類のアルゴリズムを選択できることになっていますが、この仕様を実装しているのは現状Firefoxのみです。一方、Firefoxは今回のストリーミング検証時に使用するMediaStreamTrackProcessorをサポートしていません。それを踏まえて、今回はChromeを利用し、輻輳制御アルゴリズムに関してはデフォルトの”throughput”を使用します。本来映像ストリーミングのような遅延にシビアなアプリケーションではロスベースのアルゴリズムが使われるべきですが、ここでは妥協します。

結果と考察

まずは4つのスループットそれぞれについて伝送されたWebRTC、MOQTの映像を並べて遅延を可視化した映像をご覧いただきます。

2mbps

2mbps-comparison.mp4

1mbps

1mbps-comparison.mp4

500kbps

500kbps-comparison.mp4

300kbps

300kbps-comparison.mp4

遅延について

WebRTCについては2mbpsの時点である程度画質が落ちており、さらにスループットを絞っていくにつれてどんどん画質が低下します。ただ、映像が大きく遅れることはなく、カクつく場面も少ないです。一方、MOQTについては基本画質は変化しませんが、スループットを絞るにつれて遅延がどんどん大きくなっていきます。

この両者の違いについては、輻輳制御アルゴリズムの違いとABRの実装の有無でおおよそ説明がつくかと思います。WebRTCの主要実装であるlibwebrtcは輻輳制御にロスベースと遅延ベースの両者を取り入れたGCCを採用しており、ABRの機能が組み込まれています。これによりスループットが絞られた時に自動で画質を落とし、遅延を最小限に抑えることができます。一方、MOQT、特にWebTransport上のMOQTでは先にも述べたように輻輳制御アルゴリズムは自動的に遅延ベースのものになります。つまり、送信側は遅延の状態を見てフロー制御を行うため、パケットロスは最小限に抑えられますが遅延が増大していくような制御がなされます。また、ABRについてもMOQT自体には組み込まれておらず、アプリ開発者が実装する必要があります。今回はMOQT上にABRの機能を実装していなかったため、画質を自動で落とすような動作にはならず、輻輳制御アルゴリズムの特性も相まって遅延が増大したと考えられます。筆者がもっと頑張っていればMoQTはもっと見栄えが良くなったわけですが、これも先に述べた実装の柔軟性と容易さのトレードオフの問題に帰着します。

とはいえ、WebRTCはP2P通信なのにも関わらず、クライアント・サーバー型でそれに張り合うMOQTの低遅延性は感じていただけたかと思います。実際、スループットを絞った状態だとMOQTの遅延は1秒以上になることも多々ありますが、正常なネットワークで東京都内のサーバーと通信を行うと伝送遅延は20ms程度まで縮めることができました。

スループット実測値の変動とパケットロス率について

それぞれのスループットの両プロトコルについて、tcpdumpでキャプチャした結果が以下です。

2mbps

MOQTWebRTC
実測スループット (kbps)上: 443, 下: 4111342
パケットロス率 (%)00

1mbps

MOQTWebRTC
実測スループット (kbps)上: 462, 下: 474487
パケットロス率 (%)00

500kbps

MOQTWebRTC
実測スループット (kbps)上: 151, 下: 169343
パケットロス率 (%)00

300kbps

MOQTWebRTC
実測スループット (kbps)上: 265, 下: 293231
パケットロス率 (%)00

まずはスループットについて、WebRTCは1mbpsに絞った段階で大幅に実測値が落ちています。これは輻輳制御アルゴリズムが少し過剰に反応して画質を下げた結果と考えられます。その後は上限値に近い値までスループットが出ています。一方、MOQTは最初から実測値が400kbps台と非常に低いです。映像では特に大きな揺らぎやリバッファリングが見られないことを鑑みると、そもそもMOQTの手法であればFull HDの映像を配信してもこれくらいのスループットしか必要ないとも考えられます。その後500kbpsに絞ると一気に実測値は下がり、映像もそれに応じて遅延が増大しています。上述の通りMOQTは遅延ベースの輻輳制御アルゴリズムを用いており、RTTに応じて大幅に映像伝送を抑えるように動作します。なおかつABRの機能を実装していないため画質を落とすこともできず、単純に遅延が増大し映像がカクつくという結果になりました。MOQTの実測スループットが500kbpsの際に大きく落ちている理由については、現在調査中です。

パケットロス率について、これはどちらのプロトコルもどのスループットにおいても0%でした。映像では確かにMOQTはどんどん遅延は増大しているがフレーム自体の抜けは無いように見えます。WebRTCについても、画質が大きく下がっているため、パケットロスが起きていない可能性も十分にあります。また今回は時間の制約上試すことができませんでしたが、tcでスループットを絞る際にバッファサイズを変えれば、おそらくパケットロス率は双方について増加すると考えられます。

結論

映像の様子、実測スループットの値を見るに、筆者のMOQT実装と比べるならばWebRTCの方が狭帯域に向いていると言えます。しかし、MOQTも速度については申し分ないかつ、ベースとなるQUICの輻輳制御の働きも確認できました。さらにMOQTの柔軟性を利用すれば狭帯域向けにチューニングすることも比較的容易におこなえると思われます。今回インターンシップという限られた期間では、実験環境や計測手法に課題が残ったため、今後、商用レベルのMOQT実装が登場した際には再び比較を行いたいと考えています。

インターンの感想

今回は、WebRTC MeetupにてMOQTに関するLTを行った際に声を掛けていただき、それがきっかけでインターンに参加しました。業務内容はかなり私のやりたいことに沿って決めることができ、実験環境の構築や性能の計測手法など、今後の研究活動にもつながる知識を多く得ることができました。また出社時間やミーティングの時間なども柔軟に対応していただき、学生インターンとしてはとても働きやすい環境でした。

なお、ソラコムでは現在冬季のインターンシップを募集しています。セルラーを提供する会社ということもあり、ネットワーク周りの設備や知見は長期休暇を費やしてみる価値が大いにあると思います。興味がある方はぜひ応募してみてください。

― ソラコム 八谷 (keyboh)

media over quick webrtc ソラカメ 映像配信