Zura · Read Approved Frames and Mask

In Studio you review a mask frame by frame and approve it. That approval is saved as two videos: the source clip and a monochrome mask reel. This node turns those two back into tensors so a hand-built graph is working from what you approved, not from a fresh guess.

It's the entry point to the Wan path in Graph view. Everything downstream - pose, face, preparation, sampling - is conditioning on what this node hands over.

Inputs and outputs

Two inputs, both VIDEO:

• source - the reviewed source clip.
• mask_video - the approved mask reel.

Four outputs:

• source_frames - IMAGE, the decoded source.
• approved_mask - MASK, binarised at > 0.5, resized to the source raster if the mask reel was stored at a different size.
• width, height - plain ints from the source frames, for nodes that want dimensions without measuring the tensor.

The mask handling is worth spelling out, because a mask video is not a mask: each frame arrives as three channels, gets averaged down to one, nearest-resized to the source resolution, and thresholded. "Nearest" and "average" are deliberate choices - you want the binary coverage you approved, not a soft bilinear blend that turns a hard edge into a 3-pixel gradient the sampler will interpret as a hint.

It validates three things and refuses to guess about any of them: both videos must be at 24 fps, the mask must have the same frame count as the source, and the whole thing has to be the approved timeline. Mismatches throw with a specific message rather than cropping to the shorter one.

Why 24 fps is enforced

Because the review stage produces a 24 fps timeline and every downstream Zura node - window decoding, pose carry, the preparation merge, the samplers - re-verifies it. It's the pack's frame of reference. If you re-encode or re-import the reviewed clip at 30 fps, half the pack will refuse it and the other half would quietly give you mask frames that don't correspond to the frames you approved. The strictness is the feature.

Install

Part of the pack, nothing extra:

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

Or Zura Nodes via ComfyUI Manager (publisher ZURAVFX), then restart. You need ffmpeg and ffprobe on PATH - this node decodes video, and the pack's video assembly does too. If you're using it standalone rather than in a Studio-exported graph, you'll still want the pack's mask/media helpers around it; the reviewed videos are normally written by the Studio review flow.

Common issues

"Wan review videos must be prepared at 24 fps." Most common cause is a round trip through a video editor or a re-encode that changed the container's frame rate metadata. Re-render at 24 fps, or run the clip through the pack's own decode path so the timeline is the approved one.

"The approved mask does not cover the selected clip." You have more mask frames than source frames, or fewer. Usually this means you pointed one input at a trimmed clip and the other at the full one. Check both with a GetVideoComponents branch before blaming anything downstream.

Masks come through looking soft-edged or partially grey. You probably fed it a mask video that was already blurred or colour-cast - the threshold is 0.5, so anything under that becomes zero. That's intentional; soft masks belong in a different node, not in a replacement mask the sampler reads as coverage.

Huge memory spike on a long clip. This decodes the entire clip into one IMAGE batch - no windowing. For anything past a few hundred frames, use Zura · Prepare Motion Section instead, which decodes one bounded window at a time (1–81 frames) and is the path the pack's own bounded preparation uses. That's the node the pack's long-shot pipeline is built around precisely because this one holds everything at once.