Scene Equals Character Plus Location: The Closed Loop of One Shot, Two Frames, Keyframe-Driven Video Generation
Scene equals character plus location—this formula is not a metaphor but a hard association between data tables.
Every row in the dbvideo_process table must carry a rolecode and a placecode; if either field is missing, that row will never be produced by atctoscene.
But this formula alone is not enough. For a scene to become a visible image, it must be converted into a picture—and not just one picture, but a pair: the first frame and the last frame.
The first frame defines the visual state at the start of the shot; the last frame defines the visual state at the end. All continuous motion between the two is filled in by the video generation model.
This one-shot-two-frames design exists to give dynamic video generation clear anchor points, rather than letting the model improvise freely.
If only one image is given, the video model cannot know what state the frame should ultimately transition to, which leads to drift: characters may deform, scenes may shift.
Two frames lock down the beginning and the end, and the model only needs to interpolate in between. This turns the conversion from static image to dynamic video into a controllable pipeline.
The first frame's generation path goes through the synthesis of character and location.
From dbvideo_process, read the current shot's rolecode; look up that character's name, appearance description, pose template, and previously generated character image path in dbvideo_roles—that path is stored in the fmpic field.
Then read the placecode from the same process row; look up the location's environment description, lighting characteristics, and previously generated location image path in dbvideo_places—stored in the plcpic field.
At this point, the first frame does not directly call text-to-image. Instead, it goes through placeaiwords' character-present branch, which is image-to-image synthesis.
The synthesis input includes two images: the character image fmpic and the location image plcpic, plus a synthesis prompt, scenetopic, which describes where the character stands within the location, in what pose, and how the lighting changes.
The character-present branch of placeaiwords reads these two base images and generates a new image via an image-to-image interface. In the resulting image, the character's style matches the character image, the background style matches the location image, and it also satisfies the scenetopic description.
The first frame's filename ends with -a, marking it as the shot's first frame.
The last frame's generation path differs slightly from the first frame's.
BODY:
The last frame also uses the character image and location image as base images, but its scenetopic describes the state at the end of the shot—for example, the character has turned around, the location's lighting has dimmed, or the character has walked out of frame.
The last frame's filename ends with -b.
In actual execution, the first frame and last frame are not generated independently; they are generated together by arcpictask.
The system submits two prompt descriptions simultaneously within that task—one generates -a and the other generates -b—and the only difference between them lies in scenetopic.
The benefit of this design is ensuring continuity between the two frames in terms of art style, character appearance, and location structure, avoiding a jarring break where the first frame is realistic and the last frame becomes anime.
More importantly, the taskdes field in arcpictask specifies the naming convention for the two output files and automatically checks whether both -a and -b exist. If only one file is generated, the second file is written as a STCODE.png placeholder, indicating that the task failed and will not proceed to the subsequent video synthesis stage.
In practice, most image-generation failures occur at this step, because the first and last frames are an inseparable pair for a single shot—if one is missing, the shot's motion trajectory cannot be established at all.
The complete four-step generation chain can be executed in the following order.
Step one: read the character table.
Take the rolecode from the current row in dbvideo_process, then retrieve all attributes of that character from dbvideo_roles, including rolename, appearance, and the character's standard image fmpic.
Here, fmpic is the image cache generated by a previous drawrole or placeaiwords call. If the character has already had an image generated in an earlier shot, it is reused directly, avoiding inconsistent character appearance from redundant generation.
Step two: read the location table.
Similarly, take the placecode and obtain placename, environment, and the standard location image plcpic from dbvideo_places.
Step three: compose the scene prompt.
From the eight-segment skeleton template in process.aiwords, replace the first segment's character information with the current character name, and replace the seventh segment's scene location with the current location name, keeping all other segments at their default values.
Then, based on whether a character is present, generate scenetopic—if a character exists, use the character-present branch; if not, use the empty-rolex branch for pure text-to-image.
Step four: call the image-to-image interface to output the two images.
BODY:
The interface receives two input paths, plcpic and fmpic, with scenetopic as the text guide, and outputs the first frame file and the last frame file.
After output is complete, the URLs of the two files are filled into the firstpic and secondpic fields in the process table, respectively.
Once the first and last frames are fed into the Jimeng video generator, the shot truly begins to move.
Jimeng receives both the first frame and the last frame as input—the first frame serves as the starting state, the last frame as the ending state—and the video model automatically generates the transitional frames in between.
This transition is not a simple crossfade; it involves continuous motion generated through motion prediction, such as a character moving from standing to sitting, or the camera pushing from a wide shot to a close-up.
Jimeng reads the pixel information of first frame -a as the initial state and last frame -b as the terminal state, then uses the eight-segment skeleton prompt in process.aiwords to guide the motion's style and pacing.
The eight-segment skeleton includes character information, lip-sync consistency, accent and tone, camera technique, scene location, on-screen action, aspect ratio, clarity, and duration, where the duration field determines how many seconds the generated video segment lasts. The only variable segments are three: character, action, and location.
After video generation is complete, a task ID is returned and written into the process table, but the vdurl field always remains empty—the video file is never stored back on the local server, existing only in Jimeng's external storage.
The most critical point of this closed loop is that a genuine motion relationship must exist between the first and last frames.
If the two images are exactly identical, the video generated by Jimeng will be static, carrying no meaningful information.
If the two images differ too much—for example, the character's position jumping from the left side to the right—Jimeng may generate a distorted transition with artifacts.
Therefore, the descriptive quality of scenetopic directly determines the motion effect.
If the first frame's scenetopic describes the character in a wide shot at the foot of the mountain, and the last frame's scenetopic describes the character in a close-up before the stone platform, Jimeng will understand that the camera is following the character's movement.
Conversely, if the first frame describes the character standing and the last frame describes the character sitting, Jimeng will generate a sitting motion rather than a pan.
This is precisely why a missing image means a missing motion trajectory.
Each pair of first and last frames defines a motion path within a single shot. When both images exist, the path exists, and video generation has clear start and end points.
When one image is missing, the path becomes a one-way guess—the model can only randomly fill in an endpoint, and there is no guarantee it will match the narrative you intend.
BODY:
Therefore, throughout the entire pipeline, every time arcpictask is run, a dedicated check must confirm that both firstpic and secondpic exist and that both file sizes are greater than zero. This is not merely a data-integrity requirement—it is the precondition for whether a motion trajectory can be established at all.