TimeCraker/video-motion

video-motion — Video-Overlays mit Animationen (Remotion)

Design als Code: Koordinaten / Zeitpunkte / Texte werden alle in src/cues.ts deklariert (Datenvertrag, Felder dürfen nicht geändert werden); fx-Komponenten enthalten keine hartcodierten Werte. Ändern Sie die Cues und führen Sie einen Befehl aus, um das gesamte Video neu zu generieren. Drei Animationsebenen: Untertitel SubtitleTrack / Datenbalken DataBars / Spotlight-Markierungen Spotlight (Kreis / Pfeil / Kasten).

Technische Diagramme, Prozess-/Datenbildschirme, Lottie, 3D, Karten oder Studio-Parameterbearbeitung erfolgen gemäß den entsprechenden Zweigen in Spezial-Visualisierungen. Der Regisseur gibt den Inhalt und die visuelle Richtung vor, das Produktionsmodul liefert die eigentlichen Projekt-Assets/Code und Rendering-Nachweise; aktuelle Komponenten, Typen und die Schnittstelle zur Rendering-Engine haben Vorrang.

Serienvideos setzen die Rubriken-Konventionen gemäß Serienkonsistenz in den Tokens, Schriftarten, Szenen, Untertiteln, Covern und tatsächlichen Audiospuren des Projekts um. Verwenden Sie die tatsächliche Eingabeversion und rendern Sie mit dem aktuellen Inhalt zum Vergleich; ändern Sie nicht einfach einen Themenwert und gehen Sie davon aus, dass das gesamte Video einheitlich ist. Für Produktdemos verwenden Sie tatsächliches aufgezeichnetes/erfasstes Material mit Overlays; spätere Maus- oder Spotlight-Markierungen müssen echten Aktionen und Ergebnissen entsprechen.

Schritt 1 · Drehbuch-Design (Material ansehen, nicht raten)

1. Material frameweise ansehen: npx remotion still remotion/index.ts FootageOverlay <output>/f-<n>.png --frame=<n>, wählen Sie Frames basierend auf Szenen und wichtigen Änderungen aus. Verwenden Sie den absoluten Pfad des tatsächlich generierten Bildes zum Lesen.
2. src/cues.ts Animations-Drehbuch schreiben:
   • Untertitel erklären das Bild: Sagen Sie dem Zuschauer, was er gerade sieht, segmentieren Sie es semantisch und entsprechend der Lesegeschwindigkeit.
   • Spotlights zeigen echte Objekte: Kreis / Pfeil / Kasten zeigen auf Elemente im Bild, die real und beachtenswert sind. Koordinaten zuerst mit Einzelbildern auf Treffsicherheit prüfen.
   • Zahlen brauchen Quellen: Werte von Datenbalken stammen aus echten Quellen (Bildschirm-HUD / Ergebnispanel / Backend-Daten). Falls nicht verfügbar, kennzeichnen Sie den Untertitel mit „Demonstrationsdaten“.
3. Interpretieren Sie Details, die für das Ziel relevant sind: HUD, Chat, Hinweise und Aktionen können als Beweise dienen, aber nur Inhalte markieren, die zur Erklärung notwendig sind. Nicht das gesamte Bild mit Cues füllen.

Schritt 2 · Technik und Spezifikationen (passen sich dem Material an)

1. Kopieren Sie templates/remotion-app/ ins Arbeitsverzeichnis, npm install (alle Remotion-Pakete müssen in derselben Installation installiert werden, Versionen strikt gekoppelt). Nach der Installation npm run typecheck ausführen (esbuild-Toleranz ist nicht gleich Typenreinheit, erst tsc zeigt es; Vorlage enthält TypeScript-DevDependency, sofort lauffähig).
2. Native Spezifikationen: node scripts/probe-footage.mjs <Material-Pfad> verwendet ffprobe, um src/footage-params.ts zu generieren – Ausgabeauflösung / Bildrate folgt dem Material, nicht fest codiert. Dieses Skript bei Materialwechsel erneut ausführen.
3. Material nicht im Skill: Rendern mit --public-dir <Material-Verzeichnis> (staticFile liest direkt aus der Projekt-Mediathek). Material nur dann in public/footage.mp4 kopieren, wenn Parameter nicht möglich sind.
4. Cues für 1080p-Designkoordinaten schreiben, FootageOverlay hat bereits transformOrigin: "top left" integriert, das für jede Leinwandgröße skaliert – Auflösung ändern, ohne Cues zu ändern, Animationspositionen bleiben.

Schritt 3 · Generierung (Ein Befehl)

Vor dem Rendern zuerst validieren: node scripts/verify-cues.mjs (Deck-Untertitel verwenden Parameter von src/deck-cues.ts). Fehler auf Null setzen, dann rendern; Gesamtlängen-Warnungen nur zur Information, kein Block.

cd <remotion-app>
npx remotion render remotion/index.ts FootageOverlay <Repository>/products/<Projektname>/demo.mp4 --crf=16 --public-dir <Material-Verzeichnis>

Das Produkt liegt im Repository products/<Projektname>/ (Verzeichnisregel: Skill ist reines Werkzeug, Produkte landen nicht im Skill. Bei Repos-übergreifender Nutzung im Projektstamm output/<Skill-Name>/). --crf=16 für hohe Qualität. Großes Material im Hintergrund rendern (1440p60 × 30s ca. 10 Minuten). Überprüfung über Exit-Code + ffprobe, nicht über Fortschrittsbalken.

Schritt 4 · Drei Qualitätskontrollen (Pflicht, nicht überspringbar)

① Programm: Rendern Exit-Code 0. npx remotion compositions remotion/index.ts Ausgabe durationInFrames / Breite / Höhe / fps stimmen mit Material-Metadaten überein. npx remotion still repräsentative Frames basierend auf Schlüssel-Untertiteln, Datenänderungen und Übergängen auswählen – jeder Untertitel start+0.3s / end-0.3s, Datenbalken t-0.3s / t+1.5s, Spotlight t+0.5s / t+ttl+0.3s (Frame-Nummer mit tatsächlichem fps aus compositions berechnen).

② Bildbetrachtung: Tatsächliche PNGs Frame für Frame prüfen: Erscheinungs-/Verschwindenszeitpunkte mit Text, Balkenhöhenverhältnisse mit Zahlenlabeln, Spotlight-Typ und Position, Hintergrund kein Rauschen / keine Verzerrung, kein Zeichensalat (Chinesisch mit Microsoft YaHei Fallback). Probleme in entsprechende Quelldateien zurück schreiben, nach Neurenderung ursprüngliches Problem und angrenzende Stellen prüfen; bei unklaren oder nicht behebbaren Blockaden klar berichten.

③ Kontinuierliche Wiedergabe und Hörkontrolle: Einzelframes beweisen Rhythmus und Synchronisation nicht. Mit media-qc audiovisueller Methode tatsächliche Segmente und Tonspuren prüfen, Prüfumfang dokumentieren. Endkontrolle durch Benutzer.

Schritt 5 · Lieferung

Bericht: Pfad und Größe des fertigen Videos / Auflösung Bildrate (=Material nativ) / Ergebnis der drei Qualitätskontrollen (mit Einzelbild-Prüftabelle) / cues.ts Position (erneut ausführbar). Produkte und mp4 niemals in git.

PPT Folie für Folie als Video (DeckVideo, zweite Ausgabeform)

Eine Engine, zwei Ausgabeformate: Die obigen Schritte sind „Video-Overlay mit Animationen“, dieser Abschnitt ist „PPT-Folienweise“ – PPT-Folienbilder + Sprachaufnahmen pro Folie direkt zum Video, Folienlänge folgt der tatsächlichen Audiospur, Untertitel erscheinen gemäß Zeitplan des Segment-Skripts.

1. PPT und Segment-Skript: ppt erzeugt pptx; Narrations-Segment-Skript script.json schreiben, ref schreibt "page N" (N = Foliennummer). Zuerst python skills/narration/templates/verify_narration.py <script.json> ausführen, alles grün. Jedes Segment ≤20 Zeichen (Untertitel-Einzeiler zeigt direkt Segmenttext). Mehrere Segmente pro Folie durch Satzpunkt zur Sprachausgabe verbinden.
2. Folienbilder: python scripts/extract_pages.py <in.pptx> public/deck/pages – COM nach PDF, dann fitz mit 200dpi, Ausgabe p-<N>.png (2667×1500, Leinwand mit contain gefüllt).
3. Sprachaufnahmen: Test: powershell -File scripts/make_deck_audio.ps1 <script.json> public/deck/audio (SAPI Huihui pro Folie page-N.wav). Produktion: Manuell in Jianying pro Folie aufnehmen, gleichnamige page-N.wav in dasselbe Verzeichnis exportieren, downstream transparent.
4. Verkabelung und Rendern: node scripts/build-deck-params.mjs <script.json> public/deck generiert src/deck-params.ts + src/deck-cues.ts (Seitenstart / Gesamtlänge / Untertitelverteilung alles abgeleitete Werte, nicht manuell ändern) → npx remotion render remotion/index.ts DeckVideo <Repository>/products/<Projektname>/deck.mp4 --crf=16.
5. Drei Qualitätskontrollen: Wie Schritt 4 (Programm ffprobe / compositions Abgleich + Einzelbild-Betrachtung + Benutzerkontrolle). L2 Einzelbild-Punkte: Jede Folie erster Frame+0.3s auf Reihenfolge prüfen; Überlappungsmittelpunkt nimmt Folie start+0.25s (Überlappungsende am Seitenfenster-Ende, 0.5s Cross-Dissolve). Untertitel start+0.3s / end+0.3s auf Text und Ausblendung prüfen. Am Folien-Start+0.3s ist spring-Einblendung nicht voll, Frame etwas grau – das ist Übergangszwischenzustand, kein Fehler.

Folienbilder und Audio liegen in public/deck/ (.gitignore deckt ab, nicht in git); Leinwand 1920×1080@30 Konstante in build-deck-params.mjs oben, zwei Zeilen ändern für 4K.

Szenenbasierte Videos v2→v3 Look-Qualität (scene-kit Direktzeichnung, drittes Ausgabeformat)

Upgrade-Linie der PPT-Folien-Videos: Bildinhalt von „PPT-Folienbildern“ auf Remotion-Komponenten direkt gezeichnete animierte Szenen ( src/scene-kit/ 24 Komponenten). Folienlänge/Audio/Untertitel-Mechanismus folgt deck-params Ableitungskette. „Schlicht“ oder „Billig“ anhand docs/2026-08-30-motion-grammar.md beurteilen; dieser Abschnitt enthält harte Regeln für die Craftmanship.

Qualitätsuntergrenze

Akzeptanzmethode nach Inhaltstyp aus docs/2026-08-30-motion-grammar.md wählen. Tokens und Markenkonsistenz bewahren. Bildinhalt auf echte Hauptobjekte und lesbare Informationen konzentrieren, Bewegung erklärt Veränderungen. Leerraum, Standbilder und Informationsmenge pro Einstellung nach Ziel beurteilen, keine festen Quoten oder Standbild-PPT-Ablehnung.

Zunächst von content-director Faktenquellen, Storyboard und Art-Briefing bereitstellen lassen, dann repräsentative Frames und kurzes Sample betrachten. Strukturdiagramme bevorzugt SVG, echte Oberflächen mit Screenshots/Video, Illustrationen bei Bedarf mit verfügbarem imagegen-Tool erstellen und Assets registrieren. Neue ArtLayer und mehr Animationen bedeuten nicht automatisch Qualitätsdurchgang.

Szenen-Design-Methode (allgemein, keine vorgegebenen Antworten)

Zuerst assets/patterns.md Lösungsbibliothek prüfen – ob es für ähnliche Situationen validierte PAT-Einträge gibt, dann anpassen (Situation→Layout→Komponente→Stolperfalle→Referenzbild sind im Eintrag). Wenn nichts, von Grund auf neu entwerfen. Pro Seite zuerst Inhaltstyp bestimmen (Narrativ-Schmerzpunkt / Funktionsdemo / Datenüberzeugung / Prozesserklärung / Konzept / Call-to-Action sechs Typen). Dann nach drei Regeln: Hauptobjekt durch Textinhalt bestimmen; gleicher Typ mehrere Seiten nicht dieselbe visuelle Lösung wiederholen; Hintergrundfamilie dient der Inhaltsstimmung. Vor Arbeitsbeginn Design-Tabelle erstellen (pro Seite: Textzusammenfassung → Inhaltstyp → Hauptobjektform → Hintergrundfamilie → Komponentenkombination → Begründung → Bildinformationspaket mit Quelle → Hauptobjektmarkierung). Design-Tabelle vorab prüfen, erst nach Bestehen Code schreiben. Quellen für jede unterstützende Information angeben (Sprachskript / Projektdokumentation / sichtbarer Materialinhalt).

Drei harte Lektionen (als Regeln festgehalten)

1. Fertigzustand erlaubt Lesepausen: Chat, Diagramme oder Prozesse, die Zustandsänderungen zeigen, verwenden vorhandene Komponenten. Standbilder nach Information und Rhythmus beurteilen, keine dekorativen Animationen für Prüfergebnisse erzwingen.
2. Wrapper-Komponenten müssen width explizit übergeben: Neuer Container um alte Komponente verliert width = Block-Element füllt Elterncontainer (Illustration deckt Titel, Telefonrahmen auf 700px Breite – gleiche Ursache zweimal). Container immer style={{ width, ...style}}.
3. Lange Screenshots zuerst Leerraumrate prüfen, dann Lösung wählen: Bei langem Screenshot zuerst std/Leerraumanteil pro Zeile berechnen (PIL Skript). „Leere lange Bilder“ durch Lazy-Loading nicht gerendert – Scrollen tötet sofort Leere. Zuerst Ausschnitt, Material reparieren, dann Scrollen zurück.

MG-Waffenarsenal (S0-S6, Hauptmunition für Look-Qualität)

Vorlage enthält volles Arsenal. Basis und Komponentennutzung nach assets/component-catalog.md (scene-kit 24 Komponenten / entrance-kit neun Verben / vendor Community-Selektionen / Fonts). Hier nur eiserne Regeln:

• Versionseisen: Alle @remotion/* müssen exakt gleiche Version (z.B. 4.0.533, ohne ^) – Versionsfehlpassung ist harter Remotion-Fehler, keine Warnung. Neues Paket zuerst auf vorhandene Version abstimmen (check-docs 3.7 Punkt überwacht, bei Abweichung rot).
• 4.0.533 API-Fakten (abweichend von Doku/Erinnerung, getestet; Upgrade 4.0.518→4.0.533 mit still-Basis PSNR all inf, API-Form unverändert): evolvePath gibt dash-Eigenschaften für nicht-geclippte paths zurück. interpolatePath(value, from, to) drei unabhängige Parameter. fitText akzeptiert nur withinWidth und gibt {fontSize} Objekt zurück. Chinesische Mehrzeiler nicht mit fitTextOnNLines (Worttrennung nach Leerzeichen). parseSrt akzeptiert {input} Objekt (roher String wirft undefined.split). Rückgabe {captions:[{text,startMs,endMs}]} Millisekunden.
• Transform-Wrapper-Falle (S6 Doppelfalle): Transform-Wrapper-Verben (CameraPush/SlideGroup/TextBreath/BlurTrail) dürfen nicht direkt position:absolute Subbäume wrappen – transform-Element ist containing block für absolute Nachkommen, Fließhöhe auf 0, Inhalt läuft über. Komponenten sind selbstgenügsam (CameraPush root inset 0, BlurTrail Hauptebene in flow). Trotzdem vermeiden, nackt in absolutem Elterncontainer ohne Größe zu wrappen.
• Offizielles <Trail>/TransitionSeries Semantik: Trail root ist AbsoluteFill (Seiten-Level Overlay-Semantik). Element-Level Afterimage mit scene-kit's BlurTrail (bereits relativiert). TransitionSeries Übergänge fressen benachbarte Seitenlängen, Video-Engine standardmäßig Null-Übergänge (Series harter Schnitt) + Seiten-interne Verben.
• Vendor-Disziplin: copy-paste ins Repository, kein npm-Dependency. Upgrade = erneut pullen, erneut intake machen. Vier Disziplinen siehe Vorlage src/vendor/README.md.
• Lottie-Asset-Fluss: Kostenlose kommerzielle JSONs in assets/lottie/ (Drei-Felder-Registrierung in README) → bei Nutzung ins Projekt public/ kopieren → LottieLayer src Referenz. Intake keine JSONs mit expressions (Rendering unsicher).
• Komplex-Effekt-Budget: ShutterBlur's samples und BlurTrail's layers erhöhen Rendering-Kosten. ThreeStage je nach Szene und Maschine testen. Zuerst repräsentative Frames/kurzes Video rendern, dann Umfang entscheiden, keine feste Shot-Anzahl pro Video.

Akzeptanzprozess (vierstufig)

L1 Programm (Rendering Exit-Code vollständiges Log nehmen, kein Pipe-Ende; ffprobe = compositions Frame-Abgleich). L2 Einzelbilder (nach Risiko auswählen: Eintritts-/stabiler Panorama-/Informationsdetail-/Übergang und Untertitel-Repräsentativ-Frames, tatsächliche Bilder prüfen; Vergrößern nur für Details, keine feste Anzahl pro Seite). L2.5 Stummtest (pro Seite blinde Zusammenfassung). L3 Bericht (technischer Umfang, Keyframe-Beweise, menschlich zu prüfende Punkte und ggf. alter/neuer Vergleich). Komponenten, Tokens und Layouts, die allgemein wertvoll sind, gemäß Asset-Rückfluss-Konvention in Vorlagen/Register zurückschreiben. Projektspezifische Inhalte im Projekt behalten, ohne neue Erfahrung keinen zusätzlichen Task erstellen. Rendering-Befehl wie DeckVideo (composition auf szenenbasierten Komponenten, z.B. DeckVideoV2). Cover mit npx remotion still rendern (still Frame-Nummer muss Spring-Einblendungsdauer einbeziehen).

Cover-Bild (Cover, viertes Produkt)

Kein Video, nur ein Frame: Ein Befehl erzeugt 1920×1080 Cover-PNG als Begleitbild für das Video.

1. Props: products/<Projektname>/cover-<Name>.json schreiben { title, subtitle?, badge?, bg?, preset }. preset ∈ photo (bg-Bild vollflächig + untere 55% Schwarzverlauf für Kontrast) / dark (dunkler Verlauf, Standard) / clean (heller Hintergrund + oben dünne Linie). bg relativ zu remotion-app public/. subtitle weggelassen = nicht rendern; badge weggelassen = ASTERFORGE Marken-Ecke.
2. Rendern: npx remotion still src/cover-index.ts Cover <output>.png --props=<JSON-Dateipfad> (separater Einstieg, nicht über Root.tsx, parallel zu DeckVideo ohne Konflikte).
3. Prüfung: Bild lesen, Titel vollständig ohne Abschneiden, Text unter photo-Verlauf lesbar, keine Müllzeichen. Tatsächliches Produkt mit absolutem Pfad verwenden, aktuelle Version oder Hash prüfen. Titelzeilen an Zielgröße und Lesebedarf anpassen.

Grenzen und Fallstricke

• Tatsächliches Produkt mit absolutem Pfad lesen, aktuelle Dateiversion oder Hash prüfen. Pfad nur umwandeln, wenn konkretes Tool Pfadeinschränkung hat.
• GBK-Konsole: print nur Englisch.
• Chrome Headless Shell erstes npx remotion browser ensure lädt von Google (100 MB), in China Netzwerk ggf. Timeout – Fehler sofort melden, nicht wiederholt große Dateien herunterladen.
• Große Medien, Abhängigkeiten und Caches nicht in Git. Rezepte, Cover, Untertitel, Veröffentlichungskonfiguration und Akzeptanz-Metadaten nach Archivierungsregeln behalten.

Aktueller Workflow und technische Referenzen

node scripts/studio.mjs init --id <Name> --line b bringt Vorlage. job.json's deps/typecheck erneut ausführbar. params/render/QC Befehle dieses Projekts nach Bestimmung von Szene und tatsächlicher Tonspur zu job.json hinzufügen. Nach Rendern media-qc aufrufen, technischen Bericht und Benutzerabnahme getrennt dokumentieren. Nach Archivierungsprüfung Cache leeren.

Offizielle remotion-best-practices durch python scripts/install-upstream-skills.py fest in Projekt-Cache installieren, dann von setup-skills eingehangen. Quelle in references/upstream.json; technische Referenz, ersetzt nicht diesen Workflow. Offizielle Referenz 4.0.538 getrennt von aktueller Engine 4.0.533 verwalten, vor Nutzung neuer API lokale Typen und tatsächliches Rendering prüfen, kein automatisches Upgrade.