Three Computers, Eleven Days: A Full Breakdown of Producing a Two-Hour Film
Three computers: one handles the database and scheduling hub, one handles high-concurrency calls for image generation and video generation tasks, and one is dedicated to article entry and storyboard splitting.
Eleven days later, a two-hour-and-twenty-minute AI film titled "The First Avenue" was delivered in full.
The prerequisite for this output is that there is no beyond-spec hardware—all three machines are ordinary consumer-grade PCs, yet throughout the entire process, no machine ran at full load for extended periods, and no task sat queued due to insufficient resources.
The final film specs are 2560×1440 resolution, 30 frames per second, H.264 encoding, 7.7 Mbps bitrate, AAC stereo audio, with spoken segments accounting for 87.2% of the runtime.
In traditional film production, even for animation, this result would require a team of dozens working for months—yet this production relied only on three computers and a system-engineering decomposition methodology called Yuncao Academy.
The first computer serves as the database service and task distribution hub.
It runs a MySQL instance. All business tables are prefixed with dbvideo_, including dbvideo_bookidx, which records the primary key index for books; dbvideo_article, which stores the full original text; dbvideo_roles, which stores character information; dbvideo_places, which stores per-shot location descriptions; dbvideo_process, which stores storyboard records; and dbvideo_arcpictask, which stores image generation task statuses.
The core value of this machine is that all other machines access its database through a world resource manager. It does not perform any heavy computation itself—it only handles storage and responds to query requests.
The second machine is dedicated to image generation and video generation.
It runs a client program that continuously polls the image generation task table in the database. When it finds a record with a pending status, it calls the drawrole or placeaiwords endpoint.
Since image generation is CPU- and GPU-intensive, but this machine is sufficient because it keeps tasks granular enough—each shot only generates two images, the first frame and the last frame, with each single call taking no more than ten seconds—the machine load stays within a healthy range at all times.
The third machine handles manuscript entry and storyboard splitting.
It runs a data entry tool. The operator uses this machine to paste the 93,000-word original text chapter by chapter into the dbvideo_article table, then calls the funx.atctoscene function to break each chapter into characters and locations and generate storyboard records.
On the eleven-day timeline, days one through three are the most tedious entry phase.
BODY:
Each day, approximately 31,000 characters are entered, and all 69 chapters are completed in sync.
During entry, note that each chapter must correspond to a unique articlecode, and the atctype field must be filled in correctly. The value of atctype directly determines the art style type for that chapter. In the novel, four chapters carry distinct style tendencies: Five-Element Dragon Banner, Miao Eight-Character Super Body, Miao Eight-Trigram Super Body, and Fake-Beyond Super Body. The corresponding atctype values are, in order, likely gz for costume drama, xd for modern, dm for anime, and xs for realism.
Day four enters the chapter-splitting phase.
The operator opens the splitting tool on the third machine and calls the funx.atctoscene function for each chapter. This function reads the main text from dbvideo_article, analyzes the semantics, automatically identifies character names and location names, and writes them into dbvideo_roles and dbvideo_places.
It also generates storyboard records in the dbvideo_process table. Each storyboard record includes shot number, referenced characters, referenced locations, shot description, prompt template, and other information.
Note that the atctoscene function carries an idempotent lock, meaning the same articlecode can only be split once; repeated calls are refused directly.
So on day four, only the first thirty chapters are split. Day five continues with the remaining thirty-nine chapters. During this period, two chapters require manual intervention because characters appear under alias names—the operator manually adds alias mappings in dbvideo_roles and then re-splits those chapters.
Days six through eight are the image generation phase.
All three machines work simultaneously. The first machine continues providing database services. The second machine batch-retrieves all shot records from dbvideo_process that need first and last frame generation.
For character images, the drawrole function is used. It accepts the character code and style parameters and directly calls Volcano Engine's image generation endpoint in sync mode, which returns a static image of the character.
For location images, you first need to check whether the shot involves any characters.
When a location has no characters present, it goes through the empty rolex branch of the placeaiwords function—that is, pure text-to-image mode—where the location background image is generated directly from the location description text.
If the location involves characters with presets, it goes through the character-present branch, requiring an additional scenetopic field to be passed. The system then performs image-to-image synthesis using the character image fmpic and the location image plcpic to generate a scene image containing both the character and the location.
BODY:
Each shot must generate two images—the first frame named with the suffix `-a` and the last frame named with the suffix `-b`. This rule cannot be skipped, otherwise the `secondpic` field will be left with a residual `STCODE.png` placeholder, causing the video generation phase to reference a file that does not exist.
By the end of day eight, all 1,029 shots had their first and last frames completed and stored in the database's image path fields.
Days nine and ten are the video generation phase.
The second machine continues calling Jimeng's video generation endpoint, reading the `process.aiwords` prompt for each shot from the `dbvideo_process` table. This prompt follows an eight-segment skeleton structure, arranged in order as: character information, lip-sync consistency, accent and tone, camera technique, scene location, on-screen action, aspect ratio, clarity, and duration.
Among the eight segments, only three positions are variable: the character name, the scene location, and the on-screen action description. The remaining segments are automatically generated by the system based on the `imgstyle` field.
Video generation tasks are asynchronous, so the second machine must poll the task status. Once generation completes, it records the `taskid` returned by Jimeng into the `taskid` field of the vdatabase.
Note that the `vdurl` field in the database remains empty at all times, because the Jimeng endpoint does not return a public URL. The finished videos exist only in Jimeng's cloud, and cannot be played locally—you must manually log into Jimeng's backend to download them.
Day eleven is the verification phase.
The operator stitches the downloaded video segments together in storyboard order into the complete film, while checking that audio is aligned and confirming that spoken segments account for 87.2% of the runtime, with no shots suffering from silence issues.
Finally, a unified check is performed to confirm that first and last frames exist as pairs, and that no storyboard is missing character references or location references.
The key to parallel acceleration across the three machines lies in non-overlapping division of labor.
The first machine does not execute computation tasks, so it never slows down the other two due to database congestion.
The second machine focuses solely on image generation and video generation. Its task scheduling is based on status fields in the database tables, and each time it fetches a pending task, it uses SQL statements with conditional locks to ensure the same task is only picked up by one machine.
The third machine focuses on text splitting and does not participate in any image or video computation.
The biggest advantage of this parallel strategy is the avoidance of database lock contention.
For example, while the second machine is reading image generation tasks, the third machine is not simultaneously modifying the structure of the `dbvideo_process` table, because the splitting phase has already ended and no new storyboard records will be inserted.
Even if occasional data modification is needed, it happens in different tables, so no table-level lock contention arises.
BODY:
More importantly, the idempotent lock of the `atctoscene` function ensures that even if the second machine mistakenly calls it, no duplicate storyboard records are created, so the database state remains consistent at all times.
If this AI film were produced using traditional manual methods, the first step would be script breakdown. A professional screenwriter would need at least two weeks to break a 93,000-word novel into 1,029 storyboards.
Then comes character and scene design. A concept artist would need at least three days to design the main character visuals, another five days for scene concept design, and character-scene matching would require repeated adjustments.
Next is per-shot image generation. If one person manually generates first and last frames using tools like Midjourney, even at just thirty seconds per shot for parameter tuning and prompt writing, 1,029 shots would take a full eight and a half hours of nonstop work—meaning the actual working cycle would span at least three days.
Finally, there is per-shot video generation and post-editing. Manual editing alone would require a week of continuous work.
Adding in communication and rework, the traditional approach would take at least six weeks and require collaboration between two to three skilled roles.
Yuncao Academy's engineering-based decomposition compresses this cycle to eleven days. The core difference is that all work is transformed into database records, turning the creation of every film into the filling of three tables: the book index table for the title, the article table for the original text, and the storyboard table for automatically generated records.
After that, image generation and video tasks are merely batch processing of these records.
Swapping an actor requires only modifying one row in the `dbvideo_roles` table; adjusting a shot does not require redoing any other resources; and multi-machine parallelism is essentially competing for the same batch of task records.
One person can complete this film not because he is an all-around genius, but because the system decomposes every workflow into enumerable, rerunnable, replaceable data operations.