WebRTC が世に出て 10 年以上経ちます。WebRTC には色々課題があると思われがちですが、主な課題は既に解決しています。
古い知識からアップデートできていない記事が多く WebRTC の技術を誤解したままの人が多いのは好ましくないので、以下に雑に説明していきます。
WebRTC は大規模配信ができない
できます。
現在商用で利用されている WebRTC は P2P ではなく、ほとんどがクライアント・サーバーモデルである SFU (Selective Forwarding Unit) です。
SFU の場合、数千規模の接続であれば 1 台で実現可能です。
さらに、多段構成や分散構成を利用することで、低遅延のまま数百万、数千万の配信も実現できます。
WebRTC は HLS/MPEG-DASH のように画質が選択できない
できます。
WebRTC ではサイマルキャストと呼ばれる、クライアントが最初から複数の画質を配信し、SFU 経由で視聴側のネットワークや端末性能に合わせた的確な画質を配信する技術があります。
クライアントが複数画質の映像を配信するというのは最近では Twitch がベータ版を公開しています。
これはクライアントの負荷は増えますが、配信サーバーの変換負荷を無くしつつ、遅延も減らせるのでサービス的にはメリットが大きい仕組みです。
今後はこのクライアントエンコードによる配信が主流になっていくと思います。
WebRTC はつながらない
つながります。WebRTC はたしかにベースが UDP ですが、P2P ではなく、クライアント・サーバーモデルである SFU であれば、多くの場合でつながります。さらに TURN を利用して、UDP でつながらなければ TCP へ、さらに TCP でもだめであれば TLS へとフォールバックしていきます。さらに、HTTP Proxy も利用することができます。
つながらないのは TLS のチェック機能を持ったファイアウォールなどがある環境のみです。HLS/MPEG-DASH での配信や視聴ができれば WebRTC でもつながります。
AV1 は遅いので WebRTC で利用できない
AV1 はもう遅くないです。
これは AV1 3000 kbps 1080p の映像で、左がオリジナル、右が受信したの映像です。インターネット経由でこれだけの低遅延で配信できます。これは AV1 エンコーダー/デコーダーのリファレンス実装である libaom を利用しており、さらに送信も受信もブラウザです。
