Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
WebRTC の未来

WebRTC の未来

更新:2017-07-23
作者:@voluntas
バージョン:3.1.0
URL:http://voluntas.github.io/

概要

仕事で WebRTC を扱っているついでに、調べた最新の WebRTC 状況や今後についてまとめている。

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

注意

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

間違いについて

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

今後

サーバ

WebRTC は P2P メインというよりは SFU を利用したサーバ経由が強くなってきている。 実際 WebRTC サービスを提供している Twilio や Tokbox は両方共 SFU を利用している。また Microsoft が提供している Mixir という配信サービスでも SFU を利用している。

もちろん MCU もコールセンターや IP 電話との併用であればよく利用されているが、あくまで MCU は WebRTC はおまけ、という立ち位置だろう。

仕様

WebRTC 1.0 が 2017 年中には落ち着きそうだ。またブラウザ同士の差も吸収していきたいという話が出ている。これは朗報だろう。

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

VP9

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

ただし iOS 向けの WebRTC ライブラリではフラグになっており、有効にする場合は指定が必要。

H.264

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

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

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

さらに Safari は VP8 や VP9 を採用せず、H.264 のみを採用した。そのため Safari と通信できるのが H.264 のみとなる。 一旦は H.264 が WebRTC のコーデック世界を取る形になりそうだ。

Chrome

順調に libwebrtc に追従していっている。最新の機能をいれつつも、安定化もさせていっている印象。 課題は WebRTC 1.0 API への追従がなされていないところか。今後頑張るようなので見守りたい。

Firefox

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

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

Firefox 55 で VP8 の Simulcast が入るようだ。

Edge

ソースが読めないのが一番の問題点。WebRTC 1.0 にどう対応したのかも見えない。 さらに細かい部分でおかしな点が多い。2017 年 7 月の時点では正直、動く以上のことは期待しない方が良い。

Safari

Safari 11 にて対応予定。2017 年 7 月の時点では Safari Technology Preview 32 以降で確認が可能。 レガシー API は破棄される。そのため ontrack や addTrack ベースになる、第三の仕様。

マルチストリームには対応しているが PlanB 。PlanB で ontrack なので Chrome と Firefox を足して 2 で割ったような仕様。 ただ、libwebrtc への追従は頑張るような感じはある。 Firefox よりは追従が早そう。

ただしビデオコーデックは H.264 固定、これは HWA を利用できるメリットを最大限に使っていく方針とのこと。

SVC

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

WebRTC では Chrome + VP9 + SVC がでてきそうだが、どうなるか不明。 H.264/SVC は会議システムでは広く普及している。

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

Simulcast

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

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

Firefox が 47 でフェーズ 1 として実装された。 a=simulcast として実装される。ただ 2017 年 6 月の時点でも実装はあまり進んでいないため、あまり焦る必要はない。

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

ORTC

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

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

WebRTC NV

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

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

動きが全く見えないので気にしなくて良い。

JavaScript

JavaScritp 側の API については詳しくないのでここでは省略するが、わかっていることとしては Multi-stream を前提とした実装になったタイミングで、かなりの JavaScript 力が求められると見ている。ただ普通は Multi-stream は利用しないので心配しなくて良い。

WebRTC アプリケーションを書く場合はとにかく JavaScript 力を付ける事が最優先だろう。またブラウザ互換を考えると Adapter.js になれるのがよい。

HTTPS

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

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

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

Multi-stream

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

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

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

Unified Plan (Plan A)

Firefox のみ

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

これが正しい方向。Chrome などは古い企画。

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

Plan B

Chrome と Edge と Safari

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

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 を有効にできる。

Codec

映像

現在は VP8 がデファクトだが Safari が H.264 のみに対応したことにより H.264 が主力になりそう。 現時点で主要 4 ブラウザはすべて H.264 に対応している。

映像はハードウェアアクセラレータへの対応がモバイルではかなり有効になる。ハードウェアアクセラレータ は Android で一部は VP8/H.264 に対応、iOS は H.264 のみ。

VP9 に期待していたが、残念ながらまずは H.264 の時代がきそうだ。

音声

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

ブラウザ

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

Chrome

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

Firefox

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

Edge

VIDEO コーデック:H.264UC, H.264, VP8
DTLS:バージョン 1.2
Multi-stream:PlanB

Safari

VIDEO コーデック:H.264
DTLS:バージョン 1.2
Multi-stream:PlanB

参考

広告

WebRTC SFU Sora

WebRTC SFU Sora

世界でもまだほとんど無いはずの商用 SFU です。価格は 100 接続で年間利用料ライセンス 60 万円です。毎年かかります。なんと製品のサポート料金込みです。

  • とにかく 落ちないこと を目的に作っています
  • とにかく 繋がること を目的に作っています
  • とにかく 手間がかからないこと を目的に作っています
  • 最新ブラウザのアップデート追従をしています
  • シグナリングサーバ内蔵ですので別途立てる必要はありません
  • TURN サーバ内蔵ですので別途立てる必要ありません
  • 日本語によるサポート対応しています
  • フルスクラッチ自前実装なのですべて把握しています
  • 1:1、1:N、複数人会議、録画あります
  • Apache 2.0 ライセンスで JavaScript と iOS のクライアントを公開しています
  • 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
    • 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます
  • 海外で利用される場合は該非判定書も用意しております

パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでもどうぞ。 サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分でいけます。

時間をお金で買いませんか?

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

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