動画の再生に合わせて、横に表示されたペース、心拍数、標高、ルートもリアルタイムに変化していく。
見た目は、数字を使ったいくつかのシンプルなグラフィックです。
でも実際につくり始めてみると、「動画の上に数字をいくつか置く」ほど簡単ではないことが分かりました。
運動デバイスが記録するのはデータで、DaVinci Resolve が扱うのはタイムラインだからです。
この二つをどう正確に対応させるか。それこそが、この製品で本当に解決すべき問題でした。
すべては FIT ファイルから始まる
Garmin や COROS などの運動デバイスは、一回のアクティビティを記録するとき、大量の構造化された運動データを保存します。
その中で重要な役割を果たしている形式の一つが FIT です。
一つの FIT ファイルには、次のような情報が含まれることがあります。
- 時刻
- GPS 座標
- 心拍数
- 速度
- 距離
- ピッチ
- パワー
- 標高
- ラップ
- デバイス情報
さらに、種目ごとに異なるさまざまなデータも含まれます。
情報量という点では、とても豊富です。
ただ、動画をつくる人にとって、そのデータをそのまま使えるわけではありません。
動画編集ソフトには、次のことが分からないからです。
ある FIT データが、動画のどのフレームに対応するのか。
ここが、問題全体の出発点になります。
まったく別の二つのタイムライン
スポーツウォッチとカメラは、それぞれ独立したデバイスです。
時計は 06:31:18 に記録を始めているかもしれません。
カメラが撮影を始めるのは、その数分後かもしれません。
途中で録画を止めたり、電源を入れ直したり、ショットを切り替えたり、複数のデバイスを同時に使ったりすることもあります。
その結果、まったく別の二つのタイムラインを扱うことになります。
運動データのタイムライン
と
動画のタイムライン
この二つをそろえて初めて、運動データが映像の中で意味を持ちます。
動画のあるフレームが、運動記録の 1,427 秒目に対応するとします。その瞬間に表示する心拍数、ペース、位置、標高は、すべてその時刻付近のデータでなければなりません。
数秒ずれているだけで、映像が明らかに不自然に見えることもあります。
速いペースで走っているときや、サイクリング、上り坂、レースでは、特にそうです。
データは連続しているわけではない
もう一つの問題は、FIT ファイルは動画ではないということです。
動画は 30fps や 60fps で、1秒間に何十枚ものフレームがあります。
一方、運動デバイスのデータは、それとはまったく違う頻度で記録されていることがあります。
そのため、単純にこう考えることはできません。
「動画の1フレームが、一つの FIT データに対応する。」
まず FIT の記録を解析し、運動データの時系列にする必要があります。そのうえで、動画の現在時刻に基づいて、その瞬間に表示すべき状態を求めます。
その過程では、現実的な問題がいくつも出てきます。
データが欠けていたらどうするのか。
GPS が一時的にずれたらどうするのか。
速度が急に変わったらどうするのか。
二つのデータ点の間を、どうつなぐのか。
運動を一時停止したあとの時間軸を、どう扱うのか。
こうした細部によって、最終的なオーバーレイが「変化する数字」で終わるのか、本当に動画制作に使える道具になるのかが決まります。
データをビジュアルに変える
時間の同期を解決して、ようやく見る人の目に触れる部分に進みます。
Gauge。
速度計、心拍数、ルート、標高、距離、タイマー……。
どの Gauge も、本質的には同じ運動データを別の形で表現したものです。
ただ、よい運動データのオーバーレイは、数字をそのまま表示すればよいというものではありません。
例えばペースが 4:01/km から 3:59/km に変わるたびに、コンポーネント全体が左右に揺れてしまうと、動画の見心地はとても悪くなります。
ルートマップでは、GPS 座標をどう画面に対応させるかを考える必要があります。
速度計では、数値が変わるときの動きが自然かどうかを考えます。
標高グラフでは、現在の進行位置とルート全体との関係を考えます。
さらに、異なるアスペクト比、解像度、映像のスタイルにも対応できなければなりません。
ここまで来ると、製品はもはや単なる FIT Parser ではありません。
運動データを表現する、一つのまとまったビジュアルシステムになっていきます。
最終的に DaVinci Resolve を選んだ理由
私たちは、このデータを実際の動画制作の流れに組み込みたいと考えました。
先に固定された動画を書き出して、それをクリエイターが自分の素材に重ねる方法ではなく。
クリエイターにとって、もっと自然なのは、次のようなやり方です。
編集しながら、いつデータを表示するか、何を見せるか、どこに置くか、どんな見た目にするかを決める。
それが、Resolve Telemetry Overlay を DaVinci Resolve のワークフローに沿って設計した理由です。
運動データは、編集が終わったあとに付け足すだけのものではないはずです。
映像のデザインそのものの一部であってほしいと思います。
シンプルに見える機能の裏側は、たいていシンプルではない
こうした道具を開発していて、おもしろいと感じるのもこの点です。
使う人の目に映るのは、ただこれだけかもしれません。
心拍数の数字。
一本のルート。
一つの速度計。
でも、その裏側では、こんな過程を経ています。
FIT ファイル → データ解析 → 時系列 → タイムライン同期 → データ処理 → Gauge → 動画のフレーム
どこか一つでも問題があれば、最後の映像にそのまま表れます。
よい道具は、そうした複雑さを表に出さないものであるべきです。
使う人は、FIT ファイルの内部構造を知る必要も、時系列がどう動画に対応するかを理解する必要もありません。
自分の運動記録を選んで、制作を始められればいいのです。
自分たちの必要から始める
Resolve Telemetry Overlay の出発点は、とてもシンプルでした。
私たち自身がスポーツのコンテンツを制作していて、動画の中でもっと自然に運動データを使いたいと思っていました。
既存のワークフローではうまく解決できなかったので、自分たちで道具をつくることにしました。
これは、LIGHTOUCH の多くの製品に共通する出発点でもあります。
まず、実際の問題に出会う。
それを解決する。
そして、その解決策が、同じ問題を抱えるほかの人にも役立つかを考える。
一つの FIT ファイルから、DaVinci Resolve のタイムラインにリアルタイムの心拍数が表示されるまでには、使う人には見えない数多くの工程があります。
そして、それこそがソフトウェアの役割だと、私たちは考えています。
複雑な過程は道具に任せ、使う人にはシンプルな体験を届ける。