Vroma Editを作ったので、M5 Maxの動画書き出しを測ってみた

字幕や走行情報の合成にかかる時間

まず気になったのは、字幕や速度、標高を重ねる処理です。 これに時間がかかっているなら、エンコーダーを並列に動かしても、渡す映像の準備が追いつかない可能性があります。

同じ冒頭30秒について、表示するものだけを変えて比較しました。 字幕は2個で、合計約15.8秒表示される区間です。 各条件で1秒分を事前に読み出して合成し、測定順を入れ替えながら3回ずつ実行して、中央値を取りました。

「読み出しと合成だけ」は音声や圧縮、保存を含まない別の実行です。 「書き出し全体」には音声の処理と保存も含みます。 合成の初期設定はどちらも測定外で、条件ごとの中央値は約2.8〜9.4ミリ秒でした。

字幕や速度、標高を加えると、読み出しと合成にかかる時間は約50％増えました。 その一方で、書き出し全体はどれも約6.49秒。 表示を取り除いても、全体の時間はほぼ変わりませんでした。

読み出し、合成、圧縮、保存は、処理が重なりながら進みます。 そのため、表の2列の差を、そのまま圧縮と保存にかかった時間にはできません。 今回の結果は、合成の負荷が増えても、後段へ映像を渡す速度にはまだ余裕があると考えると説明できます。 少なくとも、この区間の字幕や走行情報を軽くするだけで、書き出しが大幅に速くなりそうな結果ではありません。

前半と後半を同時に書き出すと？

動画を前半と後半に分けて、同時に書き出す処理も用意しました。 それぞれ独立して圧縮し、最後に再エンコードせず1本のMP4へ結合します。 途中の処理だけ速くても使うときの待ち時間はわからないので、結合して最終ファイルができるまでを測りました。

60秒の結果は3回の中央値で、120秒と全体は各1回の測定です。 全体をプログラムで確認すると、動画の長さは約341.817秒、約5分42秒でした。 動画1クリップに標高表示1個と字幕10個を配置したもので、通常の書き出しは約73秒。 最初の手動計測とも近い結果です。

並列処理によって、全体では約6.2秒短縮できました。 ただ、期待していた「さらに倍速」とはかなり違います。 全体の結合にかかった時間は0.745秒なので、結合のために短縮分を使い切ったわけでもありません。 長い区間は各1回だけの測定なので、繰り返したときのばらつきまではわかっていません。

通常方式と分割方式の出力については、全20,509フレームの時刻と動画の長さ、音声の時刻が連続していることを確認しました。 継ぎ目前後5フレームの縮小画像も数値で比較していますが、全解像度での見た目の確認や、継ぎ目の音声を耳で聴く確認までは含めていません。 この分割処理は検証用で、通常の書き出しにはまだ組み込んでいません。

書き出し中の受け入れ待ちと圧縮方法

並列にしても短縮が約8％にとどまるので、通常の書き出し中にどこで時間を使っているかも調べました。 Vroma Editは、AppleのAVAssetWriterを使って動画を書き出しています。 アプリから映像や音声を渡すと、Writer側で圧縮や書き込みが進みます。

30秒の書き出しを3回測ったところ、アプリの呼び出し側で計測した時間の約96％が、Writerに次のデータを渡せるようになるまでの待機でした。 数字だけ見ると、待ちすぎているようにも見えます。

そこで、受け入れ可否を確認するための待機指定を2ミリ秒から0.2ミリ秒に短縮しましたが、全体の時間は変わりませんでした。 音声を外しても、目標ビットレートを118 Mbpsから30 Mbpsへ下げても、ほぼ同じです。

待っている間にも、渡したデータの処理は裏側で進んでいます。 今回の待機時間を、そのまま削除できる無駄とみなすことはできません。 Writer内部のどの処理に時間がかかっているかまでは分離できませんでしたが、確認間隔を短くするだけでは改善しないことはわかりました。

圧縮処理を直接呼び出すと、また違う結果になりました。 Writerを通す代わりに、VideoToolboxの圧縮セッションへ映像を渡す実験です。 同じ連続した60秒の映像を使い、音声を外して各方式を2回ずつ測りました。 直接使う方式では保存と結合も省き、圧縮済みの全フレームを受け取るまでを測っています。 2セッションの場合は、前半30秒と後半30秒を同時に処理します。

直接呼び出す方式では、2セッションにすると約1.99倍の速さになりました。 一方で、通常のWriter経由は、保存も含めて、その2セッション並列に近い時間で処理できています。 保存を省いて直接圧縮すれば速くなる、という結果にはなりませんでした。

ただし、Writerと直接呼び出す方式で、内部設定や出力品質まで同じと確認した比較ではありません。 解像度、fps、目標ビットレートなどをそろえても、処理時間が近いことだけでは、使っている物理エンコーダーの数は決められません。 この結果から「Writerが自動で2基を使っている」とは判断できないままです。

2基それぞれの使用率は？

使用率も確認しようと、Xcode 27のInstrumentsでMetal System Traceを40秒記録しました。 対象は全プロセスで、その間に通常のWriter経由で120秒の動画を書き出しています。

しかし、今回の環境と記録条件では、2基それぞれの使用率を示す情報を確認できませんでした。 関連するサービスのプロセスは記録されていましたが、そのプロセス数を物理エンコーダーの台数とみなすこともできません。 Instruments全般で観測できないとわかったわけではなく、今回の記録からは確認できなかった、というところまでです。 SiliconScopeの0％表示についても、原因は特定できていません。

「M5 Maxの2基を使い切れているか」という最初の疑問は残りました。 通常の書き出しをさらに倍速にするところまでは届かず、今回の分割処理で短くなったのは約6.2秒です。 通常のアプリへ取り込むには、まだ継ぎ目の試聴や、多様な編集内容での確認も必要になります。

それでも、県道42号の約5分42秒の動画は、通常の方法で約73秒で書き出せています。 ツーリングの映像に標高やスピード、字幕を少し追加する。 そのために作ったVroma Editは、今の書き出し方でも十分速く使えそうです。