JimengFirstLastFrame2Video

First-frame/last-frame (FLF) is the loop-maker's move: you tell the model "start here, end here," and it invents a plausible middle. Regular image-to-video only anchors the start, which is why one-shot clips drift into chaos by the last second. JimengFirstLastFrame2Video gives you both anchors on ByteDance's Seedance API - no GPU, no local model, no VRAM budget to worry about. You just need two images and a Volcengine API key with credits on it.

This is the sibling node to the pack's JimengImage2Video, and it works the same way under the hood: both images get base64-encoded into data URLs, and the API call sends them along with explicit first_frame and last_frame roles. The prompt goes in with the same command-line-style flags:

{your prompt} --resolution 720p --dur 5 --camerafixed true

Then the node polls every five seconds for up to five minutes until the video is ready, and hands you the result.

The inputs that matter

• client - from the pack's JimengAPIClient node, where you paste your Ark API key. Every node in this pack needs it wired in.
• first_frame_image - the IMAGE tensor for the opening frame. Non-negotiable.
• last_frame_image - the IMAGE tensor for the ending frame. The source code has a comment calling it "optional," but the schema lists it as required and the API call always sends it. Treat it as mandatory; if you want a free-running clip, use JimengImage2Video instead.
• prompt - what should happen between the two frames.
• duration - 5 or 10 seconds.
• resolution - 480p or 720p only. This is the disappointing part: no 1080p here, unlike the plain image-to-video node.
• camerafixed - true locks the camera down.

Note the model input exists but offers exactly one choice, doubao-seedance-1-0-lite-i2v-250428 - the lite I2V model. No pro variant, no T2V. The author shipped FLF on the budget model, which tells you everything about where it sits in the product hierarchy. It's fine for loops and for matching a cut to a specific ending frame; it is not the flagship path.

It returns two strings: url (the finished video) and task_id. Same as the rest of this pack, the URL is a hosted file, not a video in your graph - wire it into the pack's PreviewVideoFromUrl node to download it and see it in the UI. The example workflow this pack ships shows exactly that pattern:

LoadImage (frame A) → JimengFirstLastFrame2Video → PreviewVideoFromUrl
LoadImage (frame B) →  ↗

Installing it

The README is four lines of Chinese update notes and an invite link - no install docs at all. Standard route: ComfyUI Manager, search ComfyUI-Jimeng, install. Or by hand:

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

The single dependency is volcengine-python-sdk[ark]. No model files, nothing to download into models/. The cost is paid per generation on Volcengine's credit system, and the README's registration link is there to give you a starter allowance.

Where people get burned

The obvious one: people assume the last frame is optional because it "should be," and the API rejects the request or the result ignores it - both frames are required, full stop. Second: the node blocks the queue while it polls, up to five minutes, with no progress indicator. Third, if the job overruns the 300-second timeout you get an empty url back with a dangling task_id, and this pack has no resume node, so recovering means checking the Volcengine console yourself. And if you feed either frame a batch of images, only the first gets used. Two clean single images in, one loop out - that's the happy path.