Member-only story
超低遅延、高画質な配信を実現するための選択肢の一つとして 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 サーバを多段型にすることで多くの接続へ配信をする仕組みが前提となります。
この仕組を利用することで、配信サーバを増やすことで同時配信数を増やすことができます。海外で WebRTC で大規模配信を実現しているサービスなどはこの仕組みをサービスとして提供しています。
ただし、HLS/MPEG-DASH が頑張れば 2–3 秒まで縮められる事を考えると WebRTC を利用した配信での 1 万接続以上を頑張るメリットはほとんどないでしょう。
そう考えると現実としては上の仕組みを使い最大 3000 接続までは WebRTC で配信を行い、それ以降は HLS での変換を同時に行うなどの仕組みが現実的だと思います。
3000 接続の配信が 1000 あるだけで、実質同時 300 万接続をさばく必要があります。サーバが 100 台あっても 1 サーバ 1 万接続を処理できる必要がでてきてしまいます。
サイマルキャスト
WebRTC は超低遅延の双方向の配信を前提としているため 1:N の場合は、N 側の様々な環境を考慮し配信側がビットレートを変更するという仕組みを取ることはできません。
回線が細く、遅い PC で見ている人もいれば、ゲーミング PC で見てる人もいれば、スマートフォンで見てる人もいるでしょう。
そのための技術としてサイマルキャストがあります。簡単に言えば配信側に数種類の画質での配信をしてもらい、サーバ側で視聴者の帯域を推定し、視聴者毎の帯域に合わせた画質の映像を配信するという仕組みです。
これは、 HLS などでいうアダプティブビットレートをリアルタイムに行う仕組みです。
