Does Every Step of Making a Video Need AI?

Imagine a bookstore video made from photographs of its storefront, entrance and reading area, with narration and subtitles. Now we want to change only the sentence introducing the entrance. The photograph can stay. It looks like a small edit.

But will the new audio last as long? Can the subtitles stay? If the entrance photograph remains on screen longer, where does the next scene begin? Editing one sentence soon involves more than one sentence.

This proposal has not been implemented. There are no samples or benchmarks; the bookstore video is a hypothetical case for thinking through the design. My idea is to have a model understand the assets and what the video needs to say, put its decisions in a configuration, and let software carry on with the composition. Lower token use is a goal to test. The task is arranging existing assets, distinct from the generative-video exploration associated with Lingke.

First, settle how the photograph will be used

Suppose the shop's name appears at the upper left of the storefront photograph. The shot should move slowly toward the entrance while keeping the name visible. The model needs the spatial relationships and the reason those words must not be cropped. The software needs an asset reference, focal area, region to preserve and type of movement to follow that plan. Making those parameters explicit also lets someone check them.

“Make it cinematic” is not enough. The software still has no instruction about where the image should move. Giving the model the original request again at every later stage could instead produce a different decision each time. I would keep narration, subtitles and visual_intent—what this scene should convey—in the scene configuration, so later steps can follow the same arrangement.

FFmpeg filters including zoompan, xfade and subtitles can handle panning and zooming over stills, transitions and subtitle composition, subject to their respective input requirements.^[2] Once the configuration is clear, the software can call the appropriate filters. Whether to preserve the shop name or emphasize something else at the entrance still needs to be decided beforehand.

This limits the suitable material to explanations that existing photographs can support. Panning and zooming change how a photograph is presented; they do not generate movement by its subjects or true three-dimensional changes. A person turning around, an object changing shape or a new viewpoint calls for another production approach. Moving closer to a photograph does not make its subjects start performing.

Change the words, generate the voice, then set the timing

Return to the small edit at the beginning. Suppose an initial version has been produced using this proposed arrangement. We revise only the wording introducing the entrance, keeping its photograph and purpose unchanged.

The new narration needs audio generated through text-to-speech, or TTS. A similar word count need not produce the same duration: speaking rate, pauses and pronunciation all affect it. The design should therefore generate the audio before measuring it. ffprobe can inspect media information to help establish the actual file and its duration.^[1] Word count can provide an estimate; the final timeline should follow the voice that was actually generated.

Knowing the total length still leaves the timing of individual sentences unknown. Subtitles need fresh alignment to the real audio, with checks for breaks, omitted words and reading time. Reusing the old timestamps might move the subtitle to the next sentence while the voice is still on the previous one. Missing audio or failed alignment should stop and report the problem here, rather than leaving discovery until someone plays the finished video.

Then comes the entrance photograph. If the narration is longer, should the image stay longer? Should the zoom slow down, or finish and hold while the voice catches up? Where suitable rules exist, configuration and software can handle the choice. Where they do not, the model or creator needs to decide.

The photograph has not changed. Its timing may already be wrong.

A new scene length may require updates to the start of later scenes, adjacent transitions and final composition. The change begins in a sentence and reaches the finished video through audio, subtitles and visual timing. Fixing shot lengths from word counts and hoping the voice will fit can cut away before one sentence is finished and leave too long a pause in another section.

Which earlier results can stay?

Changing one narration passage should not require remaking everything. The source photograph is unchanged and can stay. New narration needs new audio. Subtitle timing depends on the voice and needs updating; visual arrangements dependent on duration need recalculation. To decide whether a result needs remaking, check whether the material and parameters that produced it have changed.

That is the problem caching needs to solve. If the system remembers only that the storefront photograph is unchanged and reuses its old clip, it retains unsuitable timing along with it. A usable source photograph does not establish that its earlier rendered clip can return unchanged.

There is another layer: why are we using this photograph? If “introduce the entrance” becomes “show the atmosphere inside,” the storefront image may need replacing even when the two narration passages happen to last equally long. A cache that compares only files and durations cannot see this change. The scene's purpose therefore needs to remain in its configuration.

The design also needs to record each change: which old results no longer fit and which can stay. Rerun only the affected stages, then watch the finished video for cropped focal points, obstructive subtitles and sound that does not match the picture. Retaining more old results is not a saving if they assemble into a video that no longer fits together.

What, exactly, did the edit save?

Under this proposal, an edit might need little judgment from the model and few tokens. But TTS would still need to produce new speech, subtitles would still need alignment, and the video might need rendering again. If those stages or human checks dominate the work, fewer model calls may make little difference to the total cost.

I would record model tokens, TTS charges and rendering time separately, alongside human time spent preparing assets, checking and reworking. I would also separate initial production from a single edit. Writing a clear first configuration may take extra effort; it has a chance to save work only if later steps really reuse it. Failed attempts and repeated renders go into the record too, rather than choosing the cheapest call.

Sometimes an extra model judgment that spots a cropped shop name before rendering may be cheaper than discovering it afterward and starting again. Those extra tokens need to be weighed against the rework they might save. Comparisons also need the same standards for clarity, readability and audiovisual consistency. Less content or lower quality does not establish that this division of work is more efficient.

What I want to avoid is reconsidering the same brief from the beginning whenever one sentence changes. The shop's name still needs to remain in the frame. The voice and subtitles still need to agree. Using fewer tokens cannot save us from either of those jobs.