"The shot moves left to right" — but which command is that? A complete guide to AI video camera moves

You have a shot in your head: the camera moves from left to right.

You type it in — "the shot moves from left to right."

What comes back could be any of three things: the camera physically sliding right, the camera turning right on the spot, or the camera not moving at all while your character walks right. Those look completely different on screen, and your sentence licensed all three.

So the model isn't messing you around. It's guessing. And you just handed it the decision.

This guide does one thing: list every move a camera can make, strip out the duplicate names, and hand you a table that maps what you'd naturally say onto the command you should actually write.

Why these words are worth learning

This isn't about turning you into a cinematographer. It's that models respond better to terminology than to adjectives — and that claim has official backing.

MiniMax's API reference states it plainly in its camera-command section:

Free-form descriptions also work, but explicit commands yield more accurate results.

ByteDance's Seedance 2.0 guide says the same thing from the other side. It tells you to use standard camera terminology directly, and defines a good prompt as "an engineering-style instruction, not a copywriting-style description."

Both are pointing at the same thing: a term is shorthand you and the model already agreed on. Write "the camera slowly gets closer" and it still has to guess whether you mean walking the body forward or tightening the lens. Write [Push in] and there's nothing left to guess.

And you already know these moves. You just haven't matched them to names yet. That's what the rest of this does.

A camera can only move in three ways

Foundation first. However many terms you've encountered, they all reduce to three categories:

1. Translation — the body changes position (forward/back, left/right, up/down)
2. Rotation — the body stays put and only changes which way it faces
3. Zoom — the body doesn't move at all; only the lens angle changes

Ask "did the body change position?" first and half the confusion disappears. Every comparison below starts from that question.

This isn't a taxonomy we invented. Kling's API gives you six camera fields and defines every one of them by axis — and they land in exactly these three groups:

Kling's parameter	Official definition	Category
horizontal	camera translation along x-axis	translation
vertical	camera translation along y-axis	translation
pan	camera rotation around y-axis	rotation
tilt	camera rotation around x-axis	rotation
roll	camera rotation around z-axis	rotation
zoom	controls camera focal length change	zoom

Two translations, three rotations, one zoom. Vendors can name things however they like; the axes don't move.

Translation: three axes of actually moving

Move	In plain words	Command
Lateral	the camera slides left or right, staying parallel	[Truck left] / [Truck right]
Vertical	the whole rig rises or drops, lens still level	[Pedestal up] / [Pedestal down]
Depth	the camera walks toward or away along its sightline	[Push in] / [Pull out]

Every translation gives you parallax: you really did change position, so near things slide past faster than far ones. That's why translation feels three-dimensional and turning on the spot doesn't.

Rotation: three axes, and nobody uses the third

Move	In plain words	Command
Pan	like turning your head left or right while standing still	[Pan left] / [Pan right]
Tilt	like nodding or looking up from where you stand	[Tilt up] / [Tilt down]
Roll	like tipping your head toward your shoulder; the horizon tips with it	rarely at the prompt layer — describe it

Roll deserves a note: of the three rotation axes it's the least likely to exist as a prompt command.

But it's not that models can't do it — it's just buried in the API. Kling has a roll parameter where you pick clockwise or counterclockwise and how far. So the capability is there; most platforms simply haven't brought that dial up to the prompt layer.

If you want it in a prompt, describe the effect — "the horizon tilts about 15 degrees to the right" is safer than roll right.

The three pairs people get wrong

These are the ones that actually cost you regenerations.

1. Truck or pan? — do you want parallax

Back to the opening image. Both read as "the shot moves right":

• Truck — the camera genuinely moves. Near objects shift more than far ones, parallax appears, and space feels solid. Right for walking alongside someone, or gliding past a shop window.
• Pan — the camera turns on the spot. Foreground and background slide together, no parallax. Right for sweeping across a landscape, or establishing how big a place is.

The test: if you want the audience to feel "I'm travelling with the camera," truck. If you want "I'm standing here looking across," pan.

2. Push in or zoom in? — the background gives it away

Both make the subject bigger. The cause is completely different:

• Push in — the body moves forward. The viewpoint changes, so the subject grows faster than the background, space opens up, and it feels like walking into the scene.
• Zoom in — the body doesn't move; the lens narrows. The whole frame scales uniformly, background included. The sense of space is unchanged — it's just a tighter crop.

Everyday speech calls both "get closer," but in a prompt they're two different shots. Want the emotional weight of approaching someone? Push in. Just want the subject bigger in frame? Zoom in.

3. Pedestal or tilt? — the verticals give it away

To see something higher up, you have two options:

• Pedestal up — the whole rig rises, lens still level. The sightline stays parallel to the ground, so vertical lines stay vertical.
• Tilt up — height unchanged, lens angles upward. The sightline goes diagonal, so verticals converge and you get perspective distortion.

This pair really matters for product and architecture shots. Want something square, clean and undistorted? That's pedestal, not tilt. Want a building to feel imposing? Then tilt's distortion is exactly the point.

Orbit: the only move that shows another side

Orbit (also called arc) is translation and rotation happening at once: the body travels an arc while the lens stays locked on the subject.

The result is that the subject sits near-still in frame while the entire background sweeps past. It is the only move that reveals another side of your subject, which is why product reveals and character introductions lean on it.

It gets mistyped as pan constantly, and the failure is total: pan doesn't move the body, so the subject just slides out of frame. If you'd naturally say "the camera circles him," that's orbit. If you'd say "the camera sweeps across," that's pan.

Two composite moves — they're built from the basics

Once you know they're composites, you know how to write them:

• Crane / jib = [Pedestal up] + [Tilt down]. The body rises while the lens angles down, keeping the subject in frame as the view shifts from eye level to looking down. A staple for openings and endings.
• Dolly zoom = Push in + Zoom out (or the reverse). The two cancel, so the subject stays the same size while the background expands. This is the vertigo effect — Hitchcock used it in Vertigo, and it's since become the standard vocabulary for "something is suddenly wrong."

Composites usually have no single command. You write both basic moves and state that they happen simultaneously.

Some vendors do ship the common ones ready-made, though. Kling offers four, and every official description is itself two moves stacked:

Preset	Official description
down_back	Camera descends and moves backward
forward_up	Camera moves forward and tilts up
right_turn_forward	Rotate right then move forward
left_turn_forward	Rotate left then move forward

They're just the basic moves in pairs. Knowing how to take them apart means you can write the same effect on a platform that has no preset for it.

Worth noting: the English gloss Kling attaches to down_back is "Pan down and zoom out" — and by this article's own standard, both words are loose. Descending is pedestal, not pan; moving backward is the body travelling, not zoom. Even official docs mix the names up, which is exactly why you judge by the motion instead.

The last three describe state, not direction

Move	In plain words	Command
Static	tripod locked, not a single frame of drift	[Static shot]
Shake	the micro-tremor of a handheld camera	[Shake]
Tracking	follows the subject, relative distance unchanged	[Tracking shot]

[Static shot] looks like a wasted instruction and is in fact the most useful one here. When debugging, take the camera move away first. If a locked-off shot gets the subject and action right, the problem is the move. If the locked-off shot is already wrong, no amount of camera work will rescue it.

Plain English to command: the lookup table

This is the part worth bookmarking. Left column is what you'd naturally say. Right column is what belongs in the prompt.

What you'd say	What it actually is	What to write
follow him to the right	body translates sideways	[Truck right]
sweep across the room	rotate on the spot	[Pan right]
slowly move in on his face	body moves forward	[Push in]
zoom in a bit	lens only, body still	[Zoom in]
pull back to reveal the place	body moves back	[Pull out]
travel from his feet up to his face	lens angles up	[Tilt up]
look down on him	lens angles down	[Tilt down]
get higher without distorting it	body rises, lens level	[Pedestal up]
descend from above onto him	pedestal plus tilt	[Pedestal down] + [Tilt up]
circle around him	orbit	describe: "the camera arcs around the subject, staying locked on him"
stay with him the whole way	tracking	[Tracking shot]
keep the camera still	locked off	[Static shot]
give it a handheld feel	shake	[Shake]
make it feel like the world is tipping	roll	describe: "the horizon tilts to the right"
the closer we get, the more wrong it feels	push plus opposing zoom	describe: "the camera moves forward while the lens zooms out"

Why one move has so many names

You'll see Truck left, Dolly left, Track left, Move left, Slide left — all the same thing: the body translating sideways.

The reason is that this vocabulary comes from physical equipment. A dolly is a camera cart, trucking is that cart moving sideways, a pedestal is a rig that raises and lowers, a crane is a boom arm. Different gear, overlapping motion, and so one action ended up with several names.

Each AI video platform then picked its own subset, which is how we got here.

So the thing to judge by is always what the camera physically did, never what it's called. When you meet an unfamiliar term, three questions place it:

1. Did the body change position? (yes = translation, no = rotation or zoom)
2. If yes, along which axis? (lateral / vertical / depth)
3. If no, is it changing direction or changing angle of view? (direction = rotation, angle = zoom)

How many moves in one shot?

Three vendors, three different answers — and they aren't just different degrees of strictness:

• MiniMax lets you combine: multiple commands inside one bracket happen at once (for example [Pan left,Pedestal up]), with a recommended maximum of 3. You can also sequence them: "...[Push in], then...[Push out]".
• Seedance 2.0 goes the other way and recommends one move per shot, saying outright that demanding push, pull, pan and track at once "will increase image instability." (That's the 2.0 wording — the 1.0 guide takes the opposite line, saying multiple camera commands can be combined into creative long takes. Same vendor, different version, different advice, so check which one you're reading.)
• Kling writes it into the API: of the six config fields, "Choose only one parameter to be non-zero; rest must be 0."

That last one is a different kind of statement. The first two are advice (overdo it and the picture degrades); Kling's is a rule (overdo it and the request is rejected).

Nobody here is wrong — the models just have different temperaments. Either way the safe move: start with one camera move, confirm the subject and action are right, then consider adding a second.

One quick self-check: delete every camera term from your prompt. Can you still say what the audience sees first and what they see next? If not, those terms were decoration — they hadn't become shot design yet.

One caveat up front: what's collected here is what each vendor's documentation actually says, plus standard industry terminology. Which command genuinely lands on which model, and which quietly gets ignored, is something no vendor guarantees publicly — and it shifts between versions. So treat this as your opening move; the real answer still comes from generating a few takes yourself.

Where to go next

Camera work is one field among several. How you specify subject, action, setting and light differs sharply between vendors — MiniMax keeps its structure in the API, and the trade-off between the two approaches is in "One idea, two models".

If your problem is that each clip looks fine alone but they jump when cut together, that's continuity rather than camera work.

Official sources

The bracket command vocabulary, the combination and sequencing rules, and the "explicit commands yield more accurate results" line come from MiniMax's API reference (that table is documented for the Hailuo/Director line; it is not restated on the H3 endpoint, and this article does not claim H3 supports all fifteen). The open-ended use of camera terminology comes from BytePlus's Seedance prompt guides; the "one move per shot" recommendation is specifically from the Seedance 2.0 guide, and the 1.0 guide words it differently (1.0 says multiple camera commands can be combined), which is why the version is named in the text.

The translation/rotation/zoom taxonomy and the per-axis definitions are additionally corroborated by Kling's camera_control parameter documentation, which defines its six fields explicitly in terms of the x, y and z axes.

Dolly, truck, pedestal, crane, orbit and roll are standard industry terminology rather than any vendor's proprietary commands; the lookup table above marks which have named commands and which need to be described in words.

Last verified: 2026-08-01.

• Create Text-to-Video Generation Task (MiniMax — the 15 named camera commands and usage rules)
• Image-to-Video Task (MiniMax — same command table)
• Video Generation (MiniMax guide)
• Seedance 2.0 series prompt guide (BytePlus)
• Seedance-1.0-pro & pro-fast prompt guide (BytePlus — camera language and shot sizes)
• Kling 1.6 Image to Video (the camera_control axis definitions and six config fields)