アップルのイベントをリアルタイム視聴できるのはどうして？

イベントをリアルタイムで共有

日本時間9月8日午前2時、アップルのスペシャルイベントが開催されたのは既報のとおり。新モデルであるiPhone 7／7プラス、アップルウォッチ・シリーズ2、エアポッズなど、魅惑的な製品やサービスなどについて、非常に興味深い発表が行われました。

かつてこうしたイベントは、その場に参加した聴衆だけが聴くことができ、その内容は本誌のようなメディアが伝えるまで、ユーザは待たされるものでした。しかし、昨今ではライブストリーミングにより、MacやウィンドウズPCといったパソコンはもちろん、iPhoneやiPadといったスマートデバイス、果てはアップルTVを通じて、家庭のTVでも視聴ができるようになっています。

このライブストリーミングを支えているのが、アップルの「HLS（HTTP Live Streaming）」という技術です。

大変だったストリーミング

インターネットの黎明期から「動画を配信したい」という要望は多くありました。アップルでも2000年代には「ダーウィン・ストリーミング・サーバ（Darwin Streaming Server）」というストリーミング配信用のサーバを用意し、Mac OS Xサーバに搭載することで、その要望に応えていました。

テキストや画像が主のWEBページとは異なり、映像や音声はデータ量が非常に大きく、また遅延に弱いという特徴があります。WEBページの画像表示は10秒程度遅れてもそこまで気になりませんが、音声や動画が遅れたり止まったりすると、すぐに気がつきますし、視聴しづらいですよね。動画にとって、滑らかに配信できるということは、重要なポイントなのです。

2000年代のインターネットでは、十分な帯域がなかったため、画質を落としても滑らかな再生を優先する、また遅延が起こりにくいプロトコルを採用するのが大事でした。先のダーウィン・ストリーミング・サーバでも「RTP」ないしは「RTSP」というストリーミングのプロトコルを採用していました。

ただ、このストリーミングプロトコルはNAT（IPアドレスを変換する技術）との相性が悪いことがあったり、視聴にあたりファイアウォールを通過する設定の追加が必要だったりしました。当時から、家庭でもNATを使って複数台のデバイスをインターネットに接続したり、ファイアウォールによる防御が当たり前だったので、ストリーミングの視聴はハードルが高いものでした。

配信する側としても、視聴者の増減に応じて適切な台数分のストリーミング専用のサーバを用意しなければなりません。ストリーミングは提供する側にとってもハードルが高いものでした。

しかし、この状況は2000年代中盤から2010年代に変わっていきます。ブロードバンドが当たり前になり、インターネット通信自体が速くなって、大量のデータを送ることが可能になったからです。この増大する帯域を背景に、ユーチューブなどブラウザベースの、HTTPを使ってファイルをやりとりする動画サービスも一般化してきました。そうした中でiOS3.0とともに登場したのが、冒頭のアップルのHLSです。

単純すぎるHLS

HLSの仕組みは極めて簡単。まず、動画データをある程度の短い時間（10秒程度）でぶつ切りにして、WEBサーバに置いておきます。同じWEBサーバに拡張子「m3u8」のプレイリストを作成、先のぶつ切りにした動画ファイルを記録しておきます。

サファリなど、HLS対応のブラウザは、このHLSファイルを見つけると、そのファイルに記載された細切れの動画ファイルを一つずつ取ってきて再生します。早送りをした場合は間のファイルを飛ばして、次のファイルを取得したり、早戻しのときも前のその部分のファイルだけを取り戻します。

また、サーバに複数の画質のファイルを置いておくことで、帯域に応じた画質の調整もできます。たとえば、最初の動画ファイルを取るのに時間がかかって再生が間に合わなかったら、次からは画質が悪い、その代わりにより小さいほうのファイルを選択することで、再生を間に合うようにしていけるのです。HLSはWEBと同じHTTPを使っているので、NATやファイアウォールとの相性はまったく問題がありません。

サイズが大きいファイルの場合は、全部ダウンロードしないと再生や巻き戻し、早送りなどができませんが、HLSではその瞬間瞬間に細切れのファイルをダウンロードして再生しているだけなので、クライアント側には大きなメモリやディスクは必要ありません。性能が限られたスマートフォンではこの点が便利というわけです。また、配信側もWEBサーバを用意しておくだけで構いません。WEBサーバの増強は簡単ですし、HLSならCDN（コンテンツを置くサーバを分散させて最適化する仕組み）も利用できます。

動画を細切れにすることや、「m3u8」のプレイリストの作成など、HLSに必要なツールはアップルのデベロッパプログラムで無償提供されています。このツールはすでにある動画の分割はもちろん、動画を撮影しながら配信する、ライブストリーミングにも対応しています。もちろん、iPhoneやiPadアプリ向けには簡単にHLSを扱うことができる仕組みが提供されています。

iPhone、iPad、そしてアップルTVの成功に併せて、HLSは動画ストリーミングのデファクトスタンダードとなりました。アドビやマイクロソフトが類似規格を出したりしましたが、HLSほどには普及していないといえます。アンドロイドもHLSをサポートしており、ウィンドウズ10に搭載されたエッジブラウザでもHLSをサポートするようになりました。

かくして、アップルの基調講演を誰もが見ることができるようになった今につながります。多くの人が夜中2時からのストリーミングに夜更かしをして、翌日が辛い日々を迎えるようになったのもHLSのせいなのです。

HLSの仕組み

配信側はまずデータソースをサーバでエンコード、セグメンタでこまぎれに分割。「m3u8」形式のインデックスファイルを作成し、これらをWEBサーバに置きます。対する視聴側はブラウザでm3u8ファイルが検出されると、記載された動画ファイルのこま切れを順に取得していきます。

【 HLSをサポートする環境】

HLSは非力なiPhoneでも視聴に満足のいくライブストリーミングを目指したものなので、iOS 3以降、すなわち現在世の中にあるほぼすべてのiOSデバイスで利用できます。アンドロイドではバージョン3.0よりサポートが始まり、4.1以降では安定して再生できる模様です。マイクロソフトでは当初、「スムース・ストリーミング（Smooth Streaming）」を作ったり、アドビ、シスコ、ネットフリックスなどと「MPEG-DASH」といった対抗規格を作ったりしていましたが、ウィンドウズ10のエッジブラウザからはデファクトスタンダードでもあるHLSをサポートしています。MacのサファリももちろんHLSをサポートしています。ファイアフォックスやクロームといった、その他のブラウザについてはサポートが芳しくありません。

【 Flash Video（FLV）】

ユーチューブでも使われ一躍有名になったのがフラッシュビデオ（Flash Video）という、フラッシュを使った動画再生です。WEBページ側には再生用のフラッシュコンテンツを用意、サーバに置いておいたFLV（FlashVideo）形式の動画をストリーミングで再生するというものでした。FLVもまたストリーミングに専用のサーバを用意するのではなく、WEBサーバに動画（FLV）を置いておけばいいという簡易なものでした。またパソコンのWEBブラウザなら、おおむねフラッシュに対応していたので、追加でソフトウェアをインストールする必要もないことから、爆発的に普及したのは、（自覚はないかもしれませんが）皆さんご存じのとおりです。ただ、フラッシュの負荷はスマートデバイスには厳しいことからiPhoneなどでは対応されず、衰退を迎えつつあるのも事実です。

【ストリーミング】

動画ファイルを、すべてのデータを取得してから再生するのではなく、データを取得しながら随時再生していくことを「ストリーミング（streaming）」と呼んでいます。

【DSS】

OS Xサーバでは「クイックタイム・ストリーミング・サーバ（QuickTime Streaming Server）」と呼ばれていたストリーミングサーバをオープンソースで公開したものが、ダーウィン・ストリーミング・サーバです。