Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
WebRTC トラノマキ

WebRTC トラノマキ

更新:2017-01-27
作者:@voluntas
バージョン:2.2.0
URL:http://voluntas.github.io/

広告

WebRTC SFU Sora

WebRTC SFU Sora

時雨堂 が位置から開発したサーバソフトウェアです。 遅延が少ないリアルタイムな 1:多の配信や、グループ会議、サーバでの録画といった機能を保持しています。

パッケージ製品のため、自社内に置いて利用可能で、既存アプリとの連携を念頭に開発されているため、 認証や時間課金などを簡単に組み込むことができます。

概要

WebRTC SFU を開発しているついでに、調べた WebRTC 関連のことや今後についてまとめておく。

基本的なことを知りたい場合は WebRTC とはなんだったのか にまとめてある。

注意

DataChannel の事については触れる程度で、 MediaChannel がほとんど

間違いについて

@voluntas まで Twitter にてリプライを飛ばして欲しい。

今後

サーバ

WebRTC は P2P メインというよりは Simulcast や SVC を使ったサーバ経由が強くなってきそう。 最低限は P2P で通信しつつも、必要あればサーバ経由で通信するという流れ。

Simulcast が可能になれば、配信者はサーバ側でモバイル用は低解像度、デスクトップ用は高解像度という内容で分配することができるようになる。

サーバは SFU が主力にはなりそう。MCU が合成で使用する CPU 使用率が下げられるかどうかが課題。この辺は GPU で頑張るのかどうか。

ただ、 VP9 はあくまでデスクトップと Android 限定で、 iOS にハードウェアエンコーダは積まれることは当面はなさそう。

H.264 + Simulcast + SFU が今後の主力になってくると考えている。ただし VP9 も混合していくだろう。

Simulcast

WebRTC のクライアントが低解像度と高解像度両方の動画を送る方式。 SVC と似ているが実際に二種類の形式を送る技術。P2P であればモバイル端末は低解像度のみを受け取り、デスクトップは高解像度を受け取る。

サーバを挟むのであればサーバがそこを選定し配信を分配する。クライアントは両方の解像度をサーバに上げるだけ。

Firefox が 47 でフェーズ 1 として実装された。 a=simulcast として実装される。

Chrome は既に実装済みの模様で a=ssrc-group:SIM を使う事で対応させられる。

VP9

Chrome だけではなく MS Edge が実装を表明したが、現時点では VP8 が優先のようだ。

Firefox は M51 で対応した。ただし iOS 向けの WebRTC ライブラリでは一時的に無効化されている。

Chrome M47 にてデフォルトで対応した。CPU 使用率は 15% ほど上がる。 ただし SVC はデフォルトではフラグ付き。このタイミングは不明。

H.264

iOS 端末が HW アクセラレータを実装していることが一番大きい。 スマホ端末からの映像は H.264 がスタンダードになる可能性は高い。

libwebrtc はデフォルトで H.264 の HW オプションが有効になった。

Chrome M52 で H.264 へ対応した。Windows や OS X では HW アクセラレータが利用される。

つまり、 iOS のネイティブアプリはデスクトップに対しても安心して H.264 で配信できる未来が待っていることになる。

これは、かなり大きい。

Firefox

基本的な機能をしっかり実装していっているというイメージだ。ただ、細かい機能が抜けてたりする。 libwebrtc も追いかけてる状態で、 Chrome のほうが機能自体は豊富だし、攻めている。

最近の詳細は以下を読むのが良い。

SVC

Simulcast が複数の解像度を送るという考えに対して、実際の解決作を呈示したのが SVC という技術。

WebRTC では Chrome + VP9 + SVC がまず先にでてきそう。 H.264/SVC は会議システムでは広く普及している。

ただし SVC をサーバにて判断しビットレートをコントロールする技術は Vidyo 社がパテントとして持っているので要注意。

WebRTC という規格

映像と音声を配信するためのオープンな規格という認識をした方が良い。ブラウザ限定と考えているのはもう古い。

特にネイティブクライアントで使いやすくなっているのは強い。iOS/Android はブラウザベースというよりはネイティブベースになりつつある。

最近だと Safari が WebRTC 対応を始めたが、ブラウザはデスクトップからのおまけという感じになる。

規格自体が完全にオープンになっており、この規格に対応するだけで良くなる。もちろんブラウザやスマホだけでは無く、組込でも使える用になる。

実際 WebRTC ゲートウェイという概念でラズベリーパイなどで動作するクライアントも出てきている。

ORTC

もうなかったことになってるくらいの規格

正直気にしなくてイイと思っている。 Edge しか今のところ対応していないし、 Chrome/Firefox が追従する気配も無い。

MS Edge

MS の Edge は Windows Preview build で WebRTC 1.0 に対応した。 さらに H.264 や VP8 にも対応した。 内部は ORTC ベースなのかもしれないが、まったく気にしなくて良くなりそうだ。

WebRTC NV

Google が提唱する WebRTC で WebRTC 1.0 + ORTC を全てカバーする規格。おそらく WebRTC 1.1 となるのだろう。

Google は WebRTC と ORTC が分離することを喜んでいない。そのため両方をカバーする企画を提案しはじめている。

JS

JS 側の API については詳しくないのでここでは省略するが、わかっていることとしては Multistream を前提とした実装になったタイミングで、かなりの JS 力が求められると見ている。

WebRTC アプリケーションを書く場合はとにかく JavaScript 力を付ける事が最優先だろう。

HTTPS

Chrome M47 以降は getUserMedia が HTTPS のみでしか使用できなくなった。

テストで HTTPS がめんどうな場合は以下を参考にすると良いだろう。

http でのアクセスでカメラの映像を取得する - Qiita

Firefox も警告を出す方向で進んでいる。 Edge は当面は HTTP でも問題ないという方針で行くようだ。

Multistream

今までは複数の接続を貼る場合は毎回 DTLS セッションを貼っていたが、 1 DTLS セッションの内部に複数のストリームを含める仕組み。

SFU の場合は複数セッションを貼る必要があるが、これを一つにまとめることができるようになる技術。今後はこの技術を使って行く事になる。

たとえばスクリーンシェアリングとカメラ映像を一つのセッションで配信できるようになる。

Unified Plan (Plan A)

Firefox と Edge

SDP の形式が a=msid を採用したタイプ

これが正しい方向。Chrome は古い。

Edge は Unified Plan で行くのが決まったが、今のところマルチストリームはまだ実装されていない。

Plan B

Chrome

SDP の形式が a=ssrc msid のまま。

Chrome 側で Unified Plan の準備ができてはいるようだ。

Issue 465349 - chromium - Need to implement WebRTC "Unified Plan" for multistream - Monorail

Issue 1688383002: Implementing unified plan encoding of msid. - Code Review

すでに最新のリポジトリには Unified Plan の msid を使うような変更が入ってはいる。

2016 年内ということだったが、今のところ変化は見られないので 2017 年に期待したい。

DTLS

Firefox でも Chrome でも DTLS のバージョンは 1.2 になっている。

Chrome M52 でデフォルトの証明書が ECDSA の P-256 になった。Firefox はまだ未確認。

今後メインストリームが TLS 1.3 が普及していく事を考えると DTLS 1.3 に切り替わるタイミングがある可能性はある。

もしくは、 Google が間違って DTLS 1.3 を QUIC にしてしまう未来があるのかもしれない、多分ない。

SRTP/SRTCP

.. TODO:: RTCP 周りが結構えぐいので、 FIR や PLI をまとめる

SRTP/SRTCP 自体の暗号方式は RFC 通り。ただし RTCP 部分はかなり幅広い対応が必要。

様々な仕様がある。拡張も多い。様々な拡張が追加されていっている。

Codec

映像

現在は VP8 がデファクト。Firefox は H.264 へも対応ずみ。 Chrome M52 で H.264 へ対応した。 Firefox は VP9 に 2017 年 1 月には対応する。

映像はハードウェアアクセラレータへの対応がモバイルではかなり有効になる。

ハードウェアアクセラレータ は Android で一部は VP8/H.264 に対応、iOS は H.264 のみ。

今後

OpenMedia というアライアンスが設立された。Google を始め Cisco など、さらに MS が参戦している。 ただ、ビデオ会議の主力になる iPhone/iPad では H.264 がメインになるため、 Apple がどうなるかが重要。

Chrome での H.264 対応は M50 でのリリースを目指している。

H.265 はかなりライセンスが高くなるため、 WebRTC に採用されることはかなり厳しそうという印象。

Chrome で VP9/SVC が投入されるのが確定しているのと VP9 を MS Edge が採用したので、デスクトップ系は VP9 がくるかもしれない。

音声

Opus でほぼ確定。こっから動く事はなさそう。

ブラウザ

それぞれのブラウザの特徴をまとめてみる。

Chrome

VIDEO コーデック:VP8, VP9, H.264
DTLS:バージョン 1.2

H.264 は M52 で対応した

Firefox

VIDEO コーデック:H.264, VP8, VP9
DTLS:バージョン 1.2

Multistream 関連は最先端。新しいバージョンでは Simulcast も考慮されているとのこと。 47 で Simulcast のファーストフェーズ実装が入った。51 で VP9 が入った。

Edge

まだ Windows Preview 状態

VIDEO コーデック:H.264UC, H.264, VP8、VP9(予定だったがペンディング)
DTLS:バージョン 1.2

ORTC 対応版が年内どころか 9 月にリリースされた。といっても独特すぎてほかのブラウザとの互換性はゼロ。基本的に Skype を動作させるための仕組み。

音声コーデックに SILK があるあたりも Skype な感じ。動画コーデックは H.264UC というSVC 実装の一種が採用された。今後は H.264 にも対応していくらしい。

Edge は WebRTC 1.0 への対応を発表した。

Roadmap update for Real Time Communications in Microsoft Edge | Microsoft Edge Dev Blog

内容としては H.264 への対応、さらにネイティブでの WebRTC 1.0 対応。VP9 への対応も検討しているとの事だ。

公式見解がでたのはとても大きい。

SFU と MCU

MCU

そこそこの画質で遅延が少しだけあるが、 50 人同時会議などに向いている

MCU の利点は一つだけで、変換を中央集権型で行う事で、モバイルの非力な回線にも柔軟に対応出来ること。 ただし、CPU やメモリは膨大に消費する。このあたりはリソースで解決するかどうかというのもある。

MCU を採用するのは大規模であること、モバイルがメインであることの二つだろう。ほとんどの場合は SFU で事足りる。

JS で色々いじれるのをメリットにしている WebRTC としては MCU で統一されてしまうとかなり苦しい気がする。

SFU

高画質で遅延が少なく、1:300 程度の配信に向いている

SFU は逆に転送しかしないため、配信者が高解像度で配信した場合はモバイルは死ぬ。

SFU は SVC や Simulcast が来ないとモバイルが苦しい。ここはデコードとエンコードで切り離して考えるのが良いと思う。

iOS は配信は H.264 HW で行い、受信は VP9 SW で。もしくは受信は音声だけで行い必要があるときだけ映像を受信するという方法もある。音声だけであれば回線コストはそんなに食わない。

SFU 側でそのあたりをコントロールできればなんとか行けそうと考えている。

SFU

WebRTC の主力になる可能性がある SFU を掘り下げておく。

SFU は簡単に言うと映像の PubSub を実現する仕組みだが、ストリームなのが大きく違う。 ちなみに音声と映像それぞれの暗号に使用するキーは別だ。

SFU 自体はただ受けとった RTP データを配布するだけの機能だが、 SFU 自体にいろいろな機能を組み込むことはできる。

SFU はサーバサイドで暗号を解いているのが重要になる。TURN と違い、クライアントは SFU 自体と話をするため、閲覧者側の情報を明示的に知る事はできなくなる。

今話をしている人の映像だけを表示する機能

5 人で会議をしていたときに 5 人全員の映像を表示するコストはとても高い。 そこで、今話をしている人を自動的に SFU 側で判別し、その映像だけを流すといった技術は可能になる。

つまり、5 人の音声は全て配信されるが、動画だけは話者のみが表示されるといった機能だ。 これは特にモバイルに嬉しい。デスクトップであればまぁ 5 人くらいの動画表示はそんなに大変ではない。

MCU

MCU はあまり詳しくないのだが、課題点をいくつか書き出してみる。

  • 再エンコードは CPU を持って行きすぎる
  • 複雑である
  • 柔軟性がない

正直この三つが主な課題だ。MCU はもともとよく使われていた技術という認識。ただ再エンコードの課題はすごくある。CPU ではなく専用の変換ボードとかが今後必要になっていくルのかもしれない。

ハードで解決する世界が待っていると見ており、 SFU のようなソフトで解決できないのではないだろうか?

相談

WebRTC 技術関連、有償でもよければ相談に乗ることが可能です。

株式会社時雨堂

参考

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