FLUX Video Edit [fast]

FLUX Video Edit [fast] is Black Forest Labs' instruction-based video editing model for changing an existing clip with a natural-language prompt. It can add, remove, or replace objects and characters; alter settings, styles, actions, and on-screen text; and revise or translate dialogue while preserving unedited motion, camera work, timing, framing, and audio. It supports source clips up to 15 seconds and produces 24 FPS output at up to 720p while retaining the original duration and aspect ratio.
![FLUX Video Edit [fast]](https://assets.runware.ai/covers/bfl-flux-video-edit-fast.jpg)
Complete technical specification for integration
Ready-to-use code snippets for common workflows
Step-by-step tutorials for advanced use cases
← All GuidesPreparing source video
How to prepare source clips for FLUX Video Edit [fast]: the 15-second, 50 MiB and 720p envelope, what the output inherits, and how to work with footage that does not fit.
Introduction
The clip you send decides more about the result than the prompt does. There is no width, no height, no duration and no resolution on this model, so whatever the source is, the output is, with two exceptions this guide covers.
That makes the input envelope a design constraint rather than a footnote. A clip that is a second too long does not get trimmed to fit, it gets refused.
The edit landed and the frame came back smaller. This guide covers the whole envelope, what changes on the way out, and the workflows for footage that does not fit.
The envelope
Every limit applies to inputs.video, and all of them are hard.
| Property | Limit |
|---|---|
| Duration | 0.7 to 15 seconds |
| File size | 50 MiB |
| Minimum width | 160 pixels |
| Minimum height | 160 pixels |
The lower duration bound is 17 frames, which is where 0.7 seconds comes from at 24 fps. In practice a clip that short is below the useful floor for an edit rather than at it.
A source over 15 seconds is rejected, not truncated. There is no automatic trim and no "first fifteen seconds" behavior, so a 16-second clip fails the request outright. The same is true of the file-size limit: an oversized file is refused rather than re-encoded on your behalf.
What comes back
The output inherits the source in every respect except two:
- Duration is the source's, exactly.
- Aspect ratio is the source's, exactly.
- Audio is the source's, carried through untouched unless the prompt asked for a sound or dialogue change. A silent source returns a silent result.
- Resolution is the source's, unless the source is above 720p, in which case it is downscaled to 720p.
- Frame rate is normalized to 24 fps, whatever the source ran at.
Those last two are the only things the model changes without being asked, and both are worth planning around.
Above 720p
720p is the ceiling. A 1080p or 4K source is accepted and comes back at 720p, so the edit does not fail, it just returns a smaller file than you sent.
Three consequences follow, in the order they usually bite:
A 4K master is wasted upload. It counts against the 50 MiB budget and against your patience, and the result is the same 720p frame a 720p source would have produced. Downscale before sending, not because the model requires it, but because it lets you fit a longer clip inside the size limit at a resolution that survives.
An edited clip cannot be cut against untouched 1080p footage without treatment. The edited shot is genuinely 720p, so it will be upscaled by whatever plays it back, next to shots that were not.
Delivery above 720p is a separate step. If the finished asset has to ship at 1080p, put a video upscaler after the edit rather than trying to preserve resolution through it. FLUX Video Upscale takes a finished clip and enlarges it.
Order matters in that pipeline. Edit first, then upscale. Upscaling before the edit throws the extra pixels away at the 720p gate and charges you for them twice, and a source above 720p is more likely to breach the 50 MiB limit on the way in.
Check the returned dimensions rather than assuming them, since a 1080p source and a 720p source come back the same size.
Aspect ratio is preserved
Nothing about the framing is touched. A vertical clip comes back vertical, at the same shape it went in:
Change the mustard yellow raincoat to a burgundy one.
And a square clip comes back square, which matters for anything destined for a feed that crops:
Change the marble counter to dark slate.
There is no reframing here. A 16:9 master cannot be turned into a 9:16 cutdown by asking, and a prompt about the composition does not move the frame. Crop and reframe before the edit if the deliverable needs a different shape, and remember that a crop also shrinks the frame, so check you are still above the 160-pixel floor on both sides.
Getting a file under 50 MiB
At 720p, 50 MiB is a generous budget for fifteen seconds and a tight one for a lightly compressed export straight out of an edit suite. The fix is a re-encode rather than a shorter clip:
ffmpeg -i input.mov -vf "scale='min(1280,iw)':-2" \
-c:v libx264 -preset slow -crf 23 -pix_fmt yuv420p \
-c:a aac -b:a 128k -movflags +faststart source.mp4That caps the long edge at 1280, which is the ceiling the model would apply anyway, and lands a fifteen-second clip comfortably inside the limit. Raise the CRF towards 28 if it does not, and treat visible compression in the source as a real cost: the model re-renders whatever it is given, so blocking and mosquito noise in the input become part of what it thinks the scene looks like.
Footage longer than 15 seconds
There is no way around the ceiling inside a single request, and no continuation mode: this model edits a clip, it does not extend one. The route is to cut your footage into sections under 15 seconds, edit each one, and rejoin them in your edit. The rejoining is ffmpeg's job or your NLE's, not the model's.
Here is a 20-second walkthrough, which the model will not accept as one file:
Split into two 10-second sections, run the identical instruction on each, and concatenate the results:
ffmpeg -ss 0 -i source.mp4 -t 10 -c:v libx264 -crf 18 -c:a aac section-1.mp4
ffmpeg -ss 10 -i source.mp4 -t 10 -c:v libx264 -crf 18 -c:a aac section-2.mp4
# edit each section, then
printf "file 'edited-1.mp4'\nfile 'edited-2.mp4'\n" > parts.txt
ffmpeg -f concat -safe 0 -i parts.txt -c:v libx264 -crf 18 -c:a aac joined.mp4How well this works depends entirely on the edit. A local change gets close: recoloring a floor, swapping a product or removing an object is the same decision in both sections, so the halves land within touching distance of each other. Anything global does not. Relighting, restyling and weather are re-rendered from scratch each time, and with no seed the two sections pick different interpretations, so the join reads as a jump even when the instruction is byte-identical.
Close is not identical, and the residue is always color rather than brightness. Two sections given the same material will agree on how dark it is and disagree slightly on how warm it is, which is a difference your grade can close in seconds and a prompt cannot.
Two things narrow it before you get there. Reuse the instruction word for word, since that is the only consistency lever you have. And describe the target in measurable terms with no contradictions in it: "dark walnut, matte, fine straight grain, narrow planks in the same direction" repeats across runs, while a phrase like "cool chocolate brown" contains two different answers and lets each section pick one.
Sectioning never works for dialogue that crosses the cut. A spoken line split across two sections is two separate lip-sync problems with no knowledge of each other, and the join will land inside a word. Cut between sentences, or keep any clip with continuous speech inside the 15-second limit.
The frame rate change
Output is 24 fps regardless of what went in, which is invisible in most workflows and matters in two.
A 30 fps or 60 fps source comes back at 24. If it has to sit in a 30 fps timeline, your editor will conform it, and the conformed result is not identical to the original cadence. For a sequence where some shots are edited and some are not, conform the whole sequence rather than letting one clip arrive at a different rate.
Slow-motion footage loses its headroom. A 60 fps clip shot to be slowed down arrives at 24 fps with the extra frames gone. A 5-second bounce sent at 60 fps goes in as 298 frames and comes back as 121, so a half-speed version afterwards has less than half the frames to spend and steps through the motion instead of travelling through it. Do the slow-down before the edit, not after, or keep the fast-motion work on footage the model never touched.
The upside is that 24 fps is the delivery rate for most narrative and social work anyway, and normalization means a set of clips from different sources leaves the model matching each other.
Cost, iteration and reproducibility
Billing is per second of output video, and since the output is always exactly as long as the input, the source clip sets the price before the request is made. That gives one clear working rule: find the instruction on the shortest clip that shows the problem, then run it once on the full-length master. Iterating on a 4-second cut instead of a 15-second one is close to a quarter of the cost per attempt, and prompt search is where the attempts pile up.
There is no seed, so an edit cannot be reproduced. The same prompt against the same source gives a similar and non-identical result every time. Two habits follow:
- Archive the approved output. The file is the artifact. The prompt that made it is a recipe that will not make it again.
- Do not re-run to fix something small. With no seed, a second attempt is a fresh generation of the whole frame, and the parts you liked are as likely to change as the part you did not. Fix small problems in your edit or accept them.
Tips
-
Downscale to 720p before sending. The model caps there anyway, and the smaller file lets you fit a longer clip inside 50 MiB.
-
Never send a clip over 15 seconds and hope. It is refused, not trimmed, and the failed request still costs you the round trip.
-
Edit first, upscale second. Extra pixels sent in are discarded at the gate and paid for twice.
-
Reframe before you edit. Aspect ratio comes back exactly as sent, and no prompt will move the frame.
-
Check the 160-pixel floor after cropping. A vertical crop of an already small clip can fall under it.
-
Pass a
videoUUIDfrom an earlier task when you have one. Chaining an edit onto a clip you just generated skips a download and an upload entirely. -
Treat compression in the source as content. The model re-renders what it is given, and blocking in the input becomes blocking it believes in.
-
Section only for local edits. Recoloring, swapping and removing survive a join. Relighting, restyling and weather are re-rendered from scratch each time and will not.
-
Write the instruction with no contradiction in it. "Cool chocolate brown" holds two answers and each section picks one. Measurable terms repeat; impressions do not.
-
Keep continuous speech inside one section. A line split across a cut is two lip-sync problems that have never met.