低遅延のストリーミング配信を実現するWebRTC

普段見ているLive動画は、本当はLiveではない!

普段”Live動画”と言っているものは、実は”Live”とは言えるものではありません。

ライブコンサートで興奮した観客がステージ上でジャンプした映像を自宅で画面で見たとします。でもその観客は少なくとも30秒前にジャンプしています。
これは、遠隔地に大量のデータが流す処理の為におきる現象ですが、カメラが撮影した瞬間とその映像が画面に表示されるまでに時間差が生じます。これを遅延と呼びます。

低遅延とは何秒なのか?

動画の伝送に2-3秒の遅延が起きるのは普通ですが、そでは”低遅延”とは何秒の遅延の事なのでしょうか?

標準的なApple HLS プロトコルの遅延は約30秒~45秒程度なので、”低遅延”ということはその秒数を一桁台にする(3~4秒の遅延にする)ことだと一般的には言われています。
一方、”低遅延”という言葉はしばしばリアルタイムストリーミングを表す表現で使われおり、その事を考えると数百ミリ秒単位での遅延を”低遅延”とすべきとの議論もあります。
(ここでは便宜的に2-3秒の遅延を”低遅延”、100ミリ秒前後の遅延を”ウルトラ低遅延”と呼びます)

“低遅延”が重要な場面は?

”低遅延”もしくは”ウルトラ低遅延”にする事がどれだけ重要なのでしょう?

ほとんどのストリーミングの場面では、30秒~45秒の遅延は問題にはなりません。例えばコンサートで一人のギタリストが36秒前に弦を切ったとします。弦が切れるのを映像で見るのは今ですが遅れた事による問題はおきません。

しかし、幾つかのケースにおいては”低遅延”はビジネス・クリティカルなテーマだと言えます。“低遅延”が重要となる幾つかのケースを見てみましょう。

▶テレビとスマホのふたつの方法で同じイベントを同時視聴:
テレビであるイベントを見ながら、スマートホンでインターネット配信されている同じイベントを視聴した際、スマートホンには大きな遅延が発生しているため、別なアングルで同じイベントを同時並行してみることはできません。

ここで求められるのは”一般的な低遅延(3~4秒の遅延)”ではなく、ほぼリアルタイムに近い”ウルトラ低遅延(100ミリ秒前後の遅延)”です。同時に見える様にするためにはスマートホンの映像をテレビの映像と同期して配信する必要があるのです。

▶ビデオチャット:
ビデオチャットにおいてはリアルタイムに近い低遅延でも問題になります。
よくテレビの中継で、アナウンサーが現場にいるリポーターと話している時に、遅延によって会話の間に沈黙が起きているかのように見えます。
これは2つの遅延が原因となっています。一つはアナウンサーの質問がリポーターに届くまでの遅延、もう一つがリポーターからアナウンサーへの返答の遅延です。
とても話しにくそうに話していますね。これを回避するためには、遅延を約150ミリ秒(7分の1秒)以内にする必要があります。

▶オークションでのベッティング:
オークションやスポーツでのベッティングはとても速いテンポで動くのでとてもエキサイティングです。このスピードに対応してこそリアルタイムストリーミングと呼べるでしょう。
例えば競馬の世界では、世界中の馬主が遠くにいる馬を持ち、世界中から競馬にベッテイングする事がおきています。ここでの遅延の代償はとても高いものとなります。”ウルトラ低遅延“は遅延による損失を解消します。
同様にオンラインオークションビジネスはとても大きなビジネスです。ここでの遅延はベッティングが正しいタイミングで記録されないということを意味します。何分の1秒の遅延は入札の結果を大きく左右してしまうのです。

▶ビデオゲーム:
ゲーマーにとって「タイミング」は非常に重要で、100ミリ秒以下の遅延が絶対に必要な世界です。誰もが、もうそこにはいない敵に向かって攻撃をするなどというバカげたゲームはしたくありません。

いかに”低遅延”にするか?

低遅延とは何か?どんなケースで重要か?は理解できましたね。
次に、どうやったら低遅延のストリーミング配信ができるかを説明しましょう。

低遅延には次の”3つのトレードオフ”が存在します。それを解決するには各々のバランスを考える必要があります。

・”エンコーディングするプロトコル” と ”視聴できるデバイス/Player”
・”視聴者の数” と ”配信エリアの地理的な要素”
・”ビデオ解像度” と “その他の要素”

これを解決するために「ストリーミングのプロトコル」が重要な役割を果たしています。

低遅延のストリーミング配信を実現するWebRTC

Apple HLS はその信頼性故に最も幅広く使われているプロトコルですが、低遅延の実現には向かないプロトコルです。
HLSはHTTPベースのプロトコルで、映像を細切れの小さいデータにして更にこれらのデータを大きな塊(チャンク)にまとめて配信します。その為低遅延にするためには、このチャンクをリアルタイムに生成し、またリアルタイムに映像にもどす必要があります。Apple HLS のデフォルトのチャンクサイズは10秒で、遅延は45秒までです。カスタマイズによって遅延の時間を短くすることができますが、ウルトラ低遅延化するための十分なものではありません。視聴者はより小さな小さなチャンクを見始めてしまい、むしろ問題を悪化させることが考えられます。

RTMP (Real-Time Messaging Protocol) とWebRTC (Web Real-Time Communications) が低遅延ストリームのスタンダードです。

RTMP はとても低遅延でのストリーミングを実現します。しかしFlashベースのPlayerが必要とされ、iOSデバイスでは利用できません。そして近い将来主要なブラウザで利用できなくなります。
WebRTC は多くのプラットフォーム上でスタンダードになっており、iOSでもNativeとして採用されています。WebRTC はHTML-5ベースでかつFlashがいらない環境での低遅延を実現します。

プロトコルの選択の次に重要なのは、ストリーミングサーバ及びストリーミングクラウドです。

ストリーミング配信をする人は”遅延”と”ビデオ品質”を、「自分でコントロールでき」かつ「柔軟性にマネージできる」ストリーミングテクノロジーを求めています。
Wowzaのストリーミングサーバ及びストリーミングクラウドは、上記プロトコルを選択できるだけでなく、ハイスケールで配信できるよう設計されています。
Wowzaは視聴者が何人であっても、低遅延のストリーム配信をする事ができるのです。

これから、”サービスの品質”、”視聴者数”、”地理的な観点”、そして”それ以外の観点”で説明されるビデオをご覧ください。