Video Extend Agent Skill

Video Extension (Pusa 2.2 — temporal flowmatching)

Overview

Pusa extends a video temporally — it continues / lengthens an existing clip

rather than regenerating it from scratch. It does this on the

ComfyUI-WanVideoWrapper stack (kijai) using the WAN 2.2 T2V A14B dual

HIGH/LOW models you already have for wan-t2v-video, plus the small **Pusa V1

LoRAs and a Pusa-specific sampling path: the flowmatch_pusa** scheduler and

the WanVideoAddPusaNoise node. The input clip is encoded with

WanVideoEncode and injected as the *first latents* of the generation — that

is what carries the existing motion/content into the continuation.

The official reference graph is kijai's

wanvideo_2_2_14B_Pusa_extension_example_01.json (in

ComfyUI-WanVideoWrapper/example_workflows/). This skill is built directly from

that workflow plus the live node schemas.

> Relationship to wan-t2v-video: Pusa **rides on the exact same WanVideoWrapper

> stack** — same T2V A14B HIGH/LOW fp8 models, same UMT5 text encoder, same WAN

> VAE, same block-swap/torch-compile machinery. The *only* new downloads are the

> two Pusa V1 LoRAs (~1.9 GB total). Read wan-t2v-video first for the base

> stack; this skill is the temporal-extension delta on top of it.

> ⚠️ Verification note: every node, model, LoRA filename and setting below was

> confirmed against the live ComfyUI /object_info (WanVideoWrapper installed)

> and against kijai's example workflow JSON + HF repo (June 2026). Where a value

> is a starting recommendation rather than a hard requirement it's flagged. Don't

> substitute a node you can't confirm with list_installed_nodes /

> get_node_info.

What "temporal flowmatching" means here (why it extends, not regenerates)

WAN is a flow-matching video model: sampling integrates a velocity field from

noise to a clean latent, and **every frame normally shares the same denoising

timestep**. Pusa's contribution (Vectorized Timestep Adaptation) is to make the

timestep per-frame: the frames you already have can be held at (or near)

*t = 0 (clean)* while the new frames start from *t = 1 (noise)*, and the model

flow-matches the noisy tail conditioned on the clean head.

Concretely in the graph:

• WanVideoEncode turns the tail of your loaded clip into a clean latent.
• That latent is placed at the front of an otherwise-empty embed

(WanVideoEmptyEmbeds + WanVideoAddExtraLatent), so the generation's first

latents *are* your real footage.

• WanVideoAddPusaNoise assigns **small, ramping per-latent noise

multipliers** to those conditioning latents (so they stay mostly clean) and

full noise to the new latents — this per-frame noise schedule is the

"vectorized timestep."

• flowmatch_pusa on WanVideoSampler integrates that mixed-timestep field.

Because the conditioning latents are real (not just a single start image like

I2V), the continuation **inherits the existing motion, subject, camera and

color**, then keeps going. That's the difference from plain T2V (no memory of any

clip) and from I2V (conditions on one still frame only).

⭐ Recommended pipeline (the kijai extension graph)

VHS_LoadVideo (your clip)
      │ IMAGE (all frames)
      ▼
ImageResizeKJv2  ◄── resize to 832×480 (divisible by 16), get W/H
      │
      ├─► GetImageRangeFromBatch (tail N frames) ─► WanVideoEncode (vae, image)
      │                                                   │ LATENT  = clean
      │                                                   ▼   conditioning latents
      │                                          GetLatentSizeAndCount ─► count
      │                                                   │
WanVideoEmptyEmbeds (W,H, total_frames=81)                ▼
      │ WANVIDIMAGE_EMBEDS                       CreateScheduleFloatList
      └────────► WanVideoAddExtraLatent ◄────────┘ (per-latent noise multipliers,
                       │  (encoded clip latent at front)   ramp e.g. 0→0.2)
                       ▼ WANVIDIMAGE_EMBEDS
              WanVideoAddPusaNoise  ◄── noise_multipliers (list), noisy_steps
                       │
        ┌──────────────┴───────────────┐
        ▼ (pass 1, HIGH)               ▼ (pass 2, LOW)
 WanVideoSampler (HIGH model           WanVideoSampler (LOW model
   + Pusa HIGH LoRA + distill,           + Pusa LOW LoRA + distill,
   flowmatch_pusa, steps 6, cfg 1,       flowmatch_pusa, steps 6, cfg 1,
   shift 5, start 0 / end 3)             shift 5, start 3 / end -1)
        └──────────────┬───────────────┘
                       ▼ LATENT
                 WanVideoDecode (WAN VAE)
                       │ IMAGE
                       ▼
                 VHS_VideoCombine  ─► MP4 (16 fps)

• VHS_LoadVideo / VHS_VideoCombine come from ComfyUI-VideoHelperSuite

(installed). VHS_VideoCombine is preferred for the encode (audio passthrough).

• Everything WanVideo* is ComfyUI-WanVideoWrapper (installed).
• ImageResizeKJv2, GetImageRangeFromBatch, GetLatentSizeAndCount,

CreateScheduleFloatList are ComfyUI-KJNodes (installed alongside the

wrapper). They're convenience nodes — see "Minimal wiring" if you want fewer.

The two load-bearing nodes (confirmed schemas)

WanVideoAddPusaNoise — *"Adds latent and timestep noise multipliers when

using flowmatch_pusa."*

| Input | Type | Meaning |

|---|---|---|

| embeds | WANVIDIMAGE_EMBEDS | the embeds carrying your encoded clip latents |

| noise_multipliers | FLOAT (list) | per-input-latent noise; 0 = keep that latent fully clean, higher = let the model change it. In the example this is a ramp [0.0, 0.07, 0.13, 0.17, 0.19, 0.2] fed from CreateScheduleFloatList (one value per conditioning latent), so the oldest conditioning frame stays cleanest and the seam frame gets a touch of noise for smooth blending. |

| noisy_steps | INT (default −1) | how many sampling steps the extra noise is applied for; the example uses 0 on the HIGH pass and 2 on the LOW pass. −1 = all steps. |

It outputs WANVIDIMAGE_EMBEDS straight into WanVideoSampler's image_embeds.

flowmatch_pusa — a value in WanVideoSampler.scheduler (confirmed present

in the dropdown: ...flowmatch_distill, flowmatch_pusa, multitalk...). It **must

be selected** on the sampler(s) for the Pusa noise schedule to be interpreted

correctly. The example also wires explicit WanVideoScheduler nodes set to

flowmatch_pusa, steps 6, shift 5 (one per pass, split 0–3 / 3–end).

How the input clip conditions the extension (the key wire)

WanVideoEncode(vae, image=<tail frames of clip>) → LATENT →

WanVideoAddExtraLatent (or WanVideoEmptyEmbeds.extra_latents, tooltip:

"First latent to use for the Pusa -model"). This places the **real clip's

latents at the head** of the embed window. The sampler then only has to *generate

the tail*, flow-matched onto that clean head — that is the entire trick. No

CLIPVision, no WanFirstLastFrameToVideo.

In practice: load → strip → re-point (DON'T hand-build) ⭐ preferred

The kijai wanvideo_2_2_14B_Pusa_extension_example_01.json is a 56-node graph

thick with GetNode/SetNode buses, Reroutes, and an alternate (dead) text

branch. Hand-wiring the Pusa noise / extra-latent / frame-stitch path is slow and

error-prone. The reliable flow is load the real graph, then adapt ~7 widgets:

• Stage the example anywhere on disk (e.g. copy into the ComfyUI workflows

folder).

• panel_load_workflow(path: …) — drops it on the canvas server-side (no

150KB JSON through chat).

• panel_strip_workflow(path: …) — returns the resolved API graph

(Get/Set/Reroute/bypass collapsed to real links). This is how you SEE what is

actually wired — it exposes both the dead text branch and the silently-reset

dropdowns below. (Raw UI JSON hides them.)

⚠️ TRAP 1 — the example's model paths reset to the WRONG file on load

The example references models by subfolder (WanVideo\2_2\…,

WanVideo\Lightx2v\…, wanvideo\Wan2_1_VAE_bf16…). On a flat local models/

layout those don't resolve, so ComfyUI **silently falls each dropdown back to the

first entry in the list** — e.g. both WanVideoModelLoaders land on

Qwen_Image_Edit-Q8_0.gguf and the WanVideoVAELoader on LTX23_audio_vae_bf16.

It *looks* wired but errors (wrong arch) or renders garbage. After loading, set

each explicitly:

| Node | Set to (local) |

|---|---|

| WanVideoModelLoader HIGH | Wan2_2-T2V-A14B_HIGH_fp8_e4m3fn_scaled_KJ.safetensors — note underscore before HIGH |

| WanVideoModelLoader LOW | Wan2_2-T2V-A14B-LOW_fp8_e4m3fn_scaled_KJ.safetensors — note dash before LOW |

| WanVideoVAELoader | wan_2.1_vae.safetensors |

| WanVideoLoraSelectMulti ×2, slot lora_0 | Pusa HIGH/LOW — these DO resolve if you downloaded to loras/WanVideo/Pusa/ |

| WanVideoLoraSelectMulti ×2, slot lora_1 | lightx2v_T2V_14B_cfg_step_distill_v2_lora_rank128_bf16.safetensors @ 1.0 |

| VHS_LoadVideo | your clip |

| WanVideoTextEncodeCached positive_prompt | your continuation prompt |

> The official HIGH-underscore / LOW-dash filename inconsistency is a real

> trap — verify each one rather than copy-pasting.

⚠️ TRAP 2 — the distill LoRA silently drops to none

The example's lightx2v path is WanVideo\Lightx2v\…rank64_bf16_.safetensors (note

the trailing _). Locally you usually have rank128 (…rank128_bf16), so the

slot resets to none on load — which removes the speed LoRA, and 6-step /

cfg-1 sampling then produces mush. Re-add it to lora_1 (strength 1.0) on both

WanVideoLoraSelectMulti nodes. Keep merge_loras=false on both (fp8 gotcha

above).

⚠️ TRAP 3 — the active prompt is on WanVideoTextEncodeCached, not CLIPTextEncode

The example also contains a CLIPLoader → CLIPTextEncode → WanVideoTextEmbedBridge

branch (the "red panda" prompt). It is NOT wired to the samplers — both

WanVideoSampler.text_embeds come from WanVideoTextEncodeCached

(umt5-xxl-enc-bf16). Edit the prompt THERE; the CLIPTextEncode pair is a decoy

that strip_workflow will show dangling.

⚠️ TRAP 4 — match the conditioning fps to WAN-native (16)

If your source clip was frame-interpolated (e.g. RIFE'd to 32/50 fps), set

VHS_LoadVideo.force_rate = 16 so the conditioning frames carry motion at

WAN's native cadence. Otherwise the encoded "past" runs at 2–3× the model's pace

and you get a velocity jump at the seam — the exact artifact Pusa exists to

avoid. Best practice: extend the pre-interpolation 16fps master, then

interpolate/upscale the *combined* result afterwards, not before.

⚠️ TRAP 5 — the example assumes SageAttention + torch.compile (triton)

WanVideoModelLoader in the example sets attention_mode: sageattn and wires

a WanVideoTorchCompileSettings (inductor) into compile_args. Both are

optional accelerators with extra deps that a stock Windows ComfyUI usually lacks:

• sageattn → needs the sageattention package. Missing → the model loader

hard-fails with `ValueError: Can't import SageAttention: No module named

'sageattention' before any sampling. Fix: set attention_mode → sdpa`

on both WanVideoModelLoaders (always available; a bit slower).

• inductor torch.compile → needs triton (no official Windows build).

Missing → compile errors later. Fix: **disconnect WanVideoTorchCompileSettings

from each model loader's compile_args** (or don't load it). Only re-enable

these two if you've actually installed sageattention / triton-windows.

Check first with the ComfyUI startup log (it prints `Could not load

sageattention… and triton: unavailable) or list_installed_nodes`.

Preferred end-to-end order

**generate (or Krea2→WAN/LTX i2v) → Pusa-extend at 832×480/16fps → THEN

upscale+interpolate** (hand the extended clip to the video-upscale block / a

saved Upscale4x-RIFE-1080p subgraph). Upscaling/interpolating *before* extending

wastes the work and feeds Pusa an off-cadence, harder-to-match conditioning clip.

Models, LoRAs & where to get them

UNET — WAN 2.2 T2V A14B (already installed for wan-t2v-video)

| Model | Loader | Notes |

|---|---|---|

| Wan2_2-T2V-A14B-HIGH_fp8_e4m3fn_scaled_KJ.safetensors | WanVideoModelLoader | HighNoise expert, fp8. Quantization fp8_e4m3fn_scaled. |

| Wan2_2-T2V-A14B-LOW_fp8_e4m3fn_scaled_KJ.safetensors | WanVideoModelLoader | LowNoise expert, fp8. |

Text encoder + VAE: same as wan-t2v-video — UMT5

(umt5_xxl_fp8_e4m3fn_scaled / umt5_xxl_fp16) via the wrapper's text-embed

path, and the WAN VAE (wan_2.1_vae) via WanVideoVAELoader. The example uses

WanVideoTinyVAELoader + taew2_1.safetensors for fast preview decode; use

the full WAN VAE for final-quality decode.

Pusa V1 LoRAs — the ONLY new download (~1.9 GB)

From kijai's HF repo Kijai/WanVideo_comfy, folder Pusa/ → place in

models/loras/ (the example expects them under loras/WanVideo/Pusa/):

| LoRA file | ~Size | Applies to | Strength (example) |

|---|---|---|---|

| Wan22_PusaV1_lora_HIGH_resized_dynamic_avg_rank_98_bf16.safetensors | ~956 MB | HIGH T2V model | 1.5 |

| Wan22_PusaV1_lora_LOW_resized_dynamic_avg_rank_98_bf16.safetensors | ~968 MB | LOW T2V model | 1.4 |

> There is also a single-file Wan21_PusaV1_LoRA_14B_rank512_bf16.safetensors

> (~4.9 GB) in the same folder — that's the Wan 2.1 single-model Pusa LoRA.

> For the 2.2 dual HIGH/LOW extension graph, use the two Wan22_...rank_98

> files above, matched to the correct expert. Upstream weights / paper:

> RaphaelLiu/PusaV1 on HF.

Speed LoRA (paired with Pusa in the example)

The example also stacks the lightx2v T2V distill LoRA on each model via

WanVideoLoraSelectMulti, so 6-step low-CFG sampling works:

| LoRA | Strength | From |

|---|---|---|

| lightx2v_T2V_14B_cfg_step_distill_v2_lora_rank64_bf16_.safetensors | 1.0 | Kijai/WanVideo_comfy/Lightx2v/ |

LoRAs are selected with WanVideoLoraSelectMulti (multi-slot) and fed into

each WanVideoModelLoader's lora input — one select feeds HIGH (Pusa HIGH +

distill), one feeds LOW (Pusa LOW + distill).

⚠️ CRITICAL — merge_loras=false on fp8 models (same gotcha as wan-t2v-video)

Pusa loads LoRAs onto the fp8-quantized T2V A14B models

(quantization=fp8_e4m3fn_scaled). As documented in wan-t2v-video: when a LoRA

is applied to an fp8 model via the wrapper's LoRA select, **set merge_loras to

false**. The default merge_loras=true tries to bake the LoRA into the

already-quantized fp8 weights and **hard-crashes ComfyUI during LoRA loading with

no Python traceback** (looks like an unexplained restart/OOM). false applies

the LoRA as a runtime patch, which is fp8-safe. This applies to both the Pusa

LoRAs and the lightx2v distill LoRA. Use merge_loras=true only on

non-quantized bf16/fp16 models.

Settings

Sampler (from the example — distilled 6-step, two-pass HIGH→LOW)

| Param | HIGH pass | LOW pass | Notes |

|---|---|---|---|

| model | HIGH + Pusa HIGH (1.5) + distill (1.0) | LOW + Pusa LOW (1.4) + distill (1.0) | |

| scheduler | flowmatch_pusa | flowmatch_pusa | required for Pusa |

| steps | 6 | 6 | distilled; raise to ~20–30 for the non-distill path |

| cfg | 1.0 | 1.0 | distilled low-CFG; ~5–6 without distill |

| shift | 5.0 | 5.0 | flow-matching shift |

| start_step / end_step | 0 / 3 | 3 / −1 | HIGH does early steps, LOW finishes |

| noisy_steps (on AddPusaNoise) | 0 | 2 | extra-noise duration per pass |

If you drop the distill LoRA: use steps ~20–30, cfg ~5–6, keep

flowmatch_pusa and shift 5, single-pass unipc-style splitting still works

HIGH→LOW.

Pusa noise (WanVideoAddPusaNoise.noise_multipliers)

This is the dial that controls **how strictly the continuation honors the input

clip vs. how free it is to diverge**:

• Lower multipliers (→ 0) = conditioning latents stay clean = the

continuation clings tightly to the source frames (less drift, but can look

"stuck"/repeat).

• Higher multipliers = more noise on the conditioning latents = the model is

freer to evolve the scene (more new motion, more drift risk).

• The example ramps them [0.0 … 0.2] across the conditioning latents (one

per encoded latent, via CreateScheduleFloatList driven by

GetLatentSizeAndCount) so the oldest frame is locked and the seam frame

gets a little noise for a smooth blend. Start there; nudge the top of the ramp

up (~0.3) if continuations feel frozen, down if they drift.

Seam color/saturation drift → ColorMatch the generated frames ⭐

The most common quality complaint with a Pusa extension: **the moment you cross

the seam, the color saturates / shifts.** The conditioning frames are your real

footage (near-clean latents), but the *generated* tail comes purely from the

model's prior — which biases toward higher contrast/saturation (worse with the

distill LoRA and fp16_fast). Motion carries fine; the palette pops.

Two fixes, best applied together:

• base_precision: bf16 on both WanVideoModelLoaders instead of

fp16_fast. fp16_fast's reduced precision drifts over the generated tail

and compounds the saturation; bf16 is more color-stable (small speed cost).

• Re-grade the generated frames to the source palette with a ColorMatchV2

(KJNodes) between WanVideoDecode and the final stitch/save:

• image_target ← WanVideoDecode (the generated window)
• image_ref ← the resized original clip (ImageResizeKJv2 output — your

real footage)

• method: hm-mkl-hm (histogram→MKL→histogram; strongest at removing a

palette jump while keeping per-frame variation), strength 1.0.

• Re-route the downstream consumers (ImageBatchMulti / ImageConcatMulti's

image_1) to take the ColorMatch output instead of the raw decode.

Tune: if under-corrected, raise strength; if washed/over-corrected, drop to

~0.6; for an even tighter temporal lock use a single clean reference frame

(the last conditioning frame) instead of the whole clip. Use ColorMatchV2

(not the deprecated ColorMatch).

This also matters for chaining — color-match every new segment to the

*previous* one before concat or the drift compounds hop-to-hop.

Length, frame counts & fps

• WanVideoEmptyEmbeds.num_frames is the total window (conditioning frames +

new frames). The example uses 81 total (the WAN-native 4n+1 length, ~5 s

@16 fps).

• The number of new frames added = total − conditioning frames. With ~13

tail frames conditioned and 81 total, you add ~68 new frames (~4 s) per pass.

• num_frames step is 4 in the node; keep total on the WAN 4n+1 grid

(49 / 81 / 121 …). frame_rate for output is 16 fps (WAN 2.2 native).

• Resolution: 832×480 default (divisible by 16). ImageResizeKJv2 with

crop/center and divisor 16 keeps the loaded clip on-grid.

Chaining multiple extensions (making a long video)

Pusa adds a bounded window (~4 s) per run. To go longer, **feed the output back

in**:

• **Confirm the prior clip actually rendered — via the filesystem, not

/history. VHS_VideoCombine writes the .mp4 but frequently does NOT**

register the output in ComfyUI's /history (the prompt shows done with no

output and no error). Do NOT decide the render "silently dropped" from

get_history / queue (action:"status") alone — confirm the file with

list_output_images (it now lists videos, each tagged kind: "video"):

match the filename_prefix and check the mtime is fresh, then stage it.

• Stage the output clip as the next run's input with

stage_output_as_input (pass the rendered clip's

{ filename, subfolder?, type? }); use the returned input filename in

VHS_LoadVideo. **NEVER copy the output .mp4 into, or guess, a filesystem

input/ path** — ComfyUI's input/output dirs may be CUSTOM

(--input-directory / --output-directory), so a guessed path makes

VHS_LoadVideo fail to find/decode the file and wastes the run. The tool

routes through the server API (/view → /upload/image), which resolves the

real dirs correctly. (For a clip already on local disk, upload_video.)

• Run the extension → decode → save (or keep the frames in-graph).
• Take the tail of the *new* output (the last ~13 frames) as the next

WanVideoEncode input.

• Re-run with the same graph; the fresh tail becomes the new conditioning head.
• Repeat. ImageConcatMulti / ImageBatchMulti (KJNodes, used in the example's

preview) stitch the segments into one continuous clip.

Practical chaining tips:

• Always condition on the newest frames, not the original clip, or you'll

"rewind."

• Drift compounds across hops (color/identity slowly wander). Keep

noise_multipliers modest and re-state the subject in the prompt each hop.

• Overlap a few frames between segments and drop duplicates at concat to hide

the seam.

• Keep the same seed discipline (fixed or deliberately varied) so motion

cadence stays consistent.

• Each hop is an independent generation — clear_vram is not needed between

hops, but decode/cache long chains to disk so you don't hold every segment

in VRAM.

VRAM tiers

Same envelope as wan-t2v-video (dual A14B fp8 + UMT5) — Pusa adds only ~1.9 GB

of LoRA. Use the wrapper's offload tooling.

| VRAM | Setup |

|---|---|

| 24 GB+ | Dual fp8 A14B + Pusa LoRAs + distill. WanVideoBlockSwap (offload some blocks) for headroom; WanVideoTorchCompileSettings (inductor) for speed; sageattn. 81 frames @832×480 fits. |

| 12–16 GB | More aggressive WanVideoBlockSwap; enable VAE tiling on WanVideoEncode (enable_vae_tiling=true, 272/144 tiles) and on WanVideoDecode; drop total frames to 49; consider single-pass. |

| 8 GB | Tight — heavy block swap + tiled VAE + 49 frames + tiny VAE preview decode. Expect slow. |

• WanVideoModelLoader quant fp8_e4m3fn_scaled, base precision fp16_fast,

offload_device, sageattn (the example's settings).

• Always clear_vram before switching to this from another model family.
• Encoder VAE tiling (WanVideoEncode) matters here because you're VAE-encoding

real footage in addition to decoding output.

Gotchas

• Loading the example silently resets model/VAE/distill-LoRA dropdowns to the

wrong first entry (subfolder paths don't resolve on a flat layout) — the #1

cause of a Pusa run that errors or generates wrong content. See "In practice:

load → strip → re-point" and re-point ALL of them. Use strip_workflow to spot

it.

• The prompt lives on WanVideoTextEncodeCached, not the CLIPTextEncode

"decoy" branch (which isn't wired to the samplers).

• Interpolated source → seam speed jump — set VHS_LoadVideo.force_rate = 16,

or condition on the pre-interpolation 16 fps master.

• sageattn / torch.compile errors — the example assumes SageAttention +

triton. On a box without them, set attention_mode=sdpa and disconnect

WanVideoTorchCompileSettings from both model loaders (TRAP 5).

• Saturation/color pop after the seam — re-grade the generated frames with a

ColorMatchV2 (hm-mkl-hm) referencing the source clip, and use bf16 not

fp16_fast (see "Seam color/saturation drift").

• Scheduler must be flowmatch_pusa. Leaving it on unipc/euler ignores

the Pusa per-latent noise schedule → the conditioning latents don't behave as

clean anchors and you get a hard cut / regeneration instead of a smooth

continuation.

• merge_loras=false on fp8 (see CRITICAL above) — applies to the Pusa

*and* distill LoRAs; default true silently kills the process.

• Match Pusa LoRA to expert: ...HIGH... → HIGH model, ...LOW... → LOW

model. Crossing them degrades quality. Don't substitute the Wan 2.1

single-file rank512 LoRA into the 2.2 dual graph.

• Frame-count grid: keep num_frames on 4n+1 (49/81/121). Off-grid

totals can error or pad oddly. num_frames UI step is 4.

• Motion drift / "frozen" continuation: tune noise_multipliers. Too low =

stuck/looping; too high = subject/scene wanders. The 0→0.2 ramp is the safe

middle.

• Color/exposure drift across chained hops is the most common long-video

artifact. Mitigate: modest noise, restate the prompt, and optionally

color-match each new segment to the previous before concat.

• Audio: WAN/Pusa generate silent video. The original clip's audio is

*not* extended. Re-attach/curate audio at the end with VHS_VideoCombine

(pass the source audio through) or in an editor — and note the new section

has no native sound.

• ffmpeg required for the final mux (same as the other video skills): if

VHS_VideoCombine errors ffmpeg ... could not be found, run

<comfy-venv>/python -m pip install imageio-ffmpeg and reboot.

• Preview vs final VAE: taew2_1 (TinyVAE) is for fast preview decode; decode

the final with the full WAN VAE for quality.

Minimal wiring (if you want fewer KJNodes)

The KJNodes (GetImageRangeFromBatch, GetLatentSizeAndCount,

CreateScheduleFloatList, ImageResizeKJv2) are conveniences. The irreducible

chain is:

load clip → (resize to 16-grid) → WanVideoEncode(vae, tail frames) → LATENT
WanVideoEmptyEmbeds(W,H,total) [extra_latents = that LATENT]  → embeds
embeds → WanVideoAddPusaNoise(noise_multipliers, noisy_steps) → embeds
WanVideoSampler(model+Pusa LoRA, embeds, scheduler=flowmatch_pusa, shift 5) → LATENT
WanVideoDecode(WAN VAE) → VHS_VideoCombine

You can hand a constant list to noise_multipliers instead of building a ramp;

the ramp just smooths the seam. Two-pass HIGH→LOW is recommended (matches WAN

2.2's MoE) but a single LOW-model pass works for quick tests.

See also

• wan-t2v-video — the base WAN 2.2 T2V stack this builds on (model/encoder/

VAE loading, the merge_loras=false fp8 gotcha in full, block-swap/VRAM).

Read it first.

• video-upscale — the natural next step: extend, then upscale. Generate

/ extend at 832×480, then run the result through the

*downscale → SeedVR2 (temporal restore+upscale) → RIFE → VHS encode* pipeline

for a clean, higher-res, higher-fps final. Do the extension first, upscale

last (upscaling then extending wastes the restorer's work and risks re-drift).

• ltxv2-video — an alternative video family with its own extender variant;

Pusa/WAN is the path when you want to continue an existing WAN-style clip.

Packs

No dedicated video-extend installer pack ships yet. Since Pusa reuses the

installed WanVideoWrapper + KJNodes + VideoHelperSuite stack, a pack only needs to

ensure those custom_nodes[] (kijai/ComfyUI-WanVideoWrapper,

Kijai/ComfyUI-KJNodes, Kosinkadink/ComfyUI-VideoHelperSuite) plus the two Pusa V1

LoRAs in models[] (from Kijai/WanVideo_comfy/Pusa/). The big T2V A14B models

are shared with wan-t2v-video — don't re-download. Install nodes ad-hoc with

panel_install_node or apply a manifest with apply_manifest. Contribute a

finished pack upstream (github.com/artokun/comfyui-mcp).