How a Storyboard Table of 1,029 Shots Became the Core Production Backbone in 11 Days

What does a two-hour-and-twenty-minute film mean in a traditional production workflow? Suppose you are an independent creator. You need to find actors, rent locations, assemble a camera crew, manage equipment, and handle editing and sound design. Even under the best circumstances, filming a single scene takes at least half a day, and the full film requires shooting dozens of scenes at minimum. An eleven-day schedule would barely cover storyboard drawing and part of pre-production. But the Yuncao Academy system, using three computers and the effort of one person, produced the entire film within eleven days. The key is not hardware performance or manual speed, but the fact that the dbvideo_process storyboard table defines the core production relationship of the entire system. This table transforms a film from an indivisible giant into 1,029 micro-units. Each unit is an independent record that can be individually executed, individually modified, and individually re-run, and every unit shares the same processing pipeline. You are no longer making a film; you are managing the state transitions of roughly ten thousand tasks in a database. The dbvideo_process table sits at the absolute hub of the system. Every row links via foreign keys to the character table, location table, image generation task table, and video task table. Specifically, a process record contains scene_code, article_id, rolex (character reference), placecode (location reference), action (action description), and most importantly the status field. This status field is not a simple done-or-not flag but a staged state machine. At initial creation, status is 0, meaning the storyboard has been generated but no visual tasks have started. When the arcpictask creates first-frame and last-frame image generation tasks for this shot, status changes to 1, meaning awaiting image generation. When image generation completes and the system updates the key fields, status changes to 2, meaning images are done and awaiting video generation. Subsequently, placeaiwords composes the composite image and calls Jimeng video generation, changing status to 3, meaning video is being generated. Finally, when Jimeng returns the task ID and it is written into the vdurl field, status changes to 4, and the storyboard is declared complete. The creator can query the status value at any time to understand the overall progress of the film, and can also pinpoint exactly which processing stage a particular shot is in. In the four chapters that make up the finished "The First Avenue," the Five Elements Dragon Flag chapter contains 360 storyboards, the Miaobazi Super Body chapter 245, the Miaobagua Super Body chapter 220, and the Jiabuyi Super Body chapter 204, totaling 1,029 storyboards. The splitting tasks for the 69 chapters were not executed sequentially chapter by chapter but distributed across three computers with simultaneous scheduling. For example, the first computer handled chapters 1 through 23, the second handled chapters 24 through 46, and the third handled the remaining chapters. When each computer calls atctoscene, the same chapter is split only once due to the idempotency lock, but different chapters can run completely in parallel. In this way, a splitting job that would have taken about 110 minutes on a single machine was compressed to about 40 minutes. After splitting, the storyboard table produced 1,029 rows, which then became the downstream data source for image generation and video tasks. The three computers claimed tasks in the arcpictask table to generate first-frame and last-frame images, then composed video prompts and called Jimeng. The entire flow strictly advances each storyboard independently, and each computer only takes on a workload matching its processing capacity. Because each process record is the smallest production unit, the creator gains unprecedented flexibility. Suppose you are in the middle of production and discover that Lin Xuan's clothing color in Five Elements Dragon Flag does not fit the overall color palette. In a traditional workflow, you would need to redesign the character, reshoot all related shots, and perform color grading again. But in the storyboard table model, you only need to modify one field in dbvideo_roles, changing Lin Xuan's attire from indigo blue to ink blue. The system automatically syncs the character description across all storyboard records referencing that character. Then you simply reset the corresponding arcpictask and video task statuses to pending, and the three computers will re-execute the image generation and video generation for the affected shots. You do not need to redo any unrelated shots, and it will not affect the normal progress of other characters. Likewise, if you are unsatisfied with an action in a particular shot, you only need to update the action field in that row of the process table, reset it to pending, and the system will re-run starting from that shot's image generation without touching the preceding or following shots. This replaceability is entirely unimaginable in traditional film shooting. Parallel processing dramatically shortens total production time because there are no dependency chains between tasks. During image generation, the three computers each handle different groups of tasks by their prefixes. For example, PC-1 handles the first one hundred shots of Five Elements Dragon Flag, PC-2 handles the following shots, and PC-3 handles shots from other chapters. Processing a thousand unrelated tasks simultaneously is far faster than doing them sequentially. In fact, during the image generation phase, the three computers took about ten hours to process 2,058 images, averaging about 17.5 seconds per image. If run serially on a single machine, the total time would exceed thirty hours. The video generation phase does not consume local compute resources but does require calling the Jimeng cloud API. Each shot takes approximately thirty seconds to two minutes of queue time. When three computers call different task IDs simultaneously, the queue times overlap. The entire video generation process lasts about three days, while a single machine running serially would need at least seven days. In parallel operation, each computer only waits for its own task queue's responses, greatly reducing idle time. Furthermore, the storyboard table design eliminates the reshoot disaster of traditional filmmaking. Suppose during final review you find that in Chapter 3, Shot 8, Liu Ruyan's sword-swing direction is wrong. With traditional editing, you might manually adjust the frame or accept the error. But in the storyboard table model, you only need to modify the sword-swing direction in the action field, roll the shot's status back to initial, and the system will generate new first-frame and last-frame images and re-composite the video. Only this single shot is affected; none of the other shots from that shooting session need to be redone. You also do not need to rewrite the entire script prompt, because the rolex and placecode stored in the storyboard table automatically carry in the corresponding character description and scene description. This precise control over the smallest production unit means a two-hour-and-twenty-minute film can, in theory, undergo infinite local corrections like code debugging without collapsing the entire project. In the end, the deepest idea in this entire design is dividing a film from an indivisible whole into independently processable micro-tasks. Each shot becomes a row in the database with its own state, dependencies, and outputs. The creator's entire job becomes managing the state transitions of those 1,029 rows, ensuring every record completes its journey from text to pixels on schedule. The splitting of 69 chapters, the drawing of 2,058 images, and the compositing of 1,029 video segments are all organically connected through this storyboard table, forming an assembly-line-like production collaboration. This is why producing a feature film in eleven days is effortless: when a film is a thousand parallel small tasks, the bottleneck of time and manpower is no longer the production craft itself, but simply the upper limits of processor throughput and API call frequency.