Skip to content

Instantly share code, notes, and snippets.

@voluntas

voluntas/webrtc.rst

Last active January 23, 2024 06:57
Show Gist options
  • Star 316 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save voluntas/59a135343538c290e515 to your computer and use it in GitHub Desktop.
Save voluntas/59a135343538c290e515 to your computer and use it in GitHub Desktop.
Download ZIP
WebRTC の未来
Raw
webrtc.rst

WebRTC の未来

更新

2022-03-18

作者

@voluntas

バージョン

2022.1

URL

http://voluntas.github.io/

image

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

概要

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

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

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

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

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

用語

Safari TP

Safari Techonlogy Preview

SFU

Selective Forwarding Unit

今後

P2P

今のところ P2P に関して何か新しい方針は出ていない。

SFU

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

  • 商用の WebRTC サービスを提供している Twilio や Tokbox は自社開発の SFU を利用している
  • Discord はユーザ数 2.5 億人という大規模な世界で独自開発した SFU を運用している
  • Google Meet も WebRTC SFU を利用している
  • Google Duo も WebRTC SFU を利用している
  • Apple FaceTime for Web も WebRTC SFU を利用している
  • Epic Games に買収された Houseparty も WebRTC SFU を利用している。

いままでウェブ会議の主力だった MCU もコールセンターや IP 電話との併用であれば今後も利用されているが、 あくまで MCU は WebRTC はおまけ、という立ち位置だろう。

理由としては MCU は CPU リソース利用しすぎるため、サービスの価格を抑えることが難しいからだ。 また End to End Encryption (E2EE) も MCU では仕組み上は利用できない。

仕様

WebRTC 1.0 の仕様は 2020 年の前半には決めていきたいという思いがあるようだ。 またブラウザ同士の差も吸収していきたいという話が出ている。これは朗報だろう。

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

とはいっても 2020 年 5 月現在では Chrome と Edge はほぼ同じ、 Safari が少し遅れていて、 Firefox が脱落気味だががんばろうとしているという状況。

VP8

全てのブラウザで VP8 が利用可能。

IETF 準拠のサイマルキャストはすべてのブラウザで動作する。ただし Firefox は一部不安定。

VP9

現時点で Safari 以外のブラウザが対応済み。 Safari 14 で実験的機能として VP9 へ対応した。 Safari TP では VP9 がデフォルトには有効になっている。Safari 15 で VP9 が利用できるようになった。

AV1

WebRTC で AV1 は普通に動いている

2022 年 3 月時点の libwebrtc ではすでに AV1 は利用可能だ。 Chrome M90 以降で AV1 が WebRTC で利用可能になっている。

ただし CPU 使用率は VP9 の 2 倍程度あると考えてもらってよい。今後これは改善されていくだろう。

H.264

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

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

Chrome、 Safari 、Edge で H.264 Simulcast が動作する。

注意する点としては Android では端末依存により HWA がうまく機能せず問題が出る場合がある。

H.265

WebKit (Safari) が WebRTC の H.265 に対応した。 ハードウェアエンコーダ/デコーダにも対応済みで、Safari 14 でも実験的機能として利用可能。

image

ただし H.265 はパテント地獄なのでどうなるか ... 。

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

Chrome

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

  • Chrome M90 から AV1 が有効可能になる
  • Chrome M91 から WebTransport (over HTTP3) がフィールドトライアルとして有効になった

Firefox

基本的な機能を実装しているが、現時点では libwebrtc のバージョンが数世代遅れていることもあり、 リソースがかなり足りてなく回っていない印象。

2022 年 3 月の時点で Chrome のほうが機能自体は豊富だし、安定している。

Chrome ではつながるが Firefox ではつながらないという環境も出てきている。

  • Firefox 78 で rid ベースの Simulcast に一部対応した

Edge

Chrome とほぼ同等と考えて良い。AV1 に対応していないなど、一部対応していない部分もある。

Safari

  • Safari 15 で VP9 へ対応
  • Safari 14 で実験的機能として VP9 へ対応
  • Safari 14 で実験的機能として H.265 に対応
  • Safari 13 で画面共有機能に対応した。ただし、ブラウザのタブとかは選択できず、全画面のみ

SVC

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

WebRTC では VP9 + SVC が Chrome Canary で利用可能になる。ちなみに H.264/SVC は会議システムでは広く普及している。

Simulcast

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

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

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

最新の RFC 的な意味では a=simulcast と a=rid を利用してとして実装されている。 2022 年 3 月の時点で Chrome / Edge / Safari/ Firefox が rid ベースを実装済み。

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

DataChannel

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

最近では Google は DataChannel に利用されている SCTP ライブラリを自前で開発し始めている。

PSA: dcSCTP Library

プロトコル的に十分枯れており、安定した実装ということでリアルタムメッセージには積極的に利用して良い。 もし WebTransport がきたとしても、クライアント側の移行には時間がかかるだろう。

mDNS

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

Screen Capture

Chrome、Firefox、Safari、Edge 全てのブラウザが getDisplayMedia に対応済み。 ただし、モバイル版では一切対応していないので注意して欲しい。

Screen Capture

WebRTC Encoded Transform

Insertable Streams から名前が変更された

RTP パケタライゼーション前のデータを書き換えられる仕組み。これを利用することで E2EE やメタデータの埋め込みが実現可能になった。

Chrome M86 から Chrome / Edge で搭載。Safari TP でも実験的機能として搭載している。

WebRTC NV

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

WebCodec などの低レイヤーの API 、DTLS-RTP や SCTP over DTLS を WebTransport に置き換え、 映像周りは 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 にもなっているので、今後はマルチストリームありきとなっていく。

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 化された。Firefox は AES-GCM を利用する。Chrome ではデフォルトで AES-CTR を利用する。

Apple FaceTime for Web では強制的に AES-GCM を利用してみる。

コーデック

映像

現在は VP8 がデファクト。Safari が VP8 に対応したことでまずは VP8 一択と考えて良い。

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

AV1

RTP Payload Format For AV1

H.265

Safari への搭載が確定した。

Add initial support for WebRTC HEVC

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

Safari 以外に搭載される可能性は低いが、追従するとしたら OS を持っている Edge はありえる。

音声

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

最近では multiopus といった 7.1 / 5.1 の音声を配信できる技術も入った。

Google が Lyra という 3kbps で高音質な音声コーデックを発表

Google AI Blog: Lyra: A New Very Low-Bitrate Codec for Speech Compression

ブラウザ

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

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

Chrome

VIDEO コーデック

VP8, VP9, H.264, AV1

サイマルキャスト

VP8 / H.264

Firefox

VIDEO コーデック

VP8, H.264, VP9, AV1

サイマルキャスト

VP8

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

Edge

VIDEO コーデック

VP8, VP9, H.264

サイマルキャスト

VP8 / H.264

Safari

VIDEO コーデック

H.264 / VP8 / VP9

サイマルキャスト

VP8 / H.264

Safari 15 で VP9 に対応。 H.265 は未定。

WebTransport

WebTransport

Chrome M97 から利用可能になった。

WebTransport は HTTP/3 を利用したトランスポートの仕組み。 QUIC ベースなので UDP 前提。 フォールバック先は WebTransport over HTTP/2 となる。

An Unreliable Datagram Extension to QUIC

保証がない QUIC の Datagram 拡張を利用する。

WebTransport については別に書いてあるので、興味ある人はどうぞ。

WebCodecs

Chrome M94 から利用可能になった。

MediaStreamTrack API for Insertable Streams of Media

Stream の Track に対して Insertable Streams を引っ掛けられるためキューなどの管理をする必要がなくなる仕組み。

w3c/mediacapture-insertable-streams

Native E2EE Encryption

SFrame の処理を Native API を用意してしまおうという取り組み。

webrtc-insertable-streams/modifications.md at modif · youennf/webrtc-insertable-streams

広告

WebRTC SFU Sora

WebRTC SFU Sora

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

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

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

サーバと証明書さえ取得してあれば起動までは 10 分です。 HTTPS が必須なのでその準備が必要ですがそれさえ対応できればすぐ確認可能です。

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

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

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

Sora Cloud

URL

https::/sora-cloud.shiguredo.jp/

Sora のクラウド版です。 Sora を運用、構築する必要なく利用が可能です。

WebRTC Native Client Momo

WebRTC Native Client Momo

GitHub にオープンソースで公開している WebRTC のネイティブクライアントです。 Linux と macOS と Windows で動作します。

  • OpenMomo プロジェクト
  • ライセンスは Apache License 2.0 です
  • 多くの端末のハードウェアエンコーダに対応しています
    • Raspberry Pi Zero という非力デバイスでも H.264 ハードウェアエンコーダを利用し 720p@30 で配信可能です
    • Jetson Nano ではハードウェアエンコーダを利用することで 4K@30 で配信可能です
    • macOS でもハードウェアエンコーダを利用して動作します
  • SDL (Simple DyanmicMedia Layer) を利用することで受信した音声と映像を表示する機能を持っています

WebRTC Signaling Server Ayame

WebRTC Signaling Server Ayame

GitHub にオープンソースで公開している WebRTC のシグナリングサーバです。 Linux と macOS と Windows で動作します。

Ayame Labo

Ayame Labo

Ayame 完全互換のサービスを時雨堂が提供しています。

  • 無料で使えます
  • サインアップしないでも使えます
    • ただし STUN/TURN や認証機能などは利用できません
  • GitHub アカウントを持っていればすぐに利用できます
  • TURN の UDP / TCP / TLS を提供します
  • ルームに認証をかけられます
    • シグナリングキーを提供します
  • 認証ログを確認できます

Sora Labo

Sora Labo

Sora を検証用に無料でサービスとして提供しています。

  • 無料で使えます
  • 商用目的では使えません
  • GitHub アカウントを持っていればすぐに利用できます
  • TURN の UDP / TCP / TLS を提供します
  • チャネルに認証をかけられます
    • シグナリングキーを提供します
  • 同時接続数制限があります
  • 認証ログを確認できます
  • 統計情報を確認できます
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment