オープンイノベーション【オープンイノベーション】vol.11：GV-Sync®プロトタイプを実際に使ってみる（登録の実際）

【オープンイノベーション】vol.11：GV-Sync®プロトタイプを実際に使ってみる（登録の実際）

GV-Sync®（GNSS-Video Sync）とは

GV-Sync®は、GNSS-Video Syncの略で、GNSSの緯度経度と動画をシンクロ（同期）して、データベースに登録する、登録ツールです。

主な機能
・GNSSログと同期信号付き動画の同期処理
・地図と動画フレームの手動位置合わせ
・マルチアングルカメラ、360動画への対応
・mts（2K動画）からmp4への変換
・動画静止画切り出し処理
・データベース（postgreSQL＋POSTGIS）登録処理
・リモートストレージ"BOX"への転送機能
・動画字幕ファイル、CSVファイルの書き出し

入力と出力

※図中の"オフライン登録"は"オンライン登録の間違いです"

入力：
・GNSS-BeatBox®で取得したGNSSログ（GPX1.1当社拡張形式）
・GNSS-BeatBox®が生成する同期信号付きで録画されたmp4動画（h.264,h.265）
出力：
・静止画（EXIF JPEG）
・PosgtgreSQLデータベースレコード登録
・字幕ファイル
・DB登録CSVファイル
・再登録用TSVファイル

システム構成

GV-Sync®は、UbuntuLinuxのOS上で動作します。
（特にUbuntuに依存した作りではないので、Linuxが動作すれば恐らくどのようなPCでも動作します）

当社では、第一弾としてGPUを搭載したシングルボードコンピュータ"NVIDIA Jetson Xavier NX"に内蔵SSDを搭載し、ギガビットイーサネットでNASと接続した環境で使っています。

損傷管理データベース4D-db®（WebアプリケーションとPostgreSQLデータベース）は、クラウドサーバ上に、実データも別のクラウドストレージに設置されているため、GV-Sync®はインターネットにも出ていける環境に設置されています。

GV-Sync®から見れば、インターネット上のサーバ/ストレージでも、ローカルネットワーク上のサーバ/ストレージでも変わりありませんが、第一弾のバージョンでは、クラウドストレージとしてBOXを使う前提で、各種登録機能が作りこまれています。

GV-Sync®プロトタイプのハードウェア構成

本体：
・NVIDIA Jetson Xavier NX
(384 コア NVIDIA Volta™ GPU と 48 基の Tensor コア,6 コア NVIDIA Carmel ARM®v8.2 64 ビット CPU 6MB L2 + 4MB L3,8 GB 128 ビット LPDDR4x59.7 GB/秒)
追加パーツ：
・NVMe M.2 SSD 1TB ※内蔵SSDをBOX転送時のキャッシュディスクとして使用
・Wi-Fi,Bluetoohモジュール、アンテナ

GV-Sync®プロトタイプのソフトウェア構成

OS:
Ubuntu 18.04 LTS （NVIDIA JetPack4.5.1）
必須ソフトウェア：
Apache,PHP7.4,Python3.6.9,OpenCV4.1.1,PostgreSQL12.5,POSTGIS3.0,ffmpeg,rclone,minimodem
推奨ソフトウェア：
cifs-utils,vino,jetson-stats,psensor,

GV-Sync®で登録してみる

以下では、GV-Sync®でデータ登録する手順を記します。

データの準備

・GV-Sync®で登録を実行する前に、既定の登録フォルダ（NASのMovie2Raster/input/）配下に、gpxとmp4をコピーします。　

・videoフォルダには、カメラアングルに応じて360、360cube、back,down,front,left,right,upのサブフォルダがあるので、登録する方向にmp4を置きます。
360動画の場合は、360か360Cubeです。
（360Cubeは高解像度360動画からCubeMap切り出しを実行する場合に指定するオプションですが、今回のプロトタイプでは、機能が割愛されています）　

同期設定

Ubuntuデスクトップ上の"Movie2Raster(settings)"を起動します。　

登録対象のgpxとmp4が表示されていることを確認します。　下方向の動画に"路面"と名前を付けます。
ボタン"同期設定ファイル作成"をクリックすると、確認画面が出て同期設定ファイル生成が開始されます。

同期処理は長くても数分で完了します。

同期設定が完了したのちに、右上の"Movie2Raster"リンクをクリックします。（別タブでMovie2Rasterが開きます）」　

同期ファイルが下図のように生成されています。

動画・静止画切り出し（NAS）

Movie2Rasterが起動されると、先に生成された同期設定ファイルを読み込んで、start位置の地図と、start時点の動画のフレームが表示されます。

ここで指定すべき項目は下記です

・ジョブ名：gpxと動画のセットに付ける名前です。
・プロセス数：デフォルトは4ですが、高精細360など重い負荷が掛かるジョブになる場合は2や1に落とします。
・出力先：動画から切り出した静止画を格納する先です。（大きな空き容量が必要です）
・登録先DB：postgreSQLの登録先データベースを選択します。

同期位置（緯度経度とフレームの対応）を確認し、すべての入力項目に誤りが無ければ、ボタン"動画静止画切り出し"をクリックします。　

自動的に設定された同期位置から変更する場合は、地図画面でポイントをクリックして、動画のフレーム数を前後して調整します。

この先、数十分から数時間の長い処理が開始されます。間違いが無いか、良く確認します。（さもなくば大きな時間のロスに繋がります）　

内部動作と登録実行中の負荷

・ストレージの空き容量確認
実行開始直後、プログラムは指定された動画から、10フレーム分を静止画に書き出して、静止画の切り出し予定枚数と、ストレージの空き容量を確認します。
ここで指定した閾値以上にストレージ容量が残っていれば、切り出し実行に移ります。

処理時間：空き容量確認処理は1分程度で完了します。
アウトプット：tmpフォルダ内に静止画（サイズ計算後に自動削除）

・動画静止画切り出し実行 動画静止画切り出し実行が開始されると、設定したスレッド数のPythonプログラムが複数起動され、CPU負荷が一気に90%以上になります。
同時に、静止画を展開するためメモリ使用量が8GB近く（90%程度まで）上がります。

処理時間：数時間～数十時間（書き出し件数と1枚当たりのファイルサイズによる））
アウトプット：outputフォルダにフォルダ生成とjpeg、データベース登録用のcsvなど属性データテキスト

・データベース登録実行
動画静止画切り出しの後、データベース登録に遷移します。
データベースへの登録が開始されると、間欠的にネットワーク負荷のグラフが上下動します。

処理時間：数十分～数時間（登録件数による）
アウトプット：EXIF登録用テキスト、再登録用のcsv,tsv、動画字幕ファイル

・BOX転送
データベース登録が完了した後は、保存先ストレージ（NASや内蔵SSD）に切り出された静止画ファイルを、4D-db®が利用するリモートストレージにファイル転送を行います。
CPU負荷やメモリ消費はほとんどなく、ネットワーク利用率のグラフが間欠的に上下動します。
リモートファイル転送では、利用できるネットワーク帯域により数メガバイト/sの利用となるのが一般的です。

処理時間：数十分～数十時間（転送するファイル数やファイルサイズによる）
アウトプット：なし（動作ログのみ）

データベースの確認（postgreSQL）

実際にテーブルやレコードが登録されているかどうかを、postgreSQLのGUIツールであるpgadminで確認します。
（Q-GISなどのGISソフトウェアから直接リモートのPostgreSQLに接続することも可能です。）

テーブル"jobs"に今回登録したジョブの登録がされていて、images_yyyymmdd、labels_yyyymmddが生成されていれば、データベース登録が正常に完了しています。

登録された位置の確認は、images_yyyymmddテーブルの列"geom"を地図表示することで行えます。

BOXの確認

リモートストレージサービス"BOX"にWEBブラウザでログインし、4ddb_storeフォルダ配下のサブフォルダに、今回登録した静止画が登録されているかどうかを確認します。

登録実行中は、リアルタイムにファイル数がカウントされていきますので、今現在、どこのフォルダにファイルを転送しているのかを把握できます。

登録のパフォーマンス

容量と件数の試算

GV-Sync®は多くの事を実行しているソフトウェアで、かつ、それぞれが膨大なデータを扱う関係上、全ての実行完了までに多くの時間がかかります。

例えば、1時間の動画を撮影し、これを登録する場合、1時間：3600秒　*　FPS:30　＝　108,000枚（件）の静止画枚数とDB登録件数となります。
4K動画の場合は、書き出される静止画が2MB-5MB/枚程度、4K360の場合も同様に5MB/枚程度、11K360の場合20MB/枚が目安となります。

つまり、登録に掛かる時間とは、膨大なファイル（数十ギガから多い場合はTB）と、膨大なレコード（数万件～数十万件）を登録し、リモートストレージにコピー転送する実時間が掛かります。

実際、これまでに利用したところでは、一回の登録が短くて数十分、長いものでは数十時間の登録時間がかかりました。
コンピュータの処理性能、メモリやストレージの速度、データベース登録のパフォーマンス、ネットワーク速度の向上など、改善の余地は多く残されるものの、「これくらい時間がかかる処理である」ことは覚悟しておいた方が良いでしょう。
以下、実際に登録した実例です。

4K動画の場合（実測）

当社で良く使っているSONY HDR AX-700から生成されるmp4（4K）は、1時間の動画登録で5時間
グローバルシャッター4KカメラをH.265のmp4に変換した4K動画では、1時間の動画登録で5-11時間
がそれぞれ掛かります。

マルチカメラ撮影のデータであれば、この時間に掛けるカメラ台数分の時間が掛かります。
VIRB360などの4K360カメラ、Insta360Titanで撮影して4Kに書き出した4K動画も、上記とおおよそ同等の登録時間になります。

11K360動画の場合（実測）

現時点で最高の画質を誇るInst360Titanの11K360動画が、当社で扱う最も大きなデータになります。

スティッチ後の11K360動画は、1時間の動画登録で25時間～40時間もの時間が掛かります

これには大きな理由があり、書き出す画像が大きくメモリを沢山使うので、動画静止画書き出しを4スレッド実行ではなく、2スレッドで実行しているため、動画静止画切り出し処理が4スレッドの倍掛かることに依ります。
また生成されるファイル容量が4Kの場合の3-4倍になるため、純粋にファイル転送の実時間が数倍以上かかることに依ります。

実際、全ての処理工程の中で、ファイル転送に掛かる時間が60-80%を占めます
とはいえ、3K相当の画質の6方向マルチカメラの映像を一回の処理で実行していると考えれば、仕方がないのかもしれません。

2K以下の動画の場合（予想）

当社ではまだやっていませんが、単純にファイルサイズが4Kの1/4になるので、ファイル転送に掛かる時間が1/4になると推測され、1時間の動画登録で2.5時間程度になると予想が出来ます

マルチカメラ撮影のデータであれば、この時間に掛けるカメラ台数分の時間が掛かりますが、一日に登録できる時間数（稼働時間を8時間として）としては、3カメラ分位は出来そうです。

もちろん、夜間や休日の処理を利用すれば、6カメラ分の2K動画を一晩で処理することができます。（但し、人の段取りや調整時間を除く）

静止画切り出し・登録・BOX転送の処理時間推定

GV-Sync®の課題

前述の通り、GV-Sync®を使った動画静止画切り出し、DB登録、転送には、大きなコンピュータパワーと多くの時間が掛かっているのが実情です。
今後、工程の短縮化して、撮影から検索可能になるまでの時間をより短くするために、下記のような改善が有効だと考えています。

動画静止画変換速度の向上

まずは、処理の中心部である、動画静止画変換速度の向上です。

jtop（NVIDIAが提供するGPU利用測定ツール）で観測すると、現在の処理はCPU中心であり、GPUをフル活用しているとは言い難いので、GPUを活用できる何らかのフレームワーク（CUDAなのかOpenCVなのかはまだはっきりしませんが）を使って、動画静止画切り出し処理をプログラム面で高速化出来るものと考えています。

また、ハードウェアそのものをより高速なモノに置き換える手があります。
AGX Xavierがその筆頭ですが、現在使っているNXとAGX Xavierでは性能差が2倍以上はありますので、性能向上を期待できます。
Intel CPUとRTX3090などのGPU処理に期待するなら、ゲーミングPCの利用も有効かもしれません。

もちろん、元々のコンセプトであった、安価なPCを複数台へ並行稼働すれば良い（CPUやGPUのパワーではなく、所詮はファイル転送の速度が一番大きな制約だから）というアプローチに従って、NXを複数台スタンバイさせて工程を並行化する手段が現実的だと考えています。

360→CubeMap変換の実装

NX（ARM CPU）ではkrpanotoolを使った処理である"CubeMap"変換を実行できていません。

11Kの高精細360のメリットである、"CubeMap変換後の6面通常画角イメージを、それぞれYOLOの物体検出に掛ける"を実行するためには、GV-Sync®内で是非ともCubeMap変換を動作させてみたいところです。

実際のところ、CubeMap変換もYOLOによる物体検出もWindowsのゲーミングPCで動作させ、NAS上でデータ入出力をすれば、工程的には問題ありません。

GV-Sync®の賢いところは、CubeMap変換した個々のアングルのレコードをデータベースに全部登録しつつ、各アングルのCubeMap変換後イメージをリネームして、然るべきフォルダに格納してくれるところです。
ここを人の手でデータ加工するのはちょっと大変です（・・というか嫌です）。

転送速度の向上

転送速度を向上するために、当社では、まずNAS自体の高速化とNASとGV-Sync®が所属するネットワークの高速化に取り組みました。

ギガビットのマルチチャンネルとRAID10のNASで、以前よりも2倍～5倍の読み書きのパフォーマンスが得られ、ローカルHDD書き込みと遜色のないファイルIOが得られました。

ローカル処理部分を内蔵SSDに置き換えても見ましたが、実効速度的に有意な差を見いだせなかったことと、生成されるファイルの大きさがすぐにTBになってしまうこと、ワークフロー上でファイルコピーに掛かる時間などとの兼ね合いから、ギガビットNASに直接書く、直接読む方式を選択しました。

ただ、問題は運用システム側リモートストレージへの転送速度です。
こればかりはインターネット回線環境や、クラウド側の速度に制限されるので、高速化には限りがあります。
（他の業務でもインターネット回線を使う前提で考えれば、帯域制限を掛けないと他を圧迫します。クラウド側の制限を受ける可能性も大きいです）

クラウドストレージへの転送は、転送速度そのものを上げるのではなく、同期転送のバッチ化が有効だと考えています。

つまり、GV-Sync®の処理からBOX転送（リモートストレージへの転送）を切り離し、NASからリモートストレージへの転送を、別の大容量ファイル転送ツールに任せてしまう方法です。
回線の利用効率を考慮しながら、マルチプロセス処理で、確実・安全に（ファイル整合を保ちながら、レジューム処理をしながら）ファイル転送のみを実行してくれるソフトウェアの採用です。

動画フォーマットの変換対応

動画フォーマットの変換は是非とも実現したい機能です。
GV-Sync®は、既存の2K動画の標準的フォーマットであるmtsについては、内部でmp4に変換する機能を持っています。

今、mov（h265）→mp4変換は、撮影後に別マシンでffmpegを行って実行していますが、GV-Sync®でGPUを活用した動画フォーマット変換で出来れば、前処理の手間を削減できるからです。

mov（h265）はまだまだ閲覧できるビューアが整備されていなかったり、品質を担保したままサイズを圧縮するための適切な変換パラメータが未決なので、解決すべき技術課題はプログラム以外にも山積していますが、将来的には（なんの工夫もない）前処理のために、人手を介すのを止めて、自動的にフォーマット変換をしてもらいたいところです。

Dockerイメージ化や仮想サーバ

前述のように、動画静止画切り出し、DB登録、データ転送のプロセスは、コンピュータの能力、ファイルIO性能、ネットワーク性能の組み合わせで構成される総合力が必要です。

特定のハードウェアやOS上での稼働に縛られずに、プラットフォームやハードウェア構成を柔軟に組み替えられるようにしておきたいです。

特定のハードウェア、OS上で稼働させる想定でのDocker化や、並列処理、負荷分散への対応。異なるプラットフォーム（ゲーミングPCやクラウド仮想サーバ）上で実行できるイメージを作っておくことで、最適な処理構成を組めるはずです。

安価なIaaSクラウドサーバ上で動作して、Webブラウザ上でどこからでも登録を実行できるGV-Sync®（クラウド）が最良のソリューションであることに異論はありません。
（クラウドサービスではどうしてもファイル容量、転送量に対する課金が膨大になるため、DBサーバの近くにストレージを置くという選択に躊躇します。）
※検索システムで使うストレージに最もファイルアクセスが高速な場所に、GV-Sync®がいる方が良い。

Windows対応

Windows対応の大きな動機は、ゲームユーザに対してGPUやドライバの提供が迅速で、GPUコンピューティングの選択肢が多いこと、多くのユーザフレンドリーな業務ソフトウェア（保証付き）が提供されることです。

前述のffmpegなど画像処理ソフトウェア、業務用ファイル転送ソフトなどもそうかもしれません。

一番懸念するのは、当社のお客様がGV-Sync®を使ってデータ登録まで内部でやりたいといわれる場合に、Windowsに対する習熟度とLinuxに対する習熟度はずいぶん違うだろうということです。
※Ubuntuでいくら使いやすいデスクトップが準備されていても、やはりコマンドやファイルシステム、設定ファイルの変更くらいは使わないといけません。