Load Video from URL
Pull a video straight into your workflow from a link
- frames
- frame_count
- video_info
Instead of downloading a video, dropping it in your input folder, and pointing a loader at it, you paste a URL and this node fetches it and hands you the frames. Small convenience, big payoff for two cases: workflows you want to share (the video travels with the link, so a friend's copy runs without missing files), and pipelines where the video comes from an API - like a Runway or Kling node that returns a URL you now need to load back in.
What it does
It downloads the video at the URL, decodes it into a batch of image frames, and gives you those frames plus some metadata. Functionally it's VideoHelperSuite's Load Video, but sourced from the internet rather than disk - and it shares VHS's frame-sampling controls, which is where the real power (and the footguns) live.
The inputs that matter
- url - the direct link to the video file. Has to be a real video URL the server will hand over, not a YouTube watch page.
- frame_load_cap - the most important knob. It's the maximum number of frames to load;
0means all of them. This is your VRAM safety valve. Loading a full 30-second 30fps clip is 900 frames sitting in memory at once, which will OOM most GPUs fast. Cap it. - select_every_nth - takes every Nth frame, thinning the sequence. Set it to 2 and you halve the frame count (and effectively the fps). Great for turning a dense clip into something a vid2vid workflow can actually chew through.
- skip_first_frames - starts N frames in, for trimming an intro or grabbing a later section.
- force_rate - resamples to a target FPS (0 = leave it alone).
- force_size / custom_width / custom_height - resize on load. Pick a preset like
512x512, or chooseCustomand set the width/height fields.
Outputs: frames (the IMAGE batch - the thing you feed a sampler or a preview), frame_count (an INT, handy for wiring into other nodes), and video_info (VHS_VIDEOINFO, carrying fps/dimensions for VHS-aware downstream nodes).
Installing it
Get the pack via ComfyUI Manager (search mixlab, install comfyui-mixlab-nodes, restart) or clone it:
cd ComfyUI/custom_nodes
git clone https://github.com/shadowcz007/comfyui-mixlab-nodes
then install requirements and restart. Frame decoding uses ffmpeg under the hood, so make sure that's installed and on your PATH.
Common snags
- Out of memory / everything crawls. You almost certainly loaded too many frames. Set
frame_load_capto something sane (say 16–48) and useselect_every_nthto thin dense footage. This is the number-one mistake with this node. - It won't load the URL. It needs a direct file link. A page URL, a login-walled asset, or a link that 302s to a player won't work - feed it something that ends in the actual file and returns video bytes.
- Frames look choppy after
force_rate. Resampling FPS drops or duplicates frames; if smoothness matters, leaveforce_rateat 0 and handle timing at the encode step instead. - UI freeze after placing the node. Some users hit a known Mixlab JS conflict where the canvas locks up (no pan/zoom) after adding a video node. It's a pack-wide quirk, not this node misbehaving - disabling the pack is the crude workaround, or use VHS's own loader if you don't specifically need URL loading.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| url | STRING | https://example.com/video.mp4 | — |
| force_rate | INT | 00–60 | — |
| force_size | COMBO | 10 options: Disabled, Custom Height, Custom Width, Custom, 256x?, ?x256, +4 | |
| custom_width | INT | 5120–8192 | — |
| custom_height | INT | 5120–8192 | — |
| frame_load_cap | INT | 00–1000000 | — |
| skip_first_frames | INT | 00–1000000 | — |
| select_every_nth | INT | 11–1000000 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| frames | IMAGE | — |
| frame_count | INT | — |
| video_info | VHS_VIDEOINFO | — |