How Three Computers Finish a Film in 11 Days: Task Distribution Explained

Three computers finishing a film in eleven days—here's how the tasks are distributed: through database row locking plus a state machine. All three computers watch the same dbvideo_process storyboard table simultaneously. Whoever grabs an unprocessed record does the work, then changes its status so no one else touches it. That's all there is to it—no complex scheduling center, no manual dispatch. Based on actual measurements from "The First Avenue," 1,029 shots were claimed and processed this way by three machines. The eleven-day turnaround isn't magic; it's turning tasks into an enumerable grab pool. Where do tasks come from? Not from hand-writing them one by one. In the Yuncao Academy system, you first enter the book title to generate a bookcode, then enter the body text chapter by chapter, then run the funx.atctoscene function, which automatically splits the 93,000-character novel into 1,029 storyboards. Each storyboard is one row in the dbvideo_process table. That row contains all the information: scene, character, location, prompt template, and status field. Initially, all status fields are uniformly set to pending, forming a task pool. The three computers connect to the same database, so they all see the same pool. How does a computer know which task to grab? It executes a query to filter records with status pending, then picks one or more and attempts to change their status to processing. This status-change action is the key—if two computers query the same record simultaneously, whoever executes the update first locks the status. The other computer's update returns zero rows affected, signaling that the record has been taken, so it automatically moves on to the next one. This mechanism is database row locking, also known as optimistic locking or state machine transition. Based on experience, each computer can grab ten or twenty records at a time, depending on your API throughput. The material mentions that the large model channel is bound to a uid via CRTOR, meaning each machine uses its own fixed account to call the generation API, preventing channel contention and rate limiting. What if two machines grab the same task? This is what beginners worry about most. "I grabbed this record, but another machine grabbed it too. Won't we generate the same shot twice and waste the work?" No, you won't. Because every record in the dbvideo_process table has a unique constraint—a primary key or business unique key—and the status update isn't simply "set status = processing"; it carries a precondition: update dbvideo_process set status = processing where id = some_id and status = pending. If that where condition fails—meaning someone else has already changed the record—the update affects zero rows, and the program knows to abandon it. Additionally, the material specifically emphasizes that atctoscene has an idempotency lock and cannot be re-run. This means that during the book-splitting stage, if a chapter has already been processed once, a second attempt is blocked by the lock and will not generate duplicate storyboards. But during the storyboard image generation stage, the grab mechanism itself ensures the same shot is handled by only one machine—no duplication exists. Why is it so much faster? Let's do the math: one computer running through all 1,029 shots sequentially, assuming each shot from image API call to video generation takes an average of ten minutes, totals 10,290 minutes, or about seven days around the clock. Adding retries for failed image generation and rate-limit waits, the actual time exceeds twenty days. With three computers in parallel, each handles only 343 shots. At the same ten minutes per shot, that's about 57 hours per machine, and with daily restarts and manual adjustments, eleven days is more than enough. The material states it plainly: the essence of this design isn't the prompts—it's breaking a film into enumerable, re-runnable, replaceable records. Change an actor by editing one row, adjust a shot without redoing everything, and parallel processing simply means grabbing tasks. So three computers aren't three times the efficiency of one; they're close to three times, because you eliminate massive amounts of queue waiting. How do you actually get started? Here's a concrete set of steps. Step one: enter your film chapter by chapter into dbvideo_article, run atctoscene to generate dbvideo_process records, and ensure the table has at least a thousand pending storyboards. Step two: deploy the same client program on all three computers. This program does no complex scheduling—only one thing: loop to query pending records, grab one and change its status, process it. Step three: assign different CRTOR-bound uids to each computer—say, computer A uses uid1, computer B uses uid2, computer C uses uid3—to prevent queueing when calling the same large model API. Step four: after startup, observe the status distribution in the dbvideo_process table. If one computer grabs more tasks than others, don't worry. As long as overall progress is moving, it's fine. Based on experience, this design has low network requirements; as long as the three computers can reach the same database, even one in Changsha and one in Beijing can run in parallel. How much does it cost in money and time? Money goes mainly to large model API calls. Character images use Volcano Engine synchronous direct calls, scene compositing uses image-to-image, and video generation uses Jimeng. Each shot needs two images plus one video. Based on the material's figures—2,058 first-and-last frames and 1,029 videos—the cost per shot is roughly three to five yuan, putting total material cost at 3,000 to 6,000 yuan. In terms of time, if the three computers have similar specs and the network holds up, eleven days is the measured figure. With only two computers, expect fifteen to sixteen days based on experience; with one, more than thirty days. The longer it runs, the more prone you are to fatigue and errors, so start with at least two—three is optimal. What step do beginners most often get wrong? There are three. First, they fail to create an index on the status field. When three computers simultaneously query pending records, the absence of an index locks the entire table, making it slower than a single machine. Second, they forget the update precondition in the program, directly running update set status = processing where id = some_id without the status = pending condition. As a result, two machines grab the same record, both think they own it, and duplicate generation wastes money. Third, they set no timeout or retry limit when calling the video generation API. One API call hangs, and all three machines stall at the same spot—eleven days won't be enough. Based on experience, the correct approach is: before processing a record, each machine first sets a globally unique transaction ID—say, taskid. Whoever acquires the taskid first processes it. After completion, write the result into the vdurl field. However, the material notes that vdurl is empty across the entire film because videos exist only in Jimeng's cloud, so just change the processing status to complete. Are there counterexamples? Yes. Someone tried to save effort by skipping the state-machine grab mechanism and instead statically split the 1,029 shots into three equal parts: computer A handles 1 to 343, computer B handles 344 to 686, computer C handles 687 to 1029. It turned out computer A hit 20 consecutive failures with retries, while computer C finished early and sat idle. Computer A kept working overtime, and the total time ended up even longer than a single machine. That's the downside of static partitioning—one slow task drags down the whole line. Another person used two computers, but both programs called the large model API with the same uid. The result: too many API errors, rate limiting kicked in, and every shot required a five-minute cooling wait—slower than one machine. So CRTOR-bound uids are no decoration; each machine must have its own identity. What does this mean for you? I'll give you the most practical action: don't think about 1,029 shots yet. Break your current task into a hundred records—say, a hundred images or a hundred short clips—insert them into the dbvideo_process table with status fields, then fire up two computers with two different uids and have them race to grab those hundred records. See if you can finish within your expected time. Based on experience, you'll find dynamic grabbing is far less hassle than manual assignment. And if one machine dies, the other automatically picks up its unfinished work—that's the power of enumerable records plus a state machine. In other words, one person making an AI film doesn't rely on one computer pulling all-nighters; it relies on turning every task into a row in the database. Whoever processes it, once the status changes, the entire pipeline advances one notch. Three computers producing a two-hour-and-twenty-minute film in eleven days—that's not a miracle; it's the inevitable result of engineering.