更新: | 2018-10-20 |
---|---|
作者: | @voluntas |
バージョン: | 18.10.1 |
URL: | https://voluntas.github.io/ |
こちらの資料は更新を終了しています、最新版は以下を見てください
Contents
WebRTC における Simulcast が現実的になってきました。この資料では WebRTC SFU と Simulacst の組み合わせて何が実現できるのか、何が嬉しいのか、何が課題なのかについて書いていきます。
この資料は WebRTC 関連の知識を要求するので、以下は読んだ前提で書いていきます。
WebRTC における Simulcast とは WebRTC クライアントが映像を複数の画質で同時に送る技術です。P2P ではほとんど意味はありませんが、 WebRTC SFU と組み合わせることで WebRTC SFU で アダプティブ・ビットレート (ABR) を実現することが可能になります。
通常 WebRTC SFU で配信を行う場合、配信者は1つの画質しか配信しないため、視聴者側は配信者の配信する画質を 受信できる 必要があります。
例えば配信者がフル HD で 5000K ビットレートで配信していた場合、視聴者も 5000K の帯域を必ず持っている必要があります。 WebRTC SFU を利用して BtoC や CtoC で配信する場合は視聴者側の帯域は様々です。そのため WebRTC SFU を利用した配信には限界がありました。
ただ Simulcast を利用することでこの問題を解決することができるようになります。
Simulacst は通常 1 画質を最大 3 画質までを同時に WebRTC SFU に送ることが可能になります。
最大といったのは Chrome の Simulcast は利用可能なビットレートが下がることで同時に配信する画質を動的に減らします。もちろんビットレートが上がれば配信する画質を動的に増やします。
WebRTC SFU は配信者から送られてきた最大 3 の画質の映像を視聴者側が求める画質に合わせて配信します。
例えば Chrome で HD で 2500K の配信を Simulcast を有効にして配信した場合は以下のような映像が配信されます。
解像度 | ビットレート | 画質 |
---|---|---|
HD | 2500K | high |
VGA | 500K | middle |
QVGA | 150K | low |
この場合、 WebRTC SFU は high, middle, low の画質の映像を受信します。そしてそれを視聴者が要求する画質に配信を行います。
Simulcast を利用した固定配信が可能なことはここまで書いてきました。では自動判定はどう実現すればいいのでしょうか?
WebRTC には帯域推定という仕組みが存在します。それを利用することで視聴者が利用可能なビットレートを WebRTC SFU に送ってきます。
その帯域推定を利用し、 WebRTC SFU は視聴者に最適な画質の映像を配信するという事が実現可能だと考えています。
ちなみに、実際 HLS や MPEG-DASH の ABR を WebRTC SFU で実現できるようになります。実際クライアントが変換して送ってきてくれることもあり、WebRTC SFU 側で変換する必要もありません。
現時点では Chrome と Firefox と Safari (Techonology Preview 67 以降) が対応しています。
問題は Chrome と Firefox で Simulcast を利用するための SDP が異なります。 Chrome と Safari が古い仕様で、 Firefox が新しい仕様です。
ブラウザ | SDP | 画質 | コーデック |
---|---|---|---|
Chrome | SSRC-GROUP | ハードコード | VP8 |
Firefox | RID/SIMULCAST | 指定可能 | VP8 |
Edge | 非対応 | ||
Safari | SSRC-GROUP | ハードコード | VP8/H.264 |
コーデックは現時点で Chrome と Firefox が VP8 で、 Safari は VP8 と H.264 両方が動きます。 libwebrtc の master には H.264 対応のコミット も入っています。Safari はこの仕様を先に組み込んだのでしょう。
視聴側は特別な仕組みは不要のため、 VP8 や H.264 さえ見られれば問題ないので、
複数の解像度を変換するため、配信者の CPU 使用率が跳ね上がってしまうのではないかという疑問におもいませんか?、私もそう考えておりました。ただ、現実は先程の 2500K / 500K / 150K の 3 種類であれば 2.5M を配信するよりも 30% 程度 CPU 使用率が上がる程度ですので安心してください。
30% 程度の理由としては、ソースは一つだけであること、HD,VGA (HD の 1/4),QVGA (HD の 1/16) と半分ずつの解像度になっていることから 100 * 1/4 + 100 * 1/16 で 31% 増ということで、CPU 使用率と一致するという感じのようです。
WebRTC SFU と Simulcast を組み合わせて利用することで、超低遅延での配信で ABR を実現することが可能になります。
既存の配信の仕組みに比べて WebRTC SFU を利用した超低遅延で配信が可能になる需要は少しずつ増えてきています。その中で複数ビットレートの配信が難しかった問題を Simulcast は解決してくれます。
WebRTC SFU と Simulcast の相性はとても良く、実際に本番で採用されていくのも近いと考えています。