ドライブレコーダーの動画ファイルからGPSデータを抜き出して動画編集する(1) 解析編

こん○○は、よふかしわーくすの、よふかしさんです

今や必需品となったドライブレコーダー
わたくしのクルマにも取り付けてあります

動画は1分ごとに区切られたmovファイル
専用のViewerで開くとGPS情報が同時に見れますが
普通の動画再生アプリで開くと当然GPS情報は表示されません

今回はこの動画ファイルを出発から到着まで1本の動画にしつつ
さらにGPSログデータも合成したいなと思いましたので
その過程を残しておきたいと思います

対象のドラレコ
movファイルをバイナリエディタでのぞき見
GPSログデータの解析データ構造
GPSログデータの解析データ定義
緯度経度データの単位を考える
その他データの単位を考える
終わりに

対象のドラレコ

COMTEC製のHDR-352GHPです
2017年に購入したので、当時では結構性能よい部類でしたが、今となっては古いですね
内蔵バッテリーもほぼ死んでいる状態なので、翌朝になると日付情報がクリアされますｗ
GPSから日時を読み込んでくれますが、電源ONの後、1～2分くらいは掛かりますね…

このドラレコは専用ViewerとしてHDRviewer3が提供されてます
動画に加えて、日時、車速、XYZ軸のG、Google Mapなんかを同時に見ることができます

なんですが

動画ファイル自体が1分毎に区切られているので連続した動画として観れない
- 正確にはファイルの切れ目でラグが発生してしまう
ウィンドウサイズが一定以上大きくできなくて小さい
GPSログは専用Viewerでしか表示できないので他人に共有できない
- 一般的な動画再生アプリだとGPSデータはなく生の動画だけが再生される

という不都合なことがあります
GPSログはmovと別ファイルにはなっていないので埋め込まれている模様

そこで今回はmovファイルを解析してGPSログを取り出し
aviutlで1本の動画に合成しちゃおうという企画です

movファイルをバイナリエディタでのぞき見

まずはバイナリエディタでざっと見てみたところ
ファイルの先頭辺りにftypという文字列が見つかった
また、ファイルの最後辺りにGPSログっぽい文字列が見つかった

ftypをググってみると、MPEG4のbox構造で、ftype、mdat、moovなどの4byteタグがあり
その後の4byteがデータサイズを示していることがわかった

簡単なPythonコードを組んで探したところ、以下のタグが見つかった

ftyp
mdat
moov
udat
ICAT

先のGPSログっぽい文字列はudatの中にあることがわかった

ちなみにSinkuSuperLiteで見てみると、このmovファイルはMPEG4形式であることもわかった

ここから、本腰を入れてGPSログデータを解析していく

GPSログデータの解析データ構造

udatタグの先を見てみると
最初のデータだけヘッダデータがあるようで違うものの、2つ目以降は同じデータ構造だった

具体的にはこんな感じ（カンマと半角スペースは便宜的に記載）

XXXXX A XXXX.XXXX N XXXXX.XXXX E XXXXXXXXXXXXXXXX, 0x00, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, XXXXXXXXXXXXXXXXXXXX

※注
X：整数の文字列

HDRviewerで表示されるデータと照らし合わせて分析した結果、下記の13個に分割できた

XXXXX
A
XXXX.XXXX
N
XXXXX.XXXX
E
XXXX
XXXXXXXXXXXX
0x00, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20
XXXXX
XXXXX
XXXXX
XXXXX

GPSログデータの解析データ定義

まず、No.3が北緯、No.4がNorth、No.5が東経、No.6がEast
っぽいなぁと思ったのが取っ掛かり

次に、No.1とNo.10が同じデータになっている
データ間に0x00だったり、0x20が複数あるので、別データを区切っているためか
同じデータを2回残している模様
増加していくデータなのでインデックス的なものっぽい

No.8は日時データ
No.7は車速データ
No.11～13はX、Y、Zの順でGデータ

動画は29fpsだが、日付データは基本的に同じ値が10回繰り返されているし
動画内に601個のGPSログが残っているので、GPSは10Hzサンプリング
モータスポーツ用のGPSロガーでも5Hzなんで、高サンプリング…
HDRviewerで見ると、各データは動画のフレームレートで線形補間して表示している模様

まとめると下記となった

インデックス的なもの
固定値
緯度
N/S
経度
E/W
車速
日時
データ区切り
インデックス的なもの
前後（X軸）
左右（Y軸）
上下（Z軸）

緯度経度データの単位を考える

No.3とNo.5のGPSデータから
例えば値はこんな感じ

No.3：3539.5073
No.5：13944.4850

GPSデータはの形式は色々ある模様だが、大体下記の3つ

DD形式：度
DMS形式：度分秒
DMM形式：度分分

GPSログを色々変換してGoogle MAPに表示させてみる
Google MAPだとそれぞれ下記の書式で検索できる

DD形式：35.395073, 139.444850
DMS形式：35°39’50.73″N 139°44’48.50″E
DMM形式：35 39.5073, 139 44.4850

結果、このデータはDMM形式だった

ちなみに、これは「日本経緯度原点」の場所を指している

その他データの単位を考える

その他のデータ単位はぱっと見で分かりやすい

車速は分解能が1、単位はkm/h
日時はYYMMDDhhmmss、JST（UTCではない）
X軸、Y軸、Z軸は1文字目が符号、以降がG
符号は+/-を0/-で表現、Gは分解能が0.001、単位はG

インデックスっぽいものは基本的に100ずつ増加していく
でもたまに80だったり120だったりする
59960の次が00080になっていたので、60000でOVFする仕様
60秒の動画に10HzのGPSログだから60000で収まると思ったが
このインデックスは0ではなく00040等から始まったりするので、想定外でOVFした感じ？？

uint16の上限ではないのは何故なんだろう…

Gの符号といい、このインデックスといい、感覚的には違和感を覚えるのだが
一般的なのだろうか…？