FL2VA CONTINUOUS AV · Shotboard Interval

MiniMax H3 does image-to-video, and the interesting way to use it for anything longer than a few seconds is a chain: author a keyframe for the start, author one for the end of a shot, let the model fill the interval, then continue from where you landed. The IAMCCS Shotboard is the authoring side of that, and it holds the interval list on the cine_linx context wire.

This node is the reading glass. It inspects one interval from that plan and hands you the pieces - no sampling, no models, no side effects. When an interval renders wrong, this is how you find out which one the plan thinks it is.

Inputs and outputs

Two required inputs: cine_linx (the context payload) and segment_index (0-based, default 0).

Nine outputs, and they're a complete description of one shot:

• first_frame, last_frame - the authored keyframe images for that interval, loaded from the paths in the plan. Single-frame IMAGE batches.
• prompt - the shot's own prompt.
• width, height - the canvas the plan was compiled at.
• duration_seconds - requested_frame_count / 24. H3 is a 24fps model, so this is honest rather than approximate.
• is_first - 1 for interval 0, 0 otherwise. Use it to pick a different path for the very first clip, which starts natively rather than continuing anything.
• total_segments - how many intervals the plan holds.
• report - a human-readable line: interval N of M, whether it is a native FL2VA start or a continuation from the previous AV latent, requested frames and seconds, and the canvas.

What it enforces

The validation here is the useful part, because it fails loudly on the mistakes that otherwise surface three clips into a render:

• An index outside 0 .. total-1 raises outside 0..N-1.
• Interval 1 must have its opening image. Continuation intervals must have their destination image - every interval needs an authored landing frame.
• Audio mode has to be one the continuous chain understands; a custom AudioBoard drive is a different pipeline entirely.

One detail that confuses people reading the outputs: on continuation intervals (index > 0), first_frame returns the destination frame as a stand-in. That's deliberate. The continuous provider ignores the opening socket on continuations and instead consumes the previous interval's full AV latent as the opening authority. The socket has to return a valid IMAGE batch for wiring purposes; it just isn't the thing driving the render.

What you use it for

Two jobs. The honest one is diagnostics: wire report to a text preview, step segment_index through the chain, and confirm the plan has the intervals and durations you think it does before burning an hour of sampling.

The useful one is branching. is_first, total_segments and duration_seconds let you drive different behaviour on the opening shot versus the continuation shots - a different sampler configuration, a different safety preset, or a switch that only enables something on clip one. first_frame and last_frame on their own let you preview the authored guides, which is the fastest way to catch a shot where you dragged the wrong keyframe into place.

Install

Same as the rest of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Or search IAMCCS in Manager and restart. This node itself pulls nothing in - no models, no optional packs. It only needs to be in a graph whose upstream nodes produced a cine_linx (the pack's SuperNode / Shotboard side). Feed it a bare dict or a different type and it will fail resolving the shot plan, which is the correct behaviour: there is no plan to read.