Modelscope v2v

Same idea as SD img2img, except the "img" is a whole batch of video frames at once: feed in an existing clip, give it a prompt and a strength dial, and it pushes the frames through Zeroscope XL to reinterpret them. This is the video-to-video sibling of this pack's Modelscopet2v, and it's built by the same author who actually made Zeroscope - cerspense is Spencer Sterling, the model's creator, so this node is him wiring his own work directly into ComfyUI via diffusers rather than a third party wrapping it.

The honest take

Same call as the t2v node: Zeroscope was a genuine milestone in mid-2023, one of the first open text/video-to-video setups people could actually run, and it had its loud moment on r/StableDiffusion that summer. It's 2023-era tech now, and current-generation video models comfortably beat it on quality and coherence. zeroscope_v2_XL - the checkpoint this node defaults to - is also the heavier of the two Zeroscope models, and it's the one the community specifically flagged for using more VRAM than its own documentation suggested, with reports of 24GB cards hitting out-of-memory errors on it. If you've got this pack installed for its other utility nodes and want to mess around with the retro-video look, sure. For real video-to-video work today, Wan or LTX's v2v paths are the better use of your GPU time.

How it works

It takes video_frames as an IMAGE batch - meaning you need frames already decoded, whether from this pack's Modelscopet2v, a video loader fed a path from VidDirIterator (same pack), or anywhere else - loads a diffusers pipeline from model_path, swaps in the same DPMSolverMultistepScheduler as the t2v node, and enables CPU offload automatically. On top of that, it exposes two extra memory-saving toggles the t2v node doesn't have: enable_forward_chunking, which chunks the UNet's forward pass to trade some speed for lower memory use, and enable_vae_slicing, which decodes the VAE output in slices instead of all at once.

The inputs and outputs that matter

• video_frames - the source clip, already decoded to an IMAGE batch.
• prompt / negative_prompt - what you want the reinterpretation to look like.
• model_path - defaults to cerspense/zeroscope_v2_XL, the larger of the two Zeroscope checkpoints.
• strength (default 0.70) - how much of the source survives. Lower keeps more of the original motion and structure; push it toward 1.0 and the prompt increasingly takes over, to the point the output can look almost unrelated to your source frames' motion - that's expected behavior at high strength, not a bug.
• enable_forward_chunking (default off) / enable_vae_slicing (default on) - the two VRAM knobs. VAE slicing is already helping you by default; forward chunking is the next lever to pull if you're still running out of memory.

Output: a single IMAGE batch - the transformed frames.

Installing it

Search cspnodes in ComfyUI Manager, or clone it directly:

cd ComfyUI/custom_nodes
git clone https://github.com/cerspense/ComfyUI_cspnodes

Restart after. diffusers is a hard, actually-used dependency for this node specifically, not just a pack-wide import - you need it working to run a generation, not only to see the node in your list. Expect a first-run download of several gigabytes for the XL checkpoint the first time you point model_path at it, bigger than the t2v node's default 576w model.

Where people get tripped up

VRAM is the recurring complaint with this specific checkpoint, as noted above - if you're OOMing, enable_vae_slicing is already on by default, so the next thing to try is turning on enable_forward_chunking, or reducing the resolution/frame count of your source clip before it reaches this node. And remember that video_frames has to already be decoded frames, not a file path - if you're pulling from VidDirIterator, you need a video-loading node in between the two, since that node returns a path string, not image data.