Remote Video (GeN13)
Remote Video (GeN13) does the boring maths that makes Wan and LTX accept your clip
- image
- IMAGE
- width
- height
- seconds
- seconds_int
- fps
- length
- steps
Every video model has a frame-count rule, and every one of them is written as a formula nobody wants to do in their head. Wan wants 4n+1 frames. LTX wants 8n+1. MiniMax H3 wants 17n+5 at 24 fps. You pick "5 seconds at 16 fps", do the arithmetic wrong by two frames, and the sampler either silently rounds for you, errors at the decode, or - worst - gives you a clip that's subtly the wrong length everywhere downstream.
Remote Video (GeN13) is the node that owns that arithmetic. You tell it the aspect ratio, the megapixels, the seconds and which model family you're running. It gives you width, height, valid frame count, fps, and a resized first frame. One node, no mental math, and because it's a Remote, every clone on the same channel stays in sync - so your Wan graph and your upscale graph can't disagree about how long the clip is.
The fields
Six required widgets and one optional image in:
aspect_ratio-keepfollows your first-frame image (and falls back to 9:16 without one). Any other choice crops from the centre to hit the ratio.megapixels- total pixel budget, default 0.4. Width and height are aligned to 32, which is the number every one of these models is happy with.seconds- clip length, up to one decimal.frame_rule- the model and fps in one dropdown:H3 · 24 fps (17n+5),Wan · 16 fps (4n+1),Wan · 24 fps (4n+1),Wan · 30 fps (4n+1),LTX · 24 fps (8n+1),LTX · 25 fps (8n+1).steps- sampling steps, passed straight through so the sampler doesn't need its own copy.channel- the clone group name.
image (optional) is your first frame: it gets scaled to the chosen megapixels and aspect ratio and comes back out.
The outputs, and where each one goes
Six of them, and they're all load-bearing:
IMAGE- the scaled first frame. Straight into your image-to-video conditioning node.width/height- into the latent/video latent node, or into Resize (GeN13) if you're composing the latent yourself.length- the frame count, rounded up to the next valid value for yourframe_rule. This is the whole point of the node.fps- as FLOAT, ready for Video Combine's frame rate. Match it to your rule or your clip plays at the wrong speed.seconds/seconds_int- FLOAT and rounded INT, for filenames or for whatever node wants a duration rather than a frame count.steps- the same number you typed, out the other side.
The gap you'll notice immediately is that length rounding up means seconds and length / fps don't agree exactly. That's correct behaviour - the sampler needs a legal frame count, and a slightly longer clip is better than a rejected one.
Why "Remote" is the useful half
A Remote node is a clone group: put one in the video-sampling graph and another wherever you need the same numbers, give both the same channel, and editing either updates both - including bypass state, and including clones tucked inside subgraphs. No forty-pixel wire crossing the entire canvas, no top-level Primitive feeding three branches, and no chance of one branch being a frame behind the other because you edited the wrong widget.
The synchronisation is frontend work; the backend node just returns the value it was handed. Practically, that means it survives save/load and API use normally - you're not getting magic, you're getting a shared widget.
Installing
ComfyUI Manager → search GeN13 → install → restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/heigen13/ComfyUI-GeN13
pip install -r ComfyUI-GeN13/requirements.txt
requirements.txt contains exactly one package, nvidia-ml-py, and it's for the pack's monitor strip, not for this node. No model files, no extra dependencies, nothing to download. Portable builds: use python_embeded\python.exe -m pip.
Things people hit
The usual one is forgetting that frame_rule sets the fps and the legality rule together. Choosing "Wan · 16 fps" and then wiring fps into a Video Combine that's set to 24 gives you a clip that plays 1.5× fast - the node told you the truth, you just didn't use it.
Second: megapixels at 0.4 is roughly 832×480 territory, which is a sane Wan starting point. Don't assume 0.4 means "small"; on a 21:9 request it's a very long, thin frame. Read the width and height outputs rather than guessing.
Third: the pack has example workflows in the Templates panel under ComfyUI-GeN13, including a video color match one. Open those before hand-building - the wiring order (Remote Video → latent → sampler → decode → Color Match Temporal) is the whole lesson.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| channel | STRING | video | Channel: Remote Video nodes with the same channel name share every field and bypass. |
| aspect_ratio | COMBO | keep | Aspect ratio: keep follows the first-frame image (9:16 without an image); other ratios crop from the center. |
| megapixels | FLOAT | 0.40.01–16 | Megapixels: ◀ ▶ step by 0.1, or type up to two decimals; width and height align to 32. |
| seconds | FLOAT | 150–3600 | Seconds: video length; ◀ ▶ step by 1 second, or type up to one decimal. |
| frame_rule | COMBO | H3 · 24 fps (17n+5) | Frame rule: model and FPS; the length rounds up to a valid frame count for MiniMax H3, Wan 2.1 / 2.2 or LTX. |
| steps | INT | 81–10000 | Steps: sampling steps; connect to steps of KSampler or MiniMax H3 Dual Clock Sampler. |
| imageopt | IMAGE | First frame: scaled to the set megapixels and output as IMAGE. |
Outputs (8)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | First frame: the scaled image; empty without an image. |
| width | INT | Width: in px. |
| height | INT | Height: in px. |
| seconds | FLOAT | Seconds: as FLOAT. |
| seconds_int | INT | Seconds: as INT, rounded. |
| fps | FLOAT | FPS: the frame rate from frame_rule, as FLOAT; connect to frame_rate of Video Combine. |
| length | INT | Frames: the video length rounded up by frame_rule. |
| steps | INT | Steps: sampling steps. |