NTT R&D フォーラムで見た展示をレビューする。
ライブ・パノラマの展示
実演デモ。
一台のディスプレイを見せられて、リモコンが手渡される。ディスプレイには会場の様子が映っている。ビデオ・カメラが映している映像。1〜6 のボタンを押すと、視点が切り替わる。リモコンの十字キーを押すと、カメラの視野が変わる。右キーを押すと右側に視線 (?) が向く。上キーを押すと上へと視線が変わる。
もう一つ。タブレットが取り出される。ディスプレイ同様、カメラの映像が映っている。タブレットを左右に動かすと、映像も同期して動く。動きはスムーズ。タブレットを持ったまま、後ろへ回れ右すれば、真後ろが見える。デモゆえに、一部画像の乱れあり。
過去の技術と新しい技術
ライブカメラ
一見するとライブカメラのデモにしか見えない。ライブカメラとは、インターネットを通して遠くのカメラが映す映像を見るもの。最近は Java アプレットを使って、ユーザーがカメラの向きを変えることが出来る。展望台などに設置されたカメラから、自分の見たい方向・拡大率で映像が見れる。さながら、その場で望遠鏡を覗いている感じ。
一例を挙げれば、ぼくの故郷は四国・高松のライブカメラ。
高松駅すぐそばにサンポートと呼ばれるシンボル・タワーがある。そのタワーの上 (東側) にライブカメラが一台備えつけられている。タワー東側から望むは瀬戸内海。ユーザーはカメラを操作して、高松港や海の様子を見ることができる。
現状のライブカメラの不満点は三つ。1 つ目は Java が必要なこと。Java の入っていないパソコンでは動かないし、Java が入らないスマートフォンやタブレットは対象外。また、Java はたびたびバージョン・アップするので、ネット・リテラシーの低いユーザーには敷居が高い。2 つ目はレスポンスが悪いこと。ユーザーがカメラに右を向けと言ったら、カメラが右を向く。ほんの少しだけどタイムラグがある。3 つ目はカメラの操作権利が一人にしかないこと。一人は右を見たい、もう一人は左を見たい。そう思っても、カメラを動かせるのは一人だけ。だから、操作できる時間に制限を設けて、ライブカメラに人が集まっている時は順番待ちをしてもらうことになる。
ライブ・パノラマ
この展示では Java を使っていない。TV でもタブレットでも動く。これは嬉しい。けれど、それは新技術のおこぼれに過ぎない。
NTT のライブ・パノラマは、実はカメラが動かない。使っているカメラが違う。ライブ・パノラマでは 360 度の撮影ができるカメラを使っている。あの Google ストリート・ビューを撮るのに使っているカメラと同種のもの。
360 度で撮影した映像をユーザーのリクエストに応じて「切り出し」てライブカメラとして表示している。利点は二つ。動きがスムーズ。もともと 360 度撮影しているわけだから、「カメラを動かす」という機械的な時間ロスがない。あるとしたらソフトウェア的な時間遅延だけれども、それはカメラ本体を動かす時間に比べれば小さい。高いレスポンス性を発揮する。タブレットを持って真後ろを向いてみる場合を考えてみて欲しい。カメラだったら 180 度回転しないといけない。ところが、このライブパノラマは最初から真後ろの映像も撮っている。真後ろの映像を切り出すだけで事は済む。
利点の二つ目は操作権利が誰にでも与えられること。カメラの視点は一つだけだけど、こちらは 360 度全方位に対応している。だから複数のユーザーが別々の視点を欲したら、ユーザーごとに映像を「切り出し」てあげるだけでいい。展示会場には 6 台のパノラマ・カメラが設定され、4 台のデモ機(TV/タブレット)があった。1 台のパノラマ・カメラから 4 つの視点 (ex. 正面・右・左・上) を見ることも、この仕組みなら問題ない。
技術のお話
肝になるのはサーバー。パノラマ・カメラには一台ずつ PC が割り当てられ、映像をサーバーに送り続けている。サーバーは 2 台用意され、送られてきた映像を管理。ユーザーのリクエストに応じて、映像の切り出しを行なう。
面白いのは、切り出した映像を「動画」にエンコードしないこと。映像を切り出したら、JPEG (静止画) にして一秒間に何枚もの画像を送る。いわゆるパラパラ漫画で「動画」を再現している。これは、モバイル版ニコニコ動画がやっていたこと (今もやっているか知らないけれど) と同じ。動画エンコードの負荷を考えると、なるほどこちらの方が負荷が低い。複数ユーザーがアクセスすることを考えたら、なおさら動画エンコードなんてやってられなさそう。
課題もある。画質の低さ。そして帯域と処理速度の問題。デモの画質は SD 画質。すなわち 640 x 480。今の BD は Full HD 画質で 1920 x 1080。理想を言えば Full HD 画質に対応したい。ところで、使っているカメラは普通のカメラじゃない。360 度に対応したカメラ。SD 画質に切り出す前の「オリジナルの映像」は 2000 x 2000 という。でかい!! 更に Full HD を実現しようとすると、4K x 4K が必要になるという。その映像データをサーバーに送るには、どう圧縮しても 10 Gbps は必要とのこと。半端ない。
あとがき
最終的な目標は、音楽ライブやスポーツの会場に Full HD のパノラマ・カメラを何十台も設置して、ユーザーが好きな視点で楽しめる様にすることだという。そういう未来が来ると楽しそう。ただ、課題を考えると遠い未来のことに思えてしまう。
それよりも上の例に出した様なライブ・カメラ。あれの代替ならすぐに出来るんじゃないかな。画質はライブ・カメラとほぼ同等な上に、Java が不要。操作性は段違いに上。頑張れば一か月位いで PC/スマートフォン/タブレット用の専用アプリ/ウェブ・アプリを開発できそう (雛型はもうあるわけだしね)。不安なサーバー負荷に関しても、(悲しいことに) この手のライブ・カメラは利用者がそんなに多くない。逆を言えば、低負荷で運用できる。負荷問題のノウハウを積みながら、より利用者の多いライブ・カメラとの置換を進めて行く。ほら、実用なんかすぐ目の前に見えている。
最後に説明員の人が一言。「マネタイズがねぇ」。ああ、そうね。当然、お金が取れなきゃ運営難しいよね。お金出してまで、既存のライブカメラを替えようなんてところはあるかしらん。もし興味のあるライブカメラの運営者、いたら NTT 研究所に声をかけてみてはどうかしらん。難しいかなぁ。面白いと思うんだけどなぁ。
No comments:
Post a Comment