Open3
WebRTC RtpTransport API 雑感
voluntas概要
WebRTC の Media Transport は色々隠蔽されており、何も考えずにリアルタイムに音声や映像を利用できるようになっている。ただ、隠蔽されていることで、やりたいことができない人も出てきているのは間違いない。
そこででてきたのが、WebRTC で音声や映像を扱う RTP というプロトコルを WebRTC API つまり、ブラウザ上で利用可能にする WebRTC RtpTransport API だ。
ざっくりと WebRTC SFU 開発者 かつ WebRTC SFU 向け SDK 設計者としての感想を書いていく。
voluntasWebRTC RtpTransport API
w3c/webrtc-rtptransport: Repository for the RTPTransport specification of the WebRTC Working Group
ざっと仕様を見ると、あまりにも幅が広すぎるという印象。これ実装終わるのいつなんだろうというお気持ち。
以下、こんなことに使えるよの翻訳と、雑コメント
- カスタム（WASM）コーデックでエンコードし、パケット化して送信する
- Wasm でエンコード/デコードはいいとして、SDP どうするの
- もちろんでコード部分も自前で頑張る必要がある
- ブラウザだけの視点ならいいが、libwebrtc とか考える必要ある
- Encoded Transform APIからフレームを取得し、パケット化して送信する
- Encoded Transform APIからフレームを取得し、カスタムFECを適用して送信する
- カスタム FEC を作れる人がどれだけいるのか
- 受信NACKを監視し、カスタムRTX動作で再送信する
- カスタム RTX が必要な仕組みがどれだけいるのか
- 受信パケットを監視し、NACKが送信されるタイミングをカスタマイズする
- 即座に返さない理由はあまりない
- カスタムジッターバッファ実装を使用してパケットを受信する
- これはあってもいいかもしれない
- エンコードまたはデコードにWebCodecsを使用し、パケット化/デパケット化とカスタムジッターバッファを実装する
- WebCodecs が使えるのは普通に便利なので、結局このために追加してる感が否めない
- パケットを受信し、デパケット化し、Encoded Transformにインジェクトする（EncodedAudioFrame/EncodedVideoFrameのコンストラクタが必要）
- 入ってくるフィードバックおよび/または組み込みの輻輳制御からの推定を監視し、カスタムレート制御を実装する（送信レートが組み込みの輻輳制御によって提供される帯域幅の推定値よりも低い限り）
- Google が提供するレート制御以上のもを提供したい状況がわからない、それもブラウザで
- Encoded Transform APIからフレームを取得し、パケット化し、カスタムメタデータを付加し、送信する
- これはもともと WebRTC Encoded Transform API でできてた
- RtpTransportから帯域幅の見積もりを取得し、ビットレートの割り当てを実行し、 RtpSendersのビットレートを設定する
- カスタムビットレート指定、無理矢理指定したい場合はあるのでこれは悪くない
- RTP/RTCPパケットを1つのPeerConnectionから別のPeerConnectionに転送し、パ ケット全体を完全に制御する(SRTP/CC例外を除く)
- どんだけ大変か ...
voluntasまとめ
- WebRTC RtpTransport API は一般ユーザーが使う仕組みではない
- 使うにはそれ相応の覚悟が必要
- libwebrtc 側でも同様の実装が必要になるため、単純にコストは跳ね上がる
ブラウザ SDK と libwebrtc ベースの SDK に Lyra を組み込んだが、恐ろしいほど大変だった。ML Audio Codec を組み込むという一番シンプルそうな対応でもこれなので、例に挙がっているのを考えると正直体力ある大手が嬉しいくらいにしか見えない。
もちろん Chrome に実装されれば使っていきたいが、libwebrtc との組み合わせを考えると、しんどい気持ちしかない。Firefox と Safari に実装されるのは 2-3 年後だろうから、その頃に使えるといいなくらい。
だったら RTP over WebTransport や MoQT 頑張った方がいいのでは ... ???