Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
349 lines (219 sloc) 13.8 KB

第 2 回 時雨堂 WebRTC セミナー 夜の部

日時:2020-01-22 (水)
更新:2020-01-19
作:時雨堂
バージョン:20.01.2

http://bit.ly/shiguredo-seminar-2-night

概要

これは 第 2 回 時雨堂 WebRTC セミナー の夜の部の発表者向け資料です。

発表者がこの資料を使って口頭で補足をしつつ発表します

以下の資料は読んでいる前提となります。

WebRTC コトハジメ

セミナー諸注意

撮影、録音について

ご遠慮ください。

ツイッターなどへのつぶやき

是非、お願いします。

資料のライセンス

https://creativecommons.org/licenses/by-nc-nd/4.0/

質問について

適時質問していただいて問題ありませんので、気軽に聞いてください。

WebRTC の現在と今後

WebRTC の未来

WebRTC 1.0

よほどのことがない限り 2020 年には 1.0 が出ます。だからといって全てのブラウザが実装を守っているわけではありません。 ただ、一段落つけられるというのは大きいです。

AV1

クアルコムからハードウェアデコーダを積んだチップがでてきました。ここ 1-2 年で劇的に変わっていきそうです。 YouTube でかなり見られている動画の場合は AV1 でのエンコードも始まっているようです。

サイマルキャスト

Google 独自対応が終わりに向かい、IETF / W3C に定義されているサイマルキャストの実装が進んでいます。 残念ながらかなり知識のいる世界なため、もし使う場合は SDK を利用するのがおすすめです。

SVC

資料はせず、当日口頭でのみ発表。

QUIC

説明不要なくらい多くの場所で使われ結果も出してきています。 WebRTC では利用するプロトコルを QUIC ベースにしていきたいという考えがあります。

理由としては ..

  • DTLS-SRTP over UDP をやめたい
  • SCTP over DTLS over SDP をやめたい

というシンプルなものです。RTP は古すぎるし、SCTP はマイナーすぎる、そこで QUIC に置き換えることで色々モダンにしていきたい方向です。

実はもともとはそのまま QUIC を使えるように RTCQuicTransport という API が用意されたりもしたのですが、 どうやら流れとしては WebTransport に流れていくようです。

WebTransport

WebTransport はすごく雑に言ってしまえば、 over QUIC または over HTTP/3 の上に実装される WebSocket です。 実装自体は始まっていますが、こちら利用可能になるのは早くても 2 年後くらいだと思います。

まずは over QUIC から入っていくようです。

Media over WebTransport で再送制御や輻輳制御、FEC 周りの仕組みがそのまま入るとは思えないため、 そう考えると当面は RTP ベースにはなりそうです。

ただ DataChannel は再送周りの仕組みさえあればいいので、 WebTransport への移行は難しくなさそうです。

WebRTC Signaling Server Ayame 入門

URL:OpenAyame/ayame: WebRTC Signaling Server Ayame

資料

以下の資料を参考にお話をしていきます。

Ayame リライト版

全体的な設計の変更、ログ整理、 WS のグレイスフルシャットダウンなどに対応したバージョンです。 SDK も見直し中です。後で説明する Momo との相性がとてもいいことから、今後も力を入れていきます。

SDK は当面は Web のみの予定です。

Ayame Plus の紹介

Ayame Lite を正式リリースして置き換える版です。とはいえまだリリースできていません。 仕様も変更する予定はありません。利用規約に同意が入るのがメインです。

WebRTC Native Client Momo 入門

URL:shiguredo/momo: WebRTC Native Client Momo

WebRTC Native Client Momo はブラウザレスで複数プラットフォームで動作する WebRTC クライアントです。 音声や映像の配信、受信を 1 バイナリで実現しています。

強さ

Momo はスタンドアローンで動作します。配信、エンコード、デコード、受信すべて Momo だけで可能です。 WebRTC の配信と受信部分は libwebrtc を利用しているためスタンダード準拠です。

エンコードとデコードはハードウェアアクセラレータに対応しています。 現在は Raspberry Pi 、 NVIDIA Jetson、 Apple macOS に対応しています。 今後は Windows / Linux で NVIDIA ビデオカードや Intel グラフィックスに対応していく予定です。

継続的な開発、そしてオープンソースで公開されています。 フォークをして利用することで独自の機能も開発可能です。

今後の目玉として DataChannel をシリアル経由で読み書きできるような仕組みを検討しています。

ROS2 にも対応していき、自動運転やロボットでも使って貰えればと考えています。

4K@30

Jetson Nano を利用することで WebRTC の 1 秒未満の低遅延で 4K@30 を配信可能です。

資料

以下の資料を参考にお話をしていきます。

新製品 Azuki の紹介

Azuki は Momo をベースにした常時接続型の拠点間通信向けソフトウェアです。 複数拠点間の映像を流しっぱなしで繋ぐという事に利用可能です。

資料

以下の資料を参考にお話をしていきます。

WebRTC SFU Sora 入門

URL:WebRTC SFU Sora

Sora は時雨堂が 1 から開発している WebRTC SFU です。WebRTC 関連のライブラリもすべて自社開発しています。 Erlang/OTP という言語で書かれております。マイナーな言語です。最近だと任天堂さんが使ってるので話題になりました。

WebRTC SFU に特化しており、かなり偏ってる製品です。 SIP にも対応しない、合成にも対応しません。 機能も少なめです。主な機能は配信と録画の2つしかありません。

機能を少なめにして一つ一つの機能の価値をあげていくという方針をとっています。

配信

様々な配信が可能です。さらに配信するのに重要な「つながる」も考慮しています。 WebRTC は UDP ベースのため繋がない環境が多いです。 それを解決するために TURN というプロトコルを利用して、TCP や TLS での配信を行う仕組みがあります。 Sora は TURN 機能を内蔵しているため、 TURN サーバを別途構築する必要がありません。

また片方向での大量配信(同時 1000 クライアントに配信可能) や、複数人数での双方向配信(最大 12 クライアント)、 さらにはスポットライト機能という、 Sora 独自の「直近で話をしたクライアントのみを配信する」という機能をもっており、 これを使うことで 1 チャネルに 300 接続も可能です。

4K での配信にも対応しています。4K は高ビットレートを要求されるため再送制御が低ビットレートとは変更する必要があり、 そちらも独自で対応しています。

録画

WebM 形式でファイルを吐き出します。変換を一切していないため CPU リソースをほとんど食べません。 イベントウェブフックがあるため、録画ファイルそれぞれの処理 (たとえば S3 に上げる) なども簡単に行なえます。

後ほど Sora Labo にある録画機能でデモを行えればと思います。

SDK

ブラウザ向けの JavaScript SDK から iOS や Android 、最近では Unity に対応しました。 そして何よりすべての SDK が Apache License 2.0 で公開しています。

継続的なメンテされる OSS として公開しています。

資料

以下の資料を参考にお話をしていきます。

Sora Labo の紹介

さくらインターネットさんの協力でさくらのクラウド上で動かしております

Sora Labo は「WebRTC SFU という言葉はよく聞くが商用製品はどんなものなのか試してみたい」という方向けのサービスで始まりました。

Sora は 30 日無料で利用できる評価版を提供しているのですが、 パッケージ版ということもありサーバを構築する必要があります。

Sora Labo では GitHub アカウントさえあればすぐに Sora を利用できるようにしました。

TCP や TLS しかつながらないネットワークを体験してもらったり、 Momo で気軽に Sora が使えるようになったりと、いいことばかりです。

実際 Sora Labo を触って製品の購入を決めてくれた企業様もいらっしゃいます。

時雨堂 Sora Labo 開発ログ

事前質問への回答

データチャネルについて

個人的には WebTransport が来るまでは待ちたい、というのが本音です。 ただ ROS と SFU の組み合わせでは需要があるのでは?とは思っております。

現実的な要望を言っていただくのが、弊社としてもリソースを投入しやすいです。

実際ベース実装はあるため Sora に追加するのは 1-2 ヶ月で実現は可能です。

自動字幕機能

Sora の連携の話として、今は少し止まっていますが、 2020 年中にはお披露目できるかと思います。 GCP の Cloud Text-to-Speech API を利用する Gateway を開発中です。 OSS にて公開予定です。

WebRTC を利用したサービスを作る場合のコストの見積もり方

見積もりは基本あたらないので、小さく作って徐々に大きくしていくというのが良いです。

また、商用の WebRTC サービスやパッケージを利用したり、 テクニカルサポートを契約することです。餅は餅屋ということで。

P2P と SFU の使い分けについて

仕事で使う前提で回答させていただきます。 1:1 であれば P2P を検討してもよい、基本的には SFU を採用すべきという考えです。

これはポジショントークとかではなく、 P2P は好きなのですが、サポートを考えたりするとログが取りやすいサーバ経由である SFU を採用したほうが良いです。

WebRTC 勃興の理由と将来性

水面下ではもともと使われていたのが、Flash が死ぬことで話題になってきた以上のことは無いと思います。

将来性は WebRTC の変わりの技術は今のところ無いので、当面は WebRTC が使われていくと思います。 とはいえ、 WebTransport がくれば Media over WebTransport を進めていきそちらによっていくと考えています。

5G への期待

あまり無い、というのが正直なところです。 もちろん端末から基地局までの速度が早くなり、安定することは嬉しいのですが、 劇的になにか改善されるということは無いと考えています。

WebRTC SFU のスケールに関して

1:N であれば多段の仕組みを採用するのが無難だと思います。 多くの接続を維持するというのであれば、WebRTC SFU に依存すると思います。

ディスパッチをするサーバを用意して、 接続先の WebRTC SFU 情報を払い出す仕組みが無難だと考えています。

WebRTC のモバイル端末でのデバッグ方法

WebRTC に関する情報のキャッチアップの方法

手前味噌ですがこちらの Discord に参加するのをおすすめします。

WebRTC オンライン専用コミュニティ

質疑応答

セミナーが終わり次第、追記

今後

色々セミナーをやっていきたいと考えています。

  • Momo セミナー
    • オープン
  • Momo ハンズオン
    • オープン
  • Sora セミナー
    • クローズ
  • WebRTC セミナー
    • クローズ
    • 参加費あり
You can’t perform that action at this time.