NormalizeVideoLatentStart
Fix that flash at the start of your videos with NormalizeVideoLatentStart
- latent
- latent
If your image-to-video clips come out with a first few frames that look subtly off - too bright, too dark, slightly washed, a little jumpy before the motion settles - this is the node you didn't know you needed. NormalizeVideoLatentStart fixes the most common cause: your encoded start frames live in a different statistical range than the noise the model generates the rest of the video in, and that seam shows.
It's a one-trick pony, and the trick is clean. You give it a latent, and it takes the first start_frame_count latent frames (default 4) and re-normalizes their mean and standard deviation to match the next reference_frame_count frames (default 5). That's it - a mean/std match, done adaptively in latent space, with the rest of the latent passed through untouched. The node lives in comfy_extras/nodes_kandinsky5.py and was built alongside the Kandinsky 5 video support, but it's model-agnostic: any video latent that shows a start-frame/rest-of-video mismatch can go through it.
Why does the mismatch happen in the first place? When you anchor an I2V generation, the start frames are VAE-encoded pixels - real, specific image data. The rest of the latent is diffusion noise being gradually shaped. Those live on different scales, and depending on the model's VAE and the sampler, the encoded start can read as a bright or dark blob for the first few frames until the noise converges with it. This node just forces the start frames into the same statistical shape as the reference frames so the model doesn't have to fight the transition.
The inputs are exactly what they sound like: latent, start_frame_count (how many frames to fix), and reference_frame_count (how many frames after that to treat as the "correct" reference). The defaults of 4 and 5 work for most I2V setups; you rarely need to touch them. If the artifact spans more frames, bump start_frame_count up a notch - just don't overshoot into actual content frames or you'll flatten real motion.
Output: a single latent, same shape, ready to drop back into the sampler chain.
It's core, ships with ComfyUI, no install. The natural place in a workflow is between your I2V conditioning node (whatever builds the anchored latent) and the KSampler. A decent number of recent I2V template workflows - especially Kandinsky 5 ones - include it as a standard step, which is a hint that you should try it before blaming the model for "that weird first-frame look." The only real gotcha is applying it to a single-frame latent (it short-circuits if there's only one frame) or a latent that's already clean - in which case it's a no-op or a mild change, not a disaster.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — | |
| start_frame_count | INT | 41–16384 | Number of latent frames to normalize, counted from the start |
| reference_frame_count | INT | 51–16384 | Number of latent frames after the start frames to use as reference |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |