KI-ndervideos: Wie aus Themen, Prompts und GPUs ein zweisprachiges Lernvideo wird (Arabisch-Englisch)

Einleitung

Digitale Lerninhalte für Kinder müssen visuell ansprechend, sprachlich klar und thematisch stimmig sein. Wer zweisprachige Materialien produziert — hier Arabisch und Englisch — steht vor einem klassischen Spannungsfeld: hoher manueller Aufwand für Illustration, Bewegtbild, Vertonung und Schnitt auf der einen Seite, der Wunsch nach konsistenten Stilen und Skalierbarkeit auf der anderen.

KI-ndervideos löst genau das. Aus einem oder mehreren Themen entsteht eine vollautomatische Pipeline bis zum fertigen MP4-Lernvideo — zweisprachig, im konsistenten 2D-Cartoon-Stil, mit Hintergrundmusik und Vokabel-Narration. Ergänzend bietet ein Django-Web-Dashboard eine browserbasierte Oberfläche: Jobs anstoßen, Live-Logs lesen, generierte Bilder, Clips und das Fertigvideo direkt im Browser ansehen.

Features

Das System deckt die gesamte Produktionskette ab: Ein CLI-Aufruf mit einem oder mehreren Topics startet alle Schritte automatisch. Englische Narration übernimmt Qwen3-TTS lokal auf der GPU, Arabisch läuft über Microsoft Edge TTS. Bilder generiert FLUX im konsistenten 2D-Cartoon-Stil, Videos entstehen mit LTX-Video 0.9.7, und ein eigenes musicgen-Modul erzeugt thematisch passende Hintergrundmusik. Cache-Flags wie --reuse-prompts und --reuse-media sparen GPU-Zeit bei Wiederholungen.

Gesamtüberblick

Das System gliedert sich in drei Schichten. Die oberste ist das Django-Web-Dashboard mit Startseite, Job-Detail-Ansicht und einer Medien-API. Darunter liegt die Orchestrierungsschicht mit job_runner.py und main.py, die einen Subprocess starten und Status über meta.json und console.log nach oben weitergeben. Die unterste Schicht besteht aus den eigentlichen Medien-Generatoren: Prompt-Factory, musicgen, audiogen, FLUX, LTX-Video und MoviePy.

Kernidee: Das Dashboard startet keinen Python-Code in-process für die schwere KI-Arbeit, sondern einen Subprocess. So bleibt der Webserver stets responsiv, während die GPU-Pipeline im Hintergrund läuft.

Workflow

Für jedes Thema durchläuft die Pipeline eine feste Sequenz. Zuerst generiert die Prompt-Factory über die OpenAI API ein strukturiertes JSON mit Vokabeln, Bild-Prompts und Video-Prompts. Parallel dazu startet musicgen. Dann erzeugt audiogen für jede Vokabel zwei WAV-Dateien — Englisch via Qwen3-TTS, Arabisch via Edge TTS. Danach folgt FLUX für alle Bilder. Nach dem letzten Bild wird die FLUX-Pipeline explizit aus dem VRAM entladen, bevor LTX-Video die Kurzclips generiert. Abschließend baut MoviePy aus Layouts, Clips, Audio und Musik das finale MP4.

Datenfluss

Jedes Thema erzeugt einen eigenen Ordnerbaum. Das Prompt-JSON landet in prompts/, die WAV-Dateien in audiogen/audios/<thema>/, die PNG-Bilder in videogen/images/<thema>/, die Kurzclips in videogen/videos/<thema>/. Layout-Composites gehen nach moviegen/layouts/<thema>/, Musik nach musicgen/music/. Das finale MP4 landet in moviegen/videos/<thema>.mp4.

Technischer Stack

Ein kleiner Trick steckt in sox.py: Ein minimaler SoX-Shim implementiert die API von python-sox (Transformer.norm, build_array) mit reinem NumPy — kein systemweites Binary nötig.

Herausforderungen & Lösungen

VRAM zwischen FLUX und LTX: Beide Diffusion-Stacks gleichzeitig zu halten führt zu Out-of-Memory-Fehlern. Die Lösung: cleanup_image_pipeline() nach dem Bild-Durchlauf explizit aufrufen, CUDA-Cache leeren, GC triggern — erst dann LTX laden.

TTS für Arabisch: Qwen3-TTS deckt Arabisch nicht ab. Lösung ist ein pragmatischer Hybrid: Qwen3-TTS für Englisch, Edge TTS für Arabisch. Beide Pfade produzieren WAV-Dateien mit identischer Struktur.

Video-Stabilität: LTX neigt dazu, Hintergründe zwischen Frames zu variieren. Starke Negativ-Prompts gegen Kamera- und Hintergrundwechsel plus kategoriespezifische Szenenbeschreibungen im Positiv-Prompt verankern die Komposition.

SoX-Abhängigkeit: Der SoX-Shim eliminiert die Systemabhängigkeit komplett — keine Installationsschritte auf dem Deployment-Server.

Path Traversal im Dashboard: is_allowed_artifact_relative() filtert Pfade, full.relative_to(BASE_DIR) ist eine zweite Schutzschicht. Ungültige Pfade geben Http404 zurück.

Server-Neustart während "running": os.kill(pid, 0) prüft, ob der Prozess noch lebt. Falls nicht, wird der Status auf "unknown" gesetzt — eine ehrliche Zwischenlage statt eines falschen "running".

Ausblick

Die Pipeline funktioniert. Die nächsten Schritte liegen in der Betriebshärte: eine Job-Queue mit Redis/RQ statt einzelnen Subprocessen, granulare Fortschrittsanzeigen in meta.json, Multi-User-Unterstützung mit Django-Auth, Kostentransparenz über Token-Zähler, und schließlich ein Cloud-Deployment mit Container-Images, GPU-Node-Pools und S3-Artefakt-Storage.