Instantly share code, notes, and snippets.

Embed
What would you like to do?
WebRTC の未来

WebRTC の未来

更新:2019-01-30
作者:@voluntas
バージョン:19.01.1
URL:http://voluntas.github.io/

この記事が良いと思ったらこの記事に Star をお願いします。

概要

仕事で WebRTC SFU を開発しているついでに、調べた最新の WebRTC 状況や未来についてまとめている。うまく分けることができない話が多いため何度か同じ話をしているのでうまく読み飛ばしてもらえれば。

WebRTC の知識がある前提で書いている。基本的なことを知りたい場合は WebRTC コトハジメ にまとめてあるのでそちらを参照してほしい。

WebRTC の詳細を知りたければ発表資料で恐縮だが 詳解 WebRTC をおすすめしておく。

質問や間違いの指摘について

この記事へのコメントではなく @voluntas まで Twitter にてリプライを飛ばして欲しい。

用語

Safari TP
Safari Techonlogy Preview
SFU
Selective Forwarding Unit

今後

P2P

Google が発表した Project StreamChrome リモートデスクトップ は WebRTC P2P を使いこなしている。1:1 でスピードをとにかく優先する仕組みだ。

また、WebRTC P2P CDN も結果を出してきている。Peer5 - The Serverless P2P CDN For Video Live Streaming はサッカーのワールドカップで凄まじい結果を出した。

1:1 での速度、直接のやり取りちう部分で WebRTC P2P がなくなることはない。むしろそこに強みがある。ただしそれ以外では WebRTC SFU が利用されることが多くなってきている。

SFU

P2P と SFU はキレイな別世界を作り上げているように思える。

商用の WebRTC サービスを提供している Twilio や Tokbox は自社開発の SFU を利用している。また Microsoft が提供している Mixer というゲーム実況サービスでも OSS の Janus という SFU を利用している。Discord はユーザ数 1.5 億人という大規模な世界で独自開発した SFU を運用している。 Slack も現在は Janus で、別途 Elixir/C++ で自前で SFU を開発している。

いままでウェブ会議の主力だった MCU もコールセンターや IP 電話との併用であれば今後も利用されているが、あくまで MCU は WebRTC はおまけ、という立ち位置だろう。理由としては MCU は CPU リソース利用しすぎるため、サービスの価格を抑えることが難しいからだ。

仕様

WebRTC 1.0 の仕様は 2019 年の後半に落ち着かせたいという思いがあるようだ。またブラウザ同士の差も吸収していきたいという話が出ている。これは朗報だろう。

Completing WebRTC 1.0 https://groups.google.com/d/msg/discuss-webrtc/f4Jg53Phgco/YfetnmoqBQAJ

とはいっても 2018 年 12 月現在では Chrome / Firefox / Safari / Edge すべてのブラウザの仕様が異なる。これがすぐに落ち着くとは思えない。特に Edge は Microsoft の思惑が強く出ている。 当面は 4 種類の WebRTC に対応していく必要がある。

Chrome が M64 から ontrack を実装したため、Chrome / Firefox / Safari が歩み寄りつつある。

Chrome が M67 で Unified Plan に対応、Safari も TP で Unified Plan に対応し、開発者メニューから選択できるようになった。 さらに Safari TP では VP8 にも対応した。

Chrome が M72 で Unified Plan がデフォルトになった。

VP8

Safari が TP 67 にて VP8 をオプションとして対応、TP にて VP8 に対応。これですべての主要ブラウザが VP8 に対応したことになる。

さらに VP8 の Simulcast は Chrome と Firefox 、Safari TP で実装済み。 さらに H.264 の Simulcast が Chrome M73 と Safari TP では実装している。

Edge だけおいていかれている。が Edge は今後 Chromium ベースになるという話なので期待していきたい。

VP9

現時点で Chrome と Firefox が対応済み。Edge は検討中。 Safari は非対応という状況。

Firefox の M58 ではビデオコーデックのデフォルトが VP9 になった。

ちなみに iOS 向けの WebRTC ライブラリではデフォルト無効になっており、利用する場合はフラグを有効にする必要がある。

H.264

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

libwebrtc はデフォルトで H.264 の HW オプションが有効になった。 Chrome M52 で H.264 へ対応した。Windows や OS X では HW アクセラレータが利用される。

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

注意する点としては古い Android では HWA がうまく機能せず問題が出る可能性ある。

ただ、H.264 は古いコーデックであり VP8 や VP9 と比較すると微妙な点が多い。そのため VP8 が使える状況では VP8 を使い、理想は VP9 を使っていくべきだろう。 VP9 は H.264 や VP8 の半分のビットレートで同レベルの画質を担保できる。1Mbps が 500kbps で抑えられるのはとても大きい。

Chrome Canary M73 と Safari TP で H.264 Simulcast が動作する。

Chrome

順調に libwebrtc に追従していっている。最新の機能をいれつつも、安定化もさせていっている印象。 WebRTC 1.0 API への追従も順調に進んでいっている。

  • Chrome M64 からは ontrack / addTrack / removeTrack 対応した。
  • Chrome M65 からは onremovetrack へ対応した
    • onremovestream はそのうち消えるので使うのを辞めたほうがいい
  • Chrome Canary M67 で Unified Plan へ対応した
    • msid が入るようになる
  • Chrome M69 で Unified Plan への対応がほぼ完了した
  • Chrome M70 からは Unified Plan を選択して問題ない
  • Chrome M72 からは Unified Plan がデフォルトになった
  • Chrome M72 に getDisplayMedia が入り、スクリーンシェアが Chrome 拡張不要になった
  • Chrome Canary M73 で H.264 Simulcast が有効になった
  • Chrome Canary M74 で mDNS が有効になった

Firefox

基本的な機能を実装しているが、現時点では libwebrtc のバージョンが数世代遅れていることもあり、 リソースが足りてなく頑張って追いかけているという印象。 Chrome のほうが機能自体は豊富だし、攻めている。

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

Edge

Edge が Chromium ベースになることが発表されたので、今までの問題は忘れて良さそう。

ただ、 CHromium ベースになるまでは「使わない」のが一番。

Safari

Safari 11 にて対応。2018 年 12 月現在の最新版 12.0 では ontrack や addTrack を採用。ただし onremovetrack には非対応。

ただし Safari Techonlogy Preview では WebRTC に対して劇的な変化が起きている。

次のリリースで Safari は WebRTC 対応ブラウザとして Chrome や Firefox と同等に扱って良いだろう。

ちなみに、コーデックの統一を目指す http://aomedia.org/ に Apple が参加したので、 2019 年なにか動きがあるかもしれない。

アップル、動画圧縮技術の開発を目指すAlliance for Open Mediaに加盟 - CNET Japan

SVC

Simulcast が複数の解像度を複数の RTP で送るという考えに対して、レイヤー構造をうまく使うことで一つの RTP で実現したのが SVC という技術。

WebRTC では VP9 + SVC がでてきそうだが、まだ利用はできない。ちなみに H.264/SVC は会議システムでは広く普及している。

ただし SVC をサーバにて判断しビットレートをコントロールする技術は Vidyo 社がパテントとして持っているので要注意。 日本国内で利用する場合は Vidyo 社に確認する必要がある。

最近 Edge が SVC に力を入れ始めてきた。Skype で使いたいのだろうか。

Simulcast

WebRTC のクライアントが複数の解像度をを同時に送る方式。

SVC と似ているが実際に複数種類の形式を複数の RTP で送る技術。

基本的には SFU を挟む前提で利用される技術。SFU が視聴者が希望する画質を選択して配信することができるようになる。

最新の RFC 的な意味では a=simulcast と a=rid を利用してとして実装されている。ただ 2018 年 12 月の時点で Firefox のみが対応でしており、Chrome や Safari は別実装。

Chrome は a=ssrc-group:SIM を使う事で対応させられる。これはクライアント側で SDP を書き換えて対応する必要がある。 Chrome は SDP の a=simulcast や a=rid への対応は未定。ここはどうなるかまだ見えない。

Simulcast を試したい場合は fippo/simulcast-playground: single-page simulcast tests を見てみるといい。

DataChannel

DataChannel を利用しているサービスは P2P CDN が多かったが、最近だと Google がクラウドゲーミングやリモートデスクトップに利用している。

P2P CDN 系は Peer5 - The Serverless P2P CDN For Video Live StreamingStreamroot | Distributed Network Architecture for OTT Video Delivery がメジャーどころ。

WebTorrent - Streaming browser torrent client は WebRTC を利用した BitTorrent。

既存の SCTP over DTLS である DataChannel はここ最近変更が入っていない。完成されたプロトコルということなのだろう。

2019 年 01 月現在、 SCTP over DTLS の代わりに QUIC を使うという話が出てきており、温度感は高い。

QUIC API for WebRTC

特に QUIC 対応は Edge が積極的に対応していきたいようだ。

mDNS

間違いがある場合は Twitter で @voluntas までリプライを飛ばしてほしい

Chrome Canary M74 からは mDNS という機能が入った。これはローカルなアドレスを匿名化するという仕組み。

a=candidate:2912272267 1 udp 2122262783 70df6acb-ac40-472a-a747-6c1c5404b4c2.local 60790 typ host generation 0 network-id 2 network-cost 10
a=candidate:505434299 1 udp 2122194687 88df39c4-092e-42a5-be00-f028e92cfc23.local 60651 typ host generation 0 network-id 1 network-cost 10
a=candidate:3809887099 1 tcp 1518283007 70df6acb-ac40-472a-a747-6c1c5404b4c2.local 9 typ host tcptype active generation 0 network-id 2 network-cost 10
a=candidate:1352903755 1 tcp 1518214911 88df39c4-092e-42a5-be00-f028e92cfc23.local 9 typ host tcptype active generation 0 network-id 1 network-cost 10

本来 IP アドレスが入っている場所が <UUID>.local という形式に変わっている。これはローカル IP アドレスを隠蔽するためのしくみ。これを利用することでローカル IP アドレスが不特定多数に漏れる必要がない。このアドレスを逆引きできるのは同じネットワークに属しているものだけとなる。

Using Multicast DNS to protect privacy when exposing ICE candidates

ORTC

2018 年 12 月の時点でほとんど気にしなくて良い。 Edge しか今のところ対応していないし、 Chrome/Firefox/Safari が追従する気配はまったくない。

ORTC の仕組みをうまく WebRTC NV に持っていくという形になると思う。

ちなみに淡々と ORTC の仕様は更新されている。

w3c/ortc: ORTC Community Group specification repository (see W3C WebRTC for official standards track)

Screen Capture

Screen Capture

通称画面共有機能。需要がある割に結構ブラウザ側から扱いが悪い機能。

Chrome

Chrome M72 で getMediaDisplay が利用できるようになった。これで Chrome 拡張なしで画面共有が利用可能になる。

Firefox

Extension 不要で対応可能。

Safari

Safari TP で開発者メニューから Screen Capture を有効にすることで対応可能。

Edge

Screen Capture API に対応済み。

WebRTC NV

WebRTC NV は低レイヤーの API 、QUIC 、 AV1 という3つがコアとなることが Google から発表された。

Rtp や Dtls といった低レイヤーの API 、DTLS-RTP や SCTP over DTLS を QUIC に置き換え、映像周りは AV1 にするというのが当面のゴールになるようだ。

JavaScript

JavaScritp 側の API についてはここでは省略する。 WebRTC アプリケーションを書く場合はとにかく JavaScript 力を付ける事が最優先だろう。

HTTPS

  • Chrome は getUserMedia が HTTPS のみでしか使用できない。ただローカルホストからのアクセスは許容してる
  • Firefox は HTTPS は必須ではないが、警告がでる
  • Edge は当面は HTTP でも問題ないという方針で行くようだ
  • Safari は HTTPS のみで、ローカルホストからのアクセスもできない

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

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

マルチストリーム

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

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

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

RFC 8108 - Sending Multiple RTP Streams in a Single RTP Session

RFC にもなっているので、今後主流になる。Edge 以外は対応している。

Unified Plan

Firefox は対応済み、Chrome M70 で対応済み、Chrome M72 で Unified Plan がデフォルトになった。Safari TP 67 で選択可能に

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

これが正しい方向。Chrome などは古い規格。

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

Plan B

もう過去の規格になりつつあるので、2019 年 01 月のタイミングで気にする必要はない。

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

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

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

新しい SRTP/SRTCP の暗号方式が RFC 7714 - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) にて RFC 化された。

Chrome であれば chrome://flags で AES-GCM を有効にできる。

コーデック

映像

現在は VP8 がデファクト。Safari TP が VP8 に対応したことで一層 VP8 が流行りそう。

映像はハードウェアアクセラレータへの対応がモバイルではかなり有効になる。ハードウェアアクセラレータ は Android の端末依存で VP9/VP8/H.264 に対応しているのがある。 iOS は H.264 のみへの対応。

Chrome / Firefox と iOS や Android のネイティブだけであれば VP9 を選択することをオススメしたい。

AV1

WebRTC での対応はかなり先なのであくまで参考程度に読んでほしい

VP10 がキャンセルされ、もっとオープンな AV1 が進んできている。

AOMedia Video 1 - Wikipedia

2018 年 3 月 28 日に AV1 の仕様が発表された。

Get Started – Alliance for Open Media

Apple が AOMedia に参入した事もあり、動きがある可能性がある。

Chrome M70 で AV1 decoder が入った。これはあくまで再生できるだけ。WebRTC とは一切関係ない。

2019 年後半で WebRTC に AV1 が入ることが Google のイベントで発表された。

Firefox 65 で AV1 が再生できるようになったが、これは WebRTC とは関係ない

H.265

Safari のみになるとはおもうが H.265 が出て来る可能性は否定できない。

H.265/HEVC特許暗黒時代 - Qiita

Safari 以外に載ることはないと思っている。

音声

Opus でほぼ確定。こっから動く事はなさそう。あとはどこまで Opus の機能が渡せるか。 ステレオだったり、音質だったり色々。

ブラウザ

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

音声コーデックは全て OPUS を採用している。

Chrome

VIDEO コーデック:VP8, VP9, H.264
マルチストリーム:Unified Plan / PlanB
サイマルキャスト:VP8 / H.264

Firefox

VIDEO コーデック:VP8, H.264, VP9
マルチストリーム:Unified Plan
サイマルキャスト:VP8

デフォルトビデオコーデックに VP9 を採用している。

Edge

VIDEO コーデック:H.264, VP8
マルチストリーム:非対応

Chromium ベース待ち。

Safari

VIDEO コーデック:H.264 / VP8
マルチストリーム:Unified Plan / PlanB
サイマルキャスト:VP8 / H.264
  • Simulcast H.264 と VP8 に対応
  • TP 66 にて Unified Plan へ試験的に対応
  • TP 67 にて VP8 へ試験的に対応
  • TP 68 にて VP8 へ対応

最新の状況

W3C WebRTC WG Meeting の資料を見るのが一番速い。

広告

WebRTC SFU Sora

WebRTC SFU Sora

商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。

複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。

パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。

サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分です。

  • 大変多くのお客様に採用いただいております
  • とにかく 落ちないこと を目的に作っています
  • とにかく 繋がること を目的に作っています
  • とにかく 手間がかからないこと を目的に作っています
  • 最新ブラウザのアップデートに追従しています
  • シグナリングサーバ内蔵ですので別途立てる必要はありません
  • TURN サーバ内蔵ですので別途立てる必要ありません
  • 日本語によるサポート対応しています
  • フルスクラッチ自前実装なのですべて把握しています
  • 1:1 の双方向に対応しています
  • 1:300 の片方向に対応しています
  • 3:300 といった配信者が複数の片方向にも対応しています
  • スポットライトという機能を利用することで 10 人以上で 1 つの会議が可能です
  • 録画機能があります
  • Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
  • Apache 2.0 ライセンスで JavaScript と iOS と Android のクライアント SDK を公開しています
  • Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
  • 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
    • 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます

興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。

紹介や検討資料も公開しております。

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