Create a gist now

Instantly share code, notes, and snippets.

Embed
What would you like to do?
時雨堂 WebRTC SFU Sora 開発ログ

時雨堂 WebRTC SFU Sora 開発ログ

日時:2018-05-01
作:時雨堂
バージョン:18.05.0
url:https://sora.shiguredo.jp/

概要

時雨堂 で開発/販売している WebRTC SFU の開発ログです。

WebRTC SFU Sora

興味がある方は sora at shiguredo.jp までご連絡ください

時雨堂ノハナシ

Medium にて WebRTC SFU Sora についての技術的な記事を公開しています。是非覗いてみてください。

https://medium.com/shiguredo/tagged/sora

セミナー

気軽に参加頂けるセミナーも定期的に開催していく予定ですので、興味ある方は是非。

セミナーに興味がある方は sora at shiguredo.jp までご連絡ください。

リアルタイム配信

WebRTC はその名の通り、リアルタイムが強みです。ここでのリアルタイムとは遅延が 1 秒未満を想定しています。 もちろん、回線性能に寄って異なりますができる限り遅延を抑えた配信方式です。

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

SFU

SFU は Selective Forwarding Unit の略で、簡単に言えば SFU と呼ばれるサーバが動画を配信者に変わって複数の視聴者に配信してくれる仕組みです。

SFU は動画を再変換せず配信するため、サーバを経由したとしても遅延を 1 秒未満に抑えることが可能になります。

片方向配信

SFU を利用すれば 1:N の配信を気軽に行う事ができます。

                      / -> WebRTC -> 視聴者
                      / -> WebRTC -> 視聴者
配信者 -> WebRTC -> SFU -> WebRTC -> 視聴者
                      \ -> WebRTC -> 視聴者
                      \ -> WebRTC -> 視聴者

双方向配信

SFU の配信機能を応用することで複数人の配信を一つの PeerConnection で利用することができます。

この機能は「マルチストリーム」と呼ばれています。つまり自分の映像を複数人に配信せず、そこは SFU に任せ、他の人の映像のみを受け取るとい仕組みです。

参加者 A <- (WebRTC) ->     <- (WebRTC) -> 参加者 D
参加者 B <- (WebRTC) -> SFU <- (WebRTC) -> 参加者 E
参加者 C <- (WebRTC) ->     <- (WebRTC) -> 参加者 F

全員がそろってから開始するため、その人の映像や音声は後から設定されます。マルチストリームを利用することで、一つの PeerConnection 上に動的に映像や音声を追加削除する仕組みがマルチストリームです。

クライアントは onaddstream や ontrack 、onremovestream のコールバックを利用し、複数人数での映像音声の仕組みを利用することができます。

参加者の詳細:

         -> 自分 A の映像       (WebRTC) ->
参加者 A <- 他の参加者 B の映像 (WebRTC) <- SFU
         <- 他の参加者 C の映像 (WebRTC) <-

さらに Sora を利用すればこの複数人数の映像を全てサーバサイドで録画することができます。

SFU をもっと詳しく知りたい方向け

WebRTC SFU コトハジメ

ブラウザ対応

最新の Chrome と Firefox には対応済みです。

Edge 対応

プレビュー機能として対応中です

Sora 17.04 から Edge に対応しています。Windows 10 1703 と呼ばれるバージョンの Edge は WebRTC 1.0 に対応しました。 1:N は動作しております。

マルチストリームにはまだ Edge が対応していません。

Safari 対応

プレビュー機能として対応中です

Sora 17.06 から Safari に対応しています。現時点では Safari 11 以降で対応しています。

目的

WebRTC は映像と音声をリアルタイムに配信する仕組みです。ただ P2P の場合は大量の配信を行うことは難しくなります。 そこでサーバを経由することで遅延が少ない状態で配信を 300 人といった規模に対して配信が可能になります。

通常の WebRTC はブラウザとブラウザの間で実現する仕組みですが、サーバサイド WebRTC ではブラウザとサーバの間で WebRTC を実現します。

サーバサイドでの録画を行う場合はサーバサイドでの WebRTC スタックが無ければできません。録画以外にもスター型で WebRTC を繋ぐ場合にも必要です。

サーバでの WebRTC 可能性を探るためにフルスクラッチな WebRTC スタックを開発しています。

WebRTC SFU Sora の特徴

低遅延

WebRTC SFU Sora は低遅延を目的に作られた製品です。遅延は環境にも寄りますが基本的には 1 秒未満です。

Sora サイトのリアルタイム配信デモで是非体験してみてください https://sora.shiguredo.jp/#demo-box

無変換

WebRTC SFU は映像のコーデックなど変換を一切行わないで、複数の視聴者に映像や音声を配信する仕組みです。 変換を行わないため、サーバリソースを節約することが可能です。

さらに Sora は録画も無変換で行います。

サーバ主導

サーバ側がクライアントをコントロールし、サーバ側が色々吸収するため、クライアント側の開発コストが下がります。

またサーバ側でクライアントの切断などをコントロールしやすいため、ビジネス用途に向いています。

サーバでの録画

WebRTC SFU は映像の暗号化をいったんほどいてから配信しているため、サーバ側で映像を保存することが可能になります。

つまり好きなタイミングで配信している映像を保存可能です。

さらに変換せずその流れている映像そのままの画質で保存が可能です。VP8 + Opus または VP9 + Opus さらに H.264 + Opus の三種類形式で動画を保存可能です。

無変換で録画するため、サーバのリソースを配信に集中することができます。またすぐに録画したファイルを見ることができます。

無変換録画体験

Sora の録画機能は WebRTC SFU as a Service Anzuかんたん配信機能 での録画で体験頂けます。

録画したファイルがすぐに利用できることを是非体験してみてください。

マルチストリーム

Firefox と Chrome と Safari に対応済みです

WebRTC では複数の映像を 1 本のセッションで束ねる マルチストリーム が Firefox/Chrome には採用されています。 この マルチストリーム を使うことで複数人からの映像を 1 本にまとめられます。

SFU を使った場合は配信は 1 つですが、視聴は複数になる事があるため、 マルチストリーム と SFU の相性はよく、今後は マルチストリーム が主流になっていくと考えています。

SFU で マルチストリーム を使うと DTLS セッションを 1 本だけ張れば良くなります。WebRTC API の ontrack/onremovetrack イベントを活用することで、参加者の通知を気軽に行えます。

動的にクライアント側の実装がとてもシンプルになります。

実際に Firefox と WebRTC SFU を使った マルチストリーム のデモを動画にしてみました。

Firefox 45 と WebRTC SFU Sora を使った マルチストリーム のデモ - YouTube

詳細は Sora のドキュメント マルチストリーム をご覧ください

マルチストリームの最大参加人数

マルチストリームでの最大参加人数は 12 名です。制限はかかっていないため最大人数は増やすことはできますが、これ以上はクライアント側が耐えられない可能性が高いです。

これ以上を利用する場合はスポットライト機能を検討してください。

ビットレートシェアリング

マルチストリームのビットレート指定は現在マルチストリームに upstream で参加している人数でわった値で配信するという機能です。

たとえばボットレートの指定を 1000kbps にして、そのマルチストリームに 4 名参加している場合、配信する映像のビットレートは 250kbps となります。もし 1 名参加者が減って 3 名になった場合は 333kbps となります。

マルチストリームでは全員で共有する最大で利用可能な配信ビットレートの値を指定することになります。

マルチストリームでの録画

マルチストリームでの録画を実現しました。指定したグループに対しての録画を事前に指定できます。

録画を指定してからその録画有効期限が切れるまでは、そのグループでの映像や音声は自動で録画されるようになります。

この機能を利用することで、気軽に複数人数の録画が可能になります。

さらに録画したファイルの生成が完了したタイミングや、録画が開始されたタイミングでウェブフックから通知がくるため、アプリとの連携が簡単になります。

視聴専用機能

マルチストリームで配信している映像を、映像を配信せず視聴のみで参加することができます。

この機能を使うことで同じチャネルに 4 人が参加して配信をしているのを、他の人がみるという事が可能になります。

4 人の配信を 30 人になどが可能になります

スポットライト機能

現時点では Chrome と Firefox にしか対応していません

この機能を使うことでサーバが配信する映像を「今喋っている人」と「最近喋っていた人たち」のみに制限することができます。

まずはサンプル動画を御覧ください。

スポットライト機能 - YouTube

映像や音声はフェイクを使っておりますが、音声が発生されたタイミングで映像が切り替わっているのが確認できると思います。

この機能は SFU にとってメリットが多いです。SFU であれば実装するしかないというくらいの機能です。

  • 受け取る音声や映像が少なくなることでクライアントの CPU 負荷が減る
  • 受け取る音声や映像が少なくなることでサーバの CPU 負荷が減る
  • 配信していない人の音声や映像の暗号処理を行う必要が無いのでサーバの CPU 負荷が減る
  • 実際に配信する音声や映像が少なくなるので大規模な会議も可能になる

詳細については以下をご覧ください。

WebRTC SFU Sora で大規模会議 – shiguredo – Medium

TURN 機能

Sora は TURN 機能を内蔵しているため、 TURN サーバを別に立てる必要がなくなります。 現時点では TURN-UDP と TURN-TCP に対応しています。今後は TURN-TLS への対応も予定しています。

TURN 機能を内蔵することで TURN 利用時に必須な認証などを全て自動で行ってくれます。また WebRTC 通信自体に認証がかからないため TURN を前提とすることで、よりセキュアに WebRTC を利用することが可能になります。

詳細は Sora のドキュメント TURN 機能 をご覧ください

TURN-TLS 払い出し機能

Sora では TURN-TLS 自体を処理する機能は搭載しません。 TURN-TLS は TURN-TCP の TLS 版です。 この機能は TURN-TLS の urls turns: を払い出すようにする機能です。

実際の TLS の処理は Nginx などを利用して前段で終端して、そのご TURN-TCP に繋ぐという仕組みです。

TCP serverをSSL/TLS化するのに nginx の stream_ssl_module/stream_proxy_module が便利 - たごもりすメモ

Sora では Nginx などを前段において貰うことを前提としています。そのため、 TLS 部分の処理も前段に任せてしまうという方針です。

シグナリング

シグナリングとはクライアントと SFU が WebRTC の通信を始めるために事前にやりとりをするための仕組みです。

どんな映像コーデックを使うのか、音声は配信するのかどうか、などを指定します。認証などもここで行います。

WebRTC でのシグナリングは仕様的には定義されていません。 Sora のシグナリングは WebSocket を利用しています。

WebSocket を使い、内部で JSON 形式での通信を行います。

詳細は Sora のドキュメント シグナリング をご覧ください

シグナリング通知機能

接続してきたクライアントや、切断してきたクライアントの情報をシグナリングを利用している WebSocket 経由でプッシュで通知する仕組みです。

接続時にメタデータをSora に渡しておくことで、プッシュ通知時にそのメタデータを送信します。

この機能を使うことでどの配信が誰の配信かなどを簡単に実現できるようになります。

認証ウェブフック

Sora 自体は認証機能を持っていません。ただし、認証の処理を外部の認証サーバに委譲することができます。

外部への認証は Sora が HTTP 経由で設定に指定されたサーバに問い合わせます。そのため Sora がデータベース連携を行う必要がありません。

詳細は Sora のドキュメント 認証ウェブフック をご覧ください。

認証ウェブフックでの払い出し機能

Sora では認証サーバが払い出した JSON を利用することができます

  • event_metadata の指定
    • この機能はイベントフックで、接続、切断、更新時に送ってくる値をサーバ側から好きな値を指定することができます
    • 例えばプライマリキーなどを保存しておくことで、アプリ側の処理を単純かすることが可能です
    • この値は接続毎に保持し、クライアントに通知されることはありません
  • オーディオ、ビデオの設定の指定
    • サーバ側から利用するオーディオやビデオのコーデックやビットレートを指定することができます
    • チャネルで利用するコーデックを統一したい場合に利用可能です
  • ipv4_address や ipv6_address の指定
    • サーバ側から、クライアントが利用する IP アドレスのリストを送ることができます
    • これによりプライベートネットワークだけで通信して欲しい場合など、クライアントの接続をネットワークレベルでコントロールすることができるようになります

イベントウェブフック

Sora は状態の変化などを全てウェブフック経由でアプリケーションに通知します。

この Web フック機能を使うことで、アプリ側は通常の HTTP API アプリを書く事で Sora と連携することが可能になります。

詳細は Sora のドキュメント イベントウェブフック をご覧ください。

API

API は Sora が持っている HTTP API です。この API を操作することで指定したユーザを切断したり、指定したグループ全員にプッシュで情報を送るなどが利用可能になります。

詳細は Sora のドキュメント をご覧ください。

サポート

開発チームが直接サポート対応を行います。

SDK

SDK の有償サポートは行っておりません、ただしバグフィックスなどは最優先で対応します

Sora には現在 JavaScript と iOS と Android の SDK が存在しています。

全ての SDK がマルチストリームに対応済です。クライアントから簡単にマルチストリームを利用することができます。

さらに常に最新の WebRTC ライブラリに追従しています。

SDK は OSS で、ラインセスも Apache 2.0 にて提供しており、自由に使って頂く事を想定しています。

JavaScript SDK

iOS SDK

WebRTC ネイティブ iOS ライブラリ API ガイド

Android SDK

React Native

現在 React Native 用の WebRTC ライブラリを時雨堂で開発中です、 2018 年夏頃のリリースを目標に進めています

現時点では React-Native の SDK を提供するのは難しいため、サンプルアプリを提供しております。

SFU でのマルチストリームを利用したサンプルになっています。

https://github.com/shiguredo/sora-react-native-demos

サンプル

これは WebRTC SFU Sora を利用して録画した映像のサンプル画像です。このサンプルには音声は含まれておりません。

https://dl.dropbox.com/s/seds4hd4wqvq4wa/fhd_5000k.png

コーデックは VP9 を利用し、ビットレートは 5000kbps で解像度はフル HD 、フォーマットは WebM 形式で録画しております。

映像はこちら、 26M バイト程度あります。

https://dl.dropbox.com/s/36g3o9tlgtppea6/8d096fb4-6fd2-40d6-9637-115062a82bc6.webm

Firefox または Chrome で録画した WebM ファイルを見ることができます。このサンプルには音声は含まれておりません。

遅延のなさを実感して貰えるように、 Sora のサイトにてデモを用意してあります。

リアルタイムな配信デモとセミナー・授業デモをお試しください。 https://sora.shiguredo.jp/#demo-box

ゴール

SFU (+TURN) 機能を持った WebRTC メディアサーバです

  • 最新版の Chrome と Firefox と Edge と Safari が繋がる WebRTC サーバを製品として提供します
  • サーバ経由での片方向での音声/映像配信を可能にします
    • SFU 1 台で WebRTC 経由で 500 の片方向配信を可能にします
  • マルチストリーム を使用した双方向での音声/映像配信を可能にします
    • 常に マルチストリーム 前提で動作させます
    • マルチストリームでは最大 12 人の双方向配信を可能にします
    • マルチストリームでの一人当たりの利用帯域を人数関係なく固定することを可能にします
  • 常に組み込みでの TURN 経由アクセスを行います
    • Username/Credential な認証の仕組み自体は組み込みます
    • TURN 機能もサーバ側に盛り込みます
    • TURN-UDP 機能
    • TURN-TCP 機能
    • TURN-TLS 機能
  • 録画/録音機能を組み込みます
    • VP8, VP9, H.264 の録画に対応
    • WebM 形式での出力が可能
    • 音声のみの Opus または PCMU 録音機能
      • Opus は webm で PCMU は wav 形式での保存
    • Simulcast を使った複数画質を WebM 形式で録画可能
  • IPv6 対応
  • スポットライト機能
    • 音声が一定量を超えた配信者のみの音声や映像を配信する機能です
  • Simulcast と帯域推定による動的な配信映像の変更を行います
    • 帯域が厳しいと判断した場合は低画質の映像を配信します
  • クライアント SDK の提供
    • クライアント SDK はすべて Apache 2.0 ライセンスにて OSS として公開します
    • JavaScript
      • マルチストリーム対応
    • iOS (Swift)
      • マルチストリーム対応
    • Android (Kotlin)
      • マルチストリーム対応
  • サンプルアプリの提供
    • Apache 2.0 ライセンスにて公開します
    • iOS (Swift)
    • Android (Kotlin)
    • React-Native
  • Ubuntu 16.04 on ARM64 パッケージの提供

実装しない機能

  • HLS への変換機能
  • 音声変換機能
  • 映像合成機能
    • FFmpeg をご利用ください
  • P2P 経由への対応
  • メディアチャネルのみの実装とし、データチャネルのスタックは実装しません
    • データチャネルの実装が QUIC ベースになった場合は検討します
  • ファイルアップロード機能
  • 独自の認証機能
  • 画像変換機能

動作環境

CPU

  • x86_64
  • ARM64
    • OS は Ubuntu 16.04 固定です

OS

Linux のみに対応しており、Windows への対応は行いません

  • Ubuntu 18.04 64bit
    • 次のリリース時から提供予定です
  • Ubuntu 16.04 64bit
  • Ubuntu 14.04 64bit
    • Ubuntu 18.04 リリースの 1 年後にサポートから外れる予定です
  • CentOS 7.4 64bit
  • CentOS 6.9 64bit
    • CentOS 8.x リリースの 1 年後にサポートから外れる予定です

ブラウザ

最新の安定版ブラウザのみに対応します

  • Chrome M65
  • Firefox 59
  • Edge 42
  • Safari 11.1

最新のブラウザのみ動作を保証します。

要求スペック

Sora バージョン:18.04
コア数:最低でも 500kbps 利用時で 100 ストリーム利用の場合は 2 コア以上必要
メモリ:1G 以上

1:N とマルチストリームではストリームの数が接続数と一致しないため、ここではストリーム数で表現しています。

また実際に送られるパケット数も全く異なるため 1:N とマルチストリームでのストリーム数をそのまま計算するのは難しいです。

利用している CPU やビットレート、クライアントごとの回線状況などで CPU 利用率は大きく変わってくるため、必ず自社で負荷の検証をお願いします。

検証環境

  • Vultr dedicated instance (専有サーバ) $60 を利用しています
  • High Performance and Cheap Cloud Dedicated Servers - Vultr.com
    • 2 CPU
    • 8192 MB Memory
    • 10TB Bandwidth
  • ここでは 1 コア 100% としています。
  • ここでは 1 ストリームとは 1 音声トラック + 1 映像トラックとしています

1:N 利用時の参考値

検証結果

あくまで参考値としてご利用ください

  • audio/video 500kbps 1 チャネル 1:5 で最大 15 % 程度
    • 6 ストリーム (up 1 down 5)
    • macOS Chrome 66

マルチストリーム利用時の参考値

あくまで参考値としてご利用ください

検証結果

  • audio/video 500kbps 1 チャネル 2 接続
    • 最大 5-8 % 程度
    • macOS Chrome 66 x 2
  • audio/video 500kbps 1 チャネル 3 接続
    • 最大 10-20 % 程度
    • macOS Chrome 66 x 3
  • audio/video 500kbps 1 チャネル 4 接続
    • 最大 20-30 % 程度
    • macOS Chrome 66 x 4

スポットライト機能利用時の参考値

あくまで参考値としてご利用ください

こちらの検証は CPU 1 コア、メモリ 1 ギガのサーバで CPU 使用率 80% を利用しています。

検証結果

  • audio/video 500kbps スポットライト数 2 1 チャネル 30 接続
    • 最大 80% 程度
    • macOS Chrome 66 x 30

現状

接続試験

あくまで接続検証試験のため、最大値を保証するものではありません

この試験はシグナリング機能を省略したシミュレータを利用した試験で実際にブラウザを接続した試験ではありません

検証環境はグローバルで、 Packet の ARM64 サーバ (96 コア / 128G) を利用しました。

Chrome 56 または Firefox 51 にて 800kbps で 1:500 の映像のみ配信 x 8 の合計 4000 接続に成功しています。

https://dl.dropbox.com/s/5ga4pyeaaf5wjwe/arm64_4000.png

連続稼働

連続した安定的な配信を可能にします。 1 ヶ月以上の連続配信を実現しています。

パケットロストした RTP パケットを再取得する Generic-NACK 機能に対応しており、画質を安定して配信することが可能です。

遅延

Safari TP を利用して 1:1 での配信と視聴を行いました。ちなみにサーバははさくら VPS 4G のサーバにおいてあります

  • 上の映像が Safari のフェイクカメラをそのまま流している映像です
  • 下の映像が WebRTC SFU Sora を経由した映像です

https://dl.dropbox.com/s/cemoi60iws8jcu7/delay.png

遅延は 100 ミリ秒程度でした。これはかなり遅延が少ないと思います。

ライセンス

ライセンスは 1 年間毎での更新が必要です。

WebRTC SFU Sora は時雨堂が1から開発したパッケージ製品です。自社のサーバにインストールしてご利用ください。

採用事例を許可いただく前提で 100 同時 接続利用可能なライセンスが 60 万円/年でご利用頂けます。

ライセンス費用の詳細につきましては、 https://sora.shiguredo.jp/price をご確認ください。

大量のライセンスを購入いただいた方向けの割引もありますので、お気軽に sora at shiguredo.jp までご質問ください。

参考

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