Zenn
🤩

WebRTC Insertable Media using Streams

2020/11/23に公開
WebRTC
tech

概要

この資料は WebRTC Insertable Streams の仕組みを理解するための資料です。 API の利用方法は解説しません。

まとめ

基本的に学ぶ必要はありません。

期待する読者

WebRTC API に限界を感じているクライアント開発者

WebRTC Insertable Streams とは何か

  • 送信側はエンコード済みの音声や映像を RTP にパケタライゼーションする前にアクセスできるような仕組みです
  • 受信側はエンコード済みの音声や映像を RTP にデパケタライゼーションした後にアクセスできるような仕組みです

エンコード済みとは何か

エンコード済みとは圧縮済みという意味で間違っていません。生の映像データではなく何かしらのコーデックを利用して圧縮している状態です。

  • 音声の圧縮は WebRTC の場合は殆どが Opus を利用しています
  • 映像の圧縮は H.264 / VP8 / VP9 のどれかがほとんどです
    • 今後は H.265 や AV1 がでてくるかもしれません

エンコード済みなので音声や映像を加工するといった仕組みには利用できません。

RTP とは何か

RTP は Real-time Transport Protocol という偉そうな名前のプロトコルです。
歴史はそこそこ古く、最初の RFC は 1996 年です。

音声や映像を相手に運ぶには何かしらの枠組みが必要なので、その枠組という意味で間違っていません。

パケタライゼーションとは何か

RTP は基本的に UDP 上で利用するプロトコルです。UDP の場合は 1 パケット 1200 バイト程度にする必要があります。
なぜ分割する必要があるのかは MTU (Maximum Transmission Unit) とか MSS (Maximum Segment Size) を調べてみてください。

学ぶなら 基礎からわかるTCP/IP　ネットワークコンピューティング入門　第3版 がおすすめです。

たとえば 4K の映像は 1200 バイトには収まりません。つまりもともとのデータを複数のパケットに分割して送る必要があります。
これがパケタライゼーションです。

Insertable Streams APi ではパケタライゼーション前なので 分割前のフレーム に直接触ることができます。

デパケタライゼーションとは何か

パケタライゼーションの逆です。分割されたパケットを揃った状態、つまり結合した状態で触ることができます。
パケロスとかでパケットがなくなることすら気にする必要はありません。

この機能はどのようなものに使うのか

エンコード済みのパケットにアクセスできて何をするのかということですが、現時点ではそんなにありません。

力技で頑張るなら色々がんばれますが、正攻法で行くなら２つくらいです。

  • エンドツーエンドの暗号化
  • メタデータ付与

エンドツーエンドの暗号化とは何か

エンコード済みのパケットを WebRTC 側の暗号化を適用する前に、暗号化してしまうというものです。
WebRTC の音声や映像を扱うメディアチャネルでは DTLS-SRTP というセキュアプロトコル (RTP に対する TLS だと思ってくれて良いです) を利用して暗号化していますが、
これは WebRTC SFU のようなサーバ経由の場合はサーバで一度復号され、再度暗号化されて配信されていきます。
そのため、サーバでは音声や映像を保存することが可能です。

それをさせないのがエンドツーエンドの暗号化です。
サーバが知り得ない鍵を利用して DTLS-SRTP で暗号化される前のデータに暗号化をします。

実際この機能は Google Duo (エンドツーエンド暗号必須) をブラウザ上で利用できるようにするために入った機能といっても過言ではありません。

メタデータ付与とは何か

エンドツーエンドの暗号化はほとんどの人には求められていないのと、
鍵管理の仕組みを実装するのがコストが高すぎるため個人的にはこちらの機能がとてもおすすめです。

この機能はエンコード済みの音声や映像に自由にメタデータを追加してしまうというものです。
例えばですが音声や映像と一緒に表示したい文字列などが入れられます。
音声や映像と同時に文字列が運ばれてタイムスタンプも当たり前ですが一緒なのでズレにくいです。

バイナリであればどんな情報をいれてもいいので、かなり汎用的です。とはいえ用途はかなり限定的でしょう。

今後はどうなるのか

WebRTC Insertable Streams つまりエンコード済みの音声や映像に対するアクセスはこれ以上の発展はほとんどないくらい完成されています。
あとは用途を思いつく人次第というのがありそうです。

MediaStreamTrack Insertable Media Processing using Streams

エンコード前、つまり生のメディアにもアクセスしたいというのがあります。今もできますが、色々めんどくさいというのが現状です。

Chrome M88 で入る可能性があるのが MediaStreamTrack Insertable Media Processing using Streams という技術です。
Insertable Strams API の一種ですが WebRTC API ではなく MediaStreamTrack API に適用されます。

つまり getUserMedia から取得したストリームにキューやタイマーなどを利用することなく Insertable Streams API とほぼ同じような仕組みで気軽にアクセスできます。

これの何が嬉しいかというと音声や映像の加工などが自由に行えるという点です。エンコード前なので WebAssembly などからも触りやすいです。

Chrome M88 で Origin Trial が行われるらしいので、期待して待ちましょう。

資料

これ系の新しい技術はとにかく公式資料を見るのが一番です

WebRTC Insertable Media using Streams

MediaStreamTrack Insertable Media Processing using Streams

Discussion