高速富士山とは、インターネット上で公開されているライブカメラの画像を１日に900回程度、一定間隔でダウンロードし、日没後にこの画像からQuickTimeムービーを生成、Webサイト上にアップロードするシステム。すべてAppleScriptで記述してある。
１日のライブカメラの映像を30秒ほどのムービーに圧縮し、ライブカメラの絵の「動き」を楽しめる映像に仕立てる。１か所のライブカメラだけではなく、並行して20か所程度巡回するように設定してある。
高速富士山システムを外部非公開のまま１か月以上、Mac miniを導入してから10日あまり動作させているが、いまだムービーのアップロードなどの機能をイネーブルにできない幾つかの理由がある。
20か所というのは、だいたいの目処でしかなく、実験したところでは100か所程度の巡回を１台のマシンで行えることを確認している。ただし、ライブカメラとひとことにいっても、それぞれのライブカメラのサーバーの構造が大きく異なるため、それぞれの挙動も大きく異なる。
さて、話を戻す……まだ高速富士山の生成するムービーを公開していない理由について、であった。もちろん、まだ各ライブカメラ管理者の承諾を得ていないという運用上の問題もあるのだが、ここで扱うのは技術的な問題についてである。
１つには、Viodeo Podcastとして公開するシステムを確立したいと考えていた。このVideo Podcastがらみの問題だ。RSSを配信することは絶対条件だが、さらに一歩すすめてiTunes内で表示されるVideo Podcastとして登録。情報の伝播が行われやすい環境を作ろうと考えた。
ただ、Video Podcastとして公開するためには、Video Podcastが規定するムービーフォーマットでビデオを書き出さなくてはならない。コーデック、ムービーの縦横のピクセル数、ビットレート等がその内容だ。
ここで問題が起こる。一般的なiPod形式のビデオでは規定のビットレート内で十分な画質が得られなかったのだ。iPodの新機種登場により画面が大きいものが登場して（iPod touchのこと）、再生プラットフォームの基準が上がることを待っていた。画質を落とせないと判断し、一時はPodcastとしての配信をあきらめかけていたのだが、iPodの新機種の登場で条件が変わることも期待していたというわけだ。
高速富士山ムービーの公開が見送られてきた３つ目の理由が、安定性の問題だ。新たに巡回先に加えたライブカメラの挙動が奇怪で、高速富士山アプリケーションを停止させてしまったり、フレーム補完がうまく機能しないなどの問題が発生している。
問題が多発しているライブカメラは特定できているので、そのライブカメラを巡回先から外せば話は済みそうなものだが……話はそう単純ではない。問題の出ているライブカメラは、たしかに安定性には難があるのだが、そこから生成したムービーの動きが抜群に美しいのだ。公開時には、ぜひそのうちの１つとして加えておきたい。
仕方がないので、高速富士山を２台のマシンで運用することにして、１台は安定動作が見込めるライブカメラ用、もう１台には動作が怪しいライブカメラを巡回させるように分けるべきだろうか。
ここでようやくタイトルに関連する話が出てくるわけだが、このように運用で逃げるという選択肢がある一方で、積極的に立ち向かうという選択肢がある。
どうやって積極的に立ち向かうのかといえば……現在、ライブカメラから定期的にまる１日画像をダウンロードし続けて、日が暮れた頃にすべての画像の破損チェックを行い、破損画像を捨てている。この破損チェックを毎日数千枚の画像に対して行っているわけで、これにけっこうな時間を要している。破損チェックにムービー書き出しよりも時間がかかっているという、割と笑えない状況でもある。
そこで、１日分まとめて破損チェックを行うのではなく、ダウンロードしたそばから破損チェックを行ってはどうか、というアイデアも持っている。これが、積極的に立ち向かうという話そのものであり、「アクティブフレーム補完」と呼んでいるものだ。
ただ、ライブカメラの挙動からすると……不調のときは連続して不調状態が続くようなので、アクティブフレーム補完を行っても、破損画像が続くだけで、延々とフレーム補完作業を行いっぱなしになるのではないか、といった懸念もある。なかなか難しいところだ。