In diesem Artikel
- Eine Quelle ist noch keine fertige Geschichte
- Die lokale Werkzeugkette vorbereiten
- Modell, Provider und Stimme bewusst auswählen
- Ein neues Projekt bis zum Storyboard führen
- Aussagen und Bildmaterial vor dem Build prüfen
- Mit lokaler Stimme rendern und das Ergebnis ansehen
- Artefakte und Projektstand nachvollziehbar halten
- Quellen
Ein Repository enthält oft alles für eine gute Erklärung: Code, README, Screenshots und eine dokumentierte Entwicklung. Ein verständliches Video braucht daraus jedoch eine Auswahl und einen nachvollziehbaren Ablauf. Source2Reel ist mein lokales Werkzeug für diese Produktionskette.
Das Source2Reel-Projekt kombiniert Quellenimport, lokale KI-Unterstützung, ein strukturiertes Storyboard, lokale Sprachausgabe und FFmpeg-Rendering. Cisco-DOOM dient als Referenzepisode. Dieser Artikel erklärt den Workflow und seine Prüfstellen; automatisch erzeugte Texte sind weiterhin zu kontrollieren.
Eine Quelle ist noch keine fertige Geschichte
Eine technische Erklärung sollte zuerst eine klare Frage beantworten: Was macht das Projekt, wie funktioniert es und welche Belege zeigen das Ergebnis? Ein langer README-Abschnitt allein ergibt noch keine gut aufgebaute Szene.
Source2Reel führt daher ein Quelleninventar mit Referenzen und Hashes. Das hilft, verwendetes Material wiederzufinden und eine Fassung zuzuordnen. Ein Hash bestätigt dabei die Identität eines Inhalts, nicht dessen Wahrheit. Auch eine alte README oder ein Demo-Screenshot kann inzwischen einen anderen Stand beschreiben.
| Produktionsschritt | Ergebnis |
|---|---|
| Quellenimport | Lokale Grundlage aus Repo, Website oder Ordner |
| Evidence-Inventar | Referenzen und Inhaltskennungen |
| Recherche / Storyboard | Geplante Aussagen und Szenen |
| Stimme / Timing | Audio und daraus abgeleitete Dauer |
| Rendering | Video und begleitende Artefakte |
Die lokale Werkzeugkette vorbereiten
Der derzeit dokumentierte Installationsbezug ist Arch Linux auf Cthulhu. Prüfe die aktuelle BUILD.md, bevor du den Installer auf einem anderen Rechner ausführst. Er richtet Pakete und lokale Umgebungen ein; das ist mehr als das reine Lesen einer Datei.
Hole einen neuen Checkout:
git clone https://github.com/dennishilk/source2reel.git
Wechsle hinein:
cd source2reel
Nach Prüfung der Voraussetzungen und des Installers folgt der dokumentierte Aufbau:
./install.sh
Prüfe danach die Werkzeuge:
./s2r doctor
doctor meldet Abhängigkeiten und optionale Komponenten. Ein fehlendes Modell oder ein gestoppter API-Dienst kann als optional erscheinen; daraus folgt nicht, dass die KI-Produktion bereits startbereit ist. Eine vollständige neue Hardwareinstallation braucht eigene Funktionsprüfungen.
Modell, Provider und Stimme bewusst auswählen
Lokale Modell-Dateien liegen im ignorierten models/-Ordner; private Einstellungen in config/local.toml. Ein an die tatsächlichen Dateien anzupassender Ausschnitt ist:
[local_ai]
model_path = "models/DEIN-MODELL.gguf"
mmproj_path = "models/DEIN-PROJEKTOR.gguf"
Ein Multimodalprojektor muss zum ausgewählten Modell passen. Die Platzhalter sind keine Downloadnamen. Dokumentiere Modellrevision, Quantisierung und Hash, wenn du ein reproduzierbares Ergebnis festhalten willst.
Die dokumentierte lokale Laufzeit verwendet unter anderem llama.cpp über einen lokalen API-Endpunkt. Vulkan/RADV ist der Cthulhu-Bezug; CPU ist ein möglicher Rückweg. Daraus folgt keine pauschale ROCm- oder GPU-Kompatibilität für jedes AMD-Modell.
Die Stimme hat eine eigene Umgebung. Prüfe sie hörbar:
./s2r voice-test
Der mitgelieferte Workflow nutzt eine englische Sprachumgebung. Ein deutschsprachiges Produktionsprofil braucht eine dazu passende geprüfte Stimme und Texte. Dass dieser Blogartikel zweisprachig ist, stellt nicht automatisch die Ausgabesprache des Tools um.
Ein neues Projekt bis zum Storyboard führen
Starte die interaktive Oberfläche:
./s2r
Wähle eine neue Episode und gib eine autoritative Projektquelle ein. GitHub-URL, Website und lokaler Ordner können unterschiedliche Eingaben liefern. Beginne mit einem Thema und einer klaren Frage, statt wahllos große Materialsammlungen zusammenzugeben.
Der explizite CLI-Weg für unseren Projektbezug lautet:
./s2r create https://github.com/dennishilk/cisco9951-doom --review
Der Review-Schritt erlaubt, vor dem Build am Storyboard anzuhalten. Bei großen Quellen begrenzt Source2Reel Eingaben und legt Zwischenstände ab. Wiederverwendbare Teile sparen Arbeit, ersetzen aber keine inhaltliche Kontrolle nach einer geänderten Quelle.
Aussagen und Bildmaterial vor dem Build prüfen
Bei Cisco-DOOM ist besonders wichtig, Entwicklungsstufen zu unterscheiden. Eine frühe Streaming-Demo und das finale native Spiel zeigen unterschiedliche Architekturen. Ein gutes Video erklärt diesen Übergang, statt einen alten Screenshot als Beleg für den endgültigen Offline-Betrieb zu verwenden.
Prüfe jede relevante Szene auf drei Fragen: Passt die Aussage zur angegebenen Quelle? Zeigt das Bild den behaupteten Stand? Versteht jemand ohne Projektwissen den Zusammenhang? Eine maschinell gültige JSON-Datei allein beantwortet diese Fragen nicht.
Nutze Originalbilder nur mit passenden Nutzungsrechten. Ein privater lokaler Ordner kann neben guten Aufnahmen auch Zugangsdaten oder ungeeignete Dateien enthalten. Wähle das Material vor dem Import und prüfe das spätere Bildfeld zusätzlich auf private Details.
Mit lokaler Stimme rendern und das Ergebnis ansehen
Nach der Prüfung kannst du eine gespeicherte Episode über den interaktiven Build wählen. Der direkte Aufruf benötigt ihren tatsächlichen Slug; DEIN-EPISODEN-SLUG ist ein Platzhalter:
./s2r build DEIN-EPISODEN-SLUG
Die dokumentierte Ausgabe ist 1920×1080 mit H.264-Video und AAC-Audio. Szenendauern werden aus der erzeugten Narration abgeleitet. Große Originalmedien, Schriftarten und FFmpeg-Funktionen müssen lokal vorhanden sein; eine Episode mit zusätzlichen ungetrackten Medien ist nach einem frischen Clone nicht automatisch vollständig renderbar.
Sieh und höre das fertige Video vollständig durch. Prüfe Aussprache, Textumbrüche, eingebrannte Untertitel, Szenenwechsel und ob die Bilder zur gesprochenen Aussage passen. Der lokale Renderer verhindert weder eine falsche Schlussfolgerung noch eine missverständliche Formulierung.
Artefakte und Projektstand nachvollziehbar halten
Zu einer Produktion gehören mehr als die MP4: Storyboard, Transkript, Evidence und Provenienzmaterial helfen beim Nachprüfen. Die akzeptierte Referenzepisode ist im Projektstand mit zwölf Szenen und ungefähr 283,6 Sekunden auf Cthulhu dokumentiert. Das ist ein konkreter damaliger Abnahmestand, keine Erfolgsgarantie für jeden neuen Input.
Die konsolidierte Neuinstallation und spätere Änderungen haben eigene Prüfgrenzen. Beachte BUILD.md und den aktuellen Projektstand, statt die Abnahme einer älteren Episode auf sämtliche neuen Installationspfade zu übertragen.
Für private Modell- und Laufzeitdateien nutzt das Projekt ignorierte Verzeichnisse. Diese ignorierten Dateien brauchen bei Bedarf eigene Sicherungen; Git sichert sie nicht automatisch. Eine saubere Git-Historie hilft dagegen bei der Zuordnung veröffentlichter Quellen.
Quellen
- Source2Reel auf GitHub.
- Geprüfte Workflow-Beschreibung.
- BUILD.md, lokale KI und Projektstand.
- Cisco-DOOM-Quellprojekt.
Referenzen geprüft am 8. Oktober 2026. Der Artikel erklärt die dokumentierte Produktionskette; er behauptet keinen neu durchgeführten vollständigen Render auf Cthulhu.