YouTube LiveのWebRTCサポートを技術的にみた感想

今朝、Twitterを眺めていたらYouTubeがウェブカメラから直接配信できるサービスを始めたと聞いて詳しく調べてみました。

以前にもYouTube LiveにてGoogleハングアウトを使ったカメラ配信は出来たのですが、これは恐らくRTMPを使ったもので今回はWebRTCを使っているため、全く別物です。

現在はGoogle Chromeのみ対応しているようですが、FirefoxやSafariにも今後対応していくと考えられます。

配信基盤

YouTube Liveのカメラ配信では、先ほど述べたとおりWebRTCを使っています。

ですので、ブラウザ単体で配信することが出来ます。現在はカメラのみで画面共有は対応していないようです。

視聴者側はWebRTCではなく、トランスコード処理を行いMPEG-DASHまたはHTTP Live Streamingで配信されています。

これはWebRTCで大規模配信を行うのに不向きであるため、妥当な判断と言えるでしょう。

詳しいことは以下の記事が参考になります。

WebRTC

SDPなどを見てみるとH.264が優先的に使われるようになっています。

2018年3月現在、Google ChromeやFirefoxはデフォルトでVP9を使うようになっているのですが、特殊な事情でもあるのでしょうか。

音声はOpusで、InbandFECが有効になっています。

ICEはTrickle ICEが使われており、IPv4とIPv6両方サポートしています。またICE-TCP, ICE-UDPのほかにSSLハンドシェイクのみ行う疑似SSLであるICE-SSLTCPもサポートされています。

ちなみにICEのサーバは東京からpingを打ってみると40ms程度だったのでアジアのどこかにあると思われます(もちろんAS15169)。

ほかには特に何もおかしいところはない、至って普通のSDPでした。

追記(2018.3.22)

先ほどGoogleのエンジニアの方からリプライを頂き、VP9よりもH.264を優先にしているのは、ハードウェアアクセラレーションが重視されているようです。

MPEG-DASH/HLS

視聴者はWebRTCではなく、MPEG-DASHまたはHLSのいずれかで視聴します。通常はMPEG-DASHを使うようですが、Safariのような環境下ではHLSを使っているようです。

再生遅延はおおよそ3秒程度で特に気にならないです。

コーデックはH.264(Main profile)/AAC-LCが使われています。

また、回線状況が悪い場合(Network Link Conditionerで上り1Mbpsでシミュレーション)は再生が止まるだけでブロックノイズなどは特に出ませんでした。

まとめ

MicrosoftのMixerのようにWebRTCで大規模配信を行うのは一般的な事業者にとってはとても難しいです。

そんな中、GoogleがWebRTC to HLS/DASHを選択したのは今後の配信プラットフォームを選択する上で大きな影響が与えることになるでしょう。

YouTube以外にはピクシブ株式会社が提供しているpixiv Sketch LIVEもWebRTC to HLSで提供を行っており、この配信基盤をImageFluxとして外部向けにサービス提供を行う予定のようです。

もうすぐGoogle ChromeにUnified Planが入ってくるので、2018年はWebRTCが大きく動く年になるかもしれませんね。