Zura · Clip duration (24 fps)

This one looks like a joke node - one widget, two outputs - and then you build a camera workflow and realise it's the thing holding the whole take together.

The problem it solves is real. Video models want a frame count. Compositors, mask videos, planners and preview pickers want a duration you'd say out loud ("four seconds"). Somewhere between those two languages, people type 4 into three different widgets, get 96 in one place and 4.0 in another, and end up with a take whose audio doesn't line up with its last frame. This node does the one conversion, in one place, and snaps it.

What it actually does

There's a single input, seconds, a float with a default of 4.0, a minimum of 0.5 and a maximum of 5.0, stepped in tenths. The tooltip is the author's own and it's honest: "Use the first 0.5–5 seconds of the source. Rounded to whole frames at 24 fps."

Two outputs come out:

• seconds - the same duration you asked for, but snapped to a whole number of frames. Ask for 3.97 and you get 3.95833…, because 95 frames divided by 24 is an exact thing and 3.97 isn't.
• frames - the integer frame count itself (95, in that example).

That's the whole node. The reason it exists is that 24 fps is not a suggestion in this pipeline - the pack's own review and preparation stages refuse clips that aren't on an approved 24 fps timeline, and the Wan and H3 example graphs are built frame-exact around it. Give them a sloppy duration and the mismatch shows up later as a mask that doesn't cover the last few frames or a sync that drifts.

The upper bound is not arbitrary either. Five seconds is where H3 and LTX 2.5 regular shots top out in this pack, so 5.0 is a hard ceiling on the widget rather than a warning you can ignore.

Where it goes in the graph

Wire frames into whatever wants a count - the camera picker in the simple single-camera H3 workflow links the decoded frame count to the picker so one chosen angle covers the whole take, and this is the node that sets that count. Wire seconds into anything that wants a trim duration, including the load stage that cuts "the first N seconds" out of your source.

The practical trick: pick your duration once, fan it out. If you've ever had a graph where the mask video was 96 frames and the source was 97, you know exactly why.

Install

It ships in the Zura Nodes pack, so there's nothing extra to download for this node specifically.

1. In ComfyUI Manager, search for Zura Nodes and install the entry published by ZURAVFX. Restart ComfyUI.
2. Or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
# then, in the same Python environment that runs ComfyUI:
pip install -r ComfyUI_zura_nodes/requirements.txt

Manager pulls in requests, yt-dlp[default], ultralytics, face-alignment==1.4.1, soundfile, av, aiohttp and Pillow. Put ffmpeg and ffprobe on your PATH while you're at it - the pack uses them to decode and assemble video, and you'll hit that wall on some other Zura node within about ten minutes.

Common issues

"Why did my duration change?" Because it did, on purpose. The seconds output is the frame-snapped value, not an echo of your input. If you need the literal number you typed, keep your own primitive; if you need the number the renderer will actually use, use this one.

It errors on 0.4 or 6. Both bounds are enforced with a proper error, not a silent clamp, which is the right call - you want to know your take is out of range before you queue twenty minutes of sampling.

Node not found after updating the pack? Refresh the browser tab. ComfyUI caches the node registry per tab, and new classes don't appear until you do.