Schema Video Parameter

Here's the honest version up front: despite the pack README calling this the node for "output animations," this node does not touch video frames. It passes a file path string in one side and a file path string out the other. That's it. Which sounds useless until you remember why the pack exists - an agent needs a clean, documented contract for "where's the input clip" and "where's the output video," and a path is exactly what a machine can hand you.

Think of SchemaVideoParameter as the bookkeeping node for video in an agent-run workflow, and let other nodes do the actual video work. The docstring in the source says it plainly: input mode receives a cloud filename (e.g. from an MCP upload), output mode receives a path from an upstream node - and for real frame conversion "users should wire VHS nodes (LoadVideoPath, VideoCombine)." If you expected this node to replace your video-loading pipeline, adjust expectations now.

The inputs that matter

• io_kind - input declares "the agent provides a video file path"; output declares "the workflow produces a video at this path." Both modes are the same pass-through; the flag just labels the contract.
• name / description - the stable identifier and a machine-readable description ("Input clip for img2video, 8–16 seconds").
• value_in - typed *, and it's mandatory in practice. In input mode it should be a cloud filename from your MCP/tooling; in output mode it's the path from an upstream VideoCombine-style node. Leave it empty and the node raises a "requires a file path" error - there's no default field here.
• accepted_formats - optional metadata declaring allowed extensions (one per line); a hint for your tool, not a runtime filter.
• filename_prefix - present on the node, but note it doesn't actually drive any saving in the current code (the node doesn't write files; upstream nodes do). Set it if your tooling reads it, don't expect it to rename anything.

How it works

Execution resolves value = value_in and returns it as a STRING. No tensor conversion, no file writing, no frame counting. The value output type is STRING - not IMAGE, not VIDEO - which is the tell that this node is a pass-through for a path. (An early version returned batched frames and even had a frame_rate input; the current code deliberately backs that off in favor of "give VHS the frames, give the agent a path.")

So the practical wiring: your agent uploads or names a clip → the path flows through this node as the declared input → you split off to a VHS LoadVideoPath for the actual frame tensor → run your video model → a VHS VideoCombine writes the result → its output path feeds back through this node's output mode as the declared deliverable. The node is the contract; the VHS nodes are the machinery.

Installing it

Same as the whole pack.

cd ComfyUI/custom_nodes
git clone https://github.com/Liquid-XO/ComfyUI_SchemaNodes

Restart ComfyUI, or use ComfyUI Manager (search "ComfyUI SchemaNodes"). No pip dependencies, no model files. If you want the video work to actually happen, you'll also want VHS (VideoHelperSuite), which is a separate install from Manager.

Common gotchas

• The node is not a video loader or saver. This is the #1 misconception. It's a path declaration. Budget your time accordingly: installing this pack gives you the contract, not the codec.
• value_in empty = runtime error. Both modes raise a "requires a file path" ValueError when nothing is wired in. It's a declaration node, not a placeholder that quietly returns empty.
• The README over-promises. "Input clips, output animations" makes it sound like this node renders video. It doesn't. The source code is unambiguous about the pass-through behavior - trust the source over the README here, as with the pack's stale SCHEMA_FIELD output claim.