CPA LoadVideo

The name is the trap. CPA LoadVideo - class ComfyProAlpha_LoadVideo - takes an IMAGE batch in and puts a VIDEO out. It reads nothing from disk. It exists because SAM 3's streaming tracker in ComfyUI-SAM3 wants a VIDEO object, while the rest of the pipeline wants the actual frames, and somebody had to bridge those two facts without handing SAM 3 a tensor batch it can't seek through.

You won't find it in the node menu. Like everything in the /internal category, it's flagged deprecated so it stays out of search, and it only appears once the Comfy Pro Alpha Generator node expands its graph on Queue. Which means people meet it in one of two ways: they hit a compatibility error mentioning it, or they see it in an expanded graph and wonder what the encode step is costing them.

What it actually does

images is the plate batch, fps is the rate to record at. The node fingerprints the batch - tensor shape plus a strided sample of pixels, hashed - and uses that hash plus the fps as the filename for a cached H.264 proxy in ComfyUI/temp/comfy_pro_alpha_seq/. If that file already exists, it returns it immediately. If not, it encodes the whole batch with PyAV: libx264 at CRF 12, yuv420p, at the fps you passed.

Two details worth knowing, because both are deliberate:

Odd frame sizes get padded, not resized. yuv420p needs even dimensions, so the encode pads by edge-replicating one row or column. The mask that comes back out is then cropped back to the real size by CPA TrackMasks on the way in, so the pad never reaches your alpha.

No system ffmpeg is needed. PyAV bundles its own FFmpeg, which is why av is in the pack's requirements.txt and why the pack still works on machines with no ffmpeg on PATH. That's the dependency people skip when they install by hand and then wonder why the node shows red.

The point of all of it: SAM 3 only has to find who and follow them. Every edge decision downstream runs on the original float frames, not on this compressed proxy. So CRF 12 is generous on purpose - it's a tracking reference, not a delivery codec - and you should resist the urge to "speed it up" by lowering quality, because a mushy proxy is a dropped track.

Why the cache is the whole design

Encoding a 250-frame 1080p batch is a slow, memory-hungry operation that has nothing to do with the interesting part of the job. Because the proxy lives in temp/ under a content hash, a re-queue of the same plate is a file stat. Change the plate and you pay for it again. There's a related caching fact in the generator's picker: it warns you in the console when the plate fingerprint has changed since you picked, because your clicks were made against the old frames.

The flip side: clearing ComfyUI's temp directory clears this. That's fine - it just re-encodes - but it means "my render got slower for no reason" is sometimes literally true.

Wiring it by hand

You probably shouldn't, but if you're building a graph that pokes SAM 3's video nodes directly it's two wires:

Get Video Components  ──images──► CPA LoadVideo ──video──► SAM3VideoSegmentation
                      ──fps─────►                (fps)

Both inputs are required and there are no optional ones to trip over. Output is video, a VIDEO that SAM 3's segmentation and propagation nodes accept.

Gotchas

If you're on an older ComfyUI, the VIDEO type and InputImpl.VideoFromFile may not exist and this node is where the import failure surfaces - the pack needs ComfyUI 0.38 or newer, and the "IMPORT FAILED" entry after a half-finished update is usually the pack and the core being out of step. Update core, restart, then update the pack.

And the usual one for anything in this pack: reload the browser tab after installing or updating. The node panel is a web script, and the browser holds the old one until you do - you'll get a node that renders but shows stale UI, or a picker that doesn't respond.