Time to video (TTV)
この記事はある程度 WebRTC を理解している人向けです
Time to video (TTV) という指標があります。これは 再生ボタンを押してから、映像が表示されるまでの時間 です。 WebRTC であれば、接続したタイミングで 相手の動画が再生される時間 になります。
そんなの時間かからなくない?って思うかも知れませんが、実はそうでもないです。 この TTV が遅いと、ユーザはストレスを感じてしまうんですよね ...。
WebRTC を利用して映像を表示するまでにはざっくり以下のような手順になります。
- 認証処理
- Offer/Answer のやりとり
- ICE による通信経路の確立
- DTLS による暗号通信の確立
- I フレーム要求を他のクライアントに送信
- I フレームを受信
- 映像が表示される
これらについてそれぞれ簡単に解説していきます。
認証処理
WebRTC 関係ありませんが、サービスであれば基本的に認証は必要です。
認証の仕組みに依存しますが、データベースを引いて送られてきた認証トークンをチェックする仕組みが基本だと思います。
認証処理が遅いサービスは少ないと思いますので、ここがボトルネックになることはそうそうないと思います。
Offer/Answer のやりとり
詳しくは説明しませんが、WebRTC で必要な「双方向の利用できる音声や映像、プロトコル」をやり取るするための仕組みです。
双方向でやりとりをする必要が必ずあります。
プッシュで通知する必要があるため、WebSocket 経由でやりとりすることが多いです。 さらに Offer/Answer で利用する SDP という文字列形式のプロトコルは情報が多いので、クライアント側で必要最低限の情報に削ったりすることもあります。
いろいろなサービスの仕組みについては以下の記事が詳しいです。
Review of Signaling in different WebRTC applications
ICE による通信経路の確立
相手と利用できる経路を探す仕組みです。これが思った以上に時間がかかります。
自分の IP アドレス候補を収集する部分でブロッキングしないようにしたり、いろいろな手法が使われています。
DTLS による暗号通信の確立
暗号化通信です。ECDSA な証明書を利用したりしてパケットサイズを小さくしたりすることで、時間を削減できます。
I フレーム要求を他のクライアントに送信
暗号通信が確立したら次は I フレーム要求です。これを相手に送信することで、相手から I フレームを受信できます。
WebRTC P2P の場合は送らなくても 1:1 なので、問題ないですが WebRTC SFU の場合は必須になります。
I フレームを受信
相手から I フレームを受信してやっと映像を表示する準備が整います。
映像が表示される
確立した通信経路経由で、暗号化されたパケットが送られてきて、それを復号し、I フレームの場合は分割されてくるので、それらを結合して始めて映像が表示されます。
まとめ
WebRTC で映像が表示されるまでは、色々めんどくさいです。ただ TTV はサービスにとってはとても重要なので、指標として TTV というのがあるというのを覚えておいて貰えればと思います。
時雨堂製品の例
おまけ
時雨堂の製品では Time to video をかなり重視しています。ネット環境に依存しますが 50 ミリ秒くらいで映像が表示されます。
Discussion