3 月に iPhone 3.0 を発表した際、Apple 社は新オペレーティング システムの新しいストリーミング ビデオ機能についてわずかにヒントを出しただけで (文字通り、他の機能のスライドの下に「ストリーミング ビデオ」と書いただけ)、それがどのように動作するかについての詳細は省略し、プレゼンテーションでもその機能について詳細には触れなかった。
Appleは過去10年間、RTSP（Real-Time Streaming Protocol）サーバーを使用してライブストリーミングや再放送のビデオフィードを視聴者に提供するQuickTime Streaming Serverを販売してきました。Appleはこの技術を自社のライブイベントのストリーミングにも活用しています。しかし、ロイヤリティフリーのストリーミングを提供し、オープンソースプロジェクトとして提供しているにもかかわらず、QuickTimeのRTSPストリーミングサーバーはかつて期待されていたほどの普及には至っていません。
その大きな原因は、RTSPトラフィックが多くのファイアウォールによってブロックされ、安定したストリーミング配信が困難になっていることです。iChatの音声・ビデオ会議もRTSPに依存しており、同様の理由で一部のユーザーに苛立たしい問題を引き起こしています。iPhoneではモバイルネットワークとWi-Fiネットワーク間を頻繁に行き来するため、RTSPビデオストリーミングを動作させるのはさらに困難です。
Appleは以前、QuickTime Streaming ServerにおいてRTSP問題の解決を試み、RTSPストリーミングビデオトラフィックをHTTPパケットにバンドルするオプションを追加しました。HTTPパケットは標準的なWebトラフィックと見た目が同一であるため、ほとんどのファイアウォールを通過できます。しかし、これには追加のオーバーヘッドが伴い、結果として帯域幅の需要が増加します。iPhoneでは、AppleはHTTP Live Streamingと呼ばれる別の戦略を採用しました。
HTTPライブストリーミング
HTTP ライブ ストリーミングの背後にあるテクノロジは、5 月に Apple がそれをインターネット技術タスク フォース (IETF) に RFC (Request For Comments、テクノロジを実装するベンダー間の協力と互換性を促進するためにテクノロジの動作を定義するインターネット協会が使用する覚書) になる予定の草案標準として提出したときに、一般に知られるようになりました。
Appleが提案したHTTP Live Streamingのドラフトは、Microsoftが昨年販売を開始したSmooth Streamingという方式とよく似ています。違いは、Appleが提案したIETF標準は、誰のエンコーダーやブロードキャストサーバーでも利用可能で、ストリームを受信するように設計されたあらゆるクライアントソフトウェアで動作するという点です。一方、MicrosoftのSmooth Streamingは、当然ながらMicrosoft Expression Encoderと、Smooth Streaming拡張機能を備えたMicrosoft Internet Information Serverのみを使用するように設計されており、クライアントにはMicrosoft Silverlight 2が必要です。
本質的に、Appleは誰でも利用できるストリーミングビデオの標準規格を求めています。そうすることで、プロプライエタリソフトウェアによって市場から締め出されたり、縛られたりすることなく、ハードウェアの販売を継続できるからです。一方、ソフトウェアベンダーであるMicrosoftは、自らの意思で競合他社を締め出す力を持つ、新たな独占市場を創出したいと考えています。MicrosoftのSilverlight Smooth Streamingと並行して、Adobeも同等のFlashベースのストリーミングサーバーを独自に提供しています。
これがすべて聞き覚えのある話に聞こえ始めたとしたら、それはビデオストリーミングがマルチメディア再生とほぼ同じ歴史的軌跡をたどっており、ストリーミングの歴史が QuickTime の歴史の新たな章になっているからです。
ストリーミングの到来
90年代半ば、Appleはソフトウェアベースのデスクトップビデオオーサリングと再生技術を先駆的に開発し、マルチメディアコンピューティング分野で圧倒的なリードを築きました。しかし、インターネットの登場により、大容量ビデオファイルの配布にCD-ROMを頼ったり、ユーザーがダイヤルアップ接続で大容量ビデオを直接ダウンロードしたりする代わりに、効率的なビデオストリームをユーザーに（主にダイヤルアップ経由で）送信できる大きな可能性が見えてきました。
インターネットメディアストリーミングは、1995年にProgressive Networks社が独自のRealAudioストリーミングフォーマットによって普及させました。1997年には社名をRealNetworks社に変更し、RealPlayer 4.0の一部としてRealVideoサービスを開始しました。また、Netscape社と提携し、後にストリーミングのRTSP標準となる規格を開発しました。
Realは、マイクロソフトの億万長者ロブ・グレイザーによって設立されました。マイクロソフトは同社の株式10%を保有し、Netscapeのストリーミングサーバーを駆逐することを目指した製品NetShowにRealのストリーミングフォーマットのライセンスを供与していました。MicrosoftのNetShowは、既存コンテンツとの互換性を確保するためにRealのストリーミングフォーマットを採用していましたが、最終的にはインターネットストリーミングを独自の新しいActiveXストリーミングフォーマット（ASF）に移行することを望んでいました。Realへの関心にもかかわらず、Microsoftの野心は高まり続け、1998年には独自のWindows Media PlayerでRealPlayerに対抗するに至りました。これは、1996年にActive Movie/DirectShowプレーヤーの灰の中から蘇った不死鳥でした。Active Movie/DirectShowプレーヤー自体は、元々Video For Windowsという名前だった、同社の不運な競合製品QuickTimeのリブランド版でした。
QuickTimeがWindows 98とInternet Explorerで突然正常に動作しなくなったのと同様に、Windows Media PlayerもRealのストリーミング形式の再生を突然停止したと、グレイザー氏はMicrosoft Monopoly裁判で証言した。Realの幹部デビッド・リチャーズ氏も、MicrosoftがAOLに対しRealのサポートを中止し、代わりにMicrosoft独自のストリーミングソフトウェアを使用するよう圧力をかけていたと証言し、AOLのCEOがグレイザー氏に送ったこの件に関するメールを引用した。そのメールには「彼らはあなたたちを殺したいと強く願っている。ひどい話だ」と警告されていた。
Microsoft は、ストリーミングとデジタル再生の両方の将来を掌握したいと考え、Real と Apple にすぐに対抗し、MMS (Microsoft Media Server、NetShow の新しい名前。モバイル メッセージング プロトコルと混同しないように注意) 経由で ASF (Real キラー) をストリーミングするというアイデアを推進し、ActiveX Authoring Format (AAF) を QuickTime キラーとして確立しました。
1998年、ISOはAAFを却下し、新しいMPEG-4メディアコンテナフォーマットのベースとしてQuickTimeを採用しました。2003年には、ストリーミングメディアに独自のシステムを使用していたMMSは、Microsoftによって廃止され、独自のRTSPサーバーであるWindows Media Server 9が採用されました。ActiveXブランドが広範囲にわたるセキュリティ上の欠陥によって著しく汚名を着せられた後、ASFとAAFの「A」は「Advanced」の略称に変更されました。最近では、MicrosoftはスムーズストリーミングをサポートするためにASFを廃止し、MPEG-4コンテナを採用せざるを得ませんでした。
マイクロソフトとのストリーミング競争の最中、他に頼れる収入源を失ったRealは、RealPlayerの既存の価値を悪用し、マーケティングパートナーからのメッセージや定額制音楽販売の勧誘でユーザーを圧倒するアドウェアベンダーへと変貌を遂げました。また、2005年にはマイクロソフトを相手取り訴訟を起こし、独占禁止法違反で4億6000万ドルの和解金を獲得しました。
Appleがストリーミングの波に乗る
90年代半ばの危機的状況からまだ立ち直りつつあったAppleでしたが、Realとは異なり、存続を支えるための別の重要な事業がありました。1998年には、HTTPプログレッシブダウンロードと呼ばれる一種の疑似ストリーミング機能を搭載したQuickTime 3をリリースしました。これは、実際にビデオをリアルタイムでストリーミングするのではなく、ユーザーがファイルのダウンロードを開始し、利用可能な部分から視聴を開始することしかできないというものでした。
しかし翌年、NAB 1999でAppleはQuickTime 4とQuickTime Streaming Serverをリリースしました。これはReal標準規格に基づいたRTSPストリーミングを実現するものでした。Appleは、ユーザーごとにストリーミング使用料を課すのではなく、無制限のストリーミング利用を許可しました。これは、Realが独占し、Microsoftが要求するストリーミングビジネスに追いつくことを狙ったものでした。Appleは、このソフトウェアをDarwin Streaming Serverとしてオープンソース化しました。
暫定CEOの職に就いていたスティーブ・ジョブズはプレスリリースで、「ついに、インターネット経由のライブビデオとオーディオのストリーミングに、専用ソフトウェアや高価なサーバーは不要になりました。ストリーミング機能をMac OS X Serverに組み込み、Darwin Streaming Serverを導入することで、Appleはデジタルビデオとオーディオのストリーミングコストを大幅に削減し、その結果、高品質なストリーミングコンテンツが大量に提供されるはずです」と述べました。
しかし、Appleはストリーミング市場で依然として3位にとどまり、ストリーミングコンテンツの急増は期待通りには実現しませんでした。しかし、ストリーミングMP3ファイルをベースとしたインターネットラジオは、Nullsoftが開発したSHOUTcastプロトコルを使用して普及し始めました。GPLのIcecastサーバーに加え、QuickTime Streaming ServerもSHOUTcastオーディオストリーミングサーバーのサポートを機能として採用し、AppleはiTunesにラジオストリーミングクライアントのサポートを追加しました。
ストリーミングは技術とライセンスによって阻害されている
2002年、AppleはQuickTime 6と新機能QuickTime Broadcasterをリリースしました。これにより、ユーザーはライブビデオをキャプチャし、他のユーザーにユニキャストで送信するか、ローカルネットワークを介して複数のユーザーが視聴できるマルチキャストでストリーミング配信できるようになりました。ビデオのマルチキャスト配信は効率的ですが、インターネットでは利用できません。これは、ISPがトラフィック料金の請求方法を決定できないためです。インターネットでは、電話のようにポイントツーポイントでユニキャスト配信されるのではなく、テレビ放送のように複数のユーザーが受信できるように分散配信されます。
QuickTime Broadcasterは、QuickTime Streaming Serverにビデオストリームを送信することもできます。QuickTime Streaming Serverは、単一のストリームを他の様々なユニキャストクライアントにリフレクションしたり、信号を他のサーバーに中継して負荷分散を行ったりします。残る問題はRTSPファイアウォールの問題です。この問題を回避するには、ストリームをHTTPパケットとしてカプセル化し、ファイアウォール内のローカルユーザーに再ブロードキャストするサーバーネットワークが必要ですが、このソリューションは大規模企業での導入以外では機能しません。
ストリーミングを阻むもう一つの要因は、MPEG-4ライセンスでした。Appleはプレスリリースで次のように述べています。「QuickTime BroadcasterはMPEG-4のブロードキャストをサポートしていますが、QuickTime 6と同様に、MPEG-4ビデオライセンス条件が改善されるまで、QuickTime Broadcasterの配布は延期されます。MPEG-4特許保有者の最大のグループであるMPEG-LAが提案したMPEG-4ライセンス条件には、AppleのようなMPEG-4コーデックを出荷する企業からのロイヤルティ支払いに加え、MPEG-4を使用してビデオストリーミングを行うコンテンツプロバイダからのロイヤルティ支払いが含まれています。Appleは、QuickTimeにMPEG-4コーデックを組み込むことに対して妥当なロイヤルティを支払うことには同意しますが、コンテンツ所有者がMPEG-4を使用してコンテンツを配信するためにロイヤルティを支払わなければならない場合、MPEG-4が市場で成功できるとは考えていません。」
iPodのストリーミング回避策
ストリーミングの主な目的の一つは、90年代後半のインターネット帯域幅の制約を回避することでした。ほとんどのユーザーがダイヤルアップ接続しか利用していなかった当時、ダウンロードが完了するのを待つよりも、オーディオやビデオをストリーミングする方が理にかなった選択肢でした。2003年、ブロードバンドがほぼ普及した頃、AppleはiPodの発売に続き、新しいiTunes Storeを立ち上げました。iTunes Storeでは、インターネットラジオのストリーミングに加えて、プログレッシブダウンロード用の音楽ライブラリも提供されるようになりました。Appleはまた、iPod自体が生み出した新たな需要、ポッドキャスティングにも着目しました。
RSSフィードを利用することで、コンテンツ制作者はリアルタイムストリーミングではなく、プログレッシブダウンロードファイルとして配信できるようになりました。この新しい技術により、ストリーミングの重要性は90年代初頭のCD-ROMとウォークマンの時代に戻りました。当時は、ユーザーはリアルタイムストリーミングを試して低品質のストリームを我慢し、コスト効率の良い方法で視聴するよりも、高品質な録音済みコンテンツを事前に入手して視聴していました。
マイクロソフトは、Real Music の音楽サブスクリプション販売の取り組みを追随し続けました。一方、Apple は、録音済みコンテンツの販売とポッドキャスト配信の両方を行うこの新しいビジネスで、すぐにトップの地位を確立しました。iTunes は、従来の放送局のポッドキャストをリストするライブラリとして機能し、Apple はまた、大学に iTunes U で無料のポッドキャストとしてコンテンツを公開することを奨励しました。Mac OS X Server の一部である Podcast Producer を使用すると、組織は、リモート クライアントからビデオをキャプチャし、自動編集を実行してオープニング ビデオやタイトル、エンド クレジットを追加し、ポッドキャストとして iTunes で配信したり、QuickTime Streaming Server でストリームしたりできる出力ファイルを作成するワークフローを作成できます。
iPhone 3.0はモバイルストリーミングを導入
iTunesユーザーはブロードバンドPCからラジオのストリーミングを聴くことができますが、ストリーミングしたコンテンツをiPodに持ち出す実用的な方法はありませんでした。しかし、高額なモバイルデータプランを備えたiPhoneが登場するまではそうでした。しかし、突如として状況は一変し、iPhone購入時に既に支払っている帯域幅を有効活用するストリーミングへの新たな需要が生まれました。
iPhone 2.0向けの最初のアプリの一つにAOLラジオがあり、その後、BBC、TV.com、さらにはSlingPlayerを使ったユーザー独自の動画など、各プロバイダ独自の音声や動画のストリーム配信を行うアプリが続々と登場しました。AT&Tはこれに反発し、他のプロバイダがユーザーにほとんど音声や動画クリップを販売せずに大儲けしているのに、自社のモバイルネットワークをiPhone 2.0のアプリで使い果たすのはやめるよう要求しました。
AppleはiPhoneにRTSPサポートを組み込まなかったため、ベンダーは独自の配信メカニズムを開発せざるを得ませんでした。ファイアウォールやネットワーク間のローミングといった問題に対処するには、RTSP経由のビデオストリーミングは、ストリームの頻繁な再バッファリングによってユーザーを苛立たせ、ストレスの溜まるだけのものになる可能性が高いでしょう。そこでAppleは、HTTP Live Streamingと呼ばれる新たな代替手段を採用しました。
プログレッシブダウンロードとは異なり、HTTPライブストリーミングはコンテンツをリアルタイムでストリーミングしますが、最大30秒の遅延が発生する場合があります。RTSPよりもはるかにシンプルな仕組みで、ブロードキャストするコンテンツはMPEGトランスポートストリームにエンコードされ、約10秒の長さのセグメントに分割されます。RTSPで連続的に新しいデータストリームを取得するのではなく、この新しいプロトコルは最初の数個のクリップを要求し、必要に応じて追加のクリップを要求します。これはファイアウォールを透過しても問題なく動作し、標準的なWebサーバーであれば分割されたビデオセグメントを配信できるため、特別なサーバーは必要ありません。
HTTPライブストリーミングが輝く場所
HTTPライブストリーミングの真のメリットは、サーバーが複数の異なるフォーマットでクリップのバージョンを保持できることです。これにより、Wi-Fi接続を持つiPhoneユーザーは、EDGEのみを利用できる場合よりも高品質なビデオバージョンをネゴシエートできます。さらに、信号が改善または切断された場合、iPhoneは動的に高画質または低画質を再ネゴシエートできます。これにより、視聴者は利用可能な帯域幅で可能な限り最高のビデオ品質を体験でき、新しいセグメントが要求されるたびに継続的に最適化されます。
MicrosoftのSilverlight向けトロイの木馬「Smooth Streaming」とは異なり、HTTP Live Streamingはあらゆるプラットフォームのあらゆる再生クライアントで動作し、DRMレイヤーを必要としません。ただし、暗号化をサポートしているため、放送局はコンテンツへのアクセスを制限できます。このサポートはiPhoneに内蔵されたQuickTimeプレーヤーに直接組み込まれているため、ユーザーは放送局やチャンネルごとにアプリをダウンロードする必要さえありません。コンテンツ制作者は標準のウェブサイトにフィードを公開するだけで、iPhoneはデスクトップクライアントと同じようにアクセスできます。他の携帯電話も同様にこの相互運用可能な標準をサポートできるため、Palm Preのように商業的魅力が低かったり、本格的なアプリケーションを実行できなかったりするモバイルプラットフォームにも有利になります。
iPhoneに組み込まれたHTTPライブストリーミングのサポートは、AT&TのApp Storeの制限を回避する手段も提供します。これにより、ベンダーは公開されている標準規格を用いて、Web経由で、あるいはiPhoneアプリから直接、最適な品質でコンテンツをiPhoneユーザーに配信できるようになります。また、ビデオ再生も標準化されるため、パブリッシャーは独自のプレーヤーを開発する必要なく、iPhoneコンテンツをそのまま提供できます。AppleがQuickTimeに機能を追加すれば、これらのアプリはそれらの機能強化の恩恵を受けることができ、見た目も動作も統一されます。
HTTPライブストリーミングで概説されているシンプルなビデオストリーミングは、通常のHTTPサーバーを使用し、ビデオもサポートするM3P（MP3プレイリスト）形式の拡張版を使用してコンテンツデータを投稿するという点で、SHOUTcastに似ています。これにより、自作の放送局はインターネットラジオと同じパターンでインターネットTV放送を簡単に構築できるようになります。
次なる展開は？Apple TV に HTTP ライブストリーミングのサポートを追加することが明白です。これにより、放送局からの HD ストリーミングが直接可能になり、見たいチャンネルだけに料金を支払うことが可能になり、地元のケーブルテレビの独占を回避しながら、そこでは放送されていないコンテンツにもアクセスできるようになります。
同じコンテンツは、iPhone、デスクトップPC、あるいは最新のビデオコーデックを再生できるあらゆるデバイスでもアクセス可能です。だからこそAppleは、モバイルや家電製品のハードウェアアクセラレーションをシリコンレベルでサポートしていない、時代遅れのOgg TheoraをWebで利用しようとするMozillaの取り組みを支持していないのです。
HTTPライブストリーミングの例については、iphone.akamai.comをご覧ください。ライブストリームを視聴するには、iPhone 3.0またはSnow Leopard QuickTime Xが必要です。
