IAMCCS H3 VFX Edit · Video Source

H3's VFX edit mode is the reason a lot of people got interested in the model in the first place - feed it footage, describe what you want changed, get footage back with native audio intact. The friction is never the model. It's getting your clip in at the right frame rate, the right length, the right trim, without resampling it three times on the way.

IAMCCS H3 VFX Edit · Video Source is that adapter. It takes a path or a batch of frames plus a trim, and attaches the result to the workflow's bus so the H3 edit branch can consume it.

What it is

One required input beyond the bus, one output. It writes a decoded, trimmed, 24 fps source into the shared cine_linx payload under a VFX source resource; downstream H3 nodes read it from there. You'll see exactly one output in the graph - cine_linx - and that's fine. This is a plumbing node, and the media travels inside the pipe.

Crucially, it only does that when the shotplan's task mode is the VFX edit mode. In any other mode it hands the bus straight back unchanged. So you can leave it sitting in a workflow that switches between generation tasks and it'll be a no-op on the shots that aren't edits, rather than a spurious decode.

Inputs worth setting

• video_path - a path to a source clip. The widget accepts mp4/mov/mkv/webm. Empty is legitimate if you're feeding frames instead.
• start_seconds - where in the source to begin. Default 0.
• duration_seconds - how much to take. Default 0 means "use the plan's duration", which is what you want unless you're deliberately pulling a specific window out of a longer clip.
• source_fps - the frame rate of your file, default 24. This is the one people get wrong.
• source_video / source_audio (optional, lazy) - an IMAGE batch and AUDIO, if your source came from elsewhere in the graph rather than off disk.

How it works

Two routes, and which one you get depends on your settings rather than on wiring.

If you feed a source_video batch, the node computes how much is available from start_seconds to the end, works out a frame count at 24 fps (duration × 24, minimum one frame), maps your source frame indices onto that target using your source_fps, and slices the audio to match. Frames are chosen by index mapping, not naive truncation. Then it reports the source as fps: 24.0 with a descriptor pointing at the upload and its start offset.

If instead it takes the file route, it loads the file, trims to the plan's width and height and duration, and attaches that.

Either way there's a guard: if start_seconds is past the end of the available media, you get "VFX uploaded video trim is empty" instead of a silent zero-frame latent that fails in the sampler six nodes later. Good error, in the right place.

Two more behaviours worth knowing. The node's IS_CHANGED tracks the file's modification time, so editing the clip on disk actually causes a re-read rather than serving a cached decode - a small thing that prevents a genuinely maddening class of bug. And the optional media inputs are lazy: they're only requested when the plan says it isn't already carrying a video and the source policy isn't set to prompter-authored. That's why a workflow with both routes wired doesn't decode both.

Install

This ships in IAMCCS-nodes, so ComfyUI Manager → IAMCCS Nodes → restart → hard-refresh is the fast path. Manual:

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

Restart ComfyUI afterwards; the README also says to refresh the browser once, and if the UI looks stale, hard-refresh.

No pip dependencies for the pack itself - there's no requirements.txt. You need the H3 model set plus, per the pack's own 1.5.8 notes, the matching H3 VFX LoRA: "Character Swap and VFX require their matching H3 LoRAs." That's the dependency people miss, because the node loads fine without it and the generate step just doesn't do what you asked.

Common issues

Wrong-speed motion. Your source_fps doesn't match the file. A 30 fps clip labelled 24 gets resampled and you get either a slight speed ramp or dropped frames depending on the route. Set it honestly.

"VFX uploaded video trim is empty." start_seconds is at or past the duration of the source. Either the time is wrong or source_fps is wrong enough that the computed availability is wrong.

Trim looks right in the graph and wrong in the output. The frame count is computed at 24 fps regardless of source rate, because the H3 edit branch runs at 24. That's by design, not a bug - but it means your duration_seconds request is quantised, and a 3.0-second request on a 23.976 source won't land exactly on 72 frames of source content.

The node appears to do nothing. Check the shotplan task mode. Outside VFX edit mode this node is a deliberate pass-through - it returns the bus untouched.

Graph runs but the edit ignores your clip. Something upstream already populated the edit-video resource, or the source policy is set to prompter. The lazy logic then skips your input on purpose. The pack's own docs flag this as a feature - Prompter media and backend inputs can both supply the source - but it will absolutely read as "my video isn't being used."

Where it fits

Wire its cine_linx output onward to the H3 edit backend and keep the same bus running through to delivery. If you're mixing generated shots and VFX-edit shots in one sequence, this node is what makes a single graph handle both without you maintaining two topologies.