Lens and Depth of Field in Video Prompts

TL;DR: No AI video vendor publishes a lens, aperture, or depth-of-field field. Checked directly in the request schemas for Kling, Veo, Runway, LTX, and Sora, that parameter does not exist. What several vendors do publish is vocabulary: words their own prompting guides recommend. That's the real lever, and below is which vendor documents which words.

Search "video lens prompts" and you'll find plenty of pages listing focal lengths and f-stops as if they were settings you dial in, the same way you'd set duration or resolution. They aren't. Every request schema we could read, Kling's, Google's, Runway's, LTX's, OpenAI's, has a field for duration, a field for resolution, sometimes a field for audio. None has a field for a lens. What actually exists is narrower and more useful once you see it clearly: a handful of vendors publish specific prompt vocabulary for focus and framing, one vendor ships a camera parameter that has nothing to do with lenses at all, and the temporal move video adds over a still image, the focus pull, isn't documented anywhere as a feature.

This distinction matters for a practical reason, not just an academic one. If you believe a numbered aperture value is a real lever, you'll spend an afternoon testing "f/2.8" against "f/8" expecting a measurable, repeatable difference in blur radius the way a camera would give you one, and conclude the model is broken when the two look similar. If you understand the lever is really a handful of trained-on photographic phrases, you test those phrases against each other instead, and you stop hunting for a control that was never there. Here's what's real, sourced to each vendor's own page.

Does any AI video model have a lens, aperture, or depth-of-field parameter?

No. We checked the actual request body for five current video surfaces, not their marketing pages: Kling 3.0 Omni's text-to-video endpoint, Veo 3.1 on the Gemini API, Runway's Dev API reference, LTX-2.5's model spec, and OpenAI's Sora 2 video-generation guide. Zero fields named lens, aperture, focal_length, depth_of_field, or anything close, across all five. OpenAI states the boundary explicitly in its own Sora documentation: "The prompt defines the creative look and feel – subjects, camera, lighting, and motion – while parameters like size and seconds control the video's resolution and length." Camera and lens are prompt content. Only resolution and duration are parameters.

The single exception worth naming is also the one most likely to get mistaken for a lens control. BytePlus's Seedance video-generation reference documents camera_fixed as a real request field: type boolean, default value false, described in the reference simply as "Fix camera". It's a request-body parameter, but read what it actually does before assuming it's a hardware lock: "Whether to fix the camera. Valid values:" true, and here's the tell, "Fix the camera. ModelArk will append the fixed camera instruction to the user's prompt, but the actual result is not guaranteed." Even Seedance's one real camera parameter is implemented by silently injecting text into your prompt behind the scenes, with BytePlus's own docs declining to promise it works. It locks movement, not focus, and it isn't a lens field even loosely. Nothing else we found comes closer.

What lens and depth-of-field vocabulary do vendors actually document?

Four vendors publish something concrete, and no two publish the same list. Google's Gemini API guide for Veo lists it as one of seven optional prompt elements: "Focus and lens effects: [Optional] Use terms like shallow focus, deep focus, soft focus, macro lens, and wide-angle lens to achieve specific visual effects." Google's separate Cloud blog prompting guide for Veo 3.1 gives a shorter, differently worded version under its own five-part formula: "Lens & focus: Shallow depth of field, wide-angle lens, soft focus, macro lens, deep focus." It pairs that line with a full worked example: "Close-up with very shallow depth of field, a young woman's face, looking out a bus window at the passing city lights with her reflection faintly visible on the glass, inside a bus at night during a rainstorm, melancholic mood with cool blue tones, moody, cinematic." Same company, two pages, two different lists. Neither is wrong, they just aren't the same document, and neither page tells you the other exists.

Kling's text-to-video prompt guide folds lens vocabulary into a broader category it calls Camera Language, and draws its own boundary around what belongs there: "Camera Language: It pertains to employing various applications of the camera lens, along with the transitions and edits between shots, to communicate a narrative or message and to generate particular visual impacts and emotional tones. Techniques include ultra-wide angle shots, bokeh (background blur), close-ups, telephoto shots, low-angle shots, high-angle shots, aerial views, and depth of field, among others; (Note: This should be differentiated from camera motion control.)" That parenthetical matters: Kling is telling you its own vocabulary here is not the same system as the camera movement panel covered in our Kling camera control breakdown. Framing and motion are documented as two separate things even inside one vendor's guide.

OpenAI goes furthest of anyone we checked. Its Sora 2 prompting guide has a section literally titled "Lenses & Filtration", and its "Going Ultra-Detailed" example spells out a specific pairing: "32 mm / 50 mm spherical primes; Black Pro-Mist 1/4; slight CPL rotation to manage glass reflections on train windows." Later in the same guide, a weak-to-strong prompt table offers "Anamorphic 2.0x lens, shallow DOF, volumetric light" as the fix for a vague "Cinematic look", and a separate strong-prompt template spells out "Depth of field: shallow (sharp on subject, blurred background)" as its own line. LTX's prompting guide files the same territory under two different headings in its vocabulary list: "Depth of field" sits under Visual Effects, "Lens flares" sits under Film Characteristics. Present, but treated as generic mood words rather than a named system the way OpenAI's is.

Why doesn't a numeric aperture or focal-length field exist anywhere?

Because nothing downstream is computing optics. The vendors that publish lens vocabulary are telling you which words steer the output, not which values a lens-simulation step will consume. Our breakdown of camera and lens terms for AI images covers the underlying mechanism in depth for stills, and it holds for video the same way: a model trained on captioned footage learned what real clips tagged "35mm handheld" or "shallow depth of field" tend to look like, and reproduces that pattern. There's no ray-tracing step matching an f-stop to a blur radius, and no lookup table converting a millimeter value into a precise blur kernel the way a real lens would. That's exactly why OpenAI's Sora guide can write "The model will choose variables like camera lens, lighting and color grade accordingly" when you set an overall style. The model is inferring lens character from style words, not solving for one, which is also why two prompts naming different focal lengths but the same overall style sometimes come out looking more alike than the numbers would suggest.

This is also why a numeric aperture value is the one thing conspicuously missing from every vendor list above. Focal-length-shaped phrases like "35mm" or "50mm" show up because they're common photography captions with a consistent visual signature attached. An f-stop like "f/1.4" is a much narrower, more technical caption that shows up far less often in training data with a consistent look, so no vendor guide bothers recommending it. Not because it's forbidden, but because nobody has published evidence it does anything reliable, and the phrase itself is rarer in the kind of captioned footage a video model actually trains on than it is in still-photography captions. Stick to the vocabulary vendors actually demonstrate, like OpenAI's own "32 mm / 50 mm spherical primes", rather than inventing an f-stop and assuming it will hold. If you want a number in the prompt at all, a focal length in millimeters is the one with a documented precedent; an aperture value is not.

What about the move only video can make: the focus racking mid-shot?

This is the one place a still-image prompt and a video prompt genuinely diverge, and it's also the one place no vendor documentation helped us at all. A rack focus, the point of sharp focus shifting from one subject to another while the shot keeps rolling, only exists because video has a time axis: a still image has exactly one focus plane and always will, while a video clip can hold one focus plane at the start and a different one by the end. We checked Kling, Veo, LTX, Sora, and Runway's documentation for the phrases "rack focus" and "focus pull." Zero occurrences, on any of them. This is craft knowledge we're teaching you, not something we can attribute to a vendor guide, and you should read it that way.

What we've found holds up in testing is describing the shift as an event with a place in the sequence, the same discipline LTX's own guide demands for a hard cut between two shots. Name what changes and when, rather than leaving the model to guess which subject should be sharp at which second:

Medium shot of two chess players across a board, both in soft focus at
first behind a foreground pawn held sharp and close to camera. As the
white player's hand releases the piece, focus racks smoothly from the
pawn to the black player's face, which sharpens just as her eyes lift
to meet his. The pawn falls softly out of focus behind her.

Naming the trigger, "as the white player's hand releases the piece", gives the model a beat to hang the shift on, the same way a timestamp or a named cut gives it a boundary elsewhere in a sequence. Treat this as a technique to test per model, never as a spec any vendor has committed to.

Keeping lens language consistent once you're past one shot

Everything above holds for a single generation. The moment you're writing a sequence, a scene told across a wide shot, a rack focus, and a close-up, the risk is that "shallow depth of field" in shot one quietly becomes "soft focus" in shot three because you typed the description fresh each time instead of reusing it. Our companion piece on prompting multi-shot sequences covers the mechanics in full: write the lens and lighting description once, as a block, and repeat it verbatim at every shot boundary rather than re-describing the look from memory. For the wider vocabulary of framing, camera movement, and lighting that lens language usually travels with, the seven-part anatomy of a video prompt is the fuller structure to hang it on, and directing AI video like a filmmaker covers the six fundamentals lens sits alongside.

One closing note on what we do and don't do here. We build and store the prompt: the lens vocabulary, the style block, the whole reusable library. We do not render the video, and every field and quote above belongs to Google, Kling, OpenAI, LTX, Runway, or BytePlus, read from their own documentation on September 3, 2026. Video prompt generation sits on the Advanced and Team plans rather than Pro, and the free plan includes 5 prompt enhancements per day, forever, per our FAQ.