DEIM Forum 2014 F4-4

遠隔カメラ側でのフレーム選択を用いた時刻指定動画再生システム
奥村開里†

荒堀 喜貴††

渡辺陽介†††

横田 治夫††† 東京工業大学工学部情報工学科 〒 152-8552 東京都目黒区大岡山 2-12-1††† 東京工業大学学術国際情報センター 〒 152-8552 東京都目黒区大岡山 2-12-1†† 東京工業大学大学院情報理工学研究科計算工学専攻 〒 152-8552 東京都目黒区大岡山 2-12-1
E-mail: †{okumura,watanabe}@de.cs.titech.ac.jp, ††{arahori,yokota}@cs.titech.ac.jp
あらまし

カメラの低価格化，ネットワークの整備，防犯意識の高まりなどの理由から定点カメラの設置が進んでいるが，多数の遠隔カメラから動画データを集約再生する場合には，最新の動画圧縮技術を用いても，転送・保存のコストが問題となる。一方，半導体不揮発メモリが安価に入手できるようになり，遠隔カメラ側で一時的に動画を保存することも可能となってきている。本研究では，遠隔カメラ側に小容量に動画データのキャッシュを用意し，集約サーバ側と協調させることで，動画データの転送・保存のコストを下げて指定した時刻の動画を品質を保って再生する時
刻指定遠隔カメラ動画再生システム Recarvips を提案する。動画キャッシュ制御のための効率的なフレーム間の類似比較の仕組みを取り入れて時間指定の再生を可能とする方法を実装し，対象の動きの多い場合，少ない場合の比較実験等を行った結果を報告する。
キーワード

遠隔カメラ, 類似判定, 動画転送方法

1. は じ め に
カメラの低価格化，ネットワークの整備，防犯意識の高まりなどの理由から定点カメラの設置が進んでいる。例えば，ライブカメラによる映像の配信を行うサービス [1]，大阪駅で顔認識を行ってその人物を追跡するプロジェクト [2]，北九州市では射殺事件による反省を活かして監視カメラの大規模な増設 [3]などが行われている。しかし多数の遠隔カメラから動画データを集約し，時刻を指定して再生する場合には，高帯域のネットワークと大容量のストレージが必要となる。
これまでも動作予測を利用した動画圧縮技術などによる保存容量，転送量の削減が行われてきた [4]。しかし，最新の動画圧縮技術を用いても，転送・保存のコストの高さからカメラ数の図1

提案システムの前提増加に十分対応できない。
一方，半導体不揮発メモリが安価に入手できるようになり，遠隔カメラ側で一時的に動画を保存することも可能となってきている。本研究では，遠隔カメラ側に小容量の動画データのキャッシュを用意し，動画集約再生サーバ側と協調させることで，動画データの転送・保存のコストを下げて，指定した時刻の動画を品質を保って再生する時刻指定遠隔カメラ動画再生システム

Recarvips (Remote-Camera Recorded Video Indicated-timePlaying System) を提案する。動画キャッシュ制御のための効率的なフレーム間の類似比較を取り入れて時刻指定の再生を可能とする方法を実現する。また，対象の動きの多い場合，少ない場合の比較実験等を行った結果を報告する。
以下第 2 節では提案手法の概要について述べ，第 3 節では提案手法の実験について報告する。さらに第 4 節では関連する研究について述べ，第 5 節でまとめと今後の課題を述べる。

2. 提 案 手 法
2. 1 システムの前提前提とするシステムの概要を図 1 に示す。本研究では、遠隔にある多数の定点カメラによって撮影された動画をネットワークを介して集約し、利用者の指定したカメラが指定した時刻に撮影した動画を再生する時刻指定遠隔カメラ動画再生システムを想定する。ここで、遠隔カメラ側には小容量のストレージを持ち、それを動画のキャッシュとして利用するものとし、動画集約再生サーバ側には利用者の要求に対応するために動画を蓄積する大容量のストレージが接続されているものとする。
上記の時刻指定遠隔カメラ動画再生システムにおいて、ネットワークのデータ転送量を削減し、動画集約再生サーバの記憶効率を高めるための手法を提案する。その際、再生される動画の品質 (FPS:Frame Per Second) が定点カメラとしての要件をれた時刻がどの ID のフレームに当たるのかを求める。
（ 3 ） その ID が該当するフレームを再生する。というものである。このようにすることで、定点で撮影した動画に動きがない場合には以前のフレームをそのまま再生することができる。

2. 4 フレーム類似度比較
本手法では撮影した動画フレームとキャッシュ中に保存されているフレームを比較する際の類似度として平均二乗誤差 [5]を求めている。今回は計算量の削減の為に比較画像と原画像を8bit のグレースケール画像化してから平均二乗誤差を求めている。平均二乗誤差は原画像と処理画像との差の二乗誤差である。
例えば縦の画素数 M ，横の画素数画素数 M ′ であり ,x(i, j)，
図 2 提案システムのデータフロー

y(i, j) が座標 (i, j) におけるそれぞれの画像の画素値だとすると，２つの画像について平均二乗誤差を求める式は，満たせないレベル以下に低下することがないようにすることが求められる。また、遠隔カメラ側のストレージ容量を現実的なM′∑∑
1{x(i, j) − y(i, j)}2′(M × M )M

i=1 j=1

サイズにすることが重要となる。

2. 2 動画フレームのキャッシュ制御
図 2 に提案システムのおける定点カメラと動画集約サーバ間のデータフローを示す。定点カメラで撮影した動画フレームと小容量動画キャッシュの間で類似判定を行い、類似していると判定された動画フレームに関しては、その ID のみを動画集約サーバに転送して、サーバ側の大容量ストレージに撮影時刻とID のペアの形で蓄積する。類似していないと判定された場合には、ネットワークを介して動画フレームを転送し、サーバ側の大容量ストレージに ID をつけて蓄積するとともに、その撮影時刻と ID のペアの情報も蓄積する。このようにすることで類似した動画フレームが多発する場合には、ネットワークのデータ転送量と動画集約サーバのストレージの記憶容量を削減することができると共に、指定した時刻の動画を再生することができるようになる。
定点カメラ側での具体的な手順としては、（ 1 ） 定点カメラで撮影した動画を JPEG のフレームに変換する。
（ 2 ） 取得した動画フレームとキャッシュ中に保存されているフレームとの間で、類似度計算を行う。
（ 3 ） 類似度が閾値以上の場合、そのフレームを類似フレームとし、動画集約再生サーバには類似フレームの ID のみを送信する。類似度が閾値未満の場合は、フレームに ID を割り当て、動画集約再生サーバにその ID と動画フレームを送信し、キャッシュに画像を保存する。その際、キャッシュのオーバーフローに対応するために、リプレイスアルゴリズムを適用する。

3 節での実験では、リプレイスアルゴリズムとして、LRU とLFU の比較を行う。スワップアウトされるフレームは、動画集約再生サーバにあることが保証されているので、廃棄する。

2. 3 フレームの再生手順
動画集約再生サーバ側での再生手順は、（ 1 ） 利用者が再生したいカメラと時刻を指定する。
（ 2 ） 撮影時刻とフレームの ID のペアの情報から、指定さとなる。この値を類似度判定の閾値と比較している。

2. 5 比較時間の短縮
動画の品質を保持して動画データを転送、保存するには、リアルタイムに撮影したフレームとキャッシュ内のフレームの比較を行う際に、長時間を要することで撮影 FPS が著しく低下する事を避ける必要がある。単純に、類似画像をキャッシュ内から線形に探索すると、キャッシュするフレームの枚数が多くなるに従って、比較に時間が掛かり FPS が下がり品質が劣化する。この問題はキャッシュのヒット率を上げる為にキャッシュサイズを大きくする場合に深刻となる。
その問題を解決するため，キャッシュ中の似ている画像を検索する時に Perceptual Hash [6] [7] を用いることを考える。

Perceptual Hash は SHA-1 や MD5 などの暗号学的ハッシュのようにハッシュ化する前のデータが 1bit でも異なっていれば全く違う値になるハッシュ関数とは異なり、似ている画像ならば似ているハッシュ値になるハッシュ手法である。PerceptualHash を利用すると，撮影したフレームとキャッシュ中に存在するフレームを比較する際にそれぞれのハッシュ値間のハミング距離が大まかな目安となる。このため予めキャッシュに保存する画像の Perceptual Hash を求めておけば少ない計算量で類似度比較を行うことが可能となる。
しかし Perceptual Hash だけでは、正確な類似度比較ができない。つまり、他にさらに似ているフレームが存在するにもかかわらず、別のフレームが一番似ていると判断してしまうことがある。そこで、そのようなことを防ぐために Perceptual

Hash は比較的似ているフレームの候補を複数選ぶために用い、最終的な比較は 2. 4 で述べたフレーム類似度比較を行う。
具体的には図 3 および以下で示す様な 2 段階の比較を行う。
（ 1 ） 撮影したフレームのハッシュ値を求める。
（ 2 ） キャッシュに保存してある画像の予め求めていたハッシュ値と撮影したフレームのハッシュ値のハミング距離を求めるという一段回目の比較を行う。
（ 3 ） ハミング距離が小さかったフレームを指定数選び出す。

の定点カメラの映像であり，撮影した動画中の動きに違いがある。動画は，全フレームのうち人が含まれるフレーム数が50%程であり動きが大きい，全フレームのうち人が含まれるフレームが 10%程にであり動きが小さい，という違いを持っている。まとめたものを表 1 に示す。
表 1 動画の特徴
全フレームのうち人が含まれるフレーム数が 50%ほど
動画 1であり比較的動きが大きい
全フレームのうち人が含まれるフレーム数が 10%ほど
動画 2であり比較的動きが小さい

実験のハードウェア環境としては，表 2 に示す装置を遠隔カメラ側と動画集約再生サーバ側に用いた。また実験システムの図 3 二段階比較の手順

実装には C++を用い，カメラおよび画素を扱う際のライブラ
リとして Open CV を用いた [8]。
表2実験環境CPUメモリ
OS2.0GHz クアッドコア
遠隔カメラ側Intel Core i7
16GB OS X 10.9.1
Intel Xeon x5570
サーバ側
2.93GHz(Quad Core) 16GB CentOS 5.4

3. 2 二段階比較の有効性
3. 2. 1 実

験キャッシュに保存されている全フレームに対して単純な類似度比較を行うと，計算量が多くなり，遠隔カメラとして十分有効な FPS が得られない。そこで Perceptual Hash によって大図 4 提案システムの処理フロー（ 4 ） 選び出したフレームに対してのみ第 2. 4 節で述べた二乗平均誤差を使った類似度比較を行うという二段階目の比較を行う。
この二段階比較により、単純にキャッシュに保存されているまかな比較を行い，ハッシュ値が近い３つに対してのみ厳密な類似度比較を行う二段階比較を適用した場合と適用せず平均二乗誤差だけを用いた場合を表 3 の条件で FPS について比較した。
表 3 二段階比較の有効性に関する実験構成
キャッシュ
キャッシュ
動画 アルゴリズムの枚数
二段階比較

全てのフレームと撮影したフレームの類似度を比較している場

動画 1

LRU

40

使用しない合には計算量が多すぎて実用的な FPS を達成できない問題を

動画 1

LRU40使用解決する。
以上をまとめた提案システムの処理フローを図 4 に示す。

3. 実

験

3. 2. 2 結果

図 5 に示すようにキャッシュの枚数が 40 枚の場合でも二段階比較を用いない場合は平均して 2.56FPS という結果であった

提案した Recarvips に対する二段階比較手法の有効性、最適なキャッシュアルゴリズム、Perceptual Hash の生成方法を実験によって調べる。また，キャッシュの枚数を変化させた時のキャッシュヒット率と転送量の変化，似ていると判断する閾値
を変化させた時のキャッシュヒット率と転送量の変化を実験によって調べる。その後，最適な手法を用いた場合に Recarvipsで転送量をどれほど削減できるかの実験を行う。

3. 1 実 験 環 境
実験においては，手法比較のため，あらかじめ録画した２種類の動画に対して本手法を適用し実験を行った。用いた動画はどちらも約 2000 フレームの JPEG 画像で解像度が 640 × 480

が，二段階比較を用いた場合は平均して 7.95FPS という結果になり，FPS の大幅な向上が達成できていることがわかる。

3. 3 キャッシュアルゴリズム
3. 3. 1 実

験

提案手法における遠隔カメラ側のキャッシュのリプレースアルゴリズムとして LRU アルゴリズムと LFU アルゴリズムのどちらが最適なキャッシュアルゴリズムであるかを調べるために実験を行った。表 4 の条件で実験を行った。

図 5 二段階比較の効果について動画

表 4 実験構成
キャッシュ
キャッシュアルゴリズムの枚数
二段階比較

動画 1

LRU40使用

動画 1LFU40使用

動画 2LRU40

使用

動画 2

LFU40

使用図 7 PerceptualHash 生成アルゴリズムのヒット率比較

図 8 PerceptualHash 生成アルゴリズムの FPS 比較の比較を行う。この２つの手法に対しどちらの手法が本手法に適当かを実験して調べた。
図 6 キャッシュアルゴリズムの比較
動画

3. 3. 2 結果

実験結果は図 6 のように動きの多い動画に対してのキャッシュ

表 5 実験構成
キャッシュキャッシュアルゴリズムの枚数

ハッシュの生成方法

動画 1

LRU

40

Marr-Hildreth

動画 1

LFU40

DCT

ヒット率は LRU が 51.7%, LFU が 57.1%と LFU が優れていた。また，動きの少ない動画に対してはキャッシュヒット率は

表 5 の条件で実験を行った。

LRU が 90.5%, LFU が 90.1%となり，LRU がわずかに優れて3. 4. 2 結いるという結果になった。

図 7 からキャッシュのヒット率はあまり変わらないことがわか

果

動きの少ない動画に対して LRU はわずかに優れているが，る。しかし計算時間に関しては，図 8 からわかるように，DCTLFU は動きの多い動画に対しては LRU を大きく離すヒット率を用いた手法のほうが著しく早くなっていることがわかる。こを達成できたので LFU を以降の実験では採用する。のため本手法には DCT を用いた Perceptual Hash 生成方法の3. 4 Perceptual Hash の生成方法の比較
3. 4. 1 実験Perceptual Hash に与える値の算出手法として Marr-Hildreth
アルゴリズム [9] と離散コサイン変換 (DCT) [10] を用いた場合方が適当であると思われる。

3. 5 キャッシュの枚数が与えるキャッシュヒット率の変化
3. 5. 1 実

験キャッシュに保存するフレーム枚数を変化させた時のキャッ図 9 を見ると，動きの少ない動画 1 に対しては，5 枚以上ではキャッシュの枚数を変化させてもヒット率にあまり変化がみられず，転送量にも変化が見られなかったが，動きの多い動画

2 に対しては，キャッシュの枚数を変化させるとヒット率に増加が見られた。また図 10 からヒット率の上昇に伴い，フレームの転送量が減少していることがわかる。

3. 6 類似判定での閾値の影響
3. 6. 1 実

験

2. 4 で説明した方法で求めた平均二乗誤差を閾値として用いて，閾値を上下させるとどのような変化が起こるかを実験によって調べる。今回の比較対象画像を画素ビットが 8bit の640 × 480 のグレースケール画像にする環境では人が写って動いている時の二乗平均誤差は約 300 ほどであり，それよりも小さい閾値をパラメータとして実験を行った。
図9

キャッシュ枚数を変化させた時のキャッシュヒット率の推移

しかしその際に，どのような時に似ている画像が使われるのが適当で，またどのような時に似ている画像が使われないのが適当かを整理しておく必要がある。まず似ている画像が使われる，言い換えるとキャッシュにヒットするのが適当な場合は，蛍光灯のフリッカーによる撮影画像の明るさのチラツキや，人が写っているが動きが無い場合などが挙げられる。また似ている画像が使われない，言い換えるとキャッシュにヒットしないのが適当な場合は，動いている人が写っている場合が挙げられる。この指標をまとめた表を表 7 に示す。
表 7 適当か判断する為の指標
キャッシュにヒット
蛍光灯のフリッカーによる明るさの違いするのが適当な場合
人が写っているが動きがない場合
キャッシュにヒット動いている人が写っている場合しないのが適当な場合

以上の指標を踏まえて撮りためた動画に対して Recarvips
図 10キャッシュ枚数を変化させた時に全フレームを転送した場合とを使用して，キャッシュにヒットしているところから 10 箇所，の転送量の比率の推移

キャッシュにヒットしていないところから 10 箇所それぞれランダムに選び出し，上記の指標に合致するものをカウントし的中

シュヒット率の変化及び転送量の変化を調べる実験を行った。

率及びキャッシュヒット率を調べる実験を行う。ここで表 7 の指評価においては，表 6 に示したような特徴を持つ動画 1 と動画標を全て満たす場合を 100%とし，実際に合致したものの百分2 を用い，キャッシュの枚数を変化させ，キャッシュヒット率の率を指標的中率とする。また表 8 の条件で実験を行う。ここで変化を調べた。

いう動きの多い動画とは，全フレームの中で，人が含まれるフ
表6

実験構成

レーム数が全フレーム数の 50%程度であるということである。
表8動画

フレーム数

動画 130804 フレーム

動画 230101 フレーム

特徴
全フレームの内人が写っているフレームが10%ほどで動きが小さい
全フレームの内人が写っているフレームが50%ほどで比較的動きが大きい

3. 6. 2 結3. 5. 2 結果

実験環境

実験対象動画

キャッシュ枚数

動きの多い動画

40 枚

果

実験結果の図を図 11 に示した。二乗平均誤差が 60〜90 で大図 9 にキャッシュの枚数を変化させた時の動画 1 と動画 2

きくキャッシュヒット率が伸び，そこからはゆるやかに伸びてで Recarvips を使用した時のキャッシュヒット率の推移，図 10いくという結果になった。また指標的中率は二乗平均誤差が 90に圧縮せず動画を転送した場合の転送量を 100%とした時にくらいまでは非常に高い値を示しているがそこからは下がってRecarvips を使用した時の転送量の百分率の推移を動画 1, 動画いってしまうという結果になった。

2 について示した。

二乗平均誤差が 0〜30 でキャッシュヒット率が 0 のままなの

図 11 類似判定での閾値に関する実験結果

図 12 提案手法でのシステム全体での転送量の変化は撮影した時のノイズによる誤差だけで，似ていないと判断しかった。これは，本手法では単純に JPEG で画像全体を送っててしまっているからだと思われる。60 あたりではたまにキャッいるため，動きが多い場合には，差分転送のほうが効率が良い

シュにヒットするが，本来の目的である転送量の大幅な削減とためである。また，比較的動きの少ない動画に対しては，全ていうのは達成できない。また閾値を 120 以上大きくするとキャッのフレームを転送した場合には 168MB の転送量が必要だった

シュのヒット率は上がるが，元の動画とかけ離れてしまうのでのが，16MB の転送量，つまり 9.5%の転送量で済むようになっ本手法には適当ではない。閾値を 90 に設定した時キャッシュ内たことがわかった。さらに，H.264 で圧縮して転送した場合にのフレームを見ると，フリッカーによる明るさの違い以外はほは 23MB の転送量であり，H.264 よりも転送量の削減効果を得

ぼ同じ画像がどちらもキャッシュに格納されているのが確認でることができた。

きた。また動いている人が写った時には二乗平均誤差が 300 を

3. 8 動画の長さによる転送量の変化超えることが多かったので，閾値を 90 に設定すると，動いて

3. 8. 1 実いる人はキャッシュヒットせず期待通りの挙動を示した。以上

3. 7 で動きの大きい動画と動きの少ない動画に対して Re-

験の考察から閾値となる二乗平均誤差は 90 前後が適当だと思わcarvips を使用した場合の転送量の変化を調べたところ，動きれる。の少ない動画に対しては H.264 よりも高い削減効果を得ること

3. 7 本手法を適用しての転送量の変化ができた。これは H.264 は一定頻度でキーフレームとなるフ

3. 7. 1 実

レームを転送しているのに対し，Recarvips では一度送信する験

ここまでの実験結果を基にキャッシュリプレースアルゴリズと二度は送らないという特徴によるものだと思われる。そこで，

ムには LFU，Perceptual Hash を求める手法には DCT，キャッ動画のフレーム数の違いが与える影響を調べるために，表 9 のシュの枚数は 40 枚, 類似判定に用いる閾値には 90 をそれぞれような特徴を持つ動画を用意し，動画の長さを変化させる実験用いて Recarvips のプロトタイプを構築した。この Recarvipを行った。のプロトタイプを用いてデータ転送量における効果を評価する。

表9

本手法を適用せずにフレームをそのまま転送した場合，H.264

実験構成

フレーム数

特徴を用いて動画を圧縮して転送した場合，本手法を適用し転送し約 2000 フレーム

比較的動きが小さいた場合の転送量の変化を調べた。評価においては，表 1 の動き

約 10000 フレーム

比較的動きが小さいの多い動画，及び動きの少ない動画の２つに対してそれぞれ転約 20000 フレーム

比較的動きが小さい送量の変化を調べた。

約 30000 フレーム

比較的動きが小さい

3. 7. 2 結果

図 12 に動きの多い動画，動きの少ない動画の２つに対して3. 8. 2 結果

Recarvips を用いて転送した時の転送量を示した。動きの多動画フレーム数を 2000 から 30000 まで変化させ，Recarvips

い動画に対しては，全てのフレームを転送していた場合にはを適用し転送した時と，H.264 により圧縮し転送した時の転送160MB の転送量が必要だったのが，本手法では 70MB の転送量の変化を図 13 に示した。また元動画をそのまま転送した場量の転送量，つまり 43.7%の転送量で済むようになった。しか合の転送量を 100%とし，H.264 で圧縮して転送した場合の転し，フレームの動きの予測を行い差分だけを転送することに送量と，Recarvips によって転送した場合の転送量の百分率をより圧縮を行う H.264 では 44MB まで転送量を減らすことがそれぞれの動画について図 14 に示した。

できたので，H.264 ほどの転送量削減効果は得ることができな

図 14 から見て取れるように，Recarvips は H.264 とくらべできることも確認できた。時刻を指定して動画の再生が行えることも，それぞれの遠隔カメラの時刻に対応するフレーム IDを撮影時刻とペアにして保存することによって達成できた。リアルタイムに転送処理を行って遠隔カメラ側のストレージ要件を極めて小さくすることができた。そして，二段階比較を用いることによって，単純にキャッシュ中の全てのフレームと撮影フレームを比較する場合と比べて大幅な FPS の向上も達成できた。また複数枚のキャッシュを用いることによって照明のフリッカーにも対応できている。ただ，動きの多い動画に関しては，単純に JPEG で画像全体を転送していることから，H.264よりも転送量が多くなってしまっている。転送量を削減するためには，差分画像や動き予測と提案手法を組み合わせることが考えられる。
図 13 Recarvips と H.264 の動画の長さによる転送量の変化

4. 関 連 研 究
類似度比較の部分では平均二乗誤差を利用した単純なアルゴリズムを採用したが，それ以外にも照明の変化を考慮して，背景との差分をとる研究 [11] が行われている。また今回大まかな類似度の比較を行う際に Perceptual Hash を利用したが，高速な類似度比較の研究 [12] が行われている。従来研究においても，撮影していたフレームを一定時間保存しておき，それと似たフレームが来たら蓄積しておいたデータを採用したりするア
イディアがある [13]。しかし本手法はそれとは異なり，キャッシュとして保存しておいて，LRU や LFU などのアルゴリズムによって期間を設定し，無駄に破棄してしまう事なく転送量を減らすことができる。また最近使われている動画圧縮形式のH.264 [14] などでは次のフレームの動きを予想して，その差分を転送するが，ある頻度でキーフレームである I フレームを転送することが前提となっている。しかし本手法では基本的には
図 14

全フレーム転送に対する Recarvips と H.264 の転送量の比率の動画の長さによる変化て転送量の増加割合が小さいことがわかる。また図 14 から，H.264 は動画の長さが長くなってもあまり圧縮率は変わらないが，Recarvips では動画の長さが長くなるほど転送量の削減度合いが大きくなっていることがわかる。

Recarvips では一度転送したフレームは送信する必要がなく，動画の長さにかかわらずキャッシュにヒットしないフレームの数によって転送量が決定されるため，フレーム数が増えれば増えるほど大きな違いが出たことがわかった。それに対して，H.264
では差分が無い場合でも一定間隔ごとにキーフレームとなるフレームを送信する必要があるため，動画の長さが変化しても転送量の削減度合いにあまり違いがでなかったと思われる。

3. 9 考察

転送コスト及び、保存コストを下げることについては、設置された遠隔カメラの動画転送量を大幅に減らすことができていることが実験によってわかった。特に、類似フレーム情報を利用して転送量を減らすという本手法の特徴からも、動きの少ない場所を撮影している場合にはさらに大きな効果を得ることが一回転送するのみである。

5. お わ り に
5. 1 ま と め
本研究では遠隔カメラにフラッシュメモリなどのストレージを持たすことができることを前提に、そのストレージをキャッシュとして有効利用し、フレームの取捨選択を行い転送量、保存コスト、捨てられたフレームを再現する Recarvips (Remote-Camera Recorded Video Indicated-time Playing System) を提案した。
実際に Recarvips のプロトタイプを構築し実験を行うことによって、以下を達成することができた。

•

提案手法によって転送コスト及び保存コストを下げられること•

フレーム ID と撮影時間をペアで蓄積することによって時刻を指定して動画の再生が行えること•

リアルタイムに転送処理を行って遠隔カメラ側のストレージを圧迫しないようにすること•

転送量を減らすための演算によって動画の品質 (FPS) が著しく下がることを Perceptual Hash を用いた二段階比較を使って防ぐこと

これらにより提案手法の有効性を実証することができた。実際に Recarvips で転送・保存後に時刻指定再生した画像と，元画像と見比べると，動きの多い部分でも特に違和感がなく，動きの少ない部分でもフリッカーのないほぼ静止画として見えることが確認できた。

5. 2 今後の課題
今回は指標として一つのアルゴリズムしか試していないが、そのほかにも SN 比 [16] を用いたりと、さらに最適な指標を模索してみる必要があるだろう。また、今回は入力動画の画素数を変化させた実験は行っていないが、画素数を変化させた場合の類似度判定に用いる閾値や FPS 等への影響を調べる必要がある。一方、動画中の人物に関しても、人数が複数の場合や、動作、着衣の類似性等の影響についても評価を行っていきたいと考えている。今回は似ていると判断されるフレームがなければ、そのフレームの情報をそのまま転送していたが、さらには動画圧縮技術 H.265 [15] などで用いられているようにフレーム

217(1980)[10] S. A. Martucci, “Symmetric convolution and the discretesine and cosine transforms,” IEEE Trans. Sig. Processing
SP-42, 10381051 (1994)[11] 波部 斉, 和田 俊和, 松山 隆司 「証明変化に対して頑健な背景差分法」情報処理学会研究報告. CVIM, [コンピュータビジョンとイメージメディア] 99(29), 17-24, 1999-03-18(1999)[12] 武本 浩二, 加藤 丈和, 和田敏和「画像の 4 分木表現に対する最近傍識別 (PRMU&NC テーマセッション (1) : 認識と学習)(認識と学習, 模倣学習)」電子情報通信学会技術研究報告. PRMU,
パターン認識・メディア理解 103(390), 1-6, 2003-10-17(2003)[13] 日本特許
株式会社日立製作所. 動画データ圧縮蓄積再生装置. 特公平
5-137104 号. 1993/6/1.
[14] H264 http://www.itu.int/rec/T-REC-H.264/e (2014/1/9アクセス)[15] 大久保 榮, 鈴木輝彦, 高村誠之, 中條健「H.265/HEVC 教科書」
株式会社インプレスビジネスメディア (2013)[16] 八巻 俊介, 阿部 正英, 川又 政征「SNR と PCE を用いた位相限定相関関数の性能評価」平成 25 年度電気関係学会東北支部連合大会講演論文集, 2E15.(2013)

間の予測をして、その予測との差分のみを転送するようにするなどにより、さらなる転送量の削減が可能であろう。ただそれには今以上に演算量が多くなってしまい、ただ単に計算を追加しただけではまた FPS の低下という問題がでてきてしまうため、別の工夫が必要となると予測される。また、一日の間に光の変化などが起こることを考慮して、撮影時間帯によって用いるキャッシュを分割する手法なども考えられる。

6. 謝

辞

本研究の一部は、日本学術振興会科学研究費補助金基盤研究（A）(#22240005, #25240014) の助成により行われた。

文

献[1] USTREAM http://www.ustream.tv/(2014/1/9 アクセス)[2] 「 防 犯 カ メ ラ 増 設 北 九 州 市 が 検 討 市 長「 早 け れ ば 来 年度」」 http://www.nishinippon.co.jp/nnp/f_kitakyushu_
keichiku/article/60206(2014/1/9 アクセス)[3] 「通行人の顔，カメラで撮影し追跡 大阪駅ビルで実験へ」http://www.asahi.com/articles/ASG15410GG15PTIL008.html(2014/1/9アクセス)[4] 加藤 剛志, 小佐野 智之, 石川 憲洋「移動端末からの高精細・高画質な遠隔監視を実現するハイビジョン監視カメラ向けトランスコーダ・カメラ制御 GW」NTT DOCOMO テクニカル・
ジャーナル Vol.17 No.4
[5] 森瀬 晶志「画像類似度測定の初歩的な手法の検証」島根大学 総合理工学部 数理・情報システム学科 田中研究室[6] CHRISTOPH ZAUNER “Implementation and Benchmarking of Perceptual Image HashFuctions’ eBooks(2011)[7] Baris Coskun, Nasir Memon “Confusion/Diﬀusion Capabilities of Some Robust Hash Functions” Information Sciences
and Systems, 2006 40th Annual Conference on pp.11881193(2006)[8] OpenCV http://opencv.org/ (2014/1/9 アクセス)[9] D.Marr, and E.Hildreth “Theory of Edge Detection” Proc.
R. Soc. Lond. B 29 February 1980 vol. 207 no. 1167 187-