IO Context Video (WVW)

The "WVW" is Eclipse's WanVideo wrapper - the pack's pipe for Wan 2.x video workflows. A Wan pipeline doesn't just carry model/clip/vae; it carries a dedicated text encoder, image embeddings, LoRA stacks, torch.compile flags, block-swap args, and VRAM-management settings that no image context knows about. IO Context Video (WVW) is the context node that bundles that whole Wan-specific state into one PIPE and explodes it back out, so a Wan workflow can live on a single tidy wire instead of thirty.

What it is

A context manager built on the same merge-and-explode pattern as the image and video contexts - the source even credits the same rgthree lineage - but its slot list is Wan-flavored from top to bottom:

• Wan-specific model slots: model (WANVIDEOMODEL), clip (WANTEXTENCODER), vae (WANVAE), text_embeds (WANVIDEOTEXTEMBEDS), image_embeds (WANVIDIMAGE_EMBEDS), loras (WANVIDLORA).
• Performance plumbing: torch_compile_args (WANCOMPILEARGS), block_swap_args (BLOCKSWAPARGS), vram_management_args (VRAM_MANAGEMENTARGS). These are the knobs people fight over when Wan video eats their VRAM.
• The full video frame surface: images_input, images_ref_start/new/end, images_1st, images_loop, images_pp1/2/3, images_output, and mask_1/2/3.
• Timing and audio: frame_rate, frame_load_cap, context_length, overlap, skip_first_frames, select_every_nth, loop_idx, and audio.
• The usual core: steps, cfg, sampler/scheduler, denoise, seed, width/height, prompt text, path, purge, plus two free any_1/2 slots.

How it works

Same merge semantics as the rest of the family: start from an input pipe, overlay whatever fields you connect or set, and the output context is the merged dict. Every field also comes out individually, so you can pull just the text_embeds and image_embeds wires into a Wan text-encode stage while the context wire carries everything onward. If your pipeline uses the Eclipse KSampler (Kargim), it can consume the context directly and return an updated pipe - that's the intended loop: build context → sample → get updated context → build the next pass.

The fields a beginner actually sets:

• pipe - start from a loader-provided context or carry one forward.
• model / clip / vae - Wan's model, its text encoder, and VAE (the WanLoader family in Smart Model Loader provides these).
• block_swap_args / vram_management_args - connect these when you're setting up block swapping or VRAM management for long generations.
• images_ref_start / images_ref_end - first/last frame anchors for image-to-video.

What goes in, what comes out

All inputs optional; outputs are context (PIPE) plus one socket per field, typed to the Wan custom types (WANVIDEOMODEL, WANTEXTENCODER, etc.) so ComfyUI keeps type-checking your Wan connections.

Install

Part of ComfyUI_Eclipse. Manager → ComfyUI_Eclipse → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

Under Eclipse → Pipe. Note the Wan model loaders themselves live in the companion pack ComfyUI Smart Model Loader, and the text encoder comes via ComfyUI SmartLLM - the Eclipse pack provides the pipe plumbing, not the loaders.

Troubleshooting

• Wan types not recognized: the custom WAN* types come from the WanVideo ecosystem (Kijai's WanVideoWrapper is the common source). Install the Wan wrapper pack your loaders expect, or the sockets won't type-check.
• VRAM-heavy generation: connect block_swap_args and vram_management_args here and tune them - this node is the clean place to carry those settings through the pipeline.
• Old workflows: v4.0.0 removed legacy IDs; run python tools/migrate_workflow.py <file>.json.