You're right that the app-level crash was on us. It was a withoutActuallyEscaping misuse: under concurrency our stall watchdog could cancel a clip while AVFoundation was still holding a heartbeat block we'd handed to AVAssetWriterInput.requestMediaDataWhenReady, so the closure outlived the non-escaping assertion and trapped. Fixed, and the app stopped crashing. What actually stopped us from running concurrent transcodes wasn't an app crash or an error code, though. With that fix in, two concurrent 4K60 HEVC hardware encode sessions reliably kernel-panic the device. The whole phone powers off and reboots partway through the batch. It isn't thermal (the phone was cool) and it isn't jetsam/OOM. The panic is in the video encoder's IOMMU: panic(...): "dart-ave1 (...): DART(CPUDART) error: SID 0 PTE invalid exception on read of DVA 0x10001ff4080 (CTE 0x10 SEG 0 PTE 0x7fd) ..." @AppleT8110DART.cpp:2369 iPhone 16 Pro, iOS 26.5 (23F77). Running the transcodes serially gets through the whole library clean. I've got the full panic .ips, but it seems like I can't attach it here though. Is two concurrent 4K60 hardware HEVC encodes simply more than this encoder will take, or is the panic itself the bug? What I really want to know is whether there's a supported way to keep the decoder and encoder both busy across a batch transcode, or whether serial is the right call at this resolution.