marwanhattar94/remotion-motion-graphics

Remotion Motion Graphics

Remotion rendert React-Komponenten Bild für Bild zu einem Video. Die Codequalität ist nicht der Engpass – die handwerkliche Kunst des Bewegungsdesigns ist es. Nicht trainierte Generierung erzeugt lineare Interpolation, reine Opazitäts-Fades, gleichzeitige Einblendungen, flache Farben und keine Textur. Das ist der „generische KI-Video“-Look. Diese Fähigkeit existiert, um das zu verhindern.

Nicht verhandelbare Regeln (gelten für JEDE Komposition)

1. Niemals lineare Interpolation verwenden. Jeder interpolate()-Aufruf erhält eine Easing-Kurve; jeder Einzug bevorzugt spring(). Immer extrapolateLeft/Right: "clamp".
2. Einblendungen animieren 2–3 Eigenschaften gleichzeitig (Opazität + translateY + Skalierung). Ein einzelner Fade ist verboten.
3. Alles staffeln. Listen, Wörter, Strahlen, Karten: 3–6 Frames Versatz. Nichts tritt gleichzeitig ein.
4. Ausblendungen existieren und sind schneller als Einblendungen (~10 Frames vs. ~20).
5. Fünf-Schichten-Stapel in jeder Szene, von unten nach oben: Hintergrund-Mesh → Assets → Grafiken/Schrift → Farbkorrektur → Körnung + Vignette. Niemals einen flachen festen Hintergrund.
6. Jedes Standbild erhält Ken Burns (langsame Skalierung 1→1.08 + Schwenk). Jedes Videomaterial verwendet <OffthreadVideo>, niemals <Video>.
7. Ruhende Elemente atmen: Alles, das >2s auf dem Bildschirm ist, erhält eine Sinuswellen-Mikrobewegung.
8. Das gesamte Timing leitet sich von fps über useVideoConfig() ab. Keine magischen Bildnummern.
9. Ein Theme-Objekt am Anfang des Projekts (Farben, Easing-Kurven, Spring-Voreinstellungen, Schriftarten). Niemals eine Hex-Farbe oder Easing-Kurve inline in einer Komponente verwenden.
10. Rendern, Einzelbilder extrahieren, ANSEHEN, korrigieren, erneut rendern. Niemals ein ungeprüftes Rendering ausliefern. Dieser Kreislauf ist obligatorisch – siehe Verifikation unten.

Arbeitsablauf

Schritt 1 – Umfang

Bestimmen: Dauer, fps (30 Standard; 60 nur bei starker schneller Bewegung), Abmessungen (1080×1920 Reels/Shorts, 1920×1080 Querformat), welche Assets vorhanden sind (Bilder, Videomaterial, Audio, Logos) und ob es sich um eine neue Komposition oder eine Bearbeitung eines bestehenden Projekts handelt. Bei Bearbeitung eines bestehenden Projekts: src/ zuerst vollständig lesen, das Theme finden (oder erstellen) und Verstöße gegen die obigen Regeln umgestalten, bevor Funktionen hinzugefügt werden.

Schritt 2 – Einrichtung

Neues Projekt:

npm install remotion @remotion/cli react react-dom
# optional: @remotion/transitions @remotion/motion-blur @remotion/google-fonts

assets/theme.ts aus dieser Fähigkeit in src/theme.ts kopieren und die Palette an die Marke des Benutzers anpassen. Struktur: src/index.ts (registerRoot) → src/Root.tsx (Composition, duration/fps/size) → src/scenes/*.tsx → src/components/*.tsx. Benutzer-Assets werden in public/ abgelegt und über staticFile() geladen.

Schritt 3 – Bauen

references/motion-patterns.md für die implementierbaren Wiederverwendungskomponenten lesen (BgMesh, Grade, Grain, Vignette, KenBurns, WortReveal, Stagger, Counter, Spark, Übergänge, Parallax). Szenen aus diesen Mustern zusammensetzen. Für Tempo, Rhythmus, Typografie, Farbpaletten und Sounddesign-Regeln references/design-rules.md lesen.

Szenenrhythmus: HIT → halten (15–20 unbewegte Frames) → aufbauen → HIT. In den ersten 15 Frames muss sich etwas bewegen. Niemals >90 Frames ohne ein neues visuelles Element.

Schritt 4 – Rendern

npx remotion render src/index.ts <CompId> out/video.mp4 --codec h264 --crf 17

Remotion benötigt eine Chromium-Binärdatei. Wenn das automatische Herunterladen fehlschlägt (Sandboxes, offline CI), eine finden und explizit übergeben:

which chromium chromium-browser google-chrome 2>/dev/null
ls /opt/pw-browsers 2>/dev/null   # Playwright-Installationen befinden sich hier
npx remotion render ... --browser-executable=<Pfad>

Wenn volles Chrome mit „Old Headless mode has been removed“ fehlschlägt, stattdessen eine headless_shell-Binärdatei verwenden (Playwright liefert eine als chromium_headless_shell-*/chrome-linux/headless_shell).

Schritt 5 – VERIFIZIEREN (obligatorisch, niemals überspringen)

Einzelbilder zu Schlüsselmomenten extrahieren und jedes visuell prüfen. Die portable Methode – funktioniert auf Maschinen ohne System-ffmpeg, rendert das exakte Bild:

for f in 15 45 90 150; do
  npx remotion still src/index.ts <CompId> out/check_$f.png --frame $f --overwrite
done

Wenn System-ffmpeg verfügbar ist, extrahiert die Methode aus dem fertigen mp4 auch die Kodierung selbst (-ss ist portabler als select=-Filter, deren Zitierung in manchen Shells und in Remotions gebündeltem ffmpeg kaputtgeht):

ffmpeg -v error -ss 1.5 -i out/video.mp4 -frames:v 1 check_1.png

Suchen und korrigieren, in der Reihenfolge der Häufigkeit:

• Abstandsfehler: gap/margin in em wird gegen die SCHRIFTGRÖSSE DES ÜBERGEORDNETEN ELEMENTS (oft 16px) aufgelöst, nicht gegen die Textgröße – in Flex-Containern um große Schrift px-Werte verwenden.
• Text läuft über oder berührt Bildschirmränder (kritischen Inhalt in den mittleren 75% vertikal für 9:16 halten – UI der Plattform bedeckt oben/unten).
• Elemente, die vor ihrer Einblendung oder nach ihrer Ausblendung sichtbar sind (fehlendes Clamping).
• Farb-/Kontrastfehler: Hauptfarbe auf >1 Element pro Bild, schwacher Text über der Grade unleserlich.
• Schichtreihenfolgefehler (Körnung/Vignette müssen oben sein, Grade über dem Inhalt). Korrigieren → erneut rendern → erneut extrahieren → erneut prüfen. Nur nach einer sauberen Prüfung ausliefern. Dann die endgültige Checkliste am Ende von references/design-rules.md durchgehen.

Benutzer vorhandenes Videomaterial bearbeiten

Um ein vorhandenes MP4 zu verbessern (Untertitel, Grade, Intro/Outro) anstatt von Grund auf neu zu bauen: Datei in public/ ablegen, als Asset-Schicht mit <OffthreadVideo src={staticFile("clip.mp4")} /> rendern, Kompositionsdauer an die Clip-Länge anpassen und Grafiken/Grade/Körnung darüber stapeln. Clip-Länge und fps mit ffprobe abrufen, bevor die Komposition eingerichtet wird. Für wortgenaue Untertitel über Sprache siehe den Untertitel-Abschnitt von references/motion-patterns.md.

Referenzdateien

• references/motion-patterns.md – Copy-Paste-Komponentenbibliothek: Hintergründe, Grade/Körnung/Vignette, Ken Burns, Texteinblendungen, Zähler, Übergänge, Parallax, Audio-Sync, Untertitel. Vor dem Schreiben von Komponenten lesen.
• references/design-rules.md – Paletten, Typografieregeln, Szenenarchitektur, Sounddesign, Checkliste vor der Auslieferung. Vor dem Entwerfen von Szenen und vor der endgültigen Auslieferung lesen.
• assets/theme.ts – Die Theme-Vorlage, die in jedes Projekt kopiert werden soll.

Häufige Fehlermodi, die aktiv vermieden werden sollten

• Emojis als Icons. Emojis werden als Vollfarb-Plattform-Glyphen dargestellt (grünes ✳️, blaues 🌐), die Ihre Palette ignorieren und leise die Eine-Hauptfarbe-Regel brechen, und sie sitzen auf dem Hintergrund, den Sie ihnen gegeben haben (orangefarbenes Maskottchen auf orangefarbener Kachel = unsichtbar). Glyphen mit CSS/SVG in Theme-Farben zeichnen oder jedes Emoji gegen die extrahierten Bilder prüfen.
• Keine SFX-Assets ist kein Grund, stumm auszuliefern. Ein minimales Kit als 16-Bit-WAVs aus einem Node-Skript synthetisieren (Rauschstoß-Whoosh, Tonfalltropfen-Pop, Sinus-Tiefschlag-Kick/Bass, verstimmter Sinus-Pad) in public/sfx/ – siehe examples/scripts/ im Repository. Null Downloads, vollständig deterministisch.
• Eine riesige Komponente generieren anstatt themenbezogener, wiederverwendbarer Teile.
• durationInFrames-Missverhältnis zwischen Composition und Szeneninhalt (tote Luft).
• --overwrite bei erneuten Renderings vergessen, dann die veraltete Datei prüfen.
• Schriftarten: nie bei Helden-Text auf Systemvorgaben verlassen; eine Display-Schriftart über @remotion/google-fonts oder @font-face + staticFile laden.
• Versuchen, dem Benutzer das Ergebnis „zu beschreiben“, anstatt es zu rendern und zu verifizieren.