Chrome Video Render (CVR)

Was macht Chrome Video Render (CVR)?

Android/proot Browser- und Rendering-Adapter für Remotion und HyperFrames. Die Komposition und Audio-Zeitachsen bleiben Eigentum des Videoprojekts.

Startmodi

Modus	Verwendung	Startverhalten
cvr	Standard, alltägliche Render-Vorgänge	Erster Durchlauf misst Kurz-/Lang-Render-Pläne (Dauer skaliert mit Anzahl der Kandidaten, wird vorher angekündigt); spätere Durchläufe lesen die Pläne und beginnen sofort; keine zusätzlichen npm/Browser-Versionsabfragen; prägnante einzeilige Ausgabe
rvc	Diagnose, Release-Prüfungen	Misst beide Pläne bei jedem Durchlauf neu und überschreibt die gemeinsame Plan-Datei (Verlauf bleibt erhalten); vollständiger Umgebungsbericht, detaillierte Hardware-Budget-Aufschlüsselung, segmentweise Validierung und optionale Synchronisationsprüfung; zeitliche Zusammenfassung pro Phase

Beide Modi arbeiten im Vordergrund. Unabhängige Jobs werden serialisiert; Parallelität innerhalb eines Jobs ist durch den gemessenen Plan begrenzt.

# leichtgewichtig
python3 /skills/chrome-video-render/scripts/remotion-segmented.py --project . --composition Hello --output out.mp4 --mode quick

# detailliert
python3 /skills/chrome-video-render/scripts/remotion-segmented.py --project . --composition Hello --output out.mp4 --mode full --sync-check

Render-Pläne

Die Anzahl der Worker wird gemessen, nicht geschätzt. Beim ersten Einsatz werden für jede Kandidaten-Workeranzahl zwei feste Proben-Kompositionen über mehrere Runden gerendert. Der Medianwert bestimmt die Bewertung jedes Kandidaten. Der Gewinner wird getrennt für kurze (<=300 Frames) und lange Videos in <project>/node_modules/.cache/cvr-render-plan.json gespeichert. Spätere cvr-Durchläufe lesen den passenden Plan und beginnen sofort mit dem Rendern. rvc misst bei jedem Durchlauf neu, überschreibt die Plan-Datei und rendert den Job mit den neuen Werten; jeder Schreibvorgang wird an eine history-Liste angehängt.

Es wird keine Worker-Anzahl als Standard ausgeliefert, da die optimale Anzahl vom Gerät abhängt. Der erste Durchlauf gibt vor dem Start aus, was er tut, da er pro Kandidat, pro Runde und pro Längenklasse einen Proben-Render-Vorgang kostet. --workers N umgeht die Messung vollständig.

Browser-Umgebung

source /skills/chrome-video-render/scripts/video-browser-env.sh

cvr verwendet die Starter aus dieser Installation. rvc führt zusätzlich render-env.sh --json für Browser-, Engine- und Hardware-Berichte aus. Für ein Checkout außerhalb von /skills verwenden Sie das scripts/-Verzeichnis dieses Checkouts.

Remotion

python3 /skills/chrome-video-render/scripts/remotion-segmented.py \
  --project /path/to/project --entry src/index.ts \
  --composition Hello --output /path/to/output.mp4 \
  --input-props '{"title":"Example"}'

Verwendet das Remotion-Paket des Zielprojekts und die offiziellen APIs selectComposition(), renderMedia() und combineChunks(). Unterstützt fraktionierte FPS und JSON-Eigenschaften. Erzeugt PCM-Segmente und eine abschließende AAC-Lieferkodierung.

Die Segmentgröße passt sich an die Kompositionslänge an, wenn --segment-frames nicht angegeben wird: 90 Frames bis 300 Frames, 150 bis 900, 300 bis 3000 und 450 darüber. Lange Videos werden dadurch nicht in Dutzende von Segmenten aufgeteilt, die jeweils einen Browser neu starten. Verwenden Sie --segment-frames, um eine feste Größe festzulegen.

HyperFrames

Nach der Überprüfung und Genehmigung des Projekts:

python3 /skills/chrome-video-render/scripts/hyperframes-render.py \
  --project /path/to/project --output /path/to/output.mp4 \
  --quality looks --workers 2   # Beispielwert; projektabhängig wählen

Behält die native Zeitachse, den Mixer und das Worker-System von HyperFrames bei. Der Backend-Adapter wird anhand der Funktionssignatur und nicht eines generierten Build-Dateinamens ausgewählt.

--mode quick verwendet den installierten Headless-Shell-Starter; --mode full führt render-env.sh aus und dimensioniert die Worker anhand des Hardware-Budgets. Der zugrunde liegende hyperframes render-Aufruf ist in beiden Modi derselbe, und ein explizites --workers wird in beiden Fällen berücksichtigt. HyperFrames verwendet die gemessenen Render-Pläne nicht.

Überprüfung

• cvr: grundlegende Prüfung von dekodierten Frames, FPS, Abmessungen und Audio-Eigenschaften; der Synchronisationsstatus bleibt not-measured, es sei denn, eine Kalibrierungsprüfung wird angefordert.
• rvc: vollständige Einzeldekodierung, segmentweise Details, Hardware-Budget, markerbasierte Synchronisationsprüfungen und eine zeitliche Zusammenfassung pro Phase.
• check-av-sync.py erfordert eine Kalibrierungskomposition mit bekannten PCM-Impulsen und visuellen Blitzen.
• selftest-av-sync.py validiert sowohl ausgerichtete als auch absichtlich verzögerte Signale.
• webgl-policy-check.py ist ein optionales Backend-Audit, kein routinemäßiger Render-Schritt.

Siehe Implementierung und Kompatibilität, Browser-Backend und Backend-Hinweise.

Validierungsumfang

Getestet auf Android/proot aarch64 mit Remotion 4.0.538 und HyperFrames 0.8.198: fraktionierte FPS, Audio- und stille Kompositionen, Parameterweitergabe und Synchronisationsprüfungen. Die Versionen werden aufgeführt, damit der Leser sehen kann, was getestet wurde, nicht als Anspruch auf unterstützte Versionen.

Der erste Durchlauf kostet einen Proben-Render-Vorgang pro Kandidat, pro Runde und pro Längenklasse, daher skaliert seine Dauer mit der Anzahl der Kandidaten und der Videolänge; es handelt sich um einmalige Kosten pro Gerät, da spätere Durchläufe den aufgezeichneten Plan lesen. rvc misst bei jedem Durchlauf neu. Die adaptive Segmentierung reduziert die Anzahl der Segmente für längere Videos bei gleicher Gesamtzahl dekodierter Frames. Alle von einem Durchlauf erzeugten Zahlen beschreiben die Maschine, die sie erzeugt hat, und sind keine Garantie für andere Geräte.