A Practical Checklist for Generating 2,058 First-and-Last Frames in Pairs to Avoid Placeholder Files
With 1,029 shots, each requiring two frames—one first and one last—the entire film comes to 2,058 images total.
This number may seem modest, but in actual workflow, every single image must be generated, stored, and validated simultaneously with its corresponding counterpart. Otherwise, a STCODE.png placeholder will be left in the database.
A placeholder, in this context, is a default filename written into the system to maintain field integrity when an arcpictask task returns only one side of the image pair.
This placeholder file contains no real image data. If any later stage reads its path, that shot cannot be composited into video, because the Jimeng video generator requires both input frames to be actual images. Missing one frame means missing one motion trajectory—without the difference between the first and last frames, there is no way to interpolate the intermediate motion.
Therefore, generating first and last frames in pairs is not a suggestion but a hard validation requirement.
After each batch of arcpictask executions, you must verify against five steps. Any anomaly at any step needs immediate handling—do not defer fixes to the editing phase.
Step one: Before running arcpictask, check that the source images exist.
The source images refer to the character image fmpic and the location image plcpic. These serve as inputs for arcpictask to generate the first and last frames.
If the image paths in the character or location tables are empty, or the files do not exist on the file server, arcpictask will report an error directly.
Therefore, before invoking it, you should query dbvideo_roles and dbvideo_places to ensure that the source image paths are non-empty and that file sizes are greater than zero.
This step filters out roughly twenty percent of generation failures, because in many cases the source image was not fully generated and the task was doomed from the start.
Step two: After invoking arcpictask, immediately query the dbvideo_process table to check whether both records for the current shot appear simultaneously.
A shot theoretically corresponds to two rows: one for the first frame -a, and one for the last frame -b.
The system follows a convention during writes: when a single arcpictask run produces two filenames, both rows are inserted at the same time. There is no case where only one row is inserted.
So if a query returns only one row, it means the other side's image generation did not return a result. In that case, mark the task as failed and rerun arcpictask—do not attempt to manually fill in one image, because both images must come from the same prompt context, and manually patching one would make it difficult to maintain compositional consistency.
Step three: Check whether the secondpic field contains the placeholder value STCODE.png.
BODY:
The placeholder is written when an asynchronous task times out and the server automatically falls back—it does not mean a real file was generated.
The query is straightforward: if the value of the secondpic field contains STCODE.png, the first-and-last frame pair is invalid. Delete that row and rerun the task.
This step directly catches incomplete outputs caused by API rate limiting or network fluctuations.
Step four: On the file server, check the actual file sizes of the -a and -b files.
The paths in the database are just strings. Whether the files actually exist and are intact can only be determined by the file system's metadata.
For each shot, first retrieve the firstpic and secondpic paths, then extract the file sizes separately. If either is smaller than one kilobyte, it is most likely an error file or an empty file.
The standard practice is to write an inspection script that iterates over all process records, outputs a list of files whose sizes fall below the threshold, and reruns arcpictask for the items on that list.
Step five: After confirming no placeholder remains, mark the task as complete.
A shot is considered usable only when both files exist and are non-empty, and secondpic does not contain STCODE.png. Then update the status field of that record from pending to ready.
Only shots with a status of ready can be pulled by the video generation task.
If the status remains pending, even if you manually replace the placeholder with a real image path, you must rescan the sentinel status—otherwise the pipeline will still skip that shot.
A real-world example best illustrates the issue.
During the production of Chapter One, "Five Elements Dragon Banner," while processing shot 244, a batch task called arcpictask to send image generation requests to Volcano Direct. The first frame -a was generated, but the last frame -b did not return due to a channel timeout.
The system wrote the STCODE.png placeholder into the secondpic field.
At the time, no immediate check was performed, and the tasks for the next several hundred shots continued to execute.
By the video compositing stage, the Jimeng API received the first frame for that shot, found that the last frame path pointed to a non-existent placeholder file, and returned an error saying it could not process the request.
The troubleshooting path began with the first record for that shot in the process table. It showed firstpic was normal but secondpic was a placeholder. Next, the file server was checked, confirming the -b file did indeed not exist. The root cause was that arcpictask, upon timeout, did not retry—it simply wrote a placeholder.
The fix was to delete the two original records for that shot and rerun arcpictask. This caused all subsequent tasks to wait for the rerun, wasting about twenty minutes.
BODY:
After that incident, every batch of arcpictask executions is immediately followed by steps two and three, rather than waiting until the entire batch finishes for a single review.
This adjustment significantly reduced the failure rate across all 2,058 images in the book, and in the final film, no shot was interrupted due to placeholder issues.
One more easily overlooked detail deserves emphasis: the pairing of first and last frames applies not only at the file level but also at the prompt level.
arcpictask.taskdes contains both the first-frame description and the last-frame description, and both are submitted to the model within the same prompt request.
If split into two separate requests, the model's understanding of the input image may differ—the first frame might use the character image's front view while the last frame uses a side view, causing shape distortion in the Jimeng interpolation.
Therefore, both files must be generated in a single request.
The system maintains the same task ID within arcpictask. That task outputs two file paths, written into firstpic and secondpic respectively, and validates the file sizes before the task completes.
One request generating one pair is the lowest-cost solution for ensuring visual coherence.
When regenerating after a character change, the pair must be rerun together—you cannot replace just one image, or the character will appear to jump between the first and last frames.
Once all 2,058 images pass inspection, the full video compositing of *The First Avenue* proceeds without obstruction.
Every shot has a clear starting frame and ending frame. Jimeng does not need to guess where the ending should go; it only executes a two-dimensional interpolation from -a to -b.
Though this process may seem like handling minor details, it is the foundational work that ensures a two-hour-and-twenty-minute film does not suffer from visual breaks.
Rather than repairing broken shots in post-production, it is better to hold the line on placeholder checks upfront.
This is also one of the few stages in the entire pipeline that cannot be fully automated, because data anomalies require human intervention. But as long as the five steps are followed, every image generation task is traceable and every contingency is covered.