--- name: video-extend description: Extend / continue a video temporally with Pusa 2.2 in ComfyUI. Temporal flowmatching (the flowmatch_pusa scheduler + WanVideoAddPusaNoise) on the WanVideoWrapper stack with WAN 2.2 T2V A14B (HIGH/LOW) models and the Pusa V1 LoRAs, conditioning on the loaded clip via WanVideoEncode so the existing motion carries into the continuation. Covers the kijai wanvideo_2_2_14B_Pusa_extension graph, model/LoRA slots + downloads, noise/length/scheduler settings, chaining multiple extensions, VRAM tiers, gotchas, and the extend→upscale handoff. globs: - "**/*.json" - "**/packs/**" --- # Video Extension (Pusa 2.2 — temporal flowmatching) ## Overview Pusa extends a video temporally. It continues and 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, which is what carries the existing motion and 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 `install_custom_node` (`action: "list"`) / > `create_workflow (action:"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: 1. `WanVideoEncode` turns the tail of your loaded clip into a clean latent. 2. That latent is placed at the front of an otherwise-empty embed (`WanVideoEmptyEmbeds` + `WanVideoAddExtraLatent`), so the generation's first latents ARE your real footage. 3. `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." 4. `flowmatch_pusa` on `WanVideoSampler` integrates that mixed-timestep field. Because the conditioning latents are real (not 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` is 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 to 3 and 3 to end). ### How the input clip conditions the extension (the key wire) `WanVideoEncode(vae, image=) → 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, `Reroute`s, 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 to load the real graph, then adapt ~7 widgets: 1. Stage the example anywhere on disk (e.g. copy into the ComfyUI workflows folder). 2. `panel_load_workflow(path: …)` drops it on the canvas server-side (no 150KB JSON through chat). 3. `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 `WanVideoModelLoader`s 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 get_workflow (action:"strip") 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 to 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 means the model loader hard-fails with `ValueError: Can't import SageAttention: No module named 'sageattention'` before any sampling. Fix: set `attention_mode` to `sdpa` on BOTH `WanVideoModelLoader`s (always available; a bit slower). - inductor `torch.compile` needs triton (no official Windows build). Missing means 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 `install_custom_node` (`action: "list"`). ### Preferred end-to-end order Generate (or Krea2→WAN/LTX i2v), then 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 or 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 to 30, `cfg` ~5 to 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 (toward 0) = conditioning latents stay clean = the continuation clings tightly to the source frames (less drift, but can look "stuck" or 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 or 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 and saturation (worse with the distill LoRA and `fp16_fast`). Motion carries fine; the palette pops. Two fixes, best applied together: 1. `base_precision: bf16` on both `WanVideoModelLoader`s 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). 2. 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 or 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 by repeating the extension is in [`references/chaining.md`](references/chaining.md). ## 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). This is 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 `get_workflow (action:"strip")` 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, so 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` kills the process with no traceback. - **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 `/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 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 list 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`). ## Sources - **Official:** none found. - **Empirical:** sampler values, wiring, and prompt notes from working graphs in `packs/` and observed renders; not a vendor prompting guide.