同時録画が止まる、解像度が落ちる、フレームが落ちる理由

発熱：長回しが早く終わる最大の原因

iOS は端末全体の熱状態を段階的に報告します。DualCam はそのうち 2 段階で動きます。「serious」に達したとき、まだ録画しておらず 1080p を選んでいれば、開始前に 720p へ落とします。すでに熱い端末で重いテイクを始めるのが、中断されるいちばんの近道だからです。同じ段階ですでに 1080p で録画中なら、ファイルの途中で解像度を抜き取る代わりに警告だけを出します。

「critical」に達すると録画は停止します。ファイルは確定・保存され、理由の説明が表示されます。これを強制的に上書きする手段はありませんし、あるべきでもありません。その時点でシステムはすでにプロセッサを絞っており、そこで撮れるフレームは残す価値がないからです。

実際に効くこと

• ケースを外す。とくに厚いもの、断熱性の高いものは効果が大きい。いちばん強いレバーです。
• 可能なら、直射日光の下で画面を最大輝度にしたまま撮らない。
• 急速充電の直後や、ケーブルを挿したままで長回しを始めない。
• 長回しは 720p。カメラごとの画素スループットが半分になるのは実質的な負荷低減です。
• 20 分を数テイクに割る。テイクの合間に端末が熱を捨てられます。

空き容量：壊れたファイルを掴む前に止まる

同時録画のファイルサイズ自体は普通ですが、書き込みは連続的で、ディスクが埋まったからといって行儀よく止まってはくれません。そこで DualCam は事前に空き容量を確認します。録画開始には最低 200 MB の空きが必要で、録画中に空きが 100 MB を切ると停止します。この余裕は、書き込み途中で切り捨てられるのではなくファイルをきれいに閉じるためのものです。

アプリの録画ビットレートはおよそ 10 Mbps なので、映像はざっと毎分 75 MB を消費します。空き 1 GB でおよそ 13 分です。長回しの予定があるなら先に容量を空けてください。「もうすぐ満杯」は、撮り直しのきかない素材の 12 分目で気づきたい状態ではありません。

ハードウェアコスト：設定が収まらないとき

マルチカメラセッションにはハードウェアコストがあり、予算内に収まる必要があります。入力になるのは両カメラの解像度とフレームレートです。解像度を上げた結果の構成が予算を超えると、そのセッションは成立しません。遅くなるのでも劣化するのでもなく、単に成立しないのです。

DualCam は「再構成して、測って、戻す」で対処します。解像度を変更したあと新しい構成のコストを確認し、予算超過なら前の解像度を復元して、この端末ではその設定が使えないと伝えます。ある対応 iPhone では 1080p が選べて、より古い端末では静かに拒否されるのはこのためです。端末ごとの制限であって不具合ではありません。

割り込み：システムがカメラを取り上げるとき

iOS はアプリと無関係な理由でキャプチャセッションを中断できます。DualCam は汎用エラーではなく理由を個別に명示し、録画中であればセッションが落ちる前にファイルを確定して保存します。

• アプリがバックグラウンドに入った——バックグラウンドのアプリはカメラを使えません。
• 別のアプリがカメラを取った——典型例はビデオ通話に応答したとき。
• 複数のアプリが前面にある——分割表示や Slide Over の配置にはカメラが渡されません。
• システム負荷——負荷や発熱が一定を超え、カメラそのものが引き上げられた状態です。

実務的にはこうなります。大事なテイクの前におやすみモードにする。録画中にアプリを切り替えない。

ここで言う「フレーム落ち」の意味

両カメラは毎秒 30 フレームに固定され、遅れて届いた映像フレームはキューに積まれず破棄されます。ライブ撮影ではこれが正しい選択です。合成に間に合わないほど遅れて届いたフレームは、無いより悪い——キューに積めばパイプライン全体がさらに遅れるからです。つまり高負荷時のカクつきは、システムがタイムラインを守っている姿であって、アプリが素材を失っているのではありません。見えたときの対処は発熱と同じです。解像度を下げ、端末を冷まし、テイクを短くする。