オーディオ/ビデオを無線伝送
仕組みからパケット分析まで − iOS 4.2で登場した「AirPlay」の深奥に迫る
■AirPlayを分析する
今回登場したAirPlayは、AirTunesとの後方互換性を維持しつつ、新たに動画の送信をサポートしている。従来は(公式には)iTunesのみだった送信側デバイスも、iOS 4.2以降を搭載したiPad/iPhone/iPod touchが加わった。なお、新発売の第2世代AppleTVはAirPlayをサポートするが、受信機器としてのみ、すなわち「ワイヤレステレビ&スピーカーのためのセットトップボックス」としてしか機能しない点は、理解しておく必要がある。
AirPlayの仕様は非公開だが、LANを流れるパケットを調べればある程度の情報を把握できる。筆者が利用したのは、Mac OS X用パケットアナライザソフト「CocoaPacketAnalyzer」(フリーウェア)。iTunesで動画を再生するとき、映像/音声の出力先を第2世代AppleTVに指定し、そのパケットをキャプチャしてデータストリームの構成を調べようという寸法だ。
動画の再生を開始すると、Mac OS XとApple TVの間で(ピア・ツー・ピアで)ネゴシエーションが始まることがわかる。そのパケットのヘッダ部分を見ると、「HTTP/1.1..User-Agent: iTunes/10.1」とあることから、HTTPベースのストリーミング技術に基づいていると考えられる。
ちなみに、音楽(AACファイル)を再生するときのパケットも確認してみたが、動画とは異なり「rtsp://」で始まるURLが埋めこまれていた。この接頭辞からすると、パケットがリアルタイムストリーミングプロトコル(RTSP)で送信されること、かつ従来のAirTunesと同じ方式であることがわかる。つまり、後方互換性維持のため、音楽の再生にはAirMac Expressにも解釈可能な従来方式のRTSPを使用し、動画の再生にはHTTPベースの異なるプロトコルを使用するものと考えられる。
さらにパケットのヘッダを眺めてみると、「video/mp4」といった文字列が確認できる。MP4フォーマット、特にH.264ビデオの動画はIntel Core Duoプロセッサですら再生処理(デコード)に高い負荷がかかり、他のフォーマットにリアルタイムで再エンコードすることはかなり困難なことから、HDCPのセキュリティを利用し、そのままの状態でストリーミング配信しているものと推定される。画質についても、送信元で再生したときとの差は感じられなかった。
つまり、AirPlay経由で映像を出力すると、ビデオ/オーディオともソースと同じコーデック、ビットレートなど条件面は同一で、サーバ側(iTunesやiOSデバイス)とクライアント側(第2世代AppleTV)がバッファ量などを調整しつつ、動画データをやり取りしていると考えるのが妥当だ。
ところで、AirPlay経由での映像出力は、Apple純正のソフトウェアでなければ動作しなかった。音楽同様、サードパーティーによる解析が進むかどうかわからないが、iOSアプリを配布するにはAppleの審査が必要なだけに、公開できるとしてもパソコン版のみとなるだろう。
またコンテンツホルダーのコピープロテクトに関する意識は、音楽よりも映像に対してのほうが高いだけに、AirPlayのオーディオメーカーへのライセンスは音楽の送信(RDSPプロトコル)に関してのみ、と制限される可能性も否めない。
(海上忍)