Thirty-Seven Characters: Data Modeling Behind a Film

A two-hour-and-twenty-minute film—how much metadata does it ultimately compress into in a database? For *First Avenue*, the answer is: one book-title code, sixty-nine chapters of full text, several character records, several location records, and 1,029 storyboard records. What truly drives the entire film's generation is not a lengthy storyboard script, not hundreds of pages of director's notes, but a highly compressed data model. Adding up all the necessary configuration fields, the core driving data for each storyboard record amounts to only around thirty-seven characters: one character ID, one location ID, one frame-action description, and one style-field value. These thirty-seven characters indeed carry the generation instructions for every second of imagery in the film. This compression rate is no accident—it is the natural result of the recursive modeling philosophy embedded in the three phrases "name first, body second, storyboard third." The entire system uses extremely few metadata fields to translate what was once an incomputable filmmaking process into row-and-column-precise database operations.

The first phrase, "name first," corresponds to a single row in `dbvideo_bookidx`, whose core field is only `bookcode`. This code is globally unique in the database. It does not need to store any plot synopsis, character biographies, or art-style descriptions—it is merely a key, a root node pointing to all subsequent data. But this single key already encapsulates the ownership relationship and version boundary of the entire film. Imagine: without this root, the sixty-nine chapters and 1,029 shots would scatter across various tables, with no way to distinguish which belong to *First Avenue* and which belong to another work. `bookcode` is an identifier, but it is also a form of compression: at the cost of one string, it locks in the entire universe boundary of the film. Within that boundary, all other tables associate with it through foreign keys. When querying the database, a simple `where bookcode equals some value` retrieves every generation resource for an entire film. In the actual *First Avenue* project, the `bookidx` table holds just one row, yet it becomes the sole ancestor shared by all 1,029 shots.

The second phrase, "body second," corresponds to the sixty-nine chapter records in `dbvideo_article`. Each chapter occupies one row, storing the chapter number, title, original text, and the `atctype` style marker. What is stored here is not the generation prompt for the film, but the unprocessed novel text itself. From the standpoint of information density, 93,000 Chinese characters is a substantial amount of information, but the system slices it into sixty-nine independent units, each carrying the same field pattern. In most cases, the system does not need to read the full text word by word—it only needs to pass a specific chapter's text when invoking `atctoscene`, letting the function parse the character and location entities appearing in that chapter. Thus, the metadata burden on the `article` table is far lighter than one might expect. Beyond the body text, each chapter carries only a few auxiliary fields, such as chapter number, title, and style marker. The per-chapter information density is 1/69th of the full text, yet within each chapter are hundreds or thousands of characters of detail, all compressed into a text field. This compression is not merely raw string storage; it hands semantic information to downstream parsing functions, which extract the structured data the system actually needs. One could say the `article` layer is the heaviest part of the entire data chain, but it is also the most primitive input—not reused repeatedly, serving only as raw material for the decomposition function.

The third phrase, "storyboard third," is the most striking stage of compression efficiency. The system invokes `funx.atctoscene` to process each chapter's text, automatically extracting character and location entities into `dbvideo_roles` and `dbvideo_places` respectively, then, following the formula that a scene equals a character plus a location, creates one storyboard record in `dbvideo_process` for each combination. The key point is that each record in the `process` table does not duplicate the full descriptions of the character and location—it only stores their ID references. This means the metadata a shot truly needs is: the primary key of one row in the character table, the primary key of one row in the location table, plus a string field indicating the frame action. Take a typical shot from *First Avenue* as an example: the character ID points to the "protagonist" record in `roles`, the location ID points to the "Dragon Flag Hall" record in `places`, and the action description is a single sentence—"The protagonist stands in the center of Dragon Flag Hall, drawing his sword with his right hand." The style value `gz` indicates the period-costume style, but that style value is also stored as a foreign key referencing a chapter attribute rather than as an independent column. Thus, this `process` record stores fewer than a hundred characters, yet it drives the entire pipeline for that shot—character image generation, location image generation, scene synthesis, and video generation.

Extending this logic to the entire film: after the sixty-nine chapters of `article` text are parsed, there is no fixed upper limit on how many characters and locations are produced, but ultimately they are all reduced to a finite number of character rows plus location rows, which then combine into 1,029 `process` records. This number is the total shot count of the film and the direct mapping of its runtime. A two-hour-and-twenty-minute film equals roughly 8,000 seconds; divided by the average effective duration of approximately four to five seconds per shot, it corresponds exactly to 1,029 records. One record represents one shot; the character ID and location ID in that record point to two rows of descriptions, and those two descriptions, combined with the action string, construct the complete visual blueprint for that shot. From the perspective of high-density metadata, this is not merely a compression ratio—it is semantic compression. All descriptions of the protagonist's appearance in the text are compressed into one row of fields in `roles`; location descriptions are compressed into one row of fields in `places`; and the narrative evolution along the time axis is compressed into a 1,029-row timestamp sequence in `process`. The database does not store the imagery of every frame; it stores only the constituent elements of each shot, and everything else is expanded on demand by the generative model.

This design saves computational resources decisively. If the system adopted a traditional keyframe approach, attempting to store independent descriptive text for every second of imagery, a film would require at least hundreds of independent records, and each record's description would still need to remain stylistically consistent—the manual maintenance cost would be astronomical. With recursive decomposition, the system only needs to maintain three types of tables—characters, locations, and storyboards—whose total record count does not exceed 1,200 rows. In a mainstream relational database, this is an extremely small table; its entire contents amount to less than 100KB. With less than 100KB of metadata, the system drives 1,029 video tasks outside the database, each of which outputs a 2560x1440-resolution video file, for a total output reaching several gigabytes. The volume ratio between metadata and generated content exceeds 10,000-fold. This means most of the system's information lives in well-designed model parameters, while the database only needs to emit a series of short, precise instructions to awaken the corresponding generation capabilities within the model. The entire system is a device that triggers maximum visual output with minimal text. The highest achievement of such a device is to compress a 93,000-character source novel into an index, then use that index to invoke billions of parameters in an AI model, restoring text into flowing images.

The cost of compression lies in the safety margin. If a single character ID is written incorrectly, all shots involving that character in the film will be corrupted; if a location's description is incomplete, all composite images involving that location will show defects. Therefore, the reliability of this system does not depend on the accumulation of field count, but on the strictness of data relationships and the correctness of each row's content. During the eleven-day production of *First Avenue*, the system maintained an extreme standard of data hygiene: every row, once written, was protected by idempotency locks, disallowing duplicate execution; every first and last frame was guaranteed to be generated as a pair, disallowing single placeholder images. It is precisely this extreme strictness toward metadata quality that makes high compression rates viable. Conversely, if the data model itself lacked this compression capability and instead preserved every prompt and every parameter combination in exhaustive detail, the database volume would expand more than tenfold, maintenance costs would skyrocket, and the time spent inspecting data item by item would render meaningless the output efficiency of one person with three computers.

When the generation information of a film is distilled into 1,029 rows of `process` records, the database is no longer a pile of accumulated data—it becomes a precisely ground convex lens, focusing the smallest input into a grand cinematic output. This is the core law behind all generative AI systems: the denser the metadata, the greater the generation potential it unlocks, and the more likely it becomes that the process can be industrialized at scale.