- 更新
2018-09-21
- 作者
- 作者サイト
- バージョン
18.9.3
- セッション日時
2018-09-25 21:10-21:30
- セッション場所
さくらインターネット 大阪本社
- 発表時間
20 分
この資料は 2018-09-25 に行われる ImageFlux meetup #2 の 発表者資料 です。
この資料の質問は Twitter で @voluntas まで DM をお願いします。(DM は誰からでも受け取れるようにしてあります)
- depth
3
時雨堂 という零細企業から来ました。こんばんは。 Twitter ID は @voluntas です。
ブラウザ同士で直接音声や映像、バイナリや文字列を UDP でやり取りする仕組みです。
UDP の上で音声や映像は RTP 、バイナリや文字列は SCTP を、暗号は DTLS (データグラム向け TLS)を利用します。
RTP は音声や映像の向けプロトコルと思ってもらって問題ありません。 SCTP は UDP と TCP のいいところどりをしたプロトコルです。
- RTP over SRTP over DTLS over UDP が映像や音声をやり取りできるメディアチャネルです
- DataChannel over SCTP over DTLS over UDP がバイナリや文字列をやり取りできるデータチャネルです
やり取りするプロトコルだけでも複雑ですが、そもそも UDP が繋がらない時どうするんだというための仕組みで、 TURN という仕組みも含まれてきます。UDP がダメだったら TCP にチャレンジして、それでもダメだったら TLS にチャレンジするという仕組みです。
つまりメディアチャネルは ... RTP over SRTP over DTLS over TURN over UDP というのが正しい構成です。
この時点で、もうお腹いっぱいの人が多そうですが、大丈夫です。 ブラウザの WebRTC API はこの辺のめんどくさいのは隠蔽してくれています。
ただ、隠蔽してくれていない部分もあってそれが ICE と呼ばれるものです。簡単に言うと P2P でやり取りするためにどうすべきかを決めるプロトコルです。
P2P にはいろいろ壁があります。その壁を上手くすり抜けてやり取りをする方法を調べて、実現してくれるプロトコルが ICE です。
いろいろな技術を利用してブラウザ同士で超低遅延でいろいろな情報をやり取りできる仕組みを実現している、それが WebRTC です。
WebRTC SFU は P2P の P2P を無理やりサーバ経由にすることで、 P2P で難しかったことや、課題になっている事を実現する仕組みです。
P2P は 1:1 の通信であればとても良い仕組みなのですが、1:N や 5 人で会議といった実際のビジネスとして良くある場面で利用しようとした場合は、負荷や通信帯域の問題が顕著に出てきます。これらをできるだけ WebRTC の仕組みからぶれること無く、サーバ経由での通信を可能にする技術が SFU です。
SFU は配信者の代理に複数に配信をしてくれる仕組みが主な仕組みです。さらにブラウザ間の差分の吸収も行います。つまりクライアント側のコードが減ります。
さらにサーバ経由になることで、サーバで映像や音声を録画したり、サーバがクライアントの代理で複数人数に配信したり、サーバが動的な接続管理をコントロールしたりと、中央集権にすることでかなりのメリットが湧いてきます。
P2P と比較してもサービス運営や企業内部で使うことを考えると SFU を選択するのがオススメということになります。
時雨堂ではこの WebRTC SFU を 1 からフルスクラッチで開発し、販売しています。
さくらインターネット様や pixiv 様を含む、多くの企業に採用いただいています。
WebRTC は一般的に思われているようなプロトコルではありません。確かにプロトコルよりではあるのですが大きな強みとして音声や映像のエンコード、デコード部分も含めて提供しているということです。
そのためブラウザだけで何も考えることなく音声や映像を配信、視聴することができるようになります。
さらっと ブラウザだけで と書きましたがいうのも本当にすごいことです。配信専用ツールが一切不要でいつも使っているブラウザからすぐに配信ができます。
また、 WebRTC にはストリームであれば何でも配信できます。つまりカメラ以外も配信できます。例えば Canvas もストリームを吐き出せるので Canvas 自体の配信も可能です。さらに画面共有だってできます。 つまり配信、視聴がなんでも入っています。
さらに、今 WebRTC が多くの注目を集めているのは超低遅延配信です。超低遅延とは 1 秒未満での配信のことをここでは言っています。音声や映像、さらにはバイナリや文字列を超低遅延で配信、視聴可能になります。
もちろん距離や回線に依存しますが基本的に日本国内であれば 200-300 ミリ秒程度の遅延ですみません。サーバ経由での話です。
今まで WebRTC は双方向が前提でした。ただ、超低遅延配信という一方向での低遅延の需要が徐々に増えてきています。超低遅延は魅力です、ただし課題も多くあります。それは大規模配信がかなり難しくなるということです。
遅延をせずに大規模へ配信は難しくさらにサーバコストもとても掛かります。そこで、それらを解決するのが ImageFlux Live Streming です。
ImageFlux Live Streaming は配信を WebRTC 、視聴を HLS という仕組みです。これはブラウザから大規模配信を実現するという仕組みとしては今取れる最善の策です。YouTube も同様のサービスを提供しています。
ImageFlux Live Streaming は配信部分を完全に WebRTC に依存しており、WebRTC でいう複数人の同時やり取りであるマルチストリームを利用することで複数人数の同時配信を実現しています。
これは Co-Streaming と呼ばれる機能です。今の所この複数配信 + WebRTC + HLS という構成をとれるサービスは殆どありません。さらに ImageFlux Live Streaming は pixiv Sketch LIVE で培ったノウハウを凝縮しています。
- 全部入りで、ブラウザから簡単に配信できる WebRTC
- 数万という規模の大規模配信に対応した HLS
これらの組み合わせをシンプルに実現できるのが ImageFlux Live Streaming です。ブラウザから、iOS から、Android からと簡単に配信できます。 さらに、ImageFlux Live Streaming の前段は今までお話してきたように WebRTC SFU Sora という時雨堂の製品が利用されています。
時雨堂では WebRTC SFU Sora 向けにブラウザ向け、 iOS や Android 向けに SDK をオープンソースで提供しています。最近では React Native 向けライブラリもオープンソースで提供しています。
- WebRTC SFU Sora JavaScript SDK
- WebRTC SFU Sora iOS SDK
- WebRTC SFU Sora Android SDK
- React Native 用の WebRTC ライブラリ
これらはもちろん ImageFlux Live Streaming で利用可能です。なぜなら前段に WebRTC SFU Sora がいるからです。
つまり ImageFlux Live Streaming は WebRTC が動く環境であればなんでもいけるということになります。
現在 WebRTC Native Client Momo というのを開発中で、10 月末にオープンソースとして公開予定です。
これは何かというと、ブラウザや iOS などなしで WebRTC 配信ができるクライアントです。つまり単独で WebRTC を配信できます。
現時点で ...
- macOS x86_64
- Ubuntu x86_64
- Ubuntu ARMv8
- Windows x86_64
- Raspbian ARMv7
- Raspbian ARMv8
といった様々な環境で動作します。起動方法はコマンドから実行するだけです。カメラも勝手に認識します。
$ momo --no-audio --video-codec H264 --video-bitrate 500 \
sora --auto wss://example.com/signaing image-flux-live-streamingラズパイから配信した映像が ImageFlux Live Streaming を経由して 5000 人へ配信する事も可能になります。
興味がある人は OpenMomo プロジェクトを見てみてください。