Unlimited Length I2V — ComfyUI Workflow
Welcome to the Unlimited Length I2V workflow for ComfyUI, pushing the boundaries of video generation by leveraging the FramePack system to produce videos of virtually unlimited length (i.e. number of frames are no longer limited to 96 for previous implementations of Hunyuai or even Wan).
Just a few weeks ago, this kind of output would have been impossible — now, it's a matter of a few nodes.
⚠️ This is a first working draft. Expect massive improvements soon (see below).
🚀 What It Does
This workflow uses FramePack to perform image-to-video (I2V) generation with long, coherent sequences. By combining the original FramePack I2V architecture with the modular flexibility of ComfyUI and support from native models, this setup opens new creative possibilities for animating images far beyond the usual frame count limitations.
It currently features :
experimental LoRA support!
automatically resize input image to nearest supported format
end frame support
any input resolution accepted (will be rounded to the nearest valid one)
LLM use for image description
teacache use
I also tried to explain each setting with a note directly on the workflow. No need to keep this page open when using it !
🔧 Dependencies
To run this workflow, you need the following:
Nvidia GPU in RTX 30XX, 40XX, 50XX series that supports fp16 and bf16. The GTX 10XX/20XX are not tested.
6GB of VRAM (yes, only ! it can work on your laptop !)
🧩 Required ComfyUI Custom Node
Kijai’s FramePack Wrapper for ComfyUI
➜ https://github.com/kijai/ComfyUI-FramePackWrapper
At the time of writing, it was not available with Comfy UI interface. You can install it through Manager > Install via git URL > https://github.com/kijai/ComfyUI-FramePackWrapper.git
FOR LORA SUPPORT : you need "dev" branch and to my knowledge, it cannot be done with the GUI. You need to open PowerShell (or bash on Linux), go to ComfyUI/custom_nodes and do "git switch dev" + "git pull".
📦 Model & Resource Downloads
1. Native models (text encoders, VAE, sigclip):
2. Transformer (FramePack) model:
🧠 Autodownload (recommended):
From HuggingFace: lllyasviel/FramePackI2V_HY
➜ Place in:ComfyUI/models/diffusers/lllyasviel/FramePackI2V_HY🧠 Manual download (single safetensor files):
Place in:ComfyUI/models/diffusion_models/FramePackI2V_HY_fp8_e4m3fn.safetensors
(Optimized for low-memory GPUs, with FP8 and reduced precision for better compatibility.)FramePackI2V_HY_bf16.safetensors
(Better suited for high-memory GPUs, offering higher fidelity thanks to BF16 precision.)
☕ Optional Feature: Teacache
Teacache is a smart caching system for diffusion models that stores intermediate computation states. This drastically speeds up generation times, especially during iterative tweaking or when generating multiple video segments with similar inputs.
The workflow includes a switch to enable or disable Teacache, depending on your memory availability and whether you're prioritizing speed or full fresh runs.
Teacache boost: Up to 2x speed improvement on repeat runs
Update infos
If you come from the v0.1 or v0.2 of my workflow, you need to update kijai/ComfyUI-FramePackWrapper to dev branch.
Go to ComfyUI/custom_nodes/ComfyUI-FramePackWrapper
on powershell / Bash, type :
git switch dev
git pull
You would of course need git for this.
LoRA support is highly experimental at this point. You can of course only use HunYuan video LoRA, and the effect is quite ... random. The explanation at this point is that all these LoRA were trained on very short videos (due to original limitations), and this impact high frame videos like the one generated with FramePack. I'll try to improve this in the future (not a limitation of the workflow though, but from the original FramePack implementation).
⚡ Benchmark Results
Tested on my "old" RTX 3090:
Resolution: 704x544
Length: 150 frames
Generation time: 11 minutes
Another test :
384x448, 600 frames generated on 15 minutes.
The original project claims that with an RTX 4090 desktop it generates at a speed of 2.5 seconds/frame (unoptimized) or 1.5 seconds/frame (teacache)
🧪 Current Status
This release is an second draft. It is mostly working and "straight to the point".
This is also my VERY FIRST WORKFLOW CONTRIBUTION on Civit.ai ! Please be gentle on your comments.
Next steps are :
Upscaling (coming very soon too)
Other way to improve quality
📎 Original Project Attribution
FramePack is originally developed by lllyasviel. This workflow wraps it in ComfyUI thanks to Kijai work and additional optimizations and user-friendly features.
🧠 Credits
@lllyasviel for the original FramePack architecture
@Kijai for the ComfyUI node wrapper
Comfy-Org for the models and pipeline integration
Everyone in the ComfyUI community for testing and feedback
The default settings were based on my RTX 3090 (24GB of vRAM). If you have less and you have memory usage, first change FramePack model to use fp8 model, then if it's not enough, try lowering VAE batch parameters.
Please, post all videos made with my workflow here, I really want to see what you are doing with it !
Description
Update kijai/ComfyUI-FramePackWrapper to dev branch for LoRA support
add LoRA support
FAQ
Comments (15)
Btw not sure if have seen the feature available in FramePack Studio (https://github.com/colinurbs/FramePack-Studio) which allows you to use Timestamped Prompts.
I've tested this feature a bit and it works decently well. Not sure if this is even something that could be implemented in comfyUI but just thought I would mention it in case you are looking for ideas to expand the workflow.
always doable ... if you develop a custom nodes, that needs python skills. Not my priority though but thanks for the idea :)
wow incredible, there is actually a PR on Kijai node to implement what you just said :) https://github.com/kijai/ComfyUI-FramePackWrapper/pull/8
@Ez4M Nice, thanks for letting me know :D
Any idea why this model is generating hamburgers randomly lol
Has to do with the Positive prompt (FINAL) node. You can either deleted the hamburger text or use action "replace" to overwrite the prompt with your own
Hmm, I've never encountered a 96-frame limit with Hunyuan model. Where does this limit come from? I regularly generate T2V/I2V/V2V outputs with 173 frames (720x480) on a 3090/4090 with 24GB of VRAM without any issues. That's 8 seconds of regular video, or 16 seconds with 2x interpolation (or even 16/32s in ping-pong mode).
How long is it taking for you render this with whatever workflow you are using? I have 24GB and anytime I do a render similar to what you are suggesting.. the workflow pretty much comes to a crawl. Framepack works so much nicer.
@trashkollector175 720 x 480. 101 frames, 30 steps with teacache 1.6x - 9 minutes. 173 frames - about 15 minutes.
@trashkollector175 I'm not saying that framepack is worse or anything, I'm just wondering where the 96 frame limit that the author is talking about came from.
@Gorro17 after 96 frames it is well known that HunYuan starts generating garbage on video, when it works.
With 24GB of vRAM that's pretty much all I can generate, sometimes 120 frames, but after, either it crashed by lack of memory, or the result starts having many artifacts / not realistic movements.
Glad if it works for you :) So let's push FramePack to its boundaries and start generating 1000 frames :)
FramePackLoraSelect紅框 怎麼安裝
This was working for me, before, but for some strange reason now it always crops my videos on the sides. "Target Width" becomes the height of the video. So if i put in 1024, I get a 512x1024 video. If I enter 720, I get a 512x720 video. If I delete the "Target Width" node then i get 512x512. I'd like to set my own resolution.
I figured this out, I just installed a different "Load Image and Resize" node from KJ nodes, and it worked, now I can choose whatever resolution I want.
Many thanks for this. I looked high and low for a Framepack WF that included Lora support and this is the only one I could work with. I had to make a minor change because I couldn't figure out how to set the width/height so I added an Image Resize node. Otherwise it works well. I have a 4080 with 16GB VRAM but with your settings it ran at 83% VRAM usage.