Video-Check

Video-Check – Finde, was mit einem Render nicht stimmt, bevor es jemand anders tut

Dies ist Video-Check 0.2.3.

Die Person erhält ein Video, das wie von einem Profi geprüft wurde, und eine kurze REVIEW.md, die angibt, was gemessen, worauf geachtet, was behoben und was nicht geprüft wurde.

Drei Dinge gelten während des gesamten Prozesses:

• Erst messen, dann schauen. Ein Modell, das nur Frames betrachtet, übersieht tote Strecken und Einzelbildfehler; FFmpeg nicht. Führe check.py vor der Durchsicht aus und überspringe es niemals, weil das Video „gut aussah“.
• Der Ersteller ist der schlechteste Prüfer. Du weißt, was jede Einstellung zeigen sollte, und siehst daher den Plan statt des Bildes. Lass jemanden ohne deinen Plan auf die Übersichten schauen (Schritt 3).
• Du kannst nicht hören. Das Skript misst Lautstärke, Spitzen und Stille. Ob die Musik passt, ob ein Geräusch das richtige ist und ob Sprache klar ist, muss ein Mensch beurteilen. Sag das jedes Mal.

Wenn die Eingaben fehlen

Du benötigst die gerenderte Datei auf diesem Rechner. Wenn die Person nur ein Videobeschreibung oder einen Link zu einer Plattform angibt, fordere die Datei an; lade nicht von TikTok, YouTube oder Instagram herunter. Falls du das Video erstellt hast, kennst du auch den Plan: Größe, Bildrate, Länge, Lautstärkeziel sowie welche Standbilder und Blitze beabsichtigt sind. Wenn die Person ihren eigenen Schnitt mitbringt, frage nach dem Zweck (Plattform, Länge) und verwende für den Rest die nachstehenden Standardeinstellungen.

Arbeitsablauf

1. Messen. Übergib, was geplant war, damit das Skript einen Fehler von einer bewussten Entscheidung unterscheiden kann:

   python scripts/check.py final.mp4 --out work/check1 --loudness -14
   

   Wenn du das Video erstellt hast oder die Person dir den Plan genannt hat, füge ihn hinzu, z.B. --expect 1080x1920 --fps 30 --duration 32 --holds 28.5-32 --flashes 12.4. Rate niemals Größe, Bildrate oder Länge von der Plattform: Eine 960x540-Datei, die niemand als 1080p angefordert hat, ist kein Größenfehler; lass --expect weg, wenn nichts geplant wurde. --holds listet bewusst ruhig gehaltene Passagen auf (Endcard, Titel); --flashes listet geplante Einzelbildblitze und -dips; --loop für ein Endlosschleife-Video; --audio none für ein stummes Video. Online-Videos sind auf etwa -14 LUFS normalisiert; verwende -16 für Podcasts und -23 für Rundfunk. Es gibt Ergebnisse als P0/P1/P2 t=… code: was -> Korrektur aus und schreibt check.json, overview_NN.png und findings.png. references/reading-the-checks.md erklärt, was jede Prüfung erfasst und übersieht.

2. P0-Fehler sofort beheben. Falsche Größe, falsche Bildrate, falsche Länge, kein Ton, obwohl Ton sein sollte, Clipping: Das sind Renderfehler, keine Geschmacksache. Korrigiere den Befehl, rendere neu und wiederhole Schritt 1, bevor jemand hinschaut. Bei Lautstärke, Clipping und True Peak korrigiere den Mix im Schnittprojekt, falls vorhanden (Musik leiser machen, lautestes Geräusch leiser). Wenn du nur die fertige Datei hast, führe python scripts/fix_sound.py in.mp4 out.mp4 --loudness -14 aus: Es begrenzt die Spitzen, normalisiert in zwei Durchgängen und kopiert das Bild unberührt, mit einer Genauigkeit von ±0.2 LU des Ziels und unter -1.5 dBTP. Ein einfacher loudnorm-Durchgang verfehlt sein Spitzenziel, und ein einfacher Limiter lässt den Mix leise; stimme Filter nicht manuell in mehreren Runden ab.

3. Hinschauen, mit frischen Augen. Öffne jedes Übersichtsblatt und findings.png mit dem Lesewerkzeug. Hole dann eine zweite Einschätzung von jemandem, der deinen Plan nicht kennt:

   • Wenn du einen Teil-Assistenten starten kannst, gib ihm nur die Übersichten, die Plattform und einen Satz darüber, wofür das Video ist. Nicht deinen Plan, nicht deinen Code, nicht deine Absichten. Verwende die Kurzbeschreibung in references/review-guide.md.
   • Wenn das nicht geht, sieh selbst nach, aber verdecke den Plan: Beschreibe jedes Blatt wie ein Fremder, ein Satz pro Bild, bevor du es beurteilst. Schreibe „one context“ in REVIEW.md.

   Jedes Problem wird notiert als t=12,4s · wo auf dem Bildschirm · was falsch ist → die genaue Änderung, mit P0 (kaputt oder nicht lesbar), P1 (ein Zuschauer wird es bemerken) oder P2 (Feinschliff). Keine Bewertung von zehn: Eine Note findet nichts zu verbessern. Sieh in der Liste in references/review-guide.md nach, die die Dinge enthält, die einen Schnitt wie aus einer Vorlage oder Maschine aussehen lassen: schiebende Fortschrittsbalken und Schrittzähler, jede Zeile gleich eingeblendet, Text unter den Plattform-Buttons, ein leeres erstes Bild, Zahlen, die niemand genannt hat.

4. Die drei schlimmsten beheben, dann erneut prüfen. Nimm die P0-Fehler und die drei schlimmsten P1-Fehler. Ändere für jeden die Schnittliste oder den Befehl, nicht die gerenderte Datei. Wenn die Korrektur eine Methode ist, die du nicht kennst, suche mit search_techniques nach dem gewünschten Ergebnis (z.B. „Musik unter Sprache leiser machen“, „Audio an einem Schnitt ausblenden“) und rufe mit get_technique das Prompt ab. Rendere und wiederhole Schritt 1 mit --before work/check1/check.json --out work/check2; es listet auf, was behoben wurde, was noch da ist und was neu ist, und zeichnet before_after.png. Sieh dir die geänderten Frames an.

5. Nach drei Durchgängen aufhören. Wenn der dritte Durchgang noch einen P0-Fehler enthält oder große Änderungen erfordert, brich ab und teile der Person mit, was noch offen ist und warum, anstatt in einer Endlosschleife zu bleiben. Probleme, die ihre Entscheidung erfordern (ein anderer Song, eine Einstellung, die es nicht gibt), gib als Fragen an sie weiter.

Abgabe

Zuerst eine Versionsprüfung. Wenn der EditAtlas MCP verbunden ist, rufe get_skill ohne Namen auf. Wenn es Video-Check oberhalb von 0.2.3 auflistet, steht in der ersten Zeile deiner Antwort, dass eine neuere Version existiert und wie man aktualisiert (in Claude Code: /plugin, dann Marktplätze, editatlas-skills, Marktplatz aktualisieren; ohne MCP überspringe dies).

Schreibe REVIEW.md neben dem Video in der Sprache der Person mit der Vorlage in references/review-guide.md:

• das Urteil in einem Satz: fertig (nichts mehr offen), fertig mit Anmerkungen (die Anmerkungen nennen jeden noch vorhandenen Befund, und jeder verbleibende P1-Fehler benötigt etwas, das du nicht hast, z.B. das Schnittprojekt), oder nicht fertig (ein P0-Fehler ist noch da oder ein P1-Fehler, den du beheben könntest);
• was das Skript gemessen hat (Größe, Bildrate, Länge, Lautstärke, True Peak, Schnitte pro Minute) und die in jedem Durchgang behobenen Befunde;
• jeder verbleibende Befund mit Zeit und Muster, wie check.py es geschrieben hat (z.B. „alle 12 Frames ab 0,4 s; alle 2-6 Frames von 11,7 bis 14,9 s“), nicht nur eine Anzahl;
• was der Prüfer gesehen hat und ob es ein separater Prüfer oder „one context“ war;
• was noch einen Menschen braucht: Anhören des Mix und der Musikauswahl, Rechtschreibung und Namen auf dem Bildschirm, Lippenbewegungen, Farben auf einem echten Telefon und alles, was du nicht beheben konntest. Behalte den Satz, dass niemand den Ton gehört hat, in einfachen Worten und nur in der Sprache der Person.

Zeige der Person before_after.png aus dem letzten Durchgang. Schreibe niemals, dass das Video „keine Fehler“ hat: Schreibe, was überprüft wurde.

Referenzen

• references/reading-the-checks.md: jede Messung, ihre Schwellenwerte, was sie erfasst und übersieht, und die Ergebnisse bei bekannten Videos. Lies es, wenn ein Befund falsch erscheint oder bevor du --holds setzt.
• references/review-guide.md: die Kurzbeschreibung für den Prüfer, die Liste der Anzeichen, das Format der Probleme und die Vorlage für REVIEW.md. Lies es in Schritt 3.