YouTubeやTwitchで人気のライブ配信を支える技術とは？

通信インフラが進歩し、OBS StudioやXSplit Broadcasterといった配信用ソフトやさまざまな音響機器が簡単に入手できるようになり、YouTubeやニコニコ生放送、Twitchといったライブ配信プラットフォームが登場したことによって、誰でも簡単にライブ配信を行うことができるようになりました。そんなライブ配信を支える技術について、20年近くにわたって映像通信フレームワークの開発に携わってきたキンドラ・クレイマー氏が解説しています。

Video live streaming: Notes on RTMP, HLS, and WebRTC
https://www.daily.co/blog/video-live-streaming/

例えば、ゲーム実況配信プラットフォームとして知られるTwitchでは「配信者からTwitch」と「Twitchから視聴者」でデータの通信プロトコルが異なります。配信者側からTwitchに映像を送信する際は、ほぼ確実に「Real Time Messaging Protocol(RTMP)」が使用されています。一方で、Twitchでライブ配信を視聴している場合は、RTMPではなく「HTTP Live Streaming(HLS)」という通信プロトコルが使われています。

RTMPは、2005年にAdobeに買収されたMacromediaによって、Adobe Flash Playerとサーバー間のデータ伝送用に開発されたTCPベースの通信プロトコルです。開発されたのはおよそ20年前で、あるコンピューターシステムから別のコンピューターシステムにライブ映像を送信する方法として長く使われてきたため、またAdobe Flash Playerが長らくウェブ上における動画再生プラグインとして重宝されてきたため、業界のデファクトスタンダードとなっています。RTMP自体は2020年12月31日にAdobe Flash Playerが終了した時点でサポートは終わっているのですが、配信者側からメディアサーバーに映像を送信するための通信プロトコルとしては記事作成時点でもよく使われています。

by Gustavo da Cunha Pimenta

HLSはAppleが開発して2009年にリリースしたHTTPベースの通信プロトコルです。HLSは複数のビットレートをサポートし、表示クライアントが複数のビットレートを動的に切り替えることが可能です。例えば、屋外からスマートフォンでライブ配信を見ている人のビットレートは低く、自宅のインターネットでライブ配信を見ている人のビットレートは高くというように振り分けることで、使用する通信帯域幅をぐっと絞ることができるようになります。

ビットレートが変わるということは、スマートフォンで見たライブ配信の映像と、自宅PCで見たライブ配信の映像では品質が異なることを意味します。HLSでは、映像を短時間単位でまとめてパッケージングし、異なるビットレートでエンコードするアダプティブビットレート(ABR)ストリーミングが可能になります。

動画をデジタルで扱うための基本知識まとめ、映像や音声はどうやってPCで処理されているのか？ - GIGAZINE

ABRストリーミングは、動画を短く分割した上でそれぞれの解像度にエンコードし、もし受信するデバイスでメディアを処理できなくなった場合、動的にビットレートが切り替えます。そのため、ネットワーク環境が貧弱になっても、自動的に低解像度に切り替わるので、HLSは動画の視聴が途切れにくくなるのが特徴。なお、パッケージングされた短い動画は「.ts」の拡張子を持つチャンクファイルで、メタデータは「.m3u8」という拡張子を持つマニフェストファイルに保存されます。

HLSがRTMPよりも優れている点として、Cloudflare、Fastly、Akamai、Cloudfrontなどのコンテンツデリバリネットワーク(CDN)によってHLSチャンクを効率的に配信できることです。RTMPはストリーミング指向のプロトコルなので、RTMP接続を介してビデオとオーディオを送信するには、TCPソケットを開き、RTMP形式のデータをそのソケットにプッシュする必要があります。しかし、HLSはマニフェストファイルとチャンクがCDNによってキャッシュされるので、いつでもどこでも簡単にライブ配信を受信して視聴することが可能になるというわけです。

ただし、動画データを送受信するだけでは、ライブ配信のリアルタイム性が保証されません。ライブ配信では、「配信者のPCでゲーム映像やウェブカメラの映像をキャプチャし、エンコードし、メディアサーバーに送信し、メディアサーバーでビデオを処理し、各視聴者のビューアへ送信し、再生する」という一連の流れだけで、50ミリ秒～300ミリ秒のレイテンシが発生します。さらに、このうちのエンコードやHLSのパッケージ化などで数秒のレイテンシが発生します。また、CDNからHLSチャンクのキャッシュの取得やアンパッケージングによってさらにレイテンシは増幅します。

こうしたレイテンシを下げるため、超低遅延を目指した業界標準が「WebRTC」です。WebRTCはP2Pのリアルタイム通信向けに生まれた規格で、動画のエンコーディングを送信側で行い、データを連続したストリームとして送信します。WebRTCはTCPではなくUDPを用いており、HLSのように数秒単位のレイテンシが発生せず、再生バッファにかかる時間は30ミリ秒程度に抑えられるので、チャットツールなどでよく使われています。ただし、WebRTCの場合、送信側で動画のエンコーディングを行うため、視聴者が増えれば増えるほど、配信者側の負担が大きくなります。そのため、WebRTCは視聴者人数が多い状況にはあまり向いていません。

例えば自宅で無線LANに接続しながらNetflixで映画を見ている時に、ポップコーンを電子レンジで温めたとします。2.4GHz帯のWi-Fiに接続している場合、電子レンジがWi-Fiに干渉していまい、ネットワーク上のパケットロスが急増します。動画を分割してキャッシュを再生しているHLSだと、パケットロスの発生が数秒程度であれば、TCPの再試行でパケットロスを補うことができるので、自動的にプレイヤー側が低ビットレートに切り替えて接続を保つことが可能です。

しかし、WebRTCの場合は50ミリ秒程度のビデオパケットしか保存されないので、大きなパケットロスが発生した場合、プレイヤーは動画をレンダリングし続けることができなくなり、ロスしたパケットを再要求する際のRTTが増大します。そのため、WebRTCは通常HLSよりもかなり低いビットレートで実装されています。

また、パケットロスやジッターは、一般的に、遠くにあるサーバーに接続するよりも、近くにあるサーバーに接続する方がはるかに少なくなります。したがって、ライブ配信の視聴者が地理的に分散している場合、メディアサーバーの分散型インフラを持つことが重要となるため、WebRTCのメディアサーバー間でカスケード接続やメッシュ接続を構築する必要があります。

なお、RTMP・HLS・WebRTCのほかにも、「MPEG-DASH(Dynamic Adaptive Streaming over HTTP)」という通信プロトコルが存在します。MPEG-DASHはHLSと同様に動画を小さく分割し、各チャンクをさまざまな品質でエンコードして配信するという仕組みなので、HLSと同じようにABRストリーミングが可能。また、HLSはコーデックをH.264あるいはH.265に制限しているのに対して、MPEG-DASHは任意のエンコード標準を使用可能です。そのため、コーデックによってはより高品質なライブ配信を低ビットレートで行うことも可能です。

ただし、MPEG-DASHはISO/IEC 23001-6として国際標準規格となっていますが、Appleデバイスでサポートされておらず、iPhoneやMacBookでMPEG-DASHで配信された動画を再生することはできません。AppleはHLSを国際標準として公開していませんが、HLSはAppleデバイスでサポートされている唯一の形式であるため、ストリームプロトコルとしてはHLSが圧倒的なシェアを握っているのが現状です。

by Stuart Maxwell