2018 年 8 月現在 Simulcast の現状

V
shiguredo
Published in
7 min readAug 10, 2018

WebRTC における Simulcast の現状について、WebRTC SFU 開発者視点でまとめていきます。

Simulcast について

P2P の場合は1つの配信で配信者の回線が不安定だったり、マシンパワーがなりない場合動的に解像度やビットレートを下げていきます。

逆に配信者の回線が安定していたとしても、視聴者の回線が不安定な場合は視聴者に合わせることがほとんどです。

SFU を利用した場合は配信者のビットレートに全ての視聴者が合わせる必要が出てきます。つまり配信者が高画質な配信をしている場合、回線が細い視聴者はほぼ止まった映像を見ることになります。

そこで Simulcast の登場です。Simulcast は複数の画質の映像を配信を同時に行う技術です。例えば 2.5M, 500K, 150K といったビットレートの映像を同時に配信します。

SFU がこの 3 種類の画質の映像を受け取った場合、視聴者には視聴者にあった画質を送りつけます。光回線で PC で見ている場合は 2.5M 、回線の不安定な Wifi で見ている場合は 150K といった感じです。

Simulcast と WebRTC SFU

Simulcast が生きるのは WebRTC SFU です。P2P では正直どう生きていくのか未だによくわかっていません。もし知っている方がいらっしゃったら教えてください。

WebRTC SFU にとって画質が配信者に引っ張られてしまう問題は悩みのタネでした。MCU では視聴者に合わせて再エンコードすればよいですが、SFU は変換は行わないため対策がありません。

そこで出てきたのが Simulcast です。配信者に複数画質の映像を送って貰えばいいという戦略です。

この戦略、自分は勘違いして理解していたのでここで正しておきます。自分は複数画質をクライアントが変換するのはとてもクライアントが重くなってしまい使い物にならないと考えていました。

例えば 3 種類であれば、1 種類の配信より 3 倍 CPU を食べると考えていました。

ただ、実はそんな事は無いようです。エンコーダーに詳しい方から教えていただきましたが、例えばビットレートが 2.5M,500K,150K の 3 種類であれば 1 種類の配信に比べて 30% 程度 CPU 使用率が上がるだけのようです。

理由はちょっと今の自分には説明ができないので、勉強しておきます。

この話を聞いてかなり衝撃を受けました。実際に自分でも動作を確認してみたところ、1 種類配信しているのとほとんど CPU 使用率は変わりませんでした。つまり懸念していた Simulcast を利用すると CPU 使用率が上がってしまうという問題はほぼほぼ解決していることになります。

つまり WebRTC SFU にとっての Simulcast 対応は避けて通れないということになります。

Chrome の Simulcast 状況

Chrome の Simulcast 状況ですが、SDP を自分で書き換えることで利用可能です。ただし、現行の RFC とは異なります。

SDP では ssrc-group 属性を利用しています。ssrc-group: SIM とし、ssrc を追加することで利用可能になります。ビットレートなどはまずはデフォルトが採用されます。これはハードコードされています。

ビットレートの変更は sender の getParameters の encodings の maxBitrate を書き換えることで動的に変更可能になっています。これは Chrome Canary M70 で確認したときの動作なので、今後の動作を保証するものではありません。

また現行は Plan B でのみ確認したため Unified Plan だとまた別の話になるかもしれません。

Chrome での Simulcast の動作を確認したい人は以下で試せます。

https://fippo.github.io/simulcast-playground/chrome

Firefox の Simulcast 状況

Firefox の Simulcast は Chrome とは違い RFC 準拠していってます。

SDP では a=rid と a=simulcast とい属性を利用しています。PayloadType すら独立する仕組みのため Chrome の動作と大きく異なるため互換性がまったくありません。そのため P2P では利用できない事がわかります。

また Firefox の Simulcast は正常に動作します。ただ、実施 rid の実装も足りていないため、どこまで実装されているのかが明確ではないのが問題です。

以下で Firefox の Simulcast が試せます。

https://fippo.github.io/simulcast-playground/firefox

Firefox の Simulcast 実装は RFC に準拠しており、今後に期待できるのですが、現状動作がよくわからないことが課題です。

Simulcast の今後

正直わかりません。Chrome が a=rid 方式に切り替わっていくのかどうかすらわかりません。a=rid/a=simulcast 方式を採用は当面はしないという話を見た記憶もあります、ただこれは記憶が怪しいです。a=ssrc-group: SIM で十分というのが現状の判断なのかもしれません。

そのため Simulcast を利用する以上は Chrome を利用するのが無難です。また現時点では VP8 でしか利用できません。ただ libwebrtc の master では H.264 に対応した Simulcast 実装がマージされています。

そのため、Chrome で H.264 を利用した Simulcast を利用するが流行るかもしれません。なんといっても iOS Safari に利用できるわけですし。

WebRTC SFU 作者でもない限りは正直 Simulcast を追いかけるメリットは今の所ありません。各 SFU ベンダーが出してくるであろう SDK を使って使うくらいで十分です。

WebRTC SFU Sora の対応

Chrome の配信のみ対応予定です。といっても最近開発に着手した状況なので早くてもリリースは年末だと考えていただいて構いません。

ただ、CPU 率がそんなに増えないで複数画質を配信できるのはとても素晴らしい技術だと考えています。

まずは動くところまで早めに報告できればと思います。

--

--