Screenheroの評判がよさそうなtweetを見かけたのでちょっと調べてみました。画面を共有しての作業、複数のカーソルでの操作、ボイスチャットができるリモートワーク向けツール。PivotalLabsなどで実際にペアプログラミングで使われているようです。

WebRTCを採用してますが、WebRTCは、ビデオ通話、一方通行の画面共有が前提。遅延なくスクリーンを共有して作業する双方向の通信であるScreenheroとは、ユースケースが違うため、いくつかの工夫をしています。

ハイクオリティなサービスにするために、10fps以上を実現し、フル解像度の端末に対応、またフレームのスキップはしないという方針。また、遅延をなくすために、帯域の使用を最小限に抑え、バッファリングはしたくない。

1) VP8をx264に変更

VP8の仕様は、ウェブキャムやストリーミングのようにあらかじめ決められたフレームサイズを前提としている。高解像度の端末での通信だとしても、ビットレートを柔軟に調整してはくれない。モーションセンサの機能を止めたりしてみたが、我慢できる程度になるまで、様々な工夫が必要。

x264の場合は、quantizer（画質劣化度）をかなり上げていっても、しっかりビットレートを調整してくれる。フレームをスキップしない。イントラ更新の機能のおかげで、ビットレートを適度に保ち、キーフレームを送ることができる。VP8はUDPパケットを一つでも失うと、デコーディングを諦める。x264はデコードを続けてくれる。x264がフレームレートを安定させやすいが、VP8は突然のスパイクが頻発する。

2) ジッターバッファーをNALUAccumulatorに変更

WebRTCのジッターバッファーは、画像再生の中断を最小限に抑えながら遅延時間を可能な限り短縮するようにバッファーサイズを動的に調整する機能。

受取るパケットが途中で欠けていたら、問い合わせして入手できるまで待つが、画像の再生よりも先行してパケットを受取っているのでその時間はある。しかし、もし既に送信済だが受取っていないパケットについて問い合わせすると、リソースの無駄使いになってしまう。

そこで、NALUAccumulatorをつくった。 - 受取ったら各フレームをなるはやでレンダリングする。 - 「バッファー中です。」という表示なんかはしたくないので、遅れるフレームには期限を切る仕様にしている。パケットが揃わないフレームをレンダリングする可能性はある。 - 帯域を浪費しないかたちで、受取っていないパケットの対処をする。パケットを受取ったら、フレームとフレームでの位置のIDを付与する。つまり、リストのリストをつくる。例えば、Wifiや4Gだと、いくつか先のフレームに属するパケットが到着し、そこまで間が抜けている状態になることがある。もし問い合わせすると、リソースの浪費になる。しかし、おそらくそのほとんどはすでに送信済なはずなので、設定した期限がくると、パケットが欠けていたとしてもフレームをレンダリングする。欠けているパケットの問い合わせはスコープを絞って、次にレンダリングされるフレームのパケットのみにしている。また、Forward Error Correction（欠落したパケットを再送信させずに既知の情報で再構築する手法）も使っている。

3) 帯域を推測をSproutに変更

ISPは下りの帯域しか注力しないので、上りの帯域が問題。特に米国からのアップロードは弱い。これがバッファーをしたくない理由。映像の再生だけならば、厳密にリアルタイムである必要はないので、一定時間バッファーをとる設定でよいが、スクリーンを共有しての作業はリアルタイムのリスポンスを期待されるので、バッファーでの遅延は起こせない。よって、現時点でのデータから推測して、能動的に対応しなくてはいけない。また利用可能な帯域は状況により様々。誰かがオフィスで電子レンジ使って、Wifiの電波が突然乱れるかも。よって、ネットワークパフォーマンスの急激な変化にもついていけるようにしなくてはいけない。

WebRTCは、ウェブキャム前提で、30fpsとハードコーディングされている。帯域推測機能は、各フレーム間の時間がどれくらいあるかによってビットレートが過剰か少ないかを判断している。高ビットレートでは不安定で信頼性が低い。数値の調整のペースが遅い。

まだ本番に投入はしてないが、現在試しているのがSprout。送信中の状態のパケットがどれくらいあるかをもとに計算している。正確で、状況の変更にもすばやく対応できる。SkypeやGoogle Hangoutsよりも7x早いと言われている。

#webrtc #screenhero #sprout