AU+IMG2VID Runtime Bridge (legacy alias)

Every planning node in the AU+IMG2VID chain produces a JSON payload - planner, audio timeline, keyframe timeline, refresh policy, continuity. At some point all that JSON has to turn into actual sampling behavior. IAMCCS_AUIMG2VID_RuntimeBridge (legacy alias for Ltx2HelperModules_RuntimeBridge) is the translator: it collects every payload from the planning side, plus your runtime preferences, and emits a single backend_payload that the actual generation backend consumes. Think of it as the adapter between the "what should happen" layer and the "go do it" layer.

Inputs:

• planner_payload and audio_payload (required) - from the Planner and AudioTimeline nodes. These carry the segment plan and the audio slicing decisions.
• continuity_payload, keyframe_payload, refresh_payload (optional) - wire whatever you used.
• runtime_profile - native_canvas (keep frames in memory), disk_low_ram (frames on disk), or image_batch. This is the big fork: it tells the backend how media will be passed around.
• model_binding - external_canvas, ltx_runtime, or custom, i.e. which backend flavor this bridge is targeting.
• prompt_summary - a free-text summary of what's being generated, carried through for logging/reporting.

The single output you care about is backend_payload - one consolidated JSON the sampling backend uses to configure the actual run. The contract/linx outputs and report round it out; the report is worth reading the first time, because it shows you exactly which payloads got merged and which were missing.

The value here is structural. In a hand-wired graph, the "glue" between planning and sampling is implicit - you just connect things and hope. In the IAMCCS SuperNode philosophy, the bridge makes that handoff explicit and testable: you can inspect what the backend is about to do before it does it. It also gives the author a clean seam to swap backends - the model_binding choices (and the runtime_profile fork) are how the same planning chain drives both an in-RAM LTX-2 run and a disk-based low-RAM run without rewiring.

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, no extra deps - it's JSON aggregation.

The catch: a bridge is only as good as the payloads it receives, and the defaults are empty {}. If you drop this node into a graph and never connect the planner, it produces a backend payload with no segment plan - which the backend will either reject or (worse) silently run with defaults. And don't mix runtime_profile: disk_low_ram with a backend that expects in-memory frames; the bridge records the decision but the backend has to honor it. Keep the profile consistent with the rest of your chain and this node mostly disappears into the background - which is exactly what good glue does.