Ich habe den Text komplett neu geschrieben, weil mir die vorige Version selbst zu oberflaechlich war. Sie war nicht falsch, aber sie beschrieb den Clip eher als Ergebnis und nicht als technische Produktionsstrecke. Genau das wollte ich fuer AutomatedWeb sauberer dokumentieren. Der interessante Teil war am Ende nicht nur, dass ein Video herausfiel, sondern dass ich mehrere spezialisierte MCPs so kombiniert habe, dass daraus ein wiederholbarer Workflow fuer Bild, Video, Audio, Schnitt und Publishing wurde.
Finale Fassung: Das ist der aktuelle Clip. Die laengere Endcard ist drin, das Markenlogo steht sichtbar im Schluss, die Musik startet vom ersten Frame an und der Strassenklang bleibt als eigene Ebene erhalten.
Worum es technisch eigentlich ging
Die eigentliche Aufgabe war nicht, mit einem Modell "irgendetwas Cooles" zu rendern. Ich wollte fuer AutomatedWeb eine belastbare Produktionsstrecke aufbauen, die ich spaeter wiederverwenden kann. Wenn ich den naechsten Clip baue, will ich nicht wieder bei null mit Prompts, Browser-Tabs, manuellen Downloads und einzelnen Shell-Schnipseln anfangen. Ich will eine definierte Kette:
- Bildanker erzeugen
- Shots rendern
- Shots schneiden und zusammenbauen
- Musik erzeugen und herunterladen
- finalen Audio-Mix bauen
- Asset publizieren und im Artikel einbetten
Genau deshalb habe ich das Projekt nicht als "ein Prompt, ein Modell, ein Ergebnis" behandelt, sondern als mehrere kleine MCP-Schichten mit klarer Verantwortung.
Die MCP-Aufteilung
Am Ende bestand die Kette aus vier Bausteinen:
- Nano-Banana-MCP fuer Startframes und Bildanker
- Video-Pipeline-MCP fuer Seedance, Storyboards, Stitching und lokale ffmpeg-Schritte
- Suno-MCP fuer Musikgenerierung, Polling, Download und spaeter WAV-Konvertierung
- YouTube-MCP fuer den spaeteren Publish-Schritt
Die Aufteilung war wichtig. Ein einzelner Riesen-MCP mit allem drin waere zwar schneller hingeschrieben, aber deutlich schlechter zu warten gewesen. So konnte ich an einem Teil iterieren, ohne den Rest anzufassen. Wenn das Bildmaterial instabil war, blieb ich im Video-MCP. Wenn der Sound nicht trug, ging ich ins Suno-MCP. Wenn spaeter Metadaten oder Upload betroffen sind, liegt das im YouTube-Teil.
Der konkrete Video-Stack
Der Video-Teil lief ueber ein lokales MCP, das ich im Workspace aufgebaut habe. Das hat mehrere Werkzeuge zusammengebracht:
- Seedance "text-to-video"
- Seedance "image-to-video"
- Seedance "reference-to-video"
- Queue-Status und Result-Abfrage
- lokales Schneiden ueber ffmpeg
- nahtloses Stitching mit Video- und Audio-Fades
- Storyboard-Manifest, Run-Datei und Auto-Refresh
Die Kernidee war, nicht blind lange Clips zu generieren, sondern mit kurzen kontrollierten Einheiten zu arbeiten. Ein einzelner langer Shot sieht im Playground oft gut aus, bricht aber in echten Markenclips schnell auseinander. Architektur driftet, Kameraenergie kippt, Bewegungen werden unnatuerlich, und gerade bei Figuren oder Landmarken verraet das Material sehr schnell seine kuenstliche Herkunft.
Warum der erste Shot blieb und der Rest neu gebaut wurde
Der erste Shot war frueh schon der staerkste Teil des Films. Er hatte Tempo, Atmosphaere und genug Realitaetsbindung, um AutomatedWeb nicht wie generische Modell-Demo aussehen zu lassen. Das war wichtig, weil ich den Film nicht als KI-Schauwert wollte, sondern als Markenclip mit technologischem Unterbau.
Der Fehler waere gewesen, aus Prinzip alles neu zu rendern. Stattdessen habe ich die spaeteren Shots ersetzt und den Anfang bewusst gehalten. Das war technisch die bessere Entscheidung, weil ich damit die visuelle Energie des Openers konserviert und die schwache zweite Haelfte isoliert bearbeiten konnte.
Was bei den ersten Versionen schief lief
Es gab im Wesentlichen fuenf Problemklassen:
1. Zu statische Bildphasen
Einige fruehe Fassungen wirkten im Einzelbild stark, aber im Bewegungsfluss zu tot. Das ist ein typisches Problem, wenn man zu sehr auf Startbilder vertraut und den Shot spaeter nur noch animieren laesst. Sobald die Bewegung im Raum nicht glaubwuerdig weiterarbeitet, kippt der Film von "filmisch" zu "animiertes Bild".
2. Drift in Landmarken
Der fuer mich stoerendste Fehler war, dass sich in einer Fassung die Frauenkirche leicht bewegte. Genau das durfte nicht passieren. Sobald ein reales Landmark im Bild weich wird oder driftet, verliert der gesamte Clip an Glaubwuerdigkeit. Daraufhin habe ich die spaeteren Muenchen-Shots strenger neu gerendert und das Landmark-Verhalten haerter verankert.
3. Figuren wurden unnatuerlich
Ich hatte zwischendurch auch eine Version mit distanzierter Hauptfigur. Das Problem lag nicht nur an Seedance, sondern schon an der Bildbasis: die Referenzbilder zeigten keine wirklich identische Person. Deshalb wirkte der Mensch spaeter kuenstlich und nicht wie eine reale Klammer. Die richtige Konsequenz war, die Figur fuer diesen Clip ganz herauszunehmen.
4. Das Logo war zu kurz oder zu weich
Mehrere Versuche hatten am Ende formal "eine Marke im Bild", aber nicht wirklich einen Schluss. Entweder war das Logo zu kurz eingeblendet oder nur als Overlay auf bewegtem Material geloest. Das Ergebnis war technisch vorhanden, aber kommunikativ zu schwach.
5. Exportfehler im Finish
Der nervigste technische Fehler war, dass einzelne ffmpeg-Durchlaeufe zwar Dateien schrieben, diese aber nicht sauber finalisierten. Das aeusserte sich am Ende als ungueltige MP4 ohne sauberen "moov atom". Erst als ich die letzten Schritte vereinfacht und in kleinere Render-Schritte aufgeteilt habe, wurde der Abschluss stabil.
Was ich bei Seedance geaendert habe
Der wichtigste Wechsel war: weniger "groesserer Prompt", mehr kontrollierte Shot-Logik. Ich habe nicht versucht, aus einem einzigen Prompt den gesamten Film zu erzwingen, sondern einzelne Aufgaben sauber getrennt:
- Shot behalten, wenn er schon funktioniert
- problematische Folge-Shots neu rendern
- Landmarken und Stadtcharakter haerter verankern
- den Schluss nicht im Generationsmodell, sondern im Editing loesen
Genau das ist auch die Stelle, an der ein lokales MCP mehr bringt als ein Playground. Ich konnte die einzelnen Ergebnisse direkt weiterverarbeiten, vergleichen, schneiden und neu kombinieren, statt bei jedem Problem wieder den ganzen Film von vorne anzufassen.
Das Storyboard- und Run-Datei-Prinzip
Ein entscheidender Teil der Pipeline war, dass ich nicht nur lose Dateien verwaltet habe, sondern Run-Dateien und Storyboards. Das ist trocken, aber extrem praktisch. Ein Shot ist dann nicht nur "dieses MP4", sondern ein definierter Zustand mit:
- Eingabe-Referenzen
- Prompt
- Endpoint
- Request-ID
- Status
- Result-URL
- lokalem Output-Pfad
Das bedeutet: Ich kann einen einzelnen Shot neu fahren, ohne den Rest zu verlieren. Und ich kann spaeter nachvollziehen, welche Fassung worauf basiert. Fuer visuelle Produktion ist das deutlich sinnvoller als eine lose Sammlung von generierten Assets im Downloads-Ordner.
Das Suno-MCP war mehr als nur "mach Musik"
Beim Ton wollte ich denselben Fehler vermeiden wie bei den Bildern: keine ad-hoc-Loesung. Deshalb habe ich ein eigenes Suno-MCP gebaut. Es kapselt fuer mich genau die Suno-Schritte, die im Alltag wichtig sind:
- Credits pruefen
- Musikjob starten
- Task pollen
- Ergebnis herunterladen
- optional WAV-Konvertierung anschieben
Die eigentliche Qualitaet kam aber nicht aus dem blossem Suno-Call, sondern aus der Art, wie ich den Track eingesetzt habe. Das erste Soundbett wirkte wie eine Ersatztonspur. Das war falsch. Der Clip lebt auch vom Strassenraum. Also habe ich die Originalspur bewusst behalten und Suno als zweite Musikschicht daruebergelegt.
Das war der entscheidende Unterschied. Jetzt startet die Musik direkt am Anfang, gibt dem Film sofort Richtung, aber die Stadt bleibt hoerbar. Genau deshalb fuehlt sich der Clip nicht wie ein stummes Stockvideo mit nachtraeglicher Musik an.
Der finale Audio-Mix
Der aktuelle Schlusszustand ist technisch simpel, aber genau deshalb stabil:
- Originalton bleibt im Film
- Suno-Track startet bei Frame 1
- Musik ist im Pegel deutlich praesent, aber nicht dominant genug, um den Stadtraum zu loeschen
- Endcard bekommt ihre eigene Haltezeit
- Schlussfades passieren im Mix und nicht nur visuell
Das klingt nach einer kleinen Entscheidung, aber genau solche Dinge trennen einen "KI-Demo-Clip" von einem brauchbaren Markenfilm. Sobald Bild, Originalatmo und Musik nicht sauber zueinander stehen, wirkt alles sofort zufaellig.
Warum ich die Endcard separat gebaut habe
Ich habe mehrere Varianten versucht, bei denen das Logo einfach auf das letzte laufende Bild gelegt wurde. Das war in der Praxis nicht genug. Das Branding war technisch vorhanden, aber es stand nicht wirklich. Genau deshalb habe ich die Schlussphase spaeter in eine eigene Endcard aufgeteilt.
Das hatte drei Vorteile:
- "AutomatedWeb" steht sichtbar und lange genug.
- Das Video kann davor voll auf Bewegung gehen, ohne dass das Logo untergeht.
- Der Audioabschluss laesst sich separat feintunen.
Technisch war das zugleich die robustere Loesung fuer den Export, weil ich nicht mehr einen grossen, komplexen Enddurchlauf erzwingen musste.
Der eigentliche Nutzen fuer AutomatedWeb
Fuer mich ist der interessante Teil nicht nur der Clip selbst. Der interessantere Teil ist, dass AutomatedWeb jetzt eine kleine, wiederverwendbare Medienpipeline hat:
- Bildinput ueber Nano Banana
- Shot-Produktion ueber Seedance
- Postproduktion ueber das Video-MCP und ffmpeg
- Sound ueber Suno
- Publishing ueber EmDash und spaeter YouTube
Das passt auch inhaltlich zur Marke. AutomatedWeb soll nicht nur ueber Automatisierung sprechen. Es soll zeigen, wie man echte Arbeitswege in reproduzierbare Systeme ueberfuehrt. Dieser Clip ist dafuer ein gutes Beispiel, weil genau das hier passiert ist.
Was ich beim naechsten Durchgang anders machen wuerde
Ganz fertig ist so ein Workflow nie. Die drei offensichtlichsten Verbesserungen fuer die naechste Runde waeren:
- frueher auf eine strengere Shot-Liste gehen statt spaeter radikal zu ersetzen
- Suno bereits in einer frueheren Iteration parallel zum Bildschnitt mitdenken
- fuer die Schlussphase frueher entscheiden, ob Branding als Endcard oder als In-Scene-Element loest
Trotzdem ist die jetzige Fassung fuer mich die erste Version, bei der Bild, Stadt, Rhythmus, Sound und Marke wirklich zusammengehen.
Genau deshalb steht am Anfang dieses Artikels jetzt nicht mehr nur eine abstrakte Visualisierung, sondern ein echter Frame aus dem finalen Film. Das ist nicht mehr nur ein "ich habe mit Modellen gespielt"-Beitrag. Es ist eine dokumentierte Produktionsstrecke aus Nano Banana, Seedance, Suno, ffmpeg und mehreren MCPs, die ich fuer den naechsten Clip direkt wieder einschalten kann.