Skip to content

Instantly share code, notes, and snippets.

@voluntas

voluntas/webrtc_simulcast.rst

Last active November 1, 2023 10:22
Show Gist options
  • Star 19 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save voluntas/dd3af733825c7ae64505a1fd1bd0d684 to your computer and use it in GitHub Desktop.
Save voluntas/dd3af733825c7ae64505a1fd1bd0d684 to your computer and use it in GitHub Desktop.
Download ZIP
WebRTC Simulcast コトハジメ
Raw
webrtc_simulcast.rst

WebRTC Simulcast コトハジメ

更新

2020-02-01

作者

@voluntas

バージョン

2020.1

URL

https://voluntas.github.io/

image

この記事が良いと思ったらこの記事に Star を是非

概要

SFU での利用前提で書いてあるので、 P2P でしか WebRTC を利用していない人は読む必要はない

Simulcast は配信側が複数の画質を配信するという仕組みで、 WebRTC SFU に向けた機能。 現時点では Chrome / Firefox / Safari / Edge と主要ブラウザに全て実装されている。

ただ、 Safari の実装は SDP の ssrc-group を利用した機能で、古い機能。 新しいのは SDP の RID を利用した仕組みで Chrome / Firefox / Edge が対応している。

2020 年 2 月時点で libwebrtc が RID ベースの Simulcast の実装が一段落している。 この資料は rid と simulcast を利用した Simulcast の仕組みについて解説する資料。

WebRTC SFU のデメリット

WebRTC はもともと P2P を前提として考えられた仕組みのため、一つの配信を複数のクライアントに配信するという仕組みではない。 たとえば 1 クライアントが 2 クライアントに映像を配信する場合は、２つの映像をそれぞれの環境に合わせてエンコードするという仕組みが取られる。

不安定な回線のクライアントと、安定した回線のクライアントに送る映像の画質は異なるのは当たり前の仕組みだ。

ただ、SFU はそうではない。SFU は配信を代理する仕組みなので、すべてのクライアントが同じ画質の映像が送られるという問題がある。

Simulcast のメリット

WebRTC SFU のデメリットを解決してくれるのが Simulcast という機能になる。 クライアントは複数の画質の映像を SFU に送る。SFU はクライアントの状況に合わせて画質を選択することができるようになる。

実際の動作については自社製品で恐縮だが、 1 つの映像を 3 の画質として SFU に配信して、それぞれの画質で受信している動画を参照してほしい。

https://www.youtube.com/watch?v=niytb3bsF3Q

3 つも同時に映像を変換するのは配信側の負荷が高くなるのではないか？と思いがちだが、300% 増ではなく 30% 増程度なので安心してほしい。 一番高い解像度があり、それの半分つまり解像度的には 1/4 、そしてそれの半分 1/8 というサイズのため CPU 使用率は極端に増加しない。

Simulacst の仕様

ここでは、今後なくなっていく SDP の SSRC-GROUP ベースの仕様については省略することにする。 標準化が進んでいる RID ベースの仕組みを説明していく。

SDP 的に、送信側はこのような形になる。つまり 3 種類の画質を送るという仕組みだ。

a=rid:0 send max-width=1280;max-height=720;max-fps=30
a=rid:1 send max-width=640;max-height=360;max-fps=15
a=rid:2 send max-width=320;max-height=180;max-fps=15
a=simulcast: send rid=0;1;2

a=rid

RID は RTP Stream Identifier の略で、 RTP 拡張としてその Stream に対して ID を指定できるようになる。 この機能を使うことで SSRC を一切利用しない仕組みに切り替わる。

ただし、この機能を利用するには RTP 拡張を指定する必要がある。

Chrome Canary M75 の SDP より引用:

a=extmap:13 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:14 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

RID を使えることが Simulcast を利用することの最低条件となる。

a=simulcast

SDP の simulcast の役割は rid で定義した ID を利用し、それを simulcast として利用することになる。

a=simulcast: send rid=0;1;2

これは rid で指定した 0,1,2 の解像度を配信し、受信としては rid=3 で指定した形式を受信したいという SDP になる。 a=simulcast 自体は rid をまとめる以上の役割はないので、とてもシンプルになる。

RepairedRtpStreamId

FEC / RED / RTX を利用する場合、いままでは ssrc-group: FID を利用していたが、 rid を利用することで SSRC が一つにまとめられるため、送られてきた FEC などの Payload Type がどの RtpStreamId に結びついているかわからないという問題を解決する仕組み。

rid=1 で定義した映像に紐づく RTX パケットは RTP 拡張の RepairedRtpStreamId に 1 が入ってくるという仕組み。あとは Payload Type で判別することになる。

このことにより今まで 1 つの SSRC に対してそれぞれ FEC / RED / RTX をそれぞれ定義していた Payload Type が省略できるようになる。

現時点でのブラウザの対応

Chrome

Chrome M79 で VP8 と H.264 の Simulcast に対応している。rid ベースに対応。

RID を利用するための rtp-stream-id 拡張に対応している。

Firefox

Firefox 72 にて a=simulcast の仕様が独自だったのが RFC 準拠になった。

pt= and rid= in WebRTC simulcast attributes are no longer supported (Affecting) | Firefox Site Compatibility

RID を利用するための rtp-stream-id 拡張に対応している。

Safari

Safari は libwebrtc がかなり古いことから、どのタイミングで rid ベースに対応するかは謎

Safari 12.1 で VP8 と H.264 の Simulcast に対応している。ただし RID ベースではなく SSRC-GROUP ベースになる。

Edge

Chrome と同じ。 Chrome M79 で VP8 と H.264 の Simulcast に対応している。rid ベースに対応。

RID を利用するための rtp-stream-id 拡張に対応している。

まとめ

Simulcast は WebRTC SFU を利用する場合の主流となるのは間違いない。ただ実装コストはとても高い。 さらにこの機能をマルチストリームと組み合わせて実装するとなると、そう簡単には実装するのは難しいだろう。

ただ、技術的難易度は高いが WebRTC SFU の欠点を補うための仕組みであると言える。

参考

RFC ドラフト

WebRTC Issues

広告

WebRTC SFU Sora

WebRTC SFU Sora

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

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

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

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

  • Simulcast に対応しています
  • 大変多くのお客様に採用いただいております
  • とにかく 落ちないこと を目的に作っています
  • とにかく 繋がること を目的に作っています
  • とにかく 手間がかからないこと を目的に作っています
  • 最新ブラウザのアップデートに追従しています
  • シグナリングサーバ内蔵ですので別途立てる必要はありません
  • TURN サーバ内蔵ですので別途立てる必要ありません
  • 日本語によるサポート対応しています
  • フルスクラッチ自前実装なのですべて把握しています
  • 1:1 の双方向に対応しています
  • 1:300 の片方向に対応しています
  • 3:300 といった配信者が複数の片方向にも対応しています
  • スポットライトという機能を利用することで 50 人以上の会議に対応しています
  • サイマルキャストに対応しています
  • 録画機能があります
  • 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