WK Video Duration
Stop doing the 4n+1 arithmetic in your head
- length
- fps
- actual_seconds
- status
The chore this kills
You want a five-second clip. Your sampler wants a frame count, and that count has to be legal for the model's temporal grid. Wan wants 4n+1. LTX wants 8n+1. MiniMax H3 wants 17n+5. Get it wrong and you either get an error or - worse - a video that comes back a couple of frames short. The reason is in the VAE: Wan's temporal compression is about 4x, so N frames become ((N-1)//4)+1 latents and decode back to (T_lat-1)*4+1 frames, which is why "111 frames in" famously comes out as "109 frames" unless something pads it.
Debugging that by hand is exactly the kind of arithmetic the KB keeps finding as a community tax - the auto-extend nodes that got upvoted were largely praised for removing the "manually calculate the length of the final segment while accounting for the 4n+1 frame count requirement."
WK Video Duration is one node that does that division for you: you say "8 seconds," it hands back a legal length. It's part of ComfyUI WorkspaceKit (ZiYao00, public beta), under 🧩 WorkspaceKit/Utilities.
How it works
You pick a profile and a duration_seconds. The profile owns both the frame grid and the frame rate - you don't get to override FPS, by design, because the profile is the contract. Then:
- Seconds are converted to a candidate frame count with the profile's own strategy.
- The candidate is aligned up to the smallest legal value on that profile's grid.
actual_secondsis recomputed from the real frame count, rounded to one decimal.
The three profiles and what they actually do:
- WAN 2.x Local · 4n+1 - 16 fps, candidate =
floor(seconds × 16 + 1). Ask for 5s and you get 81 frames at an actual 5.1s. Ask for 8s and you get 129. - LTX 2.5 Local · 8n+1 - 24 fps, candidate =
seconds × 24 + 1. 5s gives 121 frames, a clean 5.0s. LTX's grid also demands width and height divisible by 32, so pair this withWK Video Resolutionset to a multiple of 32. - MiniMax H3 Local · 17n+5 - 24 fps, candidate =
round(seconds × 24), floor of 5. 5s gives 124 frames (5.2s); the node calls that rangerecommendedup to 362 frames (15.1s), matching H3's 4–15 second clip window. It hard-fails above 3600 frames.
Outputs are length (INT) into the sampler's length widget, fps (FLOAT) as a read-only fact about the profile, actual_seconds (FLOAT) so you know what you really asked for, and status (STRING) - one of recommended, valid, or valid_outside_recommended. Only the third profile sets a recommended band; the other two always report valid.
Two details worth internalising. status is advice, not enforcement - the node still hands you a number when you're outside the recommended range, because plenty of people run Wan at 129 frames and live with it. And the profile labels are serialization contracts: they're the literal strings ComfyUI stores in saved workflows, so they don't get renamed, and a model that isn't on the list doesn't get a profile until someone adds one. FPS is an output, never an input.
Where the node's job ends and your judgement starts
A legal frame count is not a wise one. The KB is clear that Wan's native context is still 81 frames, that beyond roughly 121 frames "the video starts acting strangely," and that going further means chunked conditioning - SCAIL-2 Infinity, Bernini Infinity, SVI. So 16 seconds on Wan is a legal 257 frames and still a bad idea unless you're chunking. This node makes 81 reliable and stops the 111-in-109-out bug; it doesn't make a 129-frame single pass look good.
Also worth a look: one of these profiles is named Local next to a model whose open weights are licence-locked out of the US, EU, UK and Korea. Check the licence, not just the frame grid.
Install
Manager: search WorkspaceKit or comfyui-workspacekit, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/ZiYao00/ComfyUI-WorkspaceKit.git
cd ComfyUI-WorkspaceKit
python -m pip install -r requirements.txt
Windows portable, run from the ComfyUI root:
.\python_embeded\python.exe -m pip install -r .\ComfyUI\custom_nodes\ComfyUI-WorkspaceKit\requirements.txt
requirements.txt lists one package, send2trash, for the sidebar's trash - no models, no ffmpeg, no torch. And it's a backend-only node with no frontend code of its own, so it behaves identically under the legacy canvas and Nodes 2.0.
Where it bites
- "Resolves to 3609 frames, above the supported maximum of 3600." The H3 profile has a ceiling. Ask for less than 150 seconds or pick another profile.
- Your clip is subtly the wrong length. It's rounding up to the grid; read
actual_secondsinstead of trusting your input. 5s on Wan genuinely means 5.1s. - Your model isn't in the dropdown. The node is a fixed converter, not an auto-detector. Pick the closest grid, or do the math yourself.
- Nothing appears in the node search. It's under
🧩 WorkspaceKit/Utilities- searchWK Video. And remember you're installing the whole workspace sidebar, not just a frame calculator.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| profile | COMBO | MiniMax H3 Local · 17n+5 | 3 options: WAN 2.x Local · 4n+1, LTX 2.5 Local · 8n+1, MiniMax H3 Local · 17n+5 |
| duration_seconds | FLOAT | 5.00.1–86400 | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| length | INT | — |
| fps | FLOAT | — |
| actual_seconds | FLOAT | — |
| status | STRING | — |