Zura · Prepare Motion Section

Wan 2.2 has an 81-frame native context, so any clip longer than about three and a half seconds gets processed in sections. This node is the section-level front door: tell it where to start and how many frames, and it decodes exactly that slice of the reviewed source and mask.

The reason it exists rather than "just decode the clip" is memory. Holding a 30-second 1080p take as one IMAGE batch plus its mask is a lot of RAM before you've loaded a single model. Decoding 81 frames at a time and letting each section flow through detection, preparation and sampling is the difference between a long shot being possible and ComfyUI getting killed by the OS.

Inputs and outputs

• source - VIDEO, the reviewed source.
• mask_video - VIDEO, the approved mask reel.
• clip_details - GENJ_CLIP, the reviewed-clip descriptor. It carries the total frame count and the reviewed raster, and this node checks both.
• start_frame (default 0, 0–1,000,000) - an absolute frame index on the approved timeline.
• frame_count (default 81, min 1, max 81) - how many frames this section holds.

Outputs: source_frames (IMAGE), approved_mask (MASK), width, height, and window - a ZURA_WAN_WINDOW descriptor that carries the section's identity forward. That last one isn't decoration: the pose-carry node and the section saver both take it, and it's how they know they're working on section 3 of the same shot rather than starting fresh.

What it checks before it decodes

A fair amount, and all of it is about not letting a mismatched section through:

• start_frame and frame_count have to be integers, frame_count between 1 and 81.
• start_frame + frame_count must not exceed the reviewed clip's length. The last section of a clip is usually shorter than 81 frames, and that's fine - overshooting isn't.
• clip_details must be the approved complete 24 fps timeline. The check is blunt: if the recorded duration in frames doesn't equal frames / 24, it refuses.
• Both videos must be 24 fps, both must start at 0, and both must cover the full reviewed length - not just the window, the whole timeline. So a trimmed mask video fails even if the section you asked for exists in both.
• The decoded raster must match clip_details' recorded width and height.

Then it does the same grayscale-average, nearest-resize, 0.5-threshold mask treatment as the full-clip reader, just on 81 frames instead of 900.

The node also declares that it must re-run every queue (IS_CHANGED returns NaN) - which is correct for anything that reads files and slices timelines, and does mean it isn't cached.

Install

Ships with the pack:

cd ComfyUI/custom_nodes && git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
pip install -r ComfyUI_zura_nodes/requirements.txt

Manager install: search Zura Nodes, publisher ZURAVFX, restart. ffmpeg/ffprobe on PATH are required for the decode. In practice you'll be running this inside a Studio-exported bounded graph, where an upstream node supplies start_frame and frame_count as the canonical next range - the guard node in that graph enforces that the section actually is the next one, so don't hand-edit these two widgets in an exported graph and expect it to queue.

Common issues

"Wan preparation windows must contain 1 to 81 frames." Either frame_count is out of range or start_frame went negative. For a 120-frame take, the correct sections are 0–80 and 81–119; people commonly ask for 81–161 and get an error. That's the node being right.

"Wan preparation window exceeds the reviewed clip length." Same cause, other half. Do the arithmetic from clip_details rather than from the file's runtime in seconds - 24 fps means frame 96 is exactly four seconds, and rounding a duration is how you end up one frame over.

"The decoded source raster differs from the reviewed shot details." The clip has been re-encoded, cropped or upscaled since review. Re-review it, or run the section from the exact file the review recorded.

"Wan source and reviewed mask must start at the approved shot beginning." The videos have a non-zero start time in their container - common if they were cut in an editor that kept the original timestamps. Re-mux so both start at zero.

Section looks correct but the join with the next one is rough. That's not this node; that's the carry and continuation stage. If the mask is right at the boundary but the motion isn't, the fix is in the pose-carry node or the sampler's continuation overlap, not here.