すべてのクリップが1フレーム短く届いていた
40本のクリップにイン点とアウト点をマークして、タイムラインへ送る。編集は 問題なく見える。数週間後、尺を確認していた誰かが、そのすべてがマークした 長さより1フレーム短いと教えてくれる。
1フレームは見た目には何でもないが、納品仕様にとってはすべてだ。そして これは出荷されやすい — 消えていく場所が、誰も二度と読み返さない API の たった一語だからだ。
「アウト」の意味は2通りある
アウト点をマークするとき、意味するものは2通りのどちらかで、どちらも 妥当だ:
- 包含(inclusive) — アウトフレームはクリップに含まれる。 編集アプリが見せてくるのはこちらだ。30fps の素材で 3秒から8秒をマーク すれば、151フレームを期待する — 5秒分に、着地したフレームを足した もの。
- 非包含(exclusive) — アウトフレームはクリップが止まる 位置。同じマークで150フレームになる。
どちらも間違ってはいない。厄介なのは、パイプラインのある部分が一方を 前提にし、次の部分がもう一方を前提にしたときに始まる — 差はちょうど 1フレームで、1フレームは目に見えないからだ。
実際にフレームはどこへ消えるのか
Resolve のスクリプティング API は、クリップをタイムラインへ追加するときに
開始フレームと終了フレームを受け取る。終了フレームは非包含(exclusive)だ
— 得られる尺は endFrame - startFrame になる。
だから、アウト点を包含(inclusive)のまま保持していて — インターフェース がマークした人にそう見せていた通りに — その数値をそのまま API へ渡すと、 すべてのクリップが1フレーム短く届く。最初の1本だけではない。厄介な ケースだけでもない。全部が、黙って、いつまでも。
修正は1行で済む — outPoint + 1 を渡すだけだ。難しい
のは、それが必要だと気付くことのほうだ。
知っておく価値のあるもう1つの境界条件がある。レンジが潰れて終了フレームが 開始フレームと等しくなると、append 呼び出しは false を返し、クリップは 単に届かない。長さゼロのレンジは、送り出す前に1フレームへクランプして おく必要がある。
なぜテストをすり抜けるのか
レンジは、素材アプリから1つだけではない扉を通って出ていき、その扉どうしは
意見が合わない。タイムライン API、EDL、メディアの書き出し、ALE — 自分が
扱ってきたシステムでは、これらは4つの別々の変換であり、すべてが同じ規約に
従っているわけではない。EDL も ALE も、終了点を非包含として扱う。尺を
out - in で計算する書き出しも非包含だ。包含だったのは、その人が
実際にマークしたインターフェースだけだった。
つまり変換の機会が4回あるということで、フレームがずれるには、どこか1箇所が 二重に変換するか、どこか1箇所がまったく変換しないだけで十分だ。これを扱い やすく保つルールは、内部では1つの規約を保持し、それぞれの出口でちょうど 1回だけ変換すること — 途中では絶対にしない。
自分の環境を確かめる方法
これは目視では確かめられない。何かを実際に切って、出てきたものを数える しかない。計算しやすいレンジをマークして — 30fps の素材で 3.0秒から8.0秒 — 送り、タイムライン上の尺を読む。包含なら151フレーム。非包含なら 150フレーム。
数える前に、タイムラインのフレームレートをクリップに合わせて おくこと。 ここで午後を1回丸ごと失った。30fps の素材を 24fps の タイムラインに置くと、151フレームは120フレームになる — 余分な1フレーム は他の何フレームかと一緒に丸め込まれて消え、チェックはいつの間にかチェック でなくなる。イン点は置いた場所のままなので、何もおかしく見えない。
避けたほうがいいことがあと2つある。計算を秒単位でやらないこと — 本来 121フレームであるべき値が 5.041666… として出てくることがあり、フレームへ 戻す変換でそれが120に切り捨てられる。整数フレームのまま扱うこと。そして、 クリップのソース終了フレームを返す API 呼び出しで検証しないこと — 自分が テストした限りでは、その基準点は同じタイムライン上のアイテム間でも一貫して いなかったので、1フレームをめぐる議論には決着をつけられない。代わりに オフセットと尺を読むこと。
Divecut がしていること
Divecut はアウト点を包含として保持する — それがマークした人の意図だから
であり、そして各出口で1回だけ変換する。Resolve への受け渡しでは、それは
endFrame = outPoint + 1 を意味し、潰れたレンジでも届くように
最小1フレームを保証する。
コードを信用するのではなく、上に書いたやり方で実際に確認した — 30fps の 素材で 3.0秒から8.0秒 は、フレームレートを合わせたタイムライン上で 151フレームとして届く。この実測こそが、この記事が存在する理由だ — 食い 違いを見つけたのは、実際に何かを切る前に、2つの経路を並べて読んだときで、 その修正を裏付けたのはこの数字だった。
クリップは Log のまま、手を加えられずに届き、変換は絵に焼き込まれるので はなくタイムライン情報として適用される。それはまた別の記事の話だ。
Divecut は macOS と iPad 向けの素材ブラウザです。Log クリップを撮った ときの色のまま表示し、言葉で探せるようにし、選んだ素材を Log のまま DaVinci Resolve へ渡します — レンジも含めて。 できることをすべて見る。