WebRTC SFU Sora ノススメ

日時: 2017-01-14
作: 時雨堂
バージョン: 0.0.0
URL: https://goo.gl/uQVLcq

depth: 3

この資料は 2017 年 1 月 27 日 (金) に行われる WebRTC Meetup Tokyo #13 : ATND の発表資料です。

はじめに

今回の資料はすでに https://goo.gl/uQVLcq に公開されています

@voluntas と申します。時雨堂という少人数の会社で WebRTC SFU を開発をしています。

この発表は WebRTC P2P で最低限 1:1 での双方向配信を実現したことがある方向けです。

今回は WebRTC とは？という基本的な話は Web を調べればいくらでもでてくるためお話しませんので、ご了承ください。

技術よりそもそも WebRTC SFU を利用するとどんなことが実現できるのか、という点を中心にお話させて頂きます。

WebRTC SFU とは

URL: WebRTC SFU Sora

WebRTC は P2P を利用し、クライアント同士で通信する技術ですが、それをサーバ経由にすることで、 P2P では実現しづらい機能を提供する仕組みです。

P2P は 1:1 の通信であればとても良い仕組みなのですが、1:N や 5 人で会議といった実際のビジネスとして良くある場面で利用しようとした場合は、負荷や通信帯域の問題が顕著に出てきます。これらをできるだけ WebRTC の仕組みからぶれること無く、サーバ経由での通信を可能にする技術が SFU です。

WebRTC SFU Sora とは

株式会社時雨堂がフルスクラッチで開発している WebRTC SFU です。シンプルに作っているため多機能ではありません。ただ、ビジネスにリアルタイムな双方向音声映像配信を組み込みたいと考えたときに、できるだけ配信サーバ側をがんばらなくていいいことを目的として作られています。

P2P と比べて何ができるか

P2P にできなくて、SFU にできることはあまりありません。大きな違いは 全てサーバ経由になる ことだけです。

サーバ経由になるため以下のようなことが可能になります。

サーバ経由の映像を、サーバで全て録画する
サーバ側からコーデックやビットレートを指定できる
切断したいクライアントを即サーバ側で切断できる
クライアント側からの配信を複数に送る場合、クライアント側の負荷や通信帯域をサーバが負担する

つまり、サーバ側でコントローラブルな WebRTC になると考えてもらえば大丈夫です。

そもそも実際どんな感じなのか

ここ今回のメインです

注意: 今回のサンプルは全て LTE 経由 でのサンプルになります

これから、いくつかのサンプルをお見せします。 Sora は WebRTC P2P から大きくは変わりません。そのため P2P で利用してきた方であればすぐに利用可能です。

少し違うとしたら、サーバから Offer を送る事です。通常はクライアントから Offer を送り、相手のクライアントから Answer を送りますが、 Sora はサーバ側でコントロールをしたいという考えからサーバ側から Offer を送ります。

サンプル 1:N

1:N で配信者と視聴者がいます。サーバ側が複数人数 (N) に配信するため、配信者側は全員へ配信するといったことが不要になります。

負荷の高い部分を全てサーバに委託するサンプルです。

サンプルマルチストリーム N:M

複数人で会議を行う場合 3~4 人の顔が出てるイメージで、退室したらいなくなるといったイメージだと思います。まさにそれをサーバでコントロールするという実装です。

サンプル録画

1:N での配信している映像を録画するサンプルです。今回は WebRTC SFU Sora を簡単に試してもらえるようにと無償で公開している Anzu というサービスを利用したサンプルです。

サンプル低画質/高画質 1:N

疑似 Simulcast です。 Simulcast とは解像度が異なる映像をサーバに送る事でクライアント側の状況を確認し、帯域に余裕がない場合は低解像度の映像を、帯域に余裕がある場合は高解像度の映像を送るという仕組みです。

ただ、Chrome/Firefox ともに部分的な対応しかしていないため、今回は二つの解像度を配信し、一つは低解像度、もう一つは高解像度といったサンプルをお見せします。

サンプルペイント

現在開発中のため、イベントまでに間に合わない場合はお見せできないかもしれません

WebRTC と Canvas を利用したサンプルです。遠隔系のサービスにはペイント機能を使い送られてきた映像に指示を手で書き込みたい要望が出てくると思います。さらに遠隔系の作業は記録をしておきたいということもあるでしょう。ペイントと映像を別にしてしまうと訳がわからない映像になってしまうため、クライアント側でペイントと映像を合成し、サーバに送る事によってサーバ側に書き込み済の映像が残るといったサンプルです。

サンプルスナップショット

スナップショットはパケットを余り使いたくない人に、定期的に画像だけを送るという仕組みです。定期的な画像＋音声があれば十分な人向けの機能です。

サンプルストリーミング

WebRTC から WebM-DASH を生成して配信する機能です。

サンプル React-Native

こちらのデモは LT にお任せします

React-Native を利用した iOS クライアントによるサンプルです。

React-Native を利用し、 H.264 での配信を iOS から行い、 Chrome で映像を受信します
React-Native を利用し、マルチストリームで複数人数での映像を実現します
- https://github.com/shiguredo/sora-react-native-demos

Sora を利用したマルチストリームの React-Native サンプルコードは GitHub にて公開しております。ただ、 Sora が必須になりますのでご注意ください。

WebRTC SFU Sora のアプリケーション連携

Sora はミドルウェアとしての提供になるため、アプリケーションとの連携が必須になります。 Sora は独自でのデータベース連携などを一切持ち合わせていません。あくまで全ての判断はアプリケーションに判断をさせます。

Sora にはウェブフックを登録する機能が存在します。大きくは認証とイベントの二つがあります。

認証ウェブフック

認証ウェブフックというのは Sora に接続してきたクライアントの認証をウェブフックに登録した URL に送ります。

たとえば、認証ウェブフックに https://example.com/sora/auth と登録した場合、 Sora に新しくクライアントが接続してきたタイミングで、送られてきた JSON を登録した URL に HTTP POST で叩きます。

つまり、認証の判定は Sora では一切行わず、登録した URL で行えます。

クライアントが Sora に送る JSON のサンプル

{
    "type": "connect",
    "role": "upstream",
    "channel_id": "sora",
    "access_token": "FWIAJ7Y124NKD",
    "audio": true,
    "video": {
        "codec_type": "VP9"
    }
}

type: connect はクライアントが接続を開始したい時に送る type です
role: upstream はクライアントが 配信者 として接続したいことを示しています
channel_id は簡単に言えば部屋です。ここでは sora という部屋名で配信することを示しています
access_token は sora は何も見ていません、これは登録したウェブフックの URL にそのまま送られます
- これを利用して、この接続がどんなユーザなのかどうかなどを判定できるようになります
audio: true は音声を利用する(true) ことを示しています
video の codec_type: VP9 は配信する映像コーデックに VP9 を利用することを示しています

Sora が登録された URL に対して POST で送信する JSON

{
    "type": "connect",
    "role": "upstream",
    "channel_id": "sora",
    "client_id": "50d7807a-6744-42bb-a2ae-35d1f50ad594",
    "access_token": "FWIAJ7Y124NKD",
    "audio": true,
    "video": {
        "codec_type": "VP9"
    }
}

client_id は Sora がクライアントに対して動的に付ける ID です

イベントウェブフック

Sora はイベントウェブフックに登録された URL に対して、クライアントの接続、切断や更新、または録画の終了などを通知してきます。

認証 (Authentication)

前述の認証ウェブフックを利用すれば認証が実現できます。

承認 (Authorization)

認証後にそのクライアントに対してどんな動きを許可するかどうかです。現時点では音声とビデオのコーデックや、ビデオのビットレートが指定可能です。

つまりクライアントが指定してきたコーデックなどをサーバ側で上書きすることが可能になります。サーバ側でのコントロール可能です。

課金 (Accounting)

接続時間を気軽に管理することができます。 Sora は接続したクライアントの接続時間を 1 分単位でイベントウェブフックに登録した URL に、それぞれのクライアントの接続経過時間を通知してきます。

つまりアプリケーション側は Sora が通知してくる接続時間を利用し、接続時間課金を行う事ができます。一定時間経過したら切断なども可能です。

WebRTC SFU Sora の導入メリット/デメリット

サンプルを見て頂いてあまり大きく WebRTC から逸脱している感じは無いことを理解して頂けたと思います。

導入メリット

製品なのでデメリットよりメリットが多くないと困るので、できる限り多めに上げておきます。

最新の WebRTC に追従している
- Chrome や Firefox の最新ブラウザの WebRTC の仕様を常に把握しております
- Chrome Canary で動かなくなった場合は緊急のパッチを当ててリリースすることもあります
全て自社開発のためサポートが的確、もちろん日本語でのサポートです
- 1 から全て開発しているため WebRTC の細かい技術も熟知しております
変に機能をゴテゴテさせていないので、シンプルです
サーバコントロールのためクライアント側の作業が P2P と比べて削減できます
ライセンス料金がかなり抑えております
- 機能を抑えていること、自社開発であること、営業を雇っていないことから低いライセンス料金を実現しています
- ライセンス料金は同時 100 接続で 60 万円/年です。お客様からはライセンス料金で驚かれることが多いです
  - 導入事例あり前提のライセンス料金です

導入デメリット

間違いなく ベンダーロックイン です。 WebRTC SFU Sora は OSS ではありませんので、これが一番影響として大きいです。

それ以外によく相談頂くのは以下の内容です。

小さい企業の製品のため、何があるかわからない

お客様からは特にそれ以外は言われないというのが現状です。話を聞いて何か懸念点ありましたら後でこっそり教えてください。

まとめ

WebRTC 部分を自前で頑張るのでは無く、そこはお金で解決することで、それ以外の部分に注力したい人、是非ご相談ください。

連絡先

この資料を見て興味を持った方は是非 sora at shiguredo.jp までご連絡ください。もしくは発表が終わった後、名刺交換させていただければと思います。お気軽にお声がけください。

voluntas/sora.rst