TL;DR: Almost nothing called "camera control" in AI video is an actual API parameter. Seedance's camera_fixed genuinely is one. Kling's settings object controls duration, ratio, audio and shot-splitting, not the camera itself. Runway's bodyControl and expressionIntensity move a character, not a lens. Veo has no camera field at all, only prose.

Camera Control Parameters in AI Video Tools

"Camera control" gets used as a marketing phrase for at least four different things across AI video tools: a documented settings field, a prompt-writing convention, a character-performance toggle, and a parameter that is present in the schema but doesn't do anything on the model you're calling. Confusing these is easy, because vendors themselves sometimes blur the line between an actual video camera parameter and a paragraph of prose describing camera language.

This post sorts five vendors' current APIs into what's a real field versus what's prompt language, checked directly against each vendor's own request-body schema rather than their marketing pages. The distinction matters because a real parameter is guaranteed to do something; prompt language, like the camera movement vocabulary a model was trained on, is a request the model may or may not honor.

Which AI Video Vendors Actually Expose a Camera Parameter?

Here's the honest state of the field, verified from each vendor's own API reference:

Only one row in that table is an unambiguous, working, camera-named parameter. Everything else is either a different kind of control entirely, a field that's contested about what it measures, or simply not present, with camera direction left to the prompt.

What Does Kling Actually Expose for Camera, Shot and Duration Control?

Kling's text-to-video endpoint for VIDEO 3.0 / 3.0 Omni documents a settings object with four fields that people often lump under "camera control" because they shape the finished shot: settings.aspect_ratio (16:9, 9:16 or 1:1, described in Kling's own reference as "The aspect ratio (width:height) of the generated video frames"), settings.duration (an integer from 3 to 15, described as "video duration in seconds" and covered in more depth in our video duration parameters by model reference), settings.audio (native or off, defaulting to off, described as "Whether to generate audio for the video"), and settings.multi_shot, a boolean defaulting to true and described as "Whether to generate multi-shot video".

{
  "prompt": "A drone pushes in over a coastal cliff at golden hour.",
  "settings": {
    "aspect_ratio": "16:9",
    "duration": 15,
    "audio": "off",
    "multi_shot": true
  }
}

None of those four fields names or moves a camera. What actually reads as camera direction, "push in," "dolly out," "pan left," lives entirely inside the prompt string, and how Kling's separate Camera Movement panel and Motion Control feature fit around this endpoint is its own topic, covered in Kling camera control and motion control. Kling's own API reference documents a shot grammar for splitting that prompt into segments, quoted directly: "shot n, m, words; shot n, m, words;", where n is a shot number from 1 to 6, m is that shot's duration in seconds (each shot at least 1 second, with every shot's duration summing to the total settings.duration), and words is the shot's own prompt text, capped at 512 characters.

Why Do People Think Kling Generates at 60fps?

Because of a real sentence in Kling's own documentation, read out of context. Kling's Omni-format reference states, describing the acceptable input for a feature or base reference video: "The video frame rate is based on 24fps to 60fps (the frame rate for generating videos is 24fps)." That 24-to-60 range describes what Kling will accept as an uploaded reference clip. The parenthetical, in the same sentence, states what Kling actually outputs: 24fps. Kling's text-to-video endpoint carries no frame-rate field of any kind in its request or response schema. The "Kling does 60fps" claim in circulation is a misreading of an input-video spec as if it described the model's own output.

Does Seedance's camera_fixed Really Control the Camera?

Yes, and it's the cleanest example in this whole comparison. BytePlus's own ModelArk API documentation for Seedance lists a camera_fixed field: type boolean, default value false, documented in two words as "Fix camera." Set it and the camera holds its position rather than following whatever motion the prompt describes elsewhere. It's a blunt on/off switch, not a movement or angle dial, but it is unambiguously a camera parameter in a way that nothing else in this post is.

Does Kling's Dedicated Motion Control Endpoint Use a Camera Field?

No, and it's a good illustration of how easy it is to file a feature under "camera control" that isn't one. Kling's Motion Control endpoint takes a contents array (a prompt, an appearance reference image, and a motion reference video) plus its own settings object, entirely separate from the text-to-video endpoint covered above. The field that actually drives the output is settings.character_orientation, which accepts image or video and decides whether the generated video matches the character's orientation in a reference image or in the reference video instead. Its own settings.audio field accepts original here, retaining the reference video's sound, rather than the native/off pair used on text-to-video.

There is no aspect_ratio field and no camera-named field anywhere on this endpoint. Duration isn't a settings value either; it is driven by the reference video you upload, capped at 10 seconds when orientation matches a reference image and 30 seconds when it matches a reference video, per Kling's own documentation for the endpoint. The whole feature moves a character's orientation and motion according to a reference clip. It does not touch camera framing, and none of its own field names claim otherwise, which makes it a second Kling feature, alongside settings.multi_shot, that gets folklore-labeled as camera control without a camera field backing that up.

What Are Runway's bodyControl and expressionIntensity, If Not Camera Control?

They belong to Runway's Act-Two character-performance feature, and neither touches a camera. Runway's own API specification describes bodyControl as "A boolean indicating whether to enable body control. When enabled, non-facial movements and gestures will be applied to the character in addition to facial expressions." expressionIntensity is described as "An integer between 1 and 5 (inclusive). A larger value increases the intensity of the character's expression.", defaulting to 3. Both drive how a character performs, borrowed from a reference video, not how the camera frames or moves through a scene. Search Runway's published API specification for any field with "camera" in its name and you'll find none; where Runway wants motion described at all, its promptText field for several models is documented plainly as text describing "motion or changes in the output video", meaning motion direction, camera included, is prose there too.

Is There Still a Dedicated Motion-Strength Dial Anywhere?

Barely, and where one still exists it's compromised. Vidu's movement_amplitude is the only field among these five vendors that reads like a general-purpose motion dial: a string accepting auto, small, medium or large. But Vidu's own image-to-video reference documents it as broken on the models people are actually calling, stating plainly that "Modifying this parameter is ineffective for q2, q3 models". That covers the current model lineup.

Vidu's documentation also disagrees with itself about what the field is even supposed to measure. The request-parameter table describes it as "The movement amplitude of objects in the frame". The response table, on the very same reference page, describes the value that comes back as "The camera movement amplitude parameter used for this call". Objects in one table, camera in the other, on one vendor's one page, for one field. Whichever it's meant to be, it currently changes nothing on Q2 or Q3.

So What's Left for Veo, and Everyone Else Without a Field?

Prompt language, and Veo's own guide says so directly. Google's Gemini API documentation for Veo has exactly one spatial parameter, aspectRatio, and it accepts only two values: 16:9 and 9:16. There is no camera-named field anywhere on that page. Instead, Veo's own prompting guidance carries a section literally titled "Camera motion and composition", instructing you to: "Specify how the camera moves (POV shot, aerial view, tracking drone view) and how the shot is framed (wide shot, close-up, low angle)." That's written directly into the guide's own prose, not into any parameter. That's the vendor's own model, in its own documentation, confirming camera direction is a writing problem on that surface, not a settings problem. Our 30 cinematic camera prompts for Veo and Kling is the practical companion to this post if that's the surface you're writing for.

The practical upshot is a short checklist worth running before you build around any vendor's "camera control" claim: read the actual request-body schema, not the feature page; check whether the field you want is named after a camera or after something adjacent (a character, an amplitude, a shot count); and if nothing in the schema does what you want, assume it's a prompt-language job and write the direction into the text using real camera and lens vocabulary, the way Kling's shot grammar, Runway's promptText, and Veo's prose guidance all expect you to.

None of this makes prompt-language camera direction a lesser option by default. A vendor exposing a real camera_fixed-style field just means one specific behavior is guaranteed rather than requested; everything else, framing, movement style, pacing across shots, is still being decided by a model that learned camera vocabulary from captioned footage rather than from a settings schema. Whether a given model handles one clear instruction better than five stacked, conflicting ones is worth testing on the specific vendor you're calling rather than assuming, since that's a model-behavior claim none of the five API references above actually documents either way.