Why video prompts differ from image prompts
Image prompting advice transfers badly because it has no answer to the question video forces: what happens during the shot.
- A still prompt describes a state. A video prompt must describe a state plus a change.
- Time introduces failure modes — flicker, drift, instability — that have no still-image equivalent.
- Camera behaviour becomes a first-class instruction rather than a compositional note.
The one-line difference: if your video prompt would work as a still image prompt, it is missing the part that makes it a video prompt.
The base formula
A structure that holds up across models:
- Subject — what is in frame, described concretely.
- Motion — what changes during the shot, and how fast.
- Camera — static, push in, pull out, pan, track, orbit.
- Lighting and style — time of day, quality of light, visual treatment.
- Duration — state it explicitly even when the model has a default.
Specifying motion
| Vague | Specific | Why it matters |
|---|---|---|
| “wind blowing” | “hair and loose fabric moving gently left to right” | Names what actually moves |
| “busy street” | “pedestrians crossing left to right, cars passing in the background” | Separates subject motion from background |
| “dramatic movement” | “camera pushes in slowly over four seconds” | Ties motion to time |
Name the thing that moves: models respond to concrete nouns and directions. Abstract motion adjectives produce inconsistent results because there is nothing to attach them to.
Camera terms that work
- Static — the most reliable option; use it whenever the shot allows.
- Slow push in / pull out — reliable single-axis movement.
- Pan left / right — reliable, specify direction.
- Tracking — specify what it follows and from which side.
- Orbit — more prone to subject distortion; use sparingly.
- Handheld — introduces instability; avoid unless you want it.
Complex combined moves are where consistency breaks. One move per shot is the rule that most improves output.
Why shorter prompts win
- Every additional clause is another constraint the model may resolve against the others.
- Conflicting constraints produce mush rather than a compromise.
- Two to three sentences covers the base formula comfortably.
- If a shot needs more than that, it probably needs to be two shots.
The split test: when a prompt will not produce what you want, splitting it into two shorter shots almost always beats making the prompt longer.
Building a prompt library
-
Save every prompt that produced a keeper
Include model, settings and seed. You cannot regenerate reliably without them.
-
Tag by shot type
Motion, detail, establishing, character. Retrieval by shot type is what makes a library useful.
-
Record failure modes next to successes
Knowing which prompts nearly worked saves more time than the successes do.
-
Extract patterns into templates
Once three prompts of a type work, write the template with slots for variable parts.
-
Track hit rate per template
That number is the most valuable thing in your library.
Debugging a bad result
| Symptom | Likely cause | Fix |
|---|---|---|
| Subject morphs mid-shot | Too much motion or too long | Shorten the clip; reduce motion |
| Camera does not move | Camera instruction ambiguous | Name one single-axis move |
| Output ignores half the prompt | Too many constraints | Cut the prompt; split into two shots |
| Flickering or instability | Complex motion plus long duration | Shorten duration; simplify motion |
| Wrong style | Style buried at the end | Move style earlier; state it explicitly |