H3 Max Camera Controls: Build a Keyframed Camera Path

H3 Max Camera Controls is not a better way to phrase “orbit left.” It is a separate image-to-video route that accepts an ordered camera path. Each keyframe tells the route when the camera should arrive, how far it has travelled around the subject, how high or low it is, and how far it sits from the subject.

That distinction matters. A normal H3 Max image-to-video prompt asks the model to interpret a shot direction. Camera Controls gives it coordinates to interpolate. The specialist route is useful when the scene is already composed and you want the viewpoint—not the person, product, liquid, smoke, or background—to move.

AI Live Generator's browser tool does not expose this keyframe editor. Its standard H3 Max Turbo workflow accepts natural-language camera direction and can animate the contents of the frame. Use the camera movement prompt guide for that workflow. This article explains fal's separate minimax/h3-max/camera-controls endpoint so you can decide whether numeric control is actually the right tool.

Choose the route by deciding what is allowed to move

The easiest way to choose between ordinary image-to-video and Camera Controls is to finish this sentence: “During this shot, the subject should…”

Camera Controls begins from one image. fal's current route describes the image as the first frame and supplies a freeze-oriented default prompt. If you replace that instruction with a general scene description, you have removed part of what tells the model to keep the scene still. Do not choose this endpoint for an actor performance and then fight its central constraint.

The four numbers in an H3 Max camera keyframe

The live fal schema allows a camera_trajectory with 2–12 keyframes. Every keyframe contains the same four fields:

Time is not measured in seconds. For a requested six-second clip, time: 0.25 targets about 1.5 seconds and time: 0.75 targets about 4.5 seconds. If you later change the requested length, the path keeps the same relative pacing.

Azimuth is literal and signed. A path from 0 to 360 makes a full turn in one direction; 0 to -360 makes it in the other. The schema preserves signed full turns rather than silently choosing the shortest route. That is powerful, but it also means a sequence such as 300 followed by 20 is not automatically interpreted as “continue forward another 80 degrees.” If continuation is what you mean, write 380.

Distance is not a zoom setting. It represents camera position. Keeping it constant makes an orbit read as an orbit. Reducing it while the azimuth changes turns the move into a spiral-in.

Three camera paths you can reason about before rendering

These are planning examples, not claimed outputs. The point is to make each move inspectable before it becomes a paid request.

1. A short dolly-in with a gentle finish

[
  { "time": 0, "azimuth": 0, "elevation": 5, "distance": 1.0 },
  { "time": 0.65, "azimuth": 0, "elevation": 5, "distance": 0.78 },
  { "time": 1, "azimuth": 0, "elevation": 5, "distance": 0.7 }
]

Only distance changes, so the intention is easy to audit. The camera covers most of the approach before 0.65, then travels a shorter distance over the remaining time. If the result feels like a flat crop instead of a dolly, the source image may not contain enough depth cues. Add a visible foreground edge and a separated background before adding more keyframes.

2. A measured left orbit

[
  { "time": 0, "azimuth": 0, "elevation": 8, "distance": 1.1 },
  { "time": 0.5, "azimuth": -45, "elevation": 8, "distance": 1.1 },
  { "time": 1, "azimuth": -90, "elevation": 8, "distance": 1.1 }
]

Equal angle changes over equal time intervals describe an even quarter-orbit. The slight elevation gives the model more top-surface information than a perfectly level move. A 90-degree reveal is also a more conservative first test than demanding the unseen back of a face or irregular product in one pass.

3. A deliberate hold before the move

[
  { "time": 0.3, "azimuth": 0, "elevation": 6, "distance": 1.0 },
  { "time": 0.7, "azimuth": 35, "elevation": 10, "distance": 0.9 },
  { "time": 1, "azimuth": 70, "elevation": 14, "distance": 0.82 }
]

The fal schema says the first pose is held before its timestamp and the final pose is held after its timestamp. Starting the first keyframe at 0.3 therefore creates an intentional opening hold. The same behavior becomes an accidental pause when someone assumes the first keyframe can begin anywhere without changing the shot.

Keyframe count is not a quality slider

More points do not automatically produce a better move. Every extra keyframe is another change in direction, speed, height, or radius that you have to justify.

Use two points for a simple straight approach or single arc. Add a middle point when you need to shape the pacing or combine axes. Add more only when the path genuinely changes. A twelve-point orbit with tiny corrections is harder to debug than three poses that state the same intention cleanly.

Before submitting a path, read it as four separate charts:

1. Does time always move forward?
2. Does azimuth continue in the direction you intended, including when crossing 0°?
3. Does elevation change smoothly, or does one point create an abrupt crane move?
4. Is distance steady for an orbit and monotonic for a dolly, unless a reversal is deliberate?

That check catches path errors before prompt wording can distract you.

Preserve the scene instead of describing it twice

Camera Controls needs a different kind of prompt from ordinary text-to-video. The image already contains the subject, lighting, pose, and composition. The prompt's important job is to say what must remain fixed while the camera moves.

fal's playground currently begins with a detailed freeze instruction. Keep that function intact. If one fragile element matters—liquid suspended above a glass, a hand touching a product, small lettering on a package—append a short clause naming it. Do not replace the freeze instruction with a fresh cinematic description that asks the model to reinterpret everything in the source frame.

A compact addition might read:

Keep the bottle label, cap, liquid level, countertop edge, and warm window light in their original positions. Only viewpoint and parallax change. No product rotation, pouring, hand movement, added props, or cut.

This is deliberately narrower than a normal image-to-video prompt. If the bottle itself must rotate or a hand must enter the frame, use the standard route instead.

Source images decide how far the camera can travel

A camera path asks the model to reveal surfaces the original image did not show. The wider the move, the larger that invention becomes.

Choose a frame with three readable depth layers: something near the camera, a clear subject, and a background with separation. Directional light and visible floor or tabletop geometry help the move read as a change of position. A flat cutout against a blank wall gives the model fewer clues for parallax.

Be conservative with asymmetric faces, transparent glass, reflections, thin straps, text, and anything whose hidden side is difficult to infer. A 30° product orbit can be useful even when a 300° orbit falls apart. Resolution cannot recover geometry that the source never supplied.

If you need the subject to pass through several designed states rather than remain frozen, Camera Controls is the wrong abstraction. Use first and last frames for a two-state transition, or read the middle-frame planning guide when the motion needs a meaningful state between the endpoints.

Diagnose the path before rewriting the prompt

Change one axis at a time. If an orbit fails, hold elevation and distance constant while fixing azimuth. If a dolly fails, keep azimuth and elevation fixed. Simultaneously rewriting the prompt, adding keyframes, increasing resolution, and changing the source leaves you unable to tell which decision mattered.

Current route limits and cost

As checked on October 23, 2026, the live fal schema requires one image_url and accepts 2–12 camera keyframes. It currently types requested duration as 0.92–15 seconds and warns that the output can run about 0.7 seconds longer than requested. It lists 480P, 768P, and a 1080P refinement tier, with disabled, balanced, and quality prompt-expansion modes. The schema is the right place to recheck fields before shipping an integration because fal can update route contracts independently; fal's editorial guide still describes a narrower 5–15 second whole-second workflow.

The live model page currently shows a 35% promotion through October 31: $0.0325 per second at 480P, $0.052 per second at 768P, and $0.104 per second at 1080P. It also states the post-promotion list prices as $0.05, $0.08, and $0.16 per second. Keyframe count does not appear as a separate billing dimension; calculate from the current route page at submission time rather than preserving these October numbers in application code.

For a server integration, use the live fal OpenAPI schema and keep the API key off the client. The broader MiniMax H3 Max API guide covers queue ownership, idempotency, and provider-result storage.

A useful first path is intentionally boring

Start with one strong image, a modest 45–90° orbit, constant distance, constant elevation, and two or three keyframes. That path is plain enough to expose whether the source frame can support parallax and whether your azimuth sign is correct. Only then add a crane, spiral, hold, or full turn.

Camera control becomes valuable when it turns a visual intention into numbers you can inspect. If the numbers do not make the move clearer, a well-written standard image-to-video prompt is probably the better tool.