FacebookのQUICを活用したライブ動画用プロトコルRUSHについて

Facebookの方々から「RUSH - Reliable (unreliable) streaming protocol」というプロトコル仕様が、IETFに提出されています。

簡単に眺めていきます。

Facebookとライブ動画

このRUSHはRTMP代替として、クライアント(配信者)のアプリからライブ動画を取り込むためのプロトコルのようです。Facebookではすでに使っているようです。

2018年頃のFacebookのエンジニアブログを見ると、Facebook Liveではクライアント(配信者)からの動画の取り込みに RTMPSを使っていることが紹介されています。おそらく、ココの部分を代替するのでしょう。視聴者へはCDNを通してMPEG-DASHで配信されるようです。
f:id:ASnoKaze:20210715012930j:plain

また、IETFの投稿をみると、Facebookではアプリ及びインフラでこのプロトコルを使用していると述べています (URL)。

IETFでも、Twitchの方やGoogleの方もこの仕様に興味をしています。これから議論が進んでいくところでしょう。

今回は、そんなRUSHについて簡単に仕様を眺めていきます。

クライアントとの通信においてQUICを使うメリットは大きそうです。単純に、トランスポートプロトコルとしてQUICを使うメリットについては、以前書いた記事などを参考ください。その他、QUICのストリーム管理なども以前の記事に解説を譲ります。

RUSH

「RUSH - Reliable (unreliable) streaming protocol」は、ビデオとオーディそれぞれ複数のトラックをQUIC上で送信可能にするプロトコルです。

配信保証に関して制御する仕組みがあります。ライブ動画ですので、遅れてきたデータがもう不要というケースがあります。具体的には、あるビデオフレームが一定時間内に受信できなかった場合は、そのデータの再送を中止する仕組みがあります。

RUSHではこの仕組を実現するために、ビデオフレーム及びオーディオフレーム毎にQUIC双方向ストリームを利用する形になっています。QUICはトランスポートプロトコルとして、ストリーム毎にパケロスやパケットの順番の入れ替わりが考慮されます。ストリームを越えてはパケロスの影響を受けず、届いたパケットから処理を進めることが出来ます。

RUSHではビデオフレームやオーディオフレーム毎に1つストリームを使用するため、遅れてきた不要なビデオフレームやオーディオフレームは再送を中断を実現できます。その時あ、そのストリームをクローズすることになります (なので、片方向ではなく双方向ストリームを使う)。

（なお、上記のような複数QUICストリームを用いるモードをMulti Stream Mode、単一のQUICストリームを用いて全部そこでデータ送信するNormal modeが利用できます。Normal modeでは全てのメディアデータは再送されます）