AU+IMG2VID Disk Extension (legacy alias)

Long video eats RAM. Every chunk you decode and hold as IMAGE tensors is real system memory, and past a few hundred frames your 32GB machine starts swapping while ComfyUI chokes. The IAMCCS answer, consistent with the pack's low-RAM philosophy (the README even ships a VAE Decode to Disk node), is to keep the extension frames on disk instead of in memory. IAMCCS_AUIMG2VID_DiskExtension (legacy alias for Ltx2HelperModules_DiskExtension) is the disk-based variant of the extension step: it takes directory paths instead of image tensors and does the overlap/extension bookkeeping at the path level.

Inputs are all directories, with sensible defaults pointing into the pack's convention:

• source_dir - the previous extension's frames on disk (default iamccs_extension_disk/loop_seg0_extended).
• new_dir - the freshly generated segment's VAE frames (iamccs_vae_frames/loop_audio_sync/current).
• start_dir - where the initial start frames live (iamccs_extension_disk/loop_start).
• output_dir - where the combined extension goes (iamccs_extension_disk/loop_extended).

Plus the two payloads (planner_payload, refresh_payload) that keep it in sync with the rest of the chain.

Outputs mirror the in-memory Continuity node but in path form: extended_dir (where the merged frames now live, ready to feed a disk-based video combine), start_dir_out, and the frame bookkeeping (overlap_frames, calculated_frames, extension_frames), plus a disk_payload JSON and the usual contract/linx/report.

Who should use it: if you're on 16GB or less of system RAM and generating long clips, the difference between holding 500 decoded frames as tensors and pointing nodes at directories is the difference between a session that survives and one that OOMs at minute two. It pairs with the pack's other disk-oriented nodes (IAMCCS_VAEDecodeToDisk, the disk-based extension module) which decode one frame at a time rather than building giant IMAGE batches - the KB's LTX-2 and WAN guides are full of "everything longer than ~81 frames is chunking" and "RAM is the binding limit" lore, and this node is aimed squarely at that wall.

The honest cost: it only works if everything in the chain speaks paths, and it's slower than in-memory for short clips (disk I/O per frame adds up). For a 5-second clip, use the in-memory Continuity node. For a 40-second clip on a modest machine, this is the one you'd reach for.

Installing: part of IAMCCS/IAMCCS-nodes - ComfyUI Manager → search "IAMCCS", or cd ComfyUI/custom_nodes && git clone https://github.com/IAMCCS/IAMCCS-nodes.git, restart. No models; the only requirement is that whatever decodes your frames to disk runs first and writes into a directory the node can see (the defaults are relative to ComfyUI's working directory, so keep them consistent across the chain).

The trap: the default paths are just conventions, not contracts. If your decoder writes to a different folder than this node reads, you get an empty extended_dir and a confusing report - check the paths match on your first run, then never think about it again.