Browser Load Video
A VIDEO-typed loader for local clips, with the visual picker on top
- video
Modern video models - LTX, Wan, Hunyuan and friends - don't want a pile of frames handed to them, they want a native VIDEO value. If your workflow starts from a local clip rather than a prompt, you need a loader that emits that type. BrowserLoadVideoStandard is this pack's answer: same thumbnail browser as the image node, but it outputs VIDEO instead of decoded pixels.
It's the thinnest node in the pack, and it knows it. One input, one output, no knobs. Everything interesting happens inside ComfyUI's own video pipeline; this node just finds the file and hands it over.
How it works
Two halves. On the frontend, the same JavaScript extension adds a Browse button and a thumbnail grid for video files, so you pick by eye instead of by filename. On the backend, it scans your input folder with ComfyUI's own folder_paths.filter_files_content_types for video MIME types, falling back to a hardcoded extension list (mp4, avi, mov, mkv, webm, flv, wmv, m4v) when that helper isn't available.
The interesting bit is how it builds the output. It tries InputImpl.VideoFromFile from ComfyUI's comfy_api.latest module - that's what produces a proper, typed VIDEO value that downstream video nodes accept. If that API isn't importable, it falls back to emitting a plain {"video_path": ..., "type": "VIDEO"} dict, a best-effort compatibility shim that may not satisfy every consumer.
Inputs and outputs
video- the only input, an enum of video files inComfyUI/input, with an upload widget like the other loaders.video- the single output, typedVIDEO. It goes into a video model's conditioning or reference/init-video slot, whatever your model expects as its starting clip.
Installing
The pack installs like its siblings. ComfyUI Manager: search ComfyUI_BrowserLoadImage, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/flashcol/ComfyUI_BrowserLoadImage.git
cd ComfyUI_BrowserLoadImage
pip install -r requirements.txt
Restart after. Note the real dependency here isn't OpenCV - it's a current ComfyUI. The VIDEO type and comfy_api.latest are upstream features, not this pack's code, so this node's actual requirement is "don't be six months behind on ComfyUI updates."
Gotchas
- Downstream nodes reject the video? If whatever you're wiring it into complains about the value's shape, you're almost certainly hitting the fallback dict path - update ComfyUI so
InputImpl.VideoFromFileexists. - It won't tell you the frame count or fps. If you need those numbers to know how many frames you're about to generate, this is the wrong node - use the pack's Browser Load Video to Image instead, which emits
frame_countandfpsalongside the frames. - Files live in the input folder, top level, same as everything else in the pack.
If you don't do video generation at all, skip this node and its sibling entirely - the pack's Browser Load Image works fine without opencv and without the video nodes even registering. This one's only worth having the day you're feeding local clips into a video model, which is exactly when you'll want it.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| video | COMBO | 0 options: |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| video | VIDEO | — |