| 日時: | 2016-01-23 |
|---|---|
| 作: | @voluntas |
| バージョン: | 0.1.2 |
| url: | https://voluntas.github.io/ |
間違いは Twitter で @voluntas にリプライをいただけると嬉しい。
去年の 2 月頃からリアルタイム動画配信の世界に足を踏み入れた。まだまだ知らない事だらけなのだが、そろそろ一年たつのでまとめることにした。
重点を置くリアルタイム動画配信については WebRTC ベースの話となる、それ以外の話はしない。それ以外の配信については勉強が浅いため、ざっくりとした解説になる。
動画配信には大きく分けて 3 つほど種類があると認識している。
YouTube や Netfilix とか一番目にする配信方式。
これは最初から用意されている動画を配信している、静的な配信。 Nginx とかなんでもいいのだけれど、 配信方式は HLS で配信されることが多い。
HLS 形式なのは iOS アプリが対応しているから。ただ、最近は MPEG-DASH やらなんやら色々でてきている。
YouTube Live や Ustream などほとんどの一方通行な生配信と呼ばれているものはこれにあたる。 twitch もここ。 これは RTMP だったり HLS だったりする。RTMFP が使われているかどうかはわからない。
正直この部分の知識が一番少ない。クライアントから送られてきた動画を一度ファイルに落として、 HLS 形式で CDN に配置する。プレイリストを動的に作る仕組み。
遅延は 10 秒程度。早いと 5 秒とか。
双方向はほとんど行われない。行われたとしてもテキストベース。テキストベースであれば数秒の遅延は致命的にならない。
テレビ会議やビデオチャットで使われる配信方式。FaceTime はここ。
自分が足を突っ込んだのはここ。WebRTC はココに位置する。 配信方式は RTMFP や RTP で、 UDP ベースになる。
遅延は 1 秒未満。
双方向が前提の通信なので、遅延が致命的になる。
静的な動画配信は今回は取り扱わず、ライブ動画配信とリアルタイム動画配信の二つについてまとめていく。
技術的な意味だと全く違う。というのがまず言いたいことだ。はっきり言って要求される技術が全然違う。
ライブ動画配信は大規模な人数に対して生の動画を 遅延を気にせずに配信する 技術だ。ベースが TCP であり、双方向ではなくダウンロードベースになるので、ある程度の人数までなら簡単に保証することができる。
一度動画自体をファイル化する事で、相手に pull させる方式で push 型ではない。ファイルベースのため CDN を使った配信も可能になる。
リアルタイム動画配信は一定人数に対して生の動画を 遅延なく配信する 技術だ。ベースは基本的には UDP 。さらに遅延がないことから、双方向での配信を求められることがほとんどとなる。
UDP をそのまま配信する技術のため、 CDN やキャッシュを使う事はできない。そもそも遅延が許されないので、本当に転送するだけになる。
前述したとおりだが、相手が pull してくれるので、大量ユーザーへの対応が可能となる。また配信社は高画質な動画をサーバに送りつければ、サーバは様々なビットレート形式に変換をすることができる。
YouTube などは画質の異なる形式でのファイルを保存している気がする。トランスコードしてるとは思えない。最初だけトランスコードしてるのかもしれないが。
遅延が許されるため結構好きなことができる。 CDN はとにかく強い。
遅延がほとんど無いこと だけ が強み。それ以外は全ての面で、ライブ配信に劣る。
遅延がある、トランスコードに CPU を使うくらい。ただ今の時代はクラウドもあるので、 CPU を使う事はデメリットではない気がする。
弱いところをあげるときりが無くなってくる。まず一番悲しい話としてはパケロスに弱い。リアルタイム配信では I フレームがパケロスで欠けてしまうと、それ以降の動画が大きく壊れてしまう。
回線品質による解像度の変更をリアルタイムであるため配信側が動画を複数用意するしかなくなる。
一つが高画質と低画質の二つを用意して、サーバが相手をリアルタイムに判断して配信する必要がある。これを Simulcast という。
もう一つは SVC という高画質の中に中画質と低画質を含めてしまい、高画質なデータを送ることでそこから中画質や低画質を切り出してサーバが判断して送るという技術があるが、ここではあまり詳しくは話さない。
まったく違う技術の組み合わせになる。基本は 遅延 を許容できるかどうかになる。まず動画配信をする場合はここがポイントとなる。
普通は遅延を許容 できる ことがほとんどだと思う。ケースとしては 90% 以上は許容可能だろう。許容できないのは双方向な通信だけだ。
何度も行っているが、遅延を許容できない世界は何かというと双方向だ。
WebRTC の話になるが RTC (リアルタイムコミュニケーション) なので、まぁ双方向である。つまり双方向を前提とした所以外で遅延が許されない場面はほとんどないと決めつけてしまって良い。
何かの動画を見ながら手元で操作を行う。といった IoT ライクな話となると遅延が許されない。リモートでのショベルカー操作は遅延が許されないリアルタイム配信だろう。
もちろん監視であればあまりリアルタイム性は求められない。ただ、今後を考えるとリアルタイムな動画を解析して、その場で判断を行うといった要求はでてくると考えている。
先生の講義を配信して、生徒が質問する、その質問が他の生徒にも配信されるというのはやりたいところだろう。
また、困ったら先生に相談するというのも。先生が画面を見ながらアドバイスをするというのも双方向だ。教育には需要がありそうだ。
話し尽くされてるので省略。
話し尽くされてるので省略。
ベースとなる人達が話をしているが、途中から参加者も話しに参加できる方式。 つまり特定の用途までは一方通行だが、突然双方向が入る形式。これは遅延が入るとタイミングがおかしくなる。
トークショウやディベート、パネルディスカッション、遅延のないゲーム実況がここになる。
遅延ありが普通版で、遅延なしは高級品ということで需要があるといえばありそう。数秒が命取りになる世界はありそう、ただパイは少ないだろう。
リアルタイムに解析ができるので、何かに役に立ちそう。ただ遅延を許さない場面はそんなになさそう。
一年触って感じたのはかなり解決はできてない。回線が遅くてパケロスがひどいところでは使い物にならない。
パケロスを回避するというのは難しいわけなのでいろいろな技術が導入されている。
解像度を帯域推定で判断するというのがある。この帯域推定は論文がたくさんあるくらい色々めんどくさい世界。簡単に言えば相手が許容できる帯域を推定して、動的にビットレートを上げたり下げたりする仕組み。
前述もしたが I フレームが欠けると致命的なので、そのための復旧方法がいくつかある。つまりパケロスをどのくらいしているのか、この辺が来ていないことを伝えるなどだ。
また I フレームを再生成を要求するというのもある。ただこれ配信先が 1000 人とかだと I フレーム再生成祭りが起きる可能性もあるので、サーバで吸収する必要がある。
高画質と低画質の動画をクライアントがサーバにおくり、サーバが帯域を判断してどちらを送るか決める方式。良さそうに見えるが判断するのも大変だし、クライアントは最低二種類以上の動画を変換して送る必要があるので負荷は高い。
ベースとなめらかに動作する部分を分ける方式。これを使えばパケロス 10% 程度まで耐えられるとのこと。パテントに守られまくりなので仕様には要注意。
パケロスがかなりひどいと判断した場合はもう動画を送るのをあきらめてしまう。音声だけにする。音声はパケロスに強い。音声のパケットが消えたからと行っても乱れるわけではないので。
リアルタイムな動画配信は UDP を使用するため NAT 越えが必要になる。これは ICE を使用することで解決している。このあたりは全て WebRTC の知識に固定されてしまっている。他の方法をあまりしらない。
ICE は STUN による UDP ホールパンチングを試してみて、ダメだったらサーバがリレーするという方式だ。 UDP と TCP に対応している。
商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。
複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。
パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。
サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分です。
- 大変多くのお客様に採用いただいております
- とにかく 落ちないこと を目的に作っています
- とにかく 繋がること を目的に作っています
- とにかく 手間がかからないこと を目的に作っています
- 最新ブラウザのアップデートに追従しています
- シグナリングサーバ内蔵ですので別途立てる必要はありません
- TURN サーバ内蔵ですので別途立てる必要ありません
- 日本語によるサポート対応しています
- フルスクラッチ自前実装なのですべて把握しています
- 1:1 の双方向に対応しています
- 1:300 の片方向に対応しています
- 3:300 といった配信者が複数の片方向にも対応しています
- スポットライトという機能を利用することで 50 人以上の会議に対応しています
- 録画機能があります
- Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
- Apache 2.0 ライセンスで JavaScript と iOS と Android のクライアント SDK を公開しています
- Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
- 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
- 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます
興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。
紹介や検討資料も公開しております。