Three Computers, Eleven Days: The Engineering Breakdown of an AI Film Two Hours and Twenty Minutes Long
The physical parallelism of three computers is the real lever that compressed a two-hour-and-twenty-minute AI film from twenty days down to eleven days.
Running the entire pipeline on a single computer is not impossible, but sequential execution inevitably leaves hardware idle for too long.
The whole workflow was split into three categories of tasks, assigned to three machines: the first ran funx.atctoscene for storyboard generation, the second ran drawrole for character image generation, and the third ran placeaiwords for scene composition.
The three machines were not a simple triple-speed stacking; rather, through the allocation of task queues, heavy workloads from different stages ran concurrently.
The preparation work on the first morning was to input the 93,000-character source text chapter by chapter into dbvideo_article. As soon as a chapter was entered, atctoscene was launched on the first machine immediately, instead of waiting until all sixty-nine chapters were entered before doing storyboards all at once.
This approach of entering and storyboarding simultaneously allowed the first machine to have already processed about forty chapters before the input was complete.
In terms of input and output, the first three days had the most intensive workload.
On the first day, the first 20,000 characters across fifteen chapters were entered, and meanwhile the first machine had already generated 220 storyboards for those fifteen chapters.
On the second day, input continued up to 50,000 characters, and the third machine began initializing placeaiwords. At that point, character images and location images had not yet been produced, but a dry-run test of scene composition had been completed.
By the end of the second day, the total storyboard count reached 511, averaging 14.8 shots per chapter, as expected.
The third day was the most critical. The remaining 43,000 characters were fully entered, the first machine never stopped, and it ultimately produced 1,029 shots corresponding to all sixty-nine chapters.
By then, the drawrole task queue on the second machine had accumulated a backlog of 1,029 character image requests, and the third machine's placeaiwords was also waiting for character images and location images to be in place.
On the night of the third day, a batch script was arranged so that the second machine automatically wrote the character images generated by drawrole directly into dbvideo_roles, while the third machine synchronously generated location images, preparing for the intensive image generation that followed.
The middle five days were the peak of parallelism.
Starting on the fourth day, all three computers ran at full load.
The second machine handled drawrole, with each call using the Volcengine synchronous direct invocation interface. The measured time for a single character image was 2.8 seconds; adding network latency and queueing, each character image averaged 4.5 seconds.
Because there were 1,029 shots, each requiring at least one character image, total character image generation time was about 4,630 seconds. Adding the loss from three retry attempts after failures, the time consumed was 1.5 hours.
TITLE:
BODY:
The third machine ran the empty-branch of placeaiwords (the "rolex" branch) to generate location images, averaging 6.2 seconds per location image. Handling 1,029 locations in total, and accounting for duplicate locations across titles, there were 800 distinct locations requiring image generation, taking 1 hour and 24 minutes in total.
These two tasks could be completed within the same hour, but headroom had to be reserved for parallel conflicts.
On the fourth day, 400 character images and 300 location images were actually completed, and the task queues on both the second and third machines were consumed down to roughly half.
On the fifth day, all remaining character images and location images were completed. The total character image count reached 1,029, and the total location image count was 800.
During this process, the first machine had gone idle—only the idempotence lock check in atctoscene remained, which was negligible—so the first machine was reassigned as an auxiliary to the third machine, running a pre-processing script for scene composition that pre-rendered the template for the scenetopic image-to-image composition keywords.
On the night of the fifth day, the scene composition phase began.
Scene composition required both the character image and the location image to exist. For each storyboard record, the fmpic field was filled with the character image path, and the plcpic field was filled with the location image path. When both were non-empty, the third machine executed the human-present branch of placeaiwords.
For each shot generated, the image-to-image API was called once, taking two base images as input and appending the scenetopic composition keywords, outputting two images: the first-frame-a and the last-frame-b.
Because each shot required two result images, a total of 1,029 multiplied by 2, equaling 2,058 first/last-frame images had to be generated.
Each first/last-frame composite took 7.8 seconds. Accounting for queue waiting and network fluctuation, 5.5 frames were processed per minute, so 2,058 frames required 374 minutes, approximately 6.2 hours.
This meant a single machine had to run continuously for over six hours to complete the scene composition. To improve fault tolerance, on the night of the fifth day the third machine ran continuously, while the second machine temporarily shifted to auxiliary scanning and verification, checking whether each pair of first/last frames was generated as a pair, preventing cases where the secondpic field was left with the STCODE.png placeholder.
From day six to day eight, the division of labor among the three machines changed as follows: the second machine was dedicated to verifying the integrity of first/last frame pairs, the third machine continued composing the remaining scenes, and the first machine served as a backup—once the third machine's task queue backlog exceeded a threshold, it immediately took over part of the scene composition tasks.
By the afternoon of day eight, all 2,058 first/last frames were fully generated, and the -a and -b file counts on the file server were exactly equal, with no placeholder remnants.
Video composition over the last three days became the new bottleneck.
TITLE:
BODY:
The first and last frames were fed into the Jimeng video generator, with each video clip driven by that shot's first frame and last frame, producing a short video segment.
997 shots with visible content generated 997 segments; the remaining 32 shots, lacking characters or locations, were filtered out as empty shots, supplemented only with static frames.
On the Jimeng platform, the generation speed was approximately 1.5 seconds of video per second of runtime. Each segment was 4 to 6 seconds long, so each video segment took 6 to 9 seconds.
For 1,000 segments, at an average of 7.5 seconds per segment, the total time was 7,500 seconds, or 2.08 hours.
However, these segments could not be parallelized without limit. Jimeng restricts concurrent channels by UID, allowing a maximum of five simultaneous tasks per account.
As a result, actual video generation took two and a half days: eight hours each on days nine and ten, with the remaining segments completed on the morning of day eleven.
After each segment was generated, the task queue wrote that segment's Jimeng task ID into dbvideo_process, but the vdurl field remained empty because the video files were not stored locally—only the external credential was retained.
On the afternoon of day eleven, all clips were stitched into a single complete video, transcoded to 2560x1440 at 30fps with H.264 encoding and a 7.7Mbps bitrate, with the audio track mixed as AAC stereo, finally packaged into a finished film of two hours and twenty minutes.
Looking at the log tables, the daily output was very clear: day one, six chapters entered plus 220 storyboard shots; day two, nine chapters plus 291 shots; day three, 54 chapters plus 518 shots; days four to five, 1,829 first/last frames generated; days six to eight, first/last frames completed with detail corrections; days nine to eleven, video segments generated, composited, and packaged.
The key here was not the hardware performance of the three computers themselves, but the allocation logic of the task queues.
Once atctoscene finished a chapter, it never reran that chapter, so the first machine quickly became idle, and its compute power could be reassigned to other stages.
drawrole and placeaiwords were bound to the second and third machines respectively, but during the scene composition phase, the idle first machine was dynamically pulled in to handle part of the storyboard composition in parallel.
This practice of reassigning task ownership at any time kept each machine's utilization rate consistently close to 100%.
If the traditional phased approach had been followed—first entering all the text, then generating all character images, then all location images, then all scenes, and finally all videos—it would have taken at least eighteen days, because many machines would sit completely idle while waiting for the previous stage to finish.
TITLE:
BODY:
The approach here treats the entire production pipeline as a task pool, where each machine grabs executable tasks from the pool. Output from the previous stage immediately becomes input for the next stage—as soon as the input conditions are met, the downstream stage starts work right away, with no idle gap in between.
This is the essence of multi-machine parallelism: it's not about splitting tasks in half and each doing a portion, but about making tasks flow like an assembly line, instantly passing from one machine to the next. Every machine races to claim the next task it can execute immediately, rather than sitting idle waiting for a signal that belongs to its own phase.