OpenSoraPlanDecode

OpenSoraPlanDecode is the VAE half of this pack. It takes the LATENT from OpenSoraPlanSample, runs it through the CausalVAE, and hands you an IMAGE - actual pixels you can look at, save, or wire into a video-output node. It's the node you add when you've chosen the two-step path (Loader → Sample → Decode) instead of letting OpenSoraPlanRun do the decode for you. If that distinction sounds marginal, it is: the whole reason this node exists is so the pack can offer both a fused path and a split path. You're here because you wanted the split, or because you're curious about the machinery.

How it works

Given the model object from the Loader and a LATENT from Sample, Decode pulls the latent tensor out, moves the VAE to the GPU, and decodes it in one shot. Then it normalizes the result to the 0–255 range, reorders the tensor so frames are the batch dimension, and returns it as an IMAGE. (Fun, harmless quirk: the author normalizes by 250 rather than 255 in this node, so values run a hair hot - nothing you'll ever notice in practice.) The VAE goes back to the CPU afterwards to free VRAM for the next step.

The output is a stack of frames in batch order - frame 0, frame 1, frame 2 … - not a video file. To get an actual .mp4 you need a node that saves a batch as video (VHS's save-video works, as do the usual suspects). A beginner who connects this straight to a preview and sees one frame might think the model generated a still. It didn't; the rest of your clip is sitting in the batch.

The inputs that matter

There are only two, and this is the friendliest node in the pack because of it:

• model - the OpenSoraPlanModel from OpenSoraPlanLoader. Same object the sample node used.
• samples - the LATENT out of OpenSoraPlanSample. This must be the pack's own video latent; anything else won't decode.

One output: image, an IMAGE tensor of frames. That's the whole node. If you're on the split path, this is your finishing line.

A note on finding it: this node lives under the PixArt category in the node menu, not "OpenSoraPlan." It's a leftover from the model's lineage - Open-Sora-Plan's transformer is built on the PixArt-α architecture, and the author kept the old category label. If you search the pack and can't find Decode, search "PixArt" instead.

Installing it

Same pack, same drill, whichever node you install it through. ComfyUI Manager: search "Open-Sora-Plan", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/chaojie/ComfyUI-Open-Sora-Plan

restart, and confirm the Python deps (diffusers, timm, einops, accelerate, imageio) are present in the ComfyUI environment - a red node right after install is almost always a missing import. Avoid the repo's docker requirements.txt: it pins torch 2.0.1 and diffusers 0.24, which will break a modern ComfyUI.

The first run downloads the weights from HuggingFace into a cache_dir folder next to your ComfyUI launch directory - the transformer and CausalVAE from LanguageBind/Open-Sora-Plan-v1.0.0 plus the ~11 GB T5-XXL text encoder. That first load is slow on purpose. Give it a minute; the console tells the truth.

Common issues

• Garbage or a shape error out of nowhere - the samples input was fed a standard ComfyUI latent (from VAEEncode or a KSampler). Those aren't compatible; the latent must come from OpenSoraPlanSample.
• Looks like one frame, not a video - the frames are stacked in the batch. Save the whole batch with a video-output node.
• Node red on load - missing Python dependency, not a broken install.

If you find yourself adding Decode to every workflow, stop and just use OpenSoraPlanRun - it's this node and Sample fused, and it'll save you a wire.