Create a gist now

Instantly share code, notes, and snippets.

リアルタイム動画配信コトハジメ

リアルタイム動画配信コトハジメ

日時: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

何かの動画を見ながら手元で操作を行う。といった IoT ライクな話となると遅延が許されない。リモートでのショベルカー操作は遅延が許されないリアルタイム配信だろう。

もちろん監視であればあまりリアルタイム性は求められない。ただ、今後を考えるとリアルタイムな動画を解析して、その場で判断を行うといった要求はでてくると考えている。

教育

先生の講義を配信して、生徒が質問する、その質問が他の生徒にも配信されるというのはやりたいところだろう。

また、困ったら先生に相談するというのも。先生が画面を見ながらアドバイスをするというのも双方向だ。教育には需要がありそうだ。

テレビ会議

話し尽くされてるので省略。

テレビ電話

話し尽くされてるので省略。

参加型パネルディスカッション

ベースとなる人達が話をしているが、途中から参加者も話しに参加できる方式。 つまり特定の用途までは一方通行だが、突然双方向が入る形式。これは遅延が入るとタイミングがおかしくなる。

トークショウやディベート、パネルディスカッション、遅延のないゲーム実況がここになる。

監視

遅延ありが普通版で、遅延なしは高級品ということで需要があるといえばありそう。数秒が命取りになる世界はありそう、ただパイは少ないだろう。

動画解析

リアルタイムに解析ができるので、何かに役に立ちそう。ただ遅延を許さない場面はそんなになさそう。

リアルタイム配信の技術的課題の解決方法

一年触って感じたのはかなり解決はできてない。回線が遅くてパケロスがひどいところでは使い物にならない。

パケロスを回避するというのは難しいわけなのでいろいろな技術が導入されている。

帯域推定

解像度を帯域推定で判断するというのがある。この帯域推定は論文がたくさんあるくらい色々めんどくさい世界。簡単に言えば相手が許容できる帯域を推定して、動的にビットレートを上げたり下げたりする仕組み。

復旧

前述もしたが I フレームが欠けると致命的なので、そのための復旧方法がいくつかある。つまりパケロスをどのくらいしているのか、この辺が来ていないことを伝えるなどだ。

また I フレームを再生成を要求するというのもある。ただこれ配信先が 1000 人とかだと I フレーム再生成祭りが起きる可能性もあるので、サーバで吸収する必要がある。

simulcast

高画質と低画質の動画をクライアントがサーバにおくり、サーバが帯域を判断してどちらを送るか決める方式。良さそうに見えるが判断するのも大変だし、クライアントは最低二種類以上の動画を変換して送る必要があるので負荷は高い。

SVC

ベースとなめらかに動作する部分を分ける方式。これを使えばパケロス 10% 程度まで耐えられるとのこと。パテントに守られまくりなので仕様には要注意。

動画をあきらめる

パケロスがかなりひどいと判断した場合はもう動画を送るのをあきらめてしまう。音声だけにする。音声はパケロスに強い。音声のパケットが消えたからと行っても乱れるわけではないので。

NAT 越え

リアルタイムな動画配信は UDP を使用するため NAT 越えが必要になる。これは ICE を使用することで解決している。このあたりは全て WebRTC の知識に固定されてしまっている。他の方法をあまりしらない。

ICE は STUN による UDP ホールパンチングを試してみて、ダメだったらサーバがリレーするという方式だ。 UDP と TCP に対応している。

宣伝

時雨堂:https://shiguredo.jp

WebRTC をベースとしたリアルタイム動画配信サーバを開発しております。興味がある方はご連絡ください。 また WebRTC を使ったリアルタイムなシステムの開発やコンサルなどをお受けすることが可能ですのでご連絡ください。

contact at shiguredo dot jp

リアルタイム動画配信サーバ

WebRTC SFU Sora

WebRTC を使ったリアルタイムな動画配信サーバです。同時に数百人へ遅延 1 秒未満で配信可能です。

次のバージョンでは Multistream にも対応します。

リアルタイム動画配信サービス

WebRTC SFU as a Service Anzu

上記配信サーバを気軽にウェブ上から使えるようにしたサービスです、無料で使用可能です。有償版も今後予定しております。

リアルタイム動画配信ゲートウェイ

WebRTC Gateway Momo

ブラウザ専用と思われがちな WebRTC ですが、ラズパイ2で動作するリアルタイム動画配信ゲートウェイです、ラズパイ2にインストールし、カメラをラズパイにセットするだけで、リアルタイムな動画を配信できるようになります。

リアルタイム動画配信サービスと組み合わせることで、ブラウザを使うこと無く映像を遅延なしで配信することができるようになります。

Anzu と Momo を使って Raspberry Pi 2 から映像を配信をしてみた

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment