マルチストリーム

概要

マルチストリームとは一つの PeerConnection の中で複数の映像や音声を動的に追加したり削除したりする仕組みです。これを利用することで、複数の PeerConnection を管理せずに複数の映像や音声を使用することができるようになります。

現在は Firefox と Chrome と Safari で実装されており、マルチストリームを使用することが可能です。 しかし Chrome と Safari は Plan B と呼ばれる古い仕様を実装しており、今後は Firefox が実装している Unified Plan と呼ばれる仕様に統一されてい行きます。 Chrome は 2018 年内で Unified Plan への切り替えを宣言し、 Chrome Canary M70 ではすでに問題なく `Unifed Plan`_ が動作しています。

Sora では Plan BUnified Plan 両方に対応しているため、ブラウザがどう変わったとしても問題ありません。 Sora 側で Plan BUnified Plan の差分の吸収を行っています。

Safari が Unified Plan へ移行するかどうかは全くわからないため、当面は Plan B との並行運用になると考えていただいて問題ありません。

注意

Edge の対応

Windows 10 Creators Update (1703) の Edge ではマルチストリームは動作しません。

Safari で onremovetrack 発火しない

Safari 12.0 では onremovetrack が今のところ発火しません。

Chrome におけるコーデック指定の先勝ち

Chrome や webrtc.org の libwebrtc ライブラリを使用した場合はコーデック指定はそのチャネルで入った人のコーデックが優先されます。 これは Plan B により配信または視聴に使用可能な映像コーデックが一つしかない仕様による問題です。

一部非対応機能

  • RTX 機能には対応しておりません

仕様

シグナリング

マルチストリームを使用する場合は、通常のシグナリングとは異なる仕組みを採用しています。

"type": "connect"

{
    "type": "connect",
    "channel_id": "<チャネルID>",
    "role": "upstream",
    "multistream": true,
    "metadata": "<ユーザ定義データ>",
    "video": {
        "codec_type": "VP9",
        "bit_rate": 800
    }
}

"multistream": true を追加します。JavaScript 側の実装がかなり変わることになります。

ブラウザの仕様自体が変わっていっているためうまく説明することが難しいのが現状です。

"type": "update"

マルチストリームでは通常の connect/offer/answer 以外に、update を使用します。新しくクライアントが接続したり、切断した際に送られてきます。そしてクライアントからも update で返す必要があります。 "type": "update" は sdp が入っているだけのシンプルなもので、 受信したら offer と同じように処理してください。 demo 機能の multi_pubsub.html を参考にしてください。

Sora から送られてくる "type": "update"

{
    "type": "update",
    "sdp": ".."
}

クライアントから Sora に送る "type": "update"

sdp には createAnswer で生成した SDP を入れてください。

{
    "type": "update",
    "sdp": ".."
}

Chrome 対応

Chrome や libwebrtc を使用している場合はシグナリングに "plan_b": true を指定する必要があります。今のところ plan_b フラグを true にする必要がないのは Firefox のみです。

{
    "plan_b": true,
    "type": "connect",
    "channel_id": "<チャネルID>",
    "role": "upstream",
    "multistream": true,
    "metadata": "<ユーザ定義データ>"
}

ビットレート分割機能

マルチストリームでは複数の映像を大量に受信するため、配信側のビットレートをコントロールする仕組みが入っています。 そのため、マルチストリームにおける video の bit_rate は通常の bit_rate とは扱いが異なります。

例えば bit_rate を 1200 と指定した場合 2 人で配信している場合はそれぞれ配信に 600kbps ずつ使用します。 ここに 1 人が追加して 3 人になると一人 400kbps ずつ使用して配信するようになります。

またここに 5 人が追加して 8 人になると、1 人 150kbps ずつ使用して配信するようになります。

配信の合計のビットレートを指定するのが video の bit_rate です。

同じチャネルに参加している人が異なる bit_rate を指定した場合

2 人が参加している状態で 1 人は 500 、もう 1 人は 1000 を指定した場合、 Soraは 500 を指定した人は配信に 250kbps を使用し、 1000 を指定した人は配信に 500kbps を使用します。

upstream と downstream

マルチストリームでも role には upstreamdownstream を指定することができます。

  • usptream は配信と視聴を行います
  • downstream は視聴のみを行います

upstream が 3 名いて downstream が 5 名いるといった場合、全員の画面に表示されるのは 3 名の映像です。

デモ

デモを用意してあります、 デモ機能 を有効にしてご使用ください。

Sora がインストールされているサーバの IP アドレスをここでは仮に 192.0.2.10 としています。

Sora にマルチストリームのサンプルを用意しています。Firefox と Chrome で動作が変わりますが、差分をクライアント側で吸収しています。 今後は SDK 側から意識せずにマルチストリームを使用できる仕組みを提供する予定です。

Sora を起動した後に、http://192.0.2.10:5000/multi_pubsub.html へ接続してみてください。

その後、別のタブで同様の URL を開いて、元のタブで動的に動画が追加されて表示されるかを確認してください。 また、後で開いたタブを閉じて動的に動画が消えていることを確認してみてください。

Chrome で試す場合は Chrome では HTTPS が必須なのですか? を参考にしてみてください