WOWOWスペシャルコンテンツ「12 CAMS, CREATE YOUR RAINBOW」の仕組み

12 CAMS, CREATE YOUR RAINBOW

WOWOWは、イギリスのロックバンド「RADIOHEAD」のジャパンツアーを独占放映するにあたり、番組プロモーションのためのスペシャルコンテンツ「12 CAMS, CREATE YOUR RAINBOW」を展開しました。サイトは、2008年10月5日にさいたまスーパーアリーナにて番組のために収録された同グループのライブ映像を、12台のカメラから閲覧でき、さらにユーザー自身のスイッチングでオリジナルのライブ映像に紡ぎ合わせることのできる、インタラクティブなコンテンツとなっています。

スペシャルコンテンツ「12 CAMS, CREATE YOUR RAINBOW」

これまでサイトでライブ映像を使う場合は、番組ディレクターによってあらかじめ編集されパッケージ化された形式での提供方法が一般的でした。今回の試みは、ユーザー自身がその制作プロセスに参加し、できあがったコンテンツを楽しむことができるという、Webだからこそ実現できた新たなコンテンツの楽しみ方の提案です。

RADOHEADは、最新アルバム「In Rainbows」をネット上で販売し、ユーザー自身にその購入価格を決定させたり、同アルバム収録曲「Reckoner」のリミックスを一般公募するなど、音楽流通のありかたに対して常にアグレッシブな姿勢を取っています。一方でWOWOWは、ライブ番組制作・放送のプロフェッショナルであり、非常に高いクオリティのライブ映像資産を保持しており、その新たな活用方法を模索していました。今回は番組プロモーションを通じて、Webに対する両者の価値観が一致することで実現できた、とても幸せなプロジェクトだと思います。僕は制作を担当させてもらったのですが、従来の放送や音楽プロモーションの枠組みを超えた企画で、具体的なアウトプットを任せてもらえたのは本当に貴重で興味深い経験でした。

本記事では、このサイトを制作するにあたって工夫（というか苦労）した点を、主に技術面から説明します。

技術的な仕組み

ライブ感を獲得するために

今回のコンテンツで一番大事にしたかったのは「ライブ感」です。通常、Webで再生される映像は、プログレッシブ再生でもストリーミング再生でも、再生バッファが足りなくなった時点で一時停止してしまいます。しかし、今回に限ってはライブの臨場感を獲得するために、一度演奏が始まったら最後まで途切れることなく再生され続けることが大事だと考えました。たとえカメラを切り替えても、そこでバッファリングが挟まることなく再生が続くようにしたかったのです。この要件を実現するためにはどうしたらいいのか、いくつかの方法を検討しました。

再生方法の検討

一番簡単なのは、12個の映像を同時に再生しておいて、ユーザーが選んだものだけを表示する方法です。しかし、12個の映像をプリロードすると膨大なファイルサイズになるし、ストリーミングするにしても膨大な帯域幅が必要になり、どちらも現状の一般的なユーザー回線状況を考えると非現実的です。また映像の再生負荷もかなり高くなることが予想されます。

もう1つ思いつくのは、FMSなどのストリーミングサーバを活用して、12個の映像のスイッチングをサーバ側でダイナミックに行い、ユーザーには1本のストリーミング映像として配信する方法です。今回はFMSを使うことができなかったため、検証するに至りませんでしたが、有効そうな気はします。スイッチングに対して、実際どの程度のタイムラグが出るのか興味があるので、もし誰か試みた方がいらっしゃいましたらぜひ教えてください。ただ、音を途切れさせずに映像を繋ぐのがちょっと難しいかな、と予想します。

このようにいくつか検討した上で今回僕が取った方法は、以下の2つです。

1. 音を確実に途切れさせないために、サウンドとサムネイル映像に関しては、プリロードしておく。
2. スイッチングした際に大きく表示する映像に関しては、スイッチングした映像の該当する時間部分をダイナミックにロードする。

具体策1：サウンドとサムネイル映像のプリロード

サウンドと画面下部のサムネイル映像に関しては、最初に完全に読み込まない限り、途切れさせずに再生することを保証するのは難しいと判断し、コンテンツの本編が始まる前に全てプリロードするようにしました。これで途切れず再生するための基盤を得ることができたのですが、その弊害として最初に読み込むファイルサイズがとても大きくなってしまい、本編開始までの待ち時間が結構長くなってしまいました。

この待ち時間を退屈させないために演出面で工夫することを考えました。ライブが始まる直前の「会場がRADIOHEADメンバー登場を待ちわびている」状態の映像をイントロムービーとして再生するようにしました。会場の期待感や高揚感をPCの前のユーザーとも共有できたらいいなと思いつつ。

具体策2：スイッチング映像のダイナミックなロード

一方、スイッチングした高解像度の映像を最も効率的に配信する方法は、

• スイッチングしたカメラの映像の
• 必要な秒数の部分のみを逐一ロードし再生する

というものだと考えました。「スイッチングしたカメラの映像」をロードするというのは簡単ですが、「必要な秒数の部分のみをロードする」というのが難問です。通常、映像ファイルは常にその某頭からしかロードすることができません（YouTubeのように、シークした時点からプログレッシブ再生できるような強力なサーバ側のシステムが用意できるのであれば話は別ですが）。

この問題を解決するために、

• 各カメラ映像を0.5秒単位で分割したファイルにする

というちょっと強引な方法をとりました。こうして分割したファイル群を用意しておけば、例えば「10カメの30.5秒目から再生したい」という時でも、該当する映像ファイルから順に読み込んで再生していくことができます。また、ユーザーがカメラを切り替えた際にも、すぐに新しいカメラの映像ファイルの読み込みに切り替えることができます。

各カメラ映像を0.5秒単位で分割したファイルにして、ユーザーのアクションに応じて該当する部分のファイルをダイナミックにロードしています

ただ、この方法にも難点が2つあります。1つは、各映像ファイルの再生時間が圧倒的に短いため、映像エンコードの圧縮効率が悪く、画質の割にファイルサイズが大きくなってしまうという問題です。これは基本的に回避のしようがないのですが、エンコードする元素材の黒味を気持ち強めにしたり、映像の上に細かくドットを打ったレイヤーを敷くことでブロックノイズを目立たせなくするなどして、視覚的に画質の劣化感を軽減するような処置を施しました。

もう1つの問題点は、バッファリングのための一時停止を禁忌としている都合で、回線のコンディションによっては読み込みが追いつかなくなってしまう可能性があることです。ファイルの読み込みが間に合わない場合は、代替映像としてサムネイル映像を無理やり拡大したものを再生するため、モザイク状の映像になってしまいます。これについても根本的な解決方法は無いのですが、少なくとも日本国内であればブロードバンド環境が一般的な回線環境だと考えて問題ないだろうと想定し、最低1Mbpsの回線であればモザイク化することなく映像を再生できるよう、映像の圧縮率を調整しました。また、コンテンツの開始時にユーザーが画質を選択できるようにし、あまりにモザイク状態が継続するようであれば画質を下げたバージョンで閲覧できるようにしました。

システムとデザイン

以上、今回の要件を実現するために、映像ファイルの構成とそのロードの仕方で、少し特殊な方法をとっているというお話でした。今回のように複数台のカメラを同時に回した映像素材を扱う機会は、普通なかなか無いような気がするので、いつこの記事が役に立つのかという疑問が沸かないこともないですが、少なくとも上記のような細かい検討を行って開発していることは何かの参考になるかもしれません。

僕が一番重要だと考えるのは、今回で言えば「ライブ感」がこのサイトを成立させるための根幹となる要素だと考え、その一点を追求するための技術的な工夫を重ねているところです。全体のゴールを見定め、見失わずに制作を進めることができるのであれば、そのサイトの強度というか純度を結構高いところまで持って行くことができるんじゃないかと思います。