The render gate that proves a video is real

Every video Autoretto publishes passes through a render gate. This gate is not a formality. It has to prove the video is real before a single byte goes to YouTube. It sits between the muxer and the publish scheduler. If the gate does not give a clear pass, the pipeline stops. The gate is the last line of defense before a release becomes public.

The first thing the gate takes in is the rendered MP4. That file was assembled by the in-process muxer from a video stream and an audio stream. But the gate does not trust the muxer. It also takes the original WAV from Suno, the beat map from the sync engine, and the calculated duration from the render manager. These are the reference inputs. The gate runs in an isolated sandbox, so it cannot touch the network or any other process while it works.

The first checks are about the container itself. The gate opens the MP4 and parses the structure manually. It reads the moov atom and walks the sample tables. It verifies that there is exactly one video track and one audio track. It checks the codec identifiers against the expected values from the render plan. It verifies that the track durations line up with the total duration. Any mismatch is a fail. It also checks that the file size is within an expected range. A 10-second video that is 2 megabytes is suspicious. A 10-second video that is 200 megabytes is also suspicious.

Then comes the sync verification. The beat-sync engine produced a map of timestamps. That map is used to time visual cuts. The gate does not just read the map. It re-runs beat detection on the original WAV and compares the two. Then it decodes the video frames and checks that the visual cut points fall within one frame of the expected beat timestamps. At 30 frames per second, that window is about 33 milliseconds. This catches drift early. If the muxer dropped a frame, the gate will see it as a constant offset.

Audio integrity is another layer. The gate compares the audio track in the MP4 against the source WAV. It uses a spectral fingerprint, not just a checksum. The spectrum of both files must match within a bandwidth tolerance. It also measures the integrated loudness. Autoretto targets a loudness of about -14 LUFS for YouTube. If the render normalized the audio too hard, the gate flags it because that would produce clipping or pumping. It also checks for any silent gaps at the beginning or end.

The visual check looks at the pixels. It extracts frames at regular intervals, roughly once every five seconds. It confirms that those frames are not black or frozen. It checks the color variance across the frame and across time. It compares the motion energy in the frames against the motion recipe from Sora, if Sora was used. This proves the video track is not just a static image stretched to fit. It also checks for green frames, which can happen when a codec bug goes undetected.

Every gate run writes a JSON report. That report lists each check, the measured value, and the pass or fail status. The gate also records a SHA-256 hash of the exact MP4 file that was verified. The report is stored with the release record. Later, right before upload, the scheduler rehashes the file and compares it to the stored hash. If anything changed, the release is blocked. That is how the gate proves its work. The report is immutable. No one can go back and edit it after the fact.

The gate also feeds a learning loop. A pass or a fail updates the regression model for the render pipeline. If a particular sync engine version starts producing drift, the gate catches it on the first release. It then triggers a rollback of that version. The channel never sees the bad release. That is the point. The gate is not there to slow things down. It is there to make sure the fifteen steps actually produce something worth publishing.