4DAnyone Validate Input

The 4DAnyone generator was trained on a very particular kind of input: portrait 9:16 footage of one person, 1080p-ish, at least 121 frames long. Hand it something else and it doesn't refuse - it produces something, warns in the console, and leaves you to notice three hours later that the feet are mush. This node is the cheap check that happens before any of that.

What it does

It probes the video with PyAV - no full decode, so it costs a fraction of a second - and reports what it found against the contract the generator expects.

my_clip.mp4: 1080x1920, 300 frames @ 30 fps
OK.
Also make sure: exactly ONE person, mild camera motion, person stays in place.

The numbers come from the container: width, height, frame count, frame rate. If the file is landscape-stored with a rotation tag (very common with phone footage) the width and height are swapped so you're reading what a viewer would show you, not the encoded orientation. Then it checks four things and prints a WARNING: line for each violation: portrait orientation, aspect ratio within 2% of 9:16, short side at least 720 pixels, and at least 121 frames at the source rate. A shorter clip isn't fatal - the generator works on 121 frames and holds the last frame to fill up - so it warns rather than refuses.

The report is a STRING output. It also goes to the ComfyUI console. If you want it visible in the graph rather than in the log, wire it into a text display node; but honestly, the console is where you'll be watching anyway.

What it can't see

Read the last line of the report again, because it's the honest part: "exactly ONE person, mild camera motion, person stays in place." The node cannot check any of those. Person count and camera motion are not things a container probe can tell you, and both are fatal - two people means the generator has no idea which body it's inventing angles around, and a camera that whips around means the "static viewpoint" assumption underneath the whole 4DAnyone approach is wrong. You have to look at your clip.

Also worth knowing: start_time offsets into the clip but a shorter num_frames doesn't change how much clip it reads. Even at 121 frames you're generating more.

The inputs

No required inputs, which is unusual and pleasant - you can drop it in and queue it. It takes either a video input (from Load Video) or a video_path widget, and the path widget wins when both are set. If you feed it a video that only exists in memory, it says so: "In-memory video; it is checked when generating." Connect a Load Video pointing at a file if you want a real verdict.

Errors here are plain and useful: no input at all gives "Connect a VIDEO input or set video_path," and a widget path that doesn't resolve on disk gives "video does not exist."

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-SplatKit
python_embeded/python.exe -m pip install -r ComfyUI-SplatKit/requirements.txt

Restart, or Manager → "ComfyUI-SplatKit". The probing code uses av, which ComfyUI already ships (0.34 or newer for the video-adjacent nodes), so there's nothing extra to fetch.

Where it fits

Pretty much any 4DAnyone graph should open with it: Load Video → Validate Input, then Generate Views. It costs a second and a half of CPU and it's the difference between "my preset produces mush" and "I fed it a landscape clip from my phone." Tuck it next to the graph's start and check the console before you queue the expensive node.

Two things it won't do, in fairness to it - it can't tell you whether SAM 3D Body will actually find a body in your clip (Generate Views estimates the pose before generating, and a person who is cropped, tiny in frame, or half out of shot is where that goes wrong), and it can't tell you whether the export range you have in mind is sensible. For the second one, the packing list is simple: run 0–20 through Export Frameset and Train Sequence at draft quality first, and only then extend.