The Engineering Truth Behind a 2-Hour-20-Minute Film with All vdurl Fields Empty
When you finish watching a 2-hour-20-minute AI-generated film, then open its database, search the vdurl field, and find that all 1,029 records are empty, you would naturally assume the film was never successfully generated.
But the opposite is true. The final cut has played in full, with stable quality at 2560x1440 resolution, 30 frames per second, H.264 encoding, and a measured average bitrate of 7.7Mbps.
Behind this counterintuitive phenomenon lies a deliberate design decision in how this system stores video: video files never land on its own servers. The database only holds connection credentials to an external video service, and the vdurl field was abandoned from the very beginning.
The entire video generation pipeline is built around this principle. Understanding this is key to seeing why the whole film plays smoothly despite having no real video addresses stored.
Let us trace the call chain first.
A shot starts from the process table, carrying the paths of the first frame -a and the last frame -b, and submits them to the Jimeng video generation API.
Jimeng does not return a video file immediately upon receiving the request. Instead, it returns a task ID, which is written into the taskid field of the process table.
Video generation is asynchronous and typically takes anywhere from tens of seconds to several minutes. So the system does not block and wait; it enters a polling state.
Every few seconds, it queries Jimeng's task status endpoint to check whether the task is complete.
When the status changes to success, Jimeng returns a video playback link. But this link does not point to a downloadable MP4 file—it points to a playback URL with authentication parameters, and this URL has an expiration time, usually ranging from a few hours to a day.
Once the system receives this playback URL, it temporarily writes it into memory or a log table to confirm the generation succeeded, then moves on to the next shot.
The key point is that the system does not write this URL into the persistent vdurl field.
Because such URLs are too short-lived, storing them is meaningless—once expired, they cannot be used to retrieve the source again.
So the vdurl field has remained reserved in the table structure, empty by default, with no plan to populate it from the outset.
Why store video files on the external cloud side instead of downloading them locally?
The direct reason is storage pressure.
A 2-hour-20-minute final film, calculated at 2560x1440 resolution, 30 fps, and 7.7Mbps bitrate, comes to approximately 8.1GB.
If all 1,029 shots generate individual video clips, with each clip averaging six seconds, then all clips combined total about 6,180 seconds, with the total data volume reaching 8.1GB.
BODY:
Adding in the temporary files generated by failed reruns, the server would need at least 30GB of spare storage, not to mention working directories for video stitching, audio mixing, and other tasks.
For a lightweight, single-operator server, this storage cost doubles with each additional film. When multiple films run in parallel, disk space gets exhausted quickly.
With Jimeng's cloud-side generation, however, the video files are stored directly in Jimeng's object storage. The local server retains no actual video content—only a task ID for log auditing.
This way, local storage carries only image files. With each image at a few megabytes, the 2,058 first-and-last frames, plus character images and location images, bring total capacity to under 4GB.
By comparison, the design of not storing video locally saves at least 7 times the storage space.
But this also introduces the risk of relying on an external service.
If Jimeng's service crashes or links expire, there is no backup in the database, and the video files can no longer be retrieved.
More importantly, you cannot validate video integrity the way you would with local files—you can only depend on the task status returned by Jimeng.
So, are there three alternative methods to verify whether a video was actually generated successfully?
The first method is to check whether the taskid field in the database is non-empty and correctly formatted.
After creating a task, Jimeng returns a long string ID. If this ID exists and can be looked up in the Jimeng console with a corresponding task record, at least the video generation request has been received.
But task receipt does not equal generation success, so a second method is needed: poll Jimeng's query endpoint and confirm the returned status value is success rather than created or failed.
One thing to note here: when the status is success, the returned playback link—though expired—was valid at the moment of generation.
You can open this playback link in a browser session and visit it once to confirm it returns a video stream rather than an error message.
The third method is regular sampling.
After the full batch of shots is generated, randomly select five shots, resubmit a Jimeng query for each, obtain a valid playback link, then use a tool to download the MP4 from that link and check whether the file size exceeds the expected value of bitrate multiplied by duration.
This sampling approach can, to some extent, compensate for the blind spot of having no local files. While it cannot guarantee all shots are valid, it can catch systemic generation failures—such as full-scale API timeouts or abnormal model weights.
This entire design also brings one clear benefit: the parallelism of video generation tasks is greatly enhanced.
Because the system no longer waits for video files to download locally, it submits the first-and-last frames, immediately submits the next shot's generation request, and simultaneously polls the previous shot's status.
BODY:
This asynchronous channel allows three computers to drive multiple tasks simultaneously, with each machine running several worker threads, and each worker holding a distinct CRTOR uid.
The large-model channel binds uid to CRTOR, ensuring that calls between threads never mix model configurations.
The storyboard tasks for all sixty-nine chapters were completed in eleven days, thanks precisely to the lightweight nature of this no-local-storage design. Had every shot required downloading its generated video clip back to disk, the entire pipeline would have taken at least twice as long—video download speed is far slower than video generation speed, and disk I/O would become the new bottleneck.
For those records in the database with no video addresses, the final assembly of the finished film is handled entirely through Jimeng's online editing capabilities.
The whole film is not assembled locally from 1,029 individual MP4s. Instead, all shots' task IDs and first-and-last frame information are passed to Jimeng's sequence composition endpoint, which performs continuous video generation on the cloud side, ultimately producing a single complete video stream lasting two hours and twenty minutes.
This finished film never lands on local storage either—it exists solely in Jimeng's cloud storage, served for playback through a share link.
So the vdurl field contains no address for any individual shot, because video files for the entire project have never appeared on a traditional file server.
This does challenge conventional film and media data management wisdom, but it is sound engineering: your goal is not to store videos—it is to generate videos, watch videos, and regenerate them when necessary. In that context, leaving the vdurl field empty is more honest than filling it with a link that expires anytime, and it also lets operations staff see at a glance that this is cloud-side generation rather than locally managed output.