Renders, die kein Release mehr unterbricht

Ein PageToVid-Render ist schwere Arbeit. Ein echter Chromium-Browser filmt die Website, ffmpeg schneidet und kodiert die Clips, und Remotion dekodiert jedes Bild, um das fertige MP4 zusammenzusetzen. Bisher lief all das im selben Server, der auch die Webseiten ausliefert.

Dieser Server hat aber andere Aufgaben. Er wird bei jedem Release aktualisiert, er schrumpft, wenn wenig los ist, und er kann zwei Filme gleichzeitig bekommen. Wir wollten, dass ein laufender Film unantastbar ist, egal was um ihn herum passiert: ein neues Release, eine ruhige Nacht oder ein Paket aus mehreren Videos, die zusammen bestellt wurden.

Am Tag davor hatten wir das Warten schon angenehmer gemacht: Stimme und Wort-Timing laufen jetzt parallel zur Aufnahme, und die Video-Engine wärmt sich beim Serverstart auf. Heute haben wir geändert, wo die Arbeit stattfindet.

Jeder Render läuft jetzt als eigene Ausführung eines Cloud Run Jobs. Wenn du einen Film startest, tut der Webdienst nur eine kleine Sache: Er fordert einen neuen Job an, ein Aufruf von etwa 200 Millisekunden. Dieser Job bekommt viel Arbeitsspeicher für sich allein, rendert genau einen Film von Anfang bis Ende und beendet sich.

Der Webdienst kehrt zu dem zurück, was er gut kann, Seiten ausliefern und den Fortschrittsbalken beantworten, und das auf einer kleineren Maschine. Die schwere Arbeit ist an einen Ort gezogen, der dafür gebaut ist.

Auf dem Laptop eines Entwicklers gibt es keinen Job-Dienst, also läuft dieselbe Pipeline einfach im selben Prozess wie zuvor. Ein Codepfad, zwei Orte, an denen er läuft.

Im Film selbst sieht man den Unterschied nicht, und genau darum geht es. Was sich ändert, ist alles, was ihm früher in die Quere kommen konnte:

• Releases erreichen keine Renders mehr. Wir können eine neue Version der Website ausliefern, während Filme rendern; laufende Jobs arbeiten unberührt weiter.
• Pakete laufen nebeneinander. Bestellst du mehrere Videos auf einmal, bekommt jedes seinen eigenen Job, und sie rendern parallel, statt auf dieselbe Maschine zu warten.
• Jeder Film hat Platz. Kein Film teilt seinen Speicher mit einem anderen, also hat eine lange Seite oder ein dichtes Storyboard die ganze Maschine.
• Ein fehlgeschlagener Job kann neu starten. Die Plattform kann einen Job erneut anstoßen, was eine Anfrage in einem Webserver nie konnte.

Außerdem rollt der Release-Prozess den Render-Job aus genau dem Image aus, das er gerade für die Website gebaut hat. Die Seite, die du siehst, und das Programm, das deinen Film macht, laufen immer mit demselben Code, und dieses Programm hat einen eigenen Startbefehl für die Produktion, schon am ersten Tag geprüft.

Die Isolation hat uns auch erlaubt, das Warten ehrlicher zu machen. Ein Film, der länger als acht Minuten keinen Fortschritt zeigt, wird jetzt als fehlgeschlagen markiert, statt den Balken einfrieren zu lassen, und du bekommst einen Button zum erneuten Versuch. Derselbe Wächter schützt den Status der öffentlichen API, sodass ein Entwickler, der einen Film abfragt, dieselbe klare Antwort erhält.

Schlägt ein Film fehl, geht sein Credit automatisch zurück, genau einmal, ob der Fehler aus der Pipeline, aus einem neuen Render eines bearbeiteten Storyboards oder vom Wächter kommt. Ein behandelter Fehler beendet den Job sauber, damit die Plattform ihn nicht versehentlich neu startet.

Auch die KI-Qualitätsprüfung, die jeden Film bewertet, wartet jetzt, bis sie fertig ist, bevor sich der Job beendet. Dein Film wird zuerst ausgeliefert; der Job bleibt nur ein paar Sekunden länger, um seine Punktzahl zu schreiben.

Der Umzug der Renders war ein Anlass, die ganze Pipeline anzuschauen, und eine Reihe kleinerer Verbesserungen kam gleich mit:

• Bilder aus dem Web, auf die eine Grafikszene angewiesen ist, werden vor dem Render geprüft. Ein verschwundenes Bild wird zu einer sauberen Textszene statt zu einem Abbruch kurz vor dem Ende.
• Ein Wort-Timing, das weniger als drei Viertel des Skripts abdeckt, wird verworfen, denn ein unvollständiges Timing presste Szenen in halbsekundige Blitze.
• Die Hervorhebung in den Untertiteln wird jetzt fortlaufend gezählt und bleibt so auch über ein langes Storyboard im Takt der Stimme.
• Clips werden auf den Moment geschnitten, in dem die Aktion wirklich passiert, gemessen während der Aufnahme: kein eingefrorener Vorlauf, kein abgeschnittenes Ende.
• Jede Seite hat eine begrenzte Ladezeit, damit eine Website voller Tracking-Skripte eine Szene nicht mehr anderthalb Minuten festhalten kann.
• Der Fortschritt wird einmal pro sichtbarem Prozentschritt gespeichert statt bei jedem Bild.

Zusammen machen sie einen Render kürzer, ruhiger und berechenbarer. Was am Ende herauskommt, siehst du auf der Videoseite.