FCPのフレームレート処理 〜伸びる時間、縮む時間
iPhoneカメラアプリのフレームレートについて記載した「マルチカメラ収録の予備機にiPhoneを」で、なぜフレームレート設定の違いで実際の景色を撮影した映像のタイミングが合わなくなるのか、動画映像は実際の時間を再現していないのか?と疑問に思った方はいませんか?
今回は、Final Cut Pro(ファイナルカットプロ 以下FCP)のタイムラインでのフレームレートと時間の再現について試してみます。
INDEX
ゆっくりと進む時間
先に記載したiPhoneカメラのテストでは、24fpsと23.98fpsとを比べました。整数のフレームレートと小数点のついたフレームレートは、タイムコードのページで記載したように映像内で進む時間の速さがわずかに違い、小数点のついたフレームレートの方が0.1%ゆっくりと時間が進みます。
整数のフレームレートである24fpsのときは、映像内で経過する時間と現実の時間の進み方は一致しています。つまり、24fpsで1時間の映像を見たとき、現実の時間も1時間経過しています。
これに対して、23.98fpsの映像を1時間見たとき、現実の時間は1時間3.6秒経過しています。これは23.98fpsのフレームレートでは時間が0.1%ゆっくりと経過する結果、1時間=3600秒の0.1%である3.6秒だけ現実の時間の方が速く進むためです。
タイムライン上での扱い
タイムライン上で、24fpsの動画と23.98fpsの動画に再生時間の違いがあるのかを比べます。それぞれのフレームレートで1,000フレームカウントする動画を作成して比較してみます(96_fig_01、96_fig_02)。
タイムラインとそこに配置したクリップが現実の時間を正確に再現していれば、この2つの動画の継続時間は1フレーム異なり、24fpsの動画の方が1フレーム短くなるはずです。23.98fpsのタイムラインに23.98fps、24fpsの動画を並べたのが96_fig_03です。タイムライン上部のスケールは1メモリが1フレームを表しますが、2つの動画の長さは1フレームも差がありません。
96_fog_04は、24fpsのタイムラインに23.98fps、24fpsの動画を並べたもので、こちらもタイムライン上部のスケールは1メモリが1フレームを表しますが、2つの動画の長さは1フレームも差がありません。
このことから、カラーバースト信号の追加によるフレームレートの誤差はタイムライン上では再現されないことがわかります。つまり、24fpsのタイムラインで23.98fpsの動画は1.001倍早く再生され、24fpsのタイムスケールで再生されます。また、23.98fpsのタイムラインで24fpsの動画は1.001倍ゆっくりと再生され、23.98fpsのタイムスケールで再生されます。この結果、24fpsと23.98fpsの動画をタイムライン上で混在させると、再生時間がフレームレートの0.1%だけズレてしまいます。
この挙動は、30fpsと29.97fpsとを比較しても同様の結果になります。
フレームレートの0.1%分の速度差を補正して再生する仕組みは、現実の時間を忠実に再現してはいないという点で乱暴に思えますが、この速度差を忠実に再現すると24fpsと23.98fps、あるいは30fpsと29.97fpsとが混在したタイムラインで、フレームの間引きかフレームのブレンドを行う必要が生じて動きの滑らかさや画像の先鋭さが損なわれてしまいます。そういった意味で合理的な処理だと思います。
書き出した動画ファイルと0.1%のフレームレート差
タイムラインで24fpsと23.98fpsや30fpsと29.97fpsが速度調整されて同じフレームレートとして扱われていることを考えると、書き出したファイルにフレームレートが正しく再現されているかが気になります。もちろん、これが正しく再現されていないと、24fps、23.98fps、30fps、29.97fpsといったフレームレートを設定する意味がないのですが…。
ここではDFとNDFの扱いも比較するために、30fpsと29.97fpsで比較しました。(FCPでは23.98DFというタイムコード設定がないため、29.97fps設定で比較します。)1時間の黒みを動画ファイルとして書き出して比較してみます。書き出した動画ファイルは、
- 30fpsで1時間の黒み
- 29.97fpsNDFで1時間の黒み
- 29.97fpsDFで1時間の黒み
の3点です。
書き出した動画ファイルをQuickTime Playerで開くと、カウンタに表示される動画の継続時間は
- 30fpsは1:00:00:00
- 29.97fpsNDFは00:59:59:29
- 29.97fpsDFは00:59:59:29
と表示されます。
なお、FCPから動画ファイルを書き出すと、カウンタはタイムコード表記になります。
29.97fpsが1フレーム足りないのは、最初のフレームを0フレームからカウントしているためではと思われ、全て1時間の動画ファイルとして表示されています(96_fig_05)。これは、それぞれの動画ファイルのフレームレート、ドロップフレーム設定を反映した時間で、実際に再生した場合の再生時間を表示してはいないようです。
そこで、書き出した動画ファイルの情報をFinderで見てみます。それぞれの動画ファイルの再生時間は、
- 30fpsの継続時間は1時間00分00秒
- 29.97fpsNDFは1時間00分4秒
- 29.97fpsDFは1時間00分00秒
として認識されています。
29.97fpsNDFのみ4秒長い表示になっています。29.97fpsNDF動画1時間の実際の再生時間は1時間00分3秒18フレームですが、Finderの情報表示は秒までの表記でフレーム表示が省略されているため4秒に繰り上がっているようです。この再生時間の差をみると、Finderではフレームレートの0.1%差による再生時間の違いを正しく認識していることがわかります(96_fig_06)。
DR-701Dの同期
FCPのタイムラインでは24fpsと23.98fpsや30fpsと29.97fpsのフレームレートの0.1%誤差を補正してしまうなら、TASCAMのDR-701Dの60fpsタイムコードはなぜ23.98fpsや29.97fpsのタイムラインで同期が取れるのかという疑問も生じます。整数フレームレートの60fpsタイムコードと考えられるDR-701Dのファイルを小数点の付いたフレームレートのタイムラインに配置した場合、フレームレートの0.1%誤差を補正してしまうと再生速度が変化してしまい、同期は取れないはずです。しかし、実際にはDR-701Dで収録した音声は、小数点のついたフレームレートのビデオファイルと良く同期しています。
これについては、正直なところわかりません。ただし、推測できるのはオーディオクリップについてはフレームという概念が不要なため補正の必要がない、或いはDR-701Dで収録したクリップには「ビデオのフレームレート」が定義されていないために、フレームレートの補正ルールが適用されないのではと考えられます。HDMI信号で同期をとっているという理由も考えましたが、無結線でもそれなりに同期が取れていることを考えると、上記のような理由が有望ではないかと思われます。
まとめ
FCPのタイムラインでは、24fpsと23.98fps、あるいは30fpsと29.97fpsのフレームは同じ長さとして表現されます。結果として、2つの動画ファイルは0.1%異なる速度で再生されます。
書き出した動画ファイルには、0.1%の速度差が再現されています。