IAMCCS Cine Shotboard V5 V2V Router

The Shotboard V5 planner hands you a plan - a bundle of timeline data, takes, control tracks, and backend settings riding inside cine_linx. What it does not hand you is media you can sample from. That's this node's job. IAMCCS_CineShotboardV5V2VRouter takes the plan, loads the source footage (or accepts your optional media overrides), and splits everything into three typed buses - media_bus, control_bus, preview_bus - that the backend converters (BusToLTX, BusToScail, BusToWanAnimate, BusToPoseTransfer) actually consume. It's the junction where "what I want to make" becomes "here's the footage and the settings, go."

It's a thin specialization of the pack's CineInfoV2VBackendRouter, with just one input required (cine_linx) and a wall of optional media inputs you only connect when you want to override what the planner loaded from disk:

• source_images / source_audio - override the source clip and its soundtrack.
• result_image - a placeholder/result still; falls back to the source image if unconnected.
• face_video, pose_video, background_video - per-channel media for routes that separate them (WanAnimate-style background lock being the obvious one).
• character_mask - a MASK for character-region control.
• pose_video_mask_image / reference_image_mask_image - mask images for the pose/reference channels.

Read that list as "the router is fully wired if you connect nothing at all." It loads the planner's source media from the paths in the payload and builds sensible fallbacks (face/pose/background default to the loaded source, masks default to white). The optional inputs exist for the case where the planner's file-based media isn't what you want to sample - say you're iterating on a take and want to feed a different source without rebuilding the plan.

The three outputs are where the design shows:

• media_bus - the actual tensors: source video frames, audio, source video info, result image, face/pose/background video, character mask. This is the heavy payload.
• control_bus - the instructions: backend mode/family/profile, generation width/height, the positive/negative prompts, output prefix, and backend settings straight out of the planner's payload.
• preview_bus - preview channels and the result path, for the UI/preview side rather than sampling.

Split that way on purpose: the media bus is big and stays the same while you tune; the control bus is cheap and changes every iteration. It makes the backend converters simple - they take media + control and know exactly which bits to use.

Installation is pack-standard (search IAMCCS in ComfyUI Manager, or clone into custom_nodes, restart), and it inherits the V5 story's real requirements from the backend you chose in the planner: LTX 2.3 AV weights for ltx_v2v, SCAIL for the scail modes, WanAnimate setup for the background-locked route. The router itself ships nothing.

The failure mode to expect: a router that loads media from paths in the payload and errors because the source file path from the planner is stale or was generated on another machine. The report output (STRING) is where it tells you what it loaded or why it fell back. And the recurring mental-model mistake is connecting a character_mask and expecting it to be honored by a backend that doesn't consume it - masks only matter where the converter reads them, so check the backend family in the control_bus before assuming.