WebRTC と比較した WebTrasnport の現状
定期的にアップデートしていきます
自分の立ち位置
- 商用 WebRTC SFU のプロトコルスタック実装経験あり
- QUIC プロトコルタック実装経験あり
WebTransport への理解
- WebTransport over HTTP/3 の知識はあり
- WebTransport over HTTP/2 の知識はあり
WebRTC 的な利用をする場合の結論
WebTrasnport を WebRTC 的な利用をする視点からの結論です。
WebTransport は WebRTC のような MediaChannel / DataChannel からみたら圧倒的に仕組みが足りてないので、
WebTransport の上にそれらの仕組みを作り込める必要があります。
実際 Media over QUIC のメーリングリストでは RTP over QUIC という話がでているくらいです。
結局メディア専用のプロトコルを自分たちで仕様を決め載せる必要がある。さらにブラウザから利用する場合、
プロトコル処理を自前で用意しなければならず、 WebAssembly などで解決しなければなりません。
すべてが WebRTC が実現していることを WebTransport 上で実現しようとするとあまりにも膨大な時間がかかります。
そもそも iOS / Android 向けのネイティブアプリへの対応はどうするのか、などもあります。
そのため、現時点というか当面は「体力があり、配信ビジネスで成果を出している」企業が利用していく技術です。
WebCodecs はブラウザにしかない
WebRTC には libwebrtc という何でもやってくれるライブラリがありましたが、
WebTransport はあくまで通信経路の技術です。WebCodecs はコーデック処理しかしてくれません。
さらに WebCodecs はブラウザにしか実装されていません。iOS / Android では自前実装が必要です。
デスクトップ系は Electron を使えばなんとかなるでしょう。
Media over QUIC は Warp でほぼ確定
Twitch / Meta / Cisco / Google が Warp という Media over QUIC のプロトコルを WebTransport 上に配信プロトコルを実装しています。
Warp - Live Media Transport over QUIC
Twitch が WebRTC を採用しなかった理由は以下の動画で説明されています。
Luke Curley - Low-Latency Video over QUIC - YouTube.
- レイテンシーを優先しすぎないでほしい
- WebRTC はレイテンシーが最優先のため音声や映像のライブ配信には向いていない
- ストリーム単位で独自の優先順位をつけたい
- WebRTC は凝り固まったプロトコルのため独自の優先順位はつけられない
以上の二つの理由により Warp では QUIC (WebTransport) を採用しています。この選択は間違いないと思います。
WebTransport でできて、WebRTC でできないこと
今のところ独自で何かをするという事以外はありません
- 独自コーデックを採用する
- WebRTC Encoded Transform を利用するという力業はある
- 独自プロトコルを採用する
技術的な知識
WebTrasnport は WebSocket の QUIC 版という認識で特に問題はありません。
QUIC はストリーム単位でしか再送の仕組みはないし、QUIC DATAGRAM 拡張についてはそれすらありません。
メモ
Intel による Webcodecs / WebTransport
Implementing WebTransport and WebCodecs in an Open Source Media Server - YouTube
Discussion