OpenSoraPlanRun
One node, prompt in, frames out
- model
- IMAGE
If you want to see what this pack does without ceremony, OpenSoraPlanRun is the node. You feed it the model object from OpenSoraPlanLoader, type a prompt, and get an IMAGE out the other side. It's the "sample and decode in one step" convenience node, and it's the fastest way to find out whether a 2024-era open video model is worth your GPU time - which, to be blunt, is the real question with this pack. Open-Sora-Plan was solid for its day, but the current open video scene (Wan, LTX) has moved on. Treat Run as the on-ramp for a historical model, not a daily driver.
How it works
OpenSoraPlanRun is literally OpenSoraPlanSample plus OpenSoraPlanDecode fused into one node. It runs the model's VideoGenPipeline with the frame count baked into the version you set on the Loader (65 or 221 frames at 512×512 by default), then VAE-decodes the latents on the GPU and returns a normalized frame tensor. There's a "Run" and a "Sample" because the pack lets you split sampling from decoding; Run just does both so you don't have to.
The result comes back as a batch of frames, not a video file. That's the thing that trips people up: the IMAGE output is a tensor where every frame is a separate batch entry. You need one more node - VHS's save-video, or similar - to turn that stack into an actual .mp4. Feed it straight to a standard image viewer and you'll just see the first frame of your clip.
The inputs that matter
Six inputs, and only two of them are real knobs:
num_inference_steps- default 50. This is a 50-step model; don't expect the 8-step distillation magic of modern packs. Drop below ~30 and quality falls off a cliff.guidance_scale- default 10. That's a high CFG by today's standards, but it's what this model was tuned around. Too low and you get mush; too high and it burns out.seed- default 1234, works like you'd expect. Change it to get variety.force_images- flip totrueand you get a single 512×512 still instead of a clip. The model is a joint image/video model, so this is a legitimate mode, not a bug.
model is the OpenSoraPlanModel from the Loader, and prompt is your prompt. That's the whole node. The author's code prints num_frames and the version string to the console when you run - a handy way to confirm you're actually getting 221 frames and not silently falling back to an image.
Installing it
Same pack as the Loader - install it once and all four nodes appear. ComfyUI Manager: search "Open-Sora-Plan", install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/chaojie/ComfyUI-Open-Sora-Plan
restart, and make sure the Python side is satisfied (diffusers, timm, einops, accelerate, imageio in your ComfyUI environment). Do not install the repo's docker requirements.txt - it pins torch 2.0.1 and diffusers 0.24 and will wreck a modern ComfyUI.
Model weights download on first run from HuggingFace into a cache_dir folder next to your ComfyUI launch directory - including the ~11 GB T5-XXL text encoder. The first load will look hung. It's downloading; watch the console.
Common issues
- "Video" saved as one still - you grabbed a single frame of the batch, or
force_imagesis still true. Save the whole batch with a video-output node. - Output is tiny or mushy - the default resolution is 512×512; that's the model's native training size, so upscale afterwards rather than cranking it.
- Node red on load - missing Python deps in the ComfyUI environment, not a broken clone.
The two things to actually fiddle with on your first run are num_inference_steps and guidance_scale. Everything else, the defaults are fine until you know why you're changing them.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | OpenSoraPlanModel | — | |
| prompt | STRING | — | |
| num_inference_steps | INT | 50 | — |
| guidance_scale | FLOAT | 10.00 | — |
| seed | INT | 1234 | — |
| force_images | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |