The strict render check that happens before any Autoretto video goes live

Every video on Autoretto goes through fifteen steps. Most of them happen before you ever see a frame. The one that keeps me awake at night is the render verification gate. It is the last technical barrier between a finished render and the YouTube upload pipeline. This gate takes in the MP4 file that the muxer just created. It also takes in the exact specifications that were promised by the earlier steps. Those specs include duration, resolution, frame rate, and the beat map from the audio engine.

The first thing the gate does is probe the file. It uses FFmpeg to read the container, not the file name. A file named 'video.mp4' could be garbage. So the gate asks FFmpeg to list the streams. It checks that there is exactly one video stream and one audio stream. It checks that the codecs match the target. For Autoretto, that is H.264 for video and AAC for audio. Then it compares the actual duration to the expected duration. If the render cut off early, the gate fails it.

Next, the gate decodes the video. It does not watch the whole thing. That would take too long. Instead, it extracts a frame every two seconds. It runs a pixel analysis on each frame. It looks for black frames that should not be black. It looks for frozen frames, where the image does not change between samples. It also checks for macroblock corruption, which looks like static. If any sampled frame is bad, the video is rejected. The gate is strict. A few bad frames is enough to stop the release.

The audio gets the same treatment. The gate extracts the audio track and measures its loudness. It checks for clipping. It checks that the audio is not silent. But it also checks timing. The muxer was supposed to align the visuals with the beat map. So the gate detects the beats in the audio and compares them to the timestamps of the video cuts. If the cuts are off by more than two frames, it fails. This catches a subtle bug where the renderer adds a tiny delay to the audio stream.

The gate also reruns the content policy checks on the sampled frames. The earlier content gate already reviewed the artwork and the seed prompts. But rendering can introduce unintended content. A hallucination in a text overlay or a flicker pattern that could trigger photosensitivity. So the gate sends the sampled frames through a vision model. It checks for flashing lights, text that did not get approved, and anything else that violates the channel's policy. This is the second pass, and it caught a real issue once: a subtle strobing effect in a background gradient.

If everything passes, the gate produces a verification report. The report is a JSON file with every measurement it made. It includes the FFmpeg probe output, the sampled frame hashes, the beat alignment statistics, and the policy verdict. That report is stored with the video metadata. It becomes part of the final publish log. If the video is later accepted by YouTube and goes live, the report stays as proof that the video was sound before it left our hands.

If anything fails, the gate does not hand off. It sends the video back to the renderer with an error code. There is no silent fix. The renderer has to re-export the video and run the gate again. For a typical Autoretto release, this adds a few minutes. For a video that fails repeatedly, it can add hours. But that is the point. We would rather miss a scheduled publish than upload a broken video to a creator's channel. A miss is explainable. A corrupted upload is not.

I have seen this gate prove its worth. One release had music that passed all the audio checks. The muxer produced a video that looked perfect in preview. But the gate found that the audio was offset by thirty milliseconds after muxing. That is less than one frame. A human would never notice it. But the gate caught it because the beat alignment check is precise. The video went back to the renderer, the offset was fixed, and the release went live ten minutes later. The creator never knew.