WebRTC を利用した配信の現実

超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。

ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。

せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。

P2P モデル

まずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。

WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。

さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。

ビジネスで P2P を配信に利用するのはとても現実的ではありません。

配信の場合は P2P で WebRTC という考えを捨てましょう。

クラサバモデル大規模配信

大規模配信を行う場合は P2P ではなく、あまり馴染みのない WebRTC でのクラサバモデルが前提となります。

P2P では配信者が直接視聴者に配信しますが、クラサバモデルの場合は、配信者は WebRTC サーバに配信します。視聴者と直接やり取りするのは WebRTC サーバになります。

WebRTC は UDP をベースとしているプロトコルで、さらに低遅延を目的としているため CDN を利用することはできません。

まず多くの配信を行うには CDN が前提となりますが、それが利用できないというのを念頭に置いていただければと思います。

さて、大規模配信ですが実際どのくらいを大規模というのでしょうか。感覚的に 1 万接続への配信は大規模だと感じています。

そのため 1 万接続以上への配信が WebRTC で可能かどうか、という話をここではしようと思います。

現実的には可能だと思います。ただ遅延は 200–300 ミリ秒ではなく 1 秒以内、程度のものになると思います。

この場合は複数の WebRTC サーバを多段型にすることで多くの接続へ配信をする仕組みが前提となります。

Image for post
Image for post

この仕組を利用することで、配信サーバを増やすことで同時配信数を増やすことができます。海外で WebRTC で大規模配信を実現しているサービスなどはこの仕組みをサービスとして提供しています。

ただし、HLS/MPEG-DASH が頑張れば 2–3 秒まで縮められる事を考えると WebRTC を利用した配信での 1 万接続以上を頑張るメリットはほとんどないでしょう。

そう考えると現実としては上の仕組みを使い最大 3000 接続までは WebRTC で配信を行い、それ以降は HLS での変換を同時に行うなどの仕組みが現実的だと思います。

3000 接続の配信 1000 あるだけで、実質同時 300 万接続をさばく必要があります。サーバが 100 台あっても 1 サーバ 1 万接続を処理できる必要がでてきてしまいます。

サイマルキャスト

WebRTC は超低遅延の双方向の配信を前提としているため 1:N の場合は、N 側の様々な環境を考慮し配信側がビットレートを変更するという仕組みを取ることはできません。

回線が細く、遅い PC で見ている人もいれば、ゲーミング PC で見てる人もいれば、スマートフォンで見てる人もいるでしょう。

そのための技術としてサイマルキャストがあります。簡単に言えば配信側に数種類の画質での配信をしてもらい、サーバ側で視聴者の帯域を推定し、視聴者毎の帯域に合わせた画質の映像を配信するという仕組みです。

これは、 HLS などでいうアダプティブビットレートをリアルタイムに行う仕組みです。

Image for post
Image for post

WiFi 接続している人には 800kbps の映像を送り、3G には 300kbps の映像を送るという方法です。帯域推定については検索すると深みにはまれるので興味がある方は是非どうぞ。

この方法を使えば、遅延が少なく、視聴者の帯域に合わせた配信が可能になります。

コーデック

WebRTC では音声のコーデックのデファクトが Opus というのに決められています。少ないビットレートでとても良い音質を実現し、さらに変換速度が早いといういい事ずくめのコーデックです。

では映像はというと VP8/VP9 という Google が公開しているオープンなコーデックと、H.264 の 3 つがデファクトです。

配信に向いているコーデックですが、VP9 が最も適していると考えています。VP9 は H.264 や VP8 の半分のビットレートで同等の画質を実現する仕組みです。

つまり H.264 での 1000kbps の画質は VP9 であれば 500kbps で足ります。これは配信という大規模に転送量を使うサービスではかなり重要です。なんせ転送量が半分で済むわけです。

VP9 はいい事ずくめではありません。変換にかかる CPU が VP8 とくらべて 20% 程度上昇します。

また WebRTC での VP9 は iOS や macOS での Safari や Edge で見ることができないため、ブラウザをかなり制限してしまいます。ちなみに WebM 的な VP9 であれば Edge は見ることができたりします。

ただ、デメリットを取ったとしても、配信は iOS や Android 向けのスマートフォンアプリを作る前提で考えれば VP9 を選択するのが適切だとお見ます。

ちなみに Firefox は 58 からデフォルトコーデックが VP9 になります。

AV1

VP9 も凄いのですが、更に凄いのが今開発されており 2017 年には仕様がフリーズする AV1 というコーデックです。これは VP9 や H265 とくらべてさらに 30% 程度ビットレートを圧縮したとしても同等の画質を実現するという仕組みです。

2018 年には WebRTC へ搭載されるという話もあり、今後は AV1/Opus という組み合わせがデファクトになっていくと信じています、信じさせて下さい。

Firefox Nightly でその映像が実感できますので、是非興味ある方は見てみて下さい。

録画

配信する場合は録画であとから見るが必要になります。WebRTC はサーバモデルであれば基本的に録画には対応しているのがほとんどです。

録画した映像は HLS や MPEG-DASH に変換して配信すればいいので、そこは特に問題ないでしょう。

Mixer

WebRTC での片方向配信を行っている最大のサービスはマイクロソフトの Mixer です。

Mixer は高解像度、超低遅延を WebRTC を使って実現しています。転送量はまったくけちっておらず 5Mbps がっつり使って配信しています。

400 名への配信とかも 5Mbps で実現しています。さらにWebRTC が利用できないユーザには HLS での配信も遅延 30–40 秒で提供しています。

マイクロソフトパワーではありますが、実現はできています。

まとめ

WebRTC を利用した超低遅延配信は一定の接続数までなら現実的です。別に夢物語ではありません。一定以上の場合は HLS/MPEG-DASH を採用して困ることはないでしょう。つまり住み分けすべきです。

WebRTC を利用した超低遅延配信の最大の魅力はユーザとの会話に違和感を感じないということです。チャットベースでもすぐに反応できます。

また、WebRTC の強みはブラウザを利用して気軽に配信が始められるというのもあります。配信ツールがいらないのも魅力の一つです。

WebRTC はビデオチャットアプリ専用のプロトコルではありません。超低遅延での多人数配信も可能です。

超低遅延の配信に興味がある人は是非 WebRTC を触ってみて下さい。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store