Nodes/Bjornulf_custom_nodes/๐Ÿ“นโžœ๐Ÿ–ผ Video Path to Images (Load video)
ComfyUI Node

๐Ÿ“นโžœ๐Ÿ–ผ Video Path to Images (Load video)

Split a video into frames for ComfyUI

By justUmenยทCreated 2 years agoยทUpdated about a year agoยท 545
๐Ÿ“นโžœ๐Ÿ–ผ Video Path to Images (Load video)
    • IMAGE
    • initial_fps
    • new_fps
    • total_frames
    โ—„video_pathโ€”โ–บ
    โ—„frame_interval1โ–บ
    โ—„max_frames0โ–บ

    You've got a video file and you want to run it through ComfyUI - upscale every frame, throw ControlNet at it, do a vid2vid pass, whatever. ComfyUI thinks in image batches, not videos, so first you have to crack the video open into individual frames. That's this node's entire job: point it at a video on disk and it hands back the frames as an IMAGE batch you can wire anywhere.

    What it does and where it fits

    Most video work in ComfyUI is really image-batch work with a decode step on the front and an encode step on the back. This is the front. It takes a video_path - a string path to an .mp4, .webm, .mkv, whatever your ffmpeg build reads - and pulls the frames out with OpenCV. From there the frames flow into your sampler, an interpolation node, an upscaler, or a preview. When you're done you re-encode with one of the pack's Images-to-Video nodes. It's the mirror image of that node, and the two are meant to bookend a workflow.

    The thing to internalize: this wants a path, not an uploaded video widget. It reads a file that already exists on the machine running ComfyUI. So you usually feed it a path from another node - the pack's own video nodes emit video_path outputs all over the place, and they're designed to chain straight in here.

    The inputs that matter

    Three inputs, and two of them are the interesting ones:

    • video_path - the file to open. A string.
    • frame_interval - take every Nth frame. Leave it at 1 for every frame; set it to 2 to grab half, 3 for a third, and so on. This is your main lever for keeping the batch size sane. A 10-second clip at 30fps is 300 frames, and 300 frames through a diffusion pass is a lot of GPU time. Thinning to every 2nd or 3rd frame is often invisible in the final result and cuts your cost hard.
    • max_frames - a hard ceiling. 0 means no limit (take the whole thing). Set it to, say, 24 while you're dialing in a workflow so you're not waiting on the full clip every test run.

    On the output side you get the IMAGE batch (the frames themselves, which is what you'll wire onward), plus three bookkeeping values: initial_fps (the source video's frame rate), new_fps (the effective rate after frame_interval thins it - halve the frames, halve this), and total_frames (how many you actually got). Pass new_fps into your re-encode node so the output plays back at the right speed instead of running fast or slow - that's the classic mistake when you skip frames and forget to adjust.

    Installing the pack

    Everything ships in one pack. In ComfyUI Manager, open Install Custom Nodes, search Bjornulf_custom_nodes, install, restart. Or from a terminal:

    cd ComfyUI/custom_nodes
    git clone https://github.com/justUmen/Bjornulf_custom_nodes
    pip install -r Bjornulf_custom_nodes/requirements.txt
    

    Restart ComfyUI and it shows up under the Bjornulf category. This node leans on opencv-python and ffmpeg-python, both in requirements.txt, so make sure that install actually completed - on Windows portable you run pip against the embedded interpreter (.\python.exe -m pip install ...), not your system Python.

    Common issues

    The number-one snag is the path. If the node errors or returns nothing, check that video_path points at a real file that the ComfyUI process can reach - a typo, a relative path resolving from the wrong directory, or a file OpenCV's codecs can't decode will all fail here. Feeding the path from another node instead of typing it by hand avoids most of this.

    The second one is speed and memory. Forget frame_interval and max_frames and a long clip will happily expand into hundreds of frames sitting in VRAM/RAM at once. Thin first, test on a capped batch, then run the whole thing. And remember to carry new_fps through to the encode side so playback timing survives the round trip. It's a small, dependable node - the failure modes are all about paths and frame counts, not the node itself.

    CategoryBjornulf

    Inputs (3)

    NameTypeDefaultDescription
    video_pathSTRINGโ€”
    frame_intervalINT11โ€“100โ€”
    max_framesINT00โ€“10000โ€”

    Outputs (4)

    NameTypeDescription
    IMAGEIMAGEโ€”
    initial_fpsFLOATโ€”
    new_fpsFLOATโ€”
    total_framesINTโ€”