はじめに

Chrome M97 から WebTransport が登場しました。
これにより、DATAGRAM を使っての信頼性のない UDP のような通信がブラウザ可能となりました。
すなわち HoL(Head of Line) Blocking の無いリアルタイム通信が可能になります。

前回の記事では MPEGTS を HTTP-Chunked-Transfer で送ってみましたが
HoL の無い形で送れるのであれば、リップシンクもしやすくなるので是非送ってみたい。
せっかく MPEGTS を DATAGRAM で送るのであれば、既存実装と近い形で出来ると理想的です。

であれば、RTP-FEC (ProMPEG) のペイロードを送れば、目的を満たせそうに思えます。
RTP-FEC (ProMPEG) の実装自体は超単純ですので、週末の空き時間に実装してみました。

前提

RTP-FEC (ProMPEG CoP3 #2)

FEC 付きの MPEGTS の送信の事実上の業界基準みたいな、最低限として扱われている規格です。
この規格は SMPTE ST 2022 として標準化されていますが、
RTP-FEC (ProMPEG CoP3 #2) と呼ばれる事が多く、ここでは RTP-FEC (ProMPEG) と呼びます。

内容は単純で、RTP に MPEGTS のペイロードを数パケット入れて、
その内容を R x C の二次元にマッピングして、行、列に FEC を挿入するというものです。
後発の SRT, RIST などの ARQ があるものに比べて、実装が超単純に済むのがメリットです。
(超単純なので、相互接続性の問題がすくないというメリットもあります)

あと ARQ が無い FEC のみであればスケールもしやすいんじゃないかという思惑も少しあります。
(IPTV で使ってるという話を聞いたことがあるので、実際に使えるかも...?)

QUIC-DATAGRAM へのマッピング

今回は RTP や FEC のペイロードをそのまま QUIC-DATAGRAM に載せてみます。
ProMPEG 上では RTP 上に 7 つの TS Packet を載せますが、
QUIC-DATAGRAM では MTU が少ないので 7 パケットを載せられません。
ここでは 6 パケットを QUIC-DATAGRAM に載せてみました。

実装

サーバ側 (配信側)

aioquic を使った RTP-FEC(ProMPEG) の送信側の実装はこちらになります。
(Annex-A, Annex-B はそのうち...)

クライアント側 (受信側)

RTP-FEC(ProMPEG) の受信部分の実装はこちらになります。

自作の webcodecs を使うプレイヤー (zlplayer) に組み込む形で、
WebTransport での DATAGRAM 受信モジュールの作成を行いました。

評価

10 x 10 の 2D-FEC で実際に実験しました。

1% くらいの誤りを混入させた場合では、FEC による誤り訂正によりロスを復元できました。
10% くらいにしたところす、やはり訂正能力が追い付かず、再生に影響が出てしまいます。

まとめ

実際に、MPEGTS を RTP-FEC (ProMPEG) で QUIC-DATAGRAM に載せ、
実際にプレイヤーで超低遅延での再生する所まで実装してみました。
オレオレ仕様で実際に動作する所をみると、自分で決めてるなという、面白さを感じました。

QUIC-DATAGRAM は自由に使えるため、自由度が非常に高く、面白い事ができるので
これを使った様々な独自プロトコルがそのうち大量に出来るのではないかと思っています。

相互互換性が問題になったりしそうですが、それはそれでテックジャイアントが決めた規格や
巨大なプラットフォームがサポートしている送り方が事実上の標準になるのかなと思いました。
(Twitch + IVS がやってる Warp とかが配信の主流になるのかな、とぼんやり考えてます)

あとがき

SMPTE ST-2022-7 を実装できれば、クライアント側でシームレス切り替えができたり
MPEGTS を送るというだけでも、色々と夢は広がります。

SRT over QUIC-DATAGRAM や RIST over QUIC-DATAGRAM などを試してみたい所です。
これができれば、ブラウザ上でライブプレビューなどが楽にできるなという感じがします。