Modell / Datensatz
HUANGCHIHHUNGLeo/claude-real-video avatar
HUANGCHIHHUNGLeo/claude-real-video

claude-real-video: Szenenwechsel statt fester Bildrate für die Videoanalyse mit LLMs

Let Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames + transcript, from a URL or local file. Runs locally, MIT.

2.144 Sterne189 ForksPythonMIT
GitHub

Auf einen Blick

Was ist das?
Das Python-Werkzeug crv zieht per ffmpeg szenenabhängige Keyframes, entfernt Duplikate, transkribiert lokal und legt einen Ordner an, den jedes multimodale Modell lesen kann. Ein nüchterner Blick auf Mechanik, Grenzen und den Preis der Bequemlichkeit.
Für wen ist es gedacht?
Wer einem LLM Videomaterial zuführen will, ohne die Datei an einen Cloud-Anbieter zu geben, findet in crv ein Werkzeug, das die Auswahl der Bilder tatsächlich als Problem behandelt. Für schnelle, kurze Clips mit harten Schnitten reicht der Standardlauf.
Darf ich es kommerziell nutzen?
Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 5 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich Python, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Das Problem: feste Bildrate trifft die falschen Sekunden

Die README beschreibt den Ausgangspunkt mit einer Gegenüberstellung. Ein 58-Sekunden-Clip ergibt bei einer festen Abtastung von einem Bild pro Sekunde 58 Einzelbilder. crv behält nach der Szenenerkennung 26 davon, weil nur diese sich sichtbar voneinander unterscheiden. Das ist die zentrale Behauptung des Projekts: nicht die Menge der Bilder entscheidet über die Qualität der Antwort, sondern ob die richtigen dabei sind. Der Text nennt das Problem bei multimodalen Diensten direkt. Wer eine URL in ein Chatfenster einfügt, bekommt häufig nur das Transkript zu lesen. Modelle, die Video nativ aufnehmen, arbeiten laut README mit einem festen Intervall, standardmäßig einem Bild pro Sekunde, weshalb schnelle Schnitte zwischen zwei Abtastpunkten verschwinden. crv setzt dort an und verschiebt die Auswahl von einem Zeitraster auf eine Änderungsmessung.

Die Zielgruppe ist enger, als der Name vermuten lässt. Angesprochen sind Leute, die einem Agenten oder einer Chat-Sitzung Videomaterial zuführen und dabei die Kontrolle über die Datei behalten wollen. Die Verarbeitung läuft lokal, das betont das Projekt an mehreren Stellen. Was danach an einen Anbieter geht, sind die Bilder und Texte, die man selbst in ein Modell einfügt. Wer ohnehin nur das Transkript braucht, gewinnt durch die Bildauswahl nichts.

Der Ablauf: ffmpeg sucht Szenen, Whisper hört zu, ein Ordner sammelt alles

Der dokumentierte Ablauf beginnt mit einem Aufruf wie crv "https://www.youtube.com/watch?v=..." und endet in einem Ausgabeverzeichnis crv-out. Dort liegen die Einzelbilder unter frames/, dazu frames.json mit den Zeitstempeln der einzelnen Bilder, transcript.txt und transcript.json sowie eine MANIFEST.txt. Das Manifest ist die Übergabestelle an das Modell: man legt die Bilder und diese Datei in die Sitzung und stellt Fragen. Der Datenfluss ist also eine Dateipipeline, keine API-Anbindung. Es gibt keinen Dienst, der etwas zurückliefert, und keinen Server, der etwas entgegennimmt.

Zwei Mechanismen greifen ineinander. Die Szenenerkennung stammt aus ffmpeg und liefert Kandidaten an den Stellen, an denen sich das Bildmaterial sichtbar ändert. Danach folgt eine Deduplizierung, die nahezu identische Bilder wieder entfernt. Erst diese zweite Stufe erklärt die genannte Zahl von 26 aus 58. Für die Ausgabe in Kontaktbögen gibt es den Schalter --grid, der die verbliebenen Bilder auf wenige Blätter packt. Die Transkription übernimmt Whisper, installiert über das Extra whisper. Für die Sprechertrennung existiert ein separates Extra: pip install "claude-real-video[speakers]" zieht ein lokales Diarisierungsmodell von 45 MB, das laut README einmalig heruntergeladen wird und weder Konto noch Token verlangt. Die Ausgabezeilen tragen dann Marken wie [SPEAKER_00] und [SPEAKER_01]. Wer keine Modellarbeit plant, kann das Werkzeug laut README auch als reinen Keyframe-Extraktor betreiben, ohne dass ML-Modelle geladen werden.

Installation und die Schalter, die den Unterschied machen

Der kürzeste Weg steht in der README als pip install "claude-real-video[whisper]". Für die Nutzung in einem Codier-Agenten folgt npx skills add HUANGCHIHHUNGLeo/claude-real-video, das die Skill-Datei in kompatible Agenten-Hosts legt. Wer Claude Code mit Marktplatz-Unterstützung nutzt, installiert über /plugin marketplace add HUANGCHIHHUNGLeo/claude-real-video und anschließend /plugin install claude-real-video@claude-real-video. Ohne Agenten genügt die Kommandozeile: crv "<url>" funktioniert nach dem pip-Install allein. Für alle, die kein Terminal möchten, startet crv-web eine lokale Seite mit Oberfläche in Traditionellem Chinesisch, Vereinfachtem Chinesisch und Englisch, in die man eine URL oder einen Dateipfad einfügt. Der Quelltext bleibt dabei laut README auf dem eigenen Rechner.

Interessanter als die Installation sind die Schalter, weil sie das Auswahlverhalten verändern. Mit --from 28:00 --to 43:00 wird ein Fenster gesetzt. Die README erklärt, dass ffmpeg dann springt statt die ganze Datei zu dekodieren, Whisper nur den Ausschnitt hört und das Bildbudget innerhalb des Fensters verbraucht wird. Wichtig für die Weiterverwendung: die gemeldeten Zeitstempel bleiben Zeitmarken der Quelldatei, nicht des Ausschnitts. --frame-width 1600 hebt die Breite der gespeicherten Bilder an, gedacht für Material, in dem die Bedeutung in kleiner Schrift steckt, etwa in einem Terminal oder einer Tabellenkalkulation. --adaptive stellt die Auswahl auf die rollierende Nachbarschaft eines Bildes um statt auf eine feste Schwelle, damit langsame Bewegungen wie ein Squash-and-Stretch über zwei bis drei Sekunden nicht durchfallen. --text-anchors erzwingt zusätzliche Bilder an den Zeitmarken von Untertiteln, höchstens eines pro Sekunde, und lässt die Szenenerkennung unberührt. Dafür braucht es eine begleitende .srt- oder .vtt-Datei oder eine eingebettete Untertitelspur. In die Pixel eingebrannte Untertitel erkennt der Mechanismus nicht. --viewer schreibt schließlich eine lokale viewer.html mit Video, Keyframe-Raster und Transkript, ohne Netzwerkzugriff und ohne zusätzliche Installation.

Wo das Verfahren an seine Grenzen stößt

Die Szenenerkennung ist eine Änderungsmessung, und daraus folgt ihr blindes Feld. Inhalt, der sich über viele Sekunden stetig verschiebt, ohne dass ein einzelnes Bild einen Ausschlag erzeugt, fällt durch das Raster. Die README benennt das offen und empfiehlt für Animationslehrgänge, langsame Kamerafahrten und allmähliche Übergänge den Schalter --adaptive. Ohne ihn ist mit Lücken zu rechnen.

Der zweite Fall betrifft Text. Bei Vortragsfolien, Bildschirmaufnahmen und erklärenden Videos mit sprechendem Kopf ändert sich das Bild oft kaum, während der Inhalt wechselt. --text-anchors setzt hier zusätzliche Bilder, aber nur, wenn Untertitel als Datei oder eingebettete Spur vorliegen. Sind sie eingebrannt, greift der Mechanismus nicht. Das ist keine Randnotiz, sondern schließt ganze Kategorien von Material aus. Drittens die Auflösung: die README argumentiert selbst, dass bei 640 Pixel Breite auf einer 1920 Pixel breiten Bildschirmaufnahme der richtige Moment gefunden und die Einzelheit, die ihn wertvoll machte, anschließend verworfen wird. --frame-width 1600 ist die Antwort darauf, aber sie kostet Bildgröße und damit Kontext. Wer beides braucht, genaue Auswahl und lesbaren Text, zahlt in Token.

Schließlich die Frage, für wen das Werkzeug das falsche ist. Wenn die Antwort bereits im gesprochenen Wort steckt, etwa bei einem Interview oder einer Vorlesung, liefert die Transkription allein das Ergebnis, und die Bildauswahl erzeugt nur zusätzliches Material, das ein Modell mitverarbeiten muss. Und wer Video nativ an einen Anbieter geben darf und dessen feste Abtastung akzeptiert, spart sich mit dem direkten Weg einen Zwischenschritt.

Der Unterschied zu Gemini und zu einem reinen Extraktor

Die nächstliegende Alternative ist der native Videopfad eines multimodalen Dienstes. Die README beschreibt Gemini als das Modell, das Video tatsächlich lesen kann, mit dem Unterschied, dass die Datei zu Google hochgeht und die Bilder in einem festen Intervall gezogen werden. Der Gegensatz liegt also nicht im Modell, sondern in zwei Entscheidungen: wo die Verarbeitung stattfindet und wie die Bilder ausgewählt werden. crv trifft beide anders. Die Verarbeitung bleibt lokal, die Auswahl richtet sich nach Szenenwechseln. Wer die Datei nicht aus der Hand geben darf, hat damit keine Wahl zwischen zwei gleichwertigen Wegen.

Innerhalb der Kommandozeile gibt es eine zweite Abgrenzung, die die README selbst zieht. crv lässt sich als allgemeiner Keyframe-Extraktor verwenden, Szenenerkennung plus Deduplizierung, ohne ML-Modelle. Der Unterschied zu einem Aufruf von ffmpeg mit einem Sele-Filter besteht dann in der Deduplizierungsstufe, der Manifest-Datei und den Zeitstempeln in frames.json, also in der Aufbereitung für ein Modell. Wer nur Bilder braucht, ist mit ffmpeg direkt schneller. Wer einem Modell etwas erklären will, braucht die Metadaten. Ein weiterer Unterschied zum nativen Videopfad: crv liefert Dateien, die man vor dem Absenden ansehen kann. --viewer macht genau das möglich, und in einer Umgebung, in der ein Modellaufruf Geld kostet oder eine Freigabe braucht, ist diese Kontrolle vor dem Versand kein Nebeneffekt, sondern der Grund für den Zwischenschritt.

Pflege, Versionen und die Lizenzfrage

Der letzte Push liegt laut Repository-Angabe auf dem 31. August 2026, die jüngste Veröffentlichung ist v0.10.3 vom selben Tag. Die drei jüngsten Einträge betreffen kleine Korrekturen: eine Kopfzeile über dem Transkript, die dieses nicht mehr öffnet, URL-Läufe, die die Untertitel der Quelle verwenden, und Fensterkorrekturen. Das Muster ist ein schnell getakteter Einzelstrang aus kleinen Versionen, kein sprunghaftes Modell. Für die Planung heißt das: die Oberfläche und die Ausgabedateien bewegen sich, die Kommandozeilenaufrufe sind über die letzten drei Versionen hinweg stabil geblieben, soweit die Versionshinweise das erkennen lassen.

Die Kosten liegen weniger in der Aktualisierung als in den Abhängigkeiten. Whisper kommt über das Extra whisper, die Sprechertrennung über speakers mit einem 45 MB großen Modell, das einmalig geladen wird. Beide Modelle müssen auf dem Rechner Platz und Rechenzeit finden. Die Lizenz ist MIT, der Quelltext also mit sehr wenigen Bedingungen nutzbar. Zu beachten ist die Trennung im Projekt selbst: crv Pro ist ein kostenpflichtiges Zusatzprodukt zum Einmalpreis von 29 US-Dollar, vertrieben über Capafy und Lemon Squeezy. Es steht unter einem anderen Listing als das Paket, nämlich llm-real-video Pro, und ist nicht Teil des MIT-lizenzierten Kerns. Wer die freie Version einsetzt, sollte im eigenen Projekt also nicht annehmen, dass die in der README beworbenen Zusatzfunktionen zur selben Lizenz gehören. Eine rechtliche Bewertung ersetzt diese Feststellung nicht.

Redaktionelles Fazit

Wer einem LLM Videomaterial zuführen will, ohne die Datei an einen Cloud-Anbieter zu geben, findet in crv ein Werkzeug, das die Auswahl der Bilder tatsächlich als Problem behandelt. Für schnelle, kurze Clips mit harten Schnitten reicht der Standardlauf. Wer dagegen lange Bildschirmaufnahmen mit feinem Text auswertet, sollte zuerst prüfen, ob --frame-width 1600 die eigene Auflösung abdeckt, und bei langsamen Animationen ohne --adaptive rechnen. Vor jedem größeren Lauf lohnt ein Blick in MANIFEST.txt und frames.json: dort steht, wie viele Bilder die Szenerkennung als unterschiedlich genug eingestuft hat, und diese Zahl entscheidet, ob die Auswahl für das eigene Material trägt.

Offizielle Quellen

  1. HUANGCHIHHUNGLeo/claude-real-video on GitHub
  2. Issues
  3. License: MIT
  4. README
  5. Releases
Community-Notizen

Community-Notizen