Jeder kennt dieses Gefühl: Jemand schickt ein Video, man hat keine Zeit, es anzuschauen, und liest stattdessen die Zusammenfassung. Meistens reicht das. Aber manchmal bleibt ein Rest Unsicherheit zurück. Hat man etwas Entscheidendes verpasst? Genau an dieser Stelle setzt der Entwickler des Open-Source-Tools „claude-real-video“ an. In seinen Engineering Notes beschreibt er, warum es einen fundamentalen Unterschied macht, ob ein Sprachmodell einen Text über ein Video bekommt oder das Video selbst.
Eine Zusammenfassung ist nicht das Ereignis
Ein Video ist kein Artikel über das Video. Wer ein Video einmal gesehen hat, hat eine Kompression des Geschehens in der Hand. Ein Mensch hat zugeschaut, entschieden, was wichtig war, und den Rest verworfen. Das Framing, das Timing, Details am Bildrand, die niemand notiert hat – all das fehlt im Text. Wenn ein LLM einen solchen Artikel liest, bewegt es sich innerhalb der Entscheidungen des Autors. Es kann nichts zurückholen, was geschnitten wurde, und es kann eine Auswahl nicht infrage stellen, die es nie gesehen hat.
Gibt man dem Modell stattdessen das Video, verschiebt sich die Kompression auf das Modell selbst. Der Entwickler beschreibt diesen Unterschied als den zwischen dem Lesen einer Zeugenaussage und dem selbst vor Ort sein. Das Modell sieht, wie das Demo tatsächlich aussah, nicht wie ein Rezensent es beschrieben hat. Es bemerkt die Fehlermeldung, die in einem Tutorial kurz aufblitzt und die keiner transkribiert hat. Es erkennt, dass die „schnelle Einrichtung“ elf Schnitte gebraucht hat. Dasselbe Thema, sehr verschiedene Positionen. Genau deshalb sind die Token-Budget und die Auswahl der Frames so entscheidend.
Das Token-Budget setzt die Grenzen
Der größte Teil dessen, was heute als Video-Understanding verkauft wird, ist ein Transkript plus Frames, die per Timer gezogen werden – ein Frame pro Sekunde, manchmal nur alle zehn Sekunden. Uniform Sampling scheitert gleich in beide Richtungen: Es begräbt das Modell unter fast identischen Frames eines sprechenden Kopfes und überspringt genau die eine Sekunde, in der sich etwas verändert hat. Die Ursache ist beide Male dieselbe: Der Sampler hat keine Ahnung, was sich geändert hat.
Die harte Randbedingung ist das Token-Budget. Bilder sind die teuerste Sache, die man in einen Kontext legen kann. Wenn man einmal akzeptiert, dass nur etwa 100 bis 150 Frames pro Video Platz haben, hört die Extraktion auf, das Problem zu sein. Die Selektion ist das Problem. Jeder behaltene Frame muss sich seinen Platz verdienen. Der Rest des Artikels dreht sich darum, wie man diesen Platz gut vergibt – mit Szenenerkennung, Deduplizierung und einer sauberen Fusion des Transkripts.
Szenenerkennung: Der gleitende Durchschnitt schlägt den fixen Schwellwert
Der erste Durchlauf ist Standard: ffmpegs Scene-Score. Ein Frame wird bei jedem Szenenwechsel gezogen, plus eine niedrige Mindestdichte, damit eine lange, ungeschnittene Einstellung nicht leer ausgeht. Alles in einem chronologischen Durchlauf, weil die Deduplizierung später echte Nachbarn vergleichen will. Feste Schwellwerte scheitern allerdings an einer bestimmten Sorte von Inhalt: Animation und langsame Kamerabewegung.
Eine Cartoon-Figur, die sich dehnt und staucht, oder ein langsamer Schwenk verändert das Bild ständig, aber nie abrupt. Der Score überschreitet die Linie nicht, und der Sampler schläft durch die ganze Szene. Die Lösung klingt langweilig, funktioniert aber: Man berechnet die Scene-Scores frame-weise in einem reinen Metadaten-Durchlauf und behält einen Frame immer dann, wenn sein Score ein Vielfaches des rollierenden Durchschnitts übertrifft. Bewegungsintensives Material hebt die Latte, ruhiges senkt sie. Niemand muss manuell etwas tunen.
Deduplizierung: Aus einem Kanal wurden drei
Die Deduplizierung startete als ein einziger Vergleicher. Jedes Mal, wenn echtes Videomaterial ihn vorführte, kam ein Kanal dazu. Der erste Kanal ist der globale: Er skaliert das Bild auf eine 16×16-RGB-Signatur herunter und zählt die Zellen, die sich in irgendeinem Kanal um mehr als 25/255 verändert haben. Sinkt die Zahl der veränderten Zellen unter etwa acht Prozent, wird der Frame verworfen.
Wichtig ist dabei RGB und nicht Graustufen, weil ein Rot-Grün-Schnitt mit gleicher Luminanz für einen Graustufen-Vergleich unsichtbar bleibt. Außerdem vergleicht der Kanal gegen ein Fenster der letzten vier behaltenen Frames und nicht nur gegen den unmittelbaren Vorgänger. Sonst re-admittiert ein A-B-A-Schnitt – Interview, Reaktionsshot, zurück zum Interview – einen bereits gesehenen Shot, nur weil dazwischen ein anderer Frame lag.
Der zweite Kanal: Kleine Subjekte, starke Veränderung
Ein prozentualer Schwellwert ist strukturell blind für kleine Motive. Ein Mensch, der im Weitwinkel nur 0,5 Prozent der Bildfläche einnimmt, kann niemals acht Prozent der Pixel verändern, egal was er tut. Der eine relevante Moment wird also wegdedupliziert. Der Entwickler hat dieses Problem nicht in einem Benchmark gefunden. Ein Nutzer entdeckte es, nachdem das Tool über 2.181 reale Videos gelaufen war.
Der Patch arbeitet auf einem 32×32-Raster. Wenn dort auch nur eine Handvoll Zellen sich hart verändern – also mehr als 45/255 –, gilt der Frame unabhängig vom Prozentsatz als neu. Kleines Motiv, scharfe Änderung, wird behalten. Das ist die Lektion, die sich durch die ganze Deduplizierung zieht: Prozentwerte allein sagen nichts über Bedeutung aus, wenn die Veränderung klein und konzentriert ist.
Der dritte Kanal: Der ruhige Blick auf den Zustand
Der globale Kanal kann außerdem kleine lokale Zustandsänderungen nicht sehen: einen Untertitelwechsel, eine Linie Tinte auf dem Whiteboard, ein aktualisiertes UI-Element. Auf der 16×16-Skala messen solche Änderungen praktisch null. Der dritte Kanal arbeitet deshalb mit einer 192×192-Signatur und sucht Pixel, die sich stark von jedem Frame im behaltenen Fenster unterscheiden. Eine Verschiebung von plus/minus einem Pixel ist erlaubt, weil Filmkorn, Sensor-Jitter und Bildrauschen sonst überall Änderungen melden.
Die Schutzmechanismen sind hier wichtiger als der Detektor. Der Kanal läuft nur, wenn die Szene sonst statisch ist, weil Bewegung die Aufgabe der anderen Kanäle ist. Dazu kommen zwei weitere Bremsen. Kandidaten-Pixel müssen eine zweite, strengere Toleranzprüfung bestehen. Das filtert weiche Kontrastverläufe heraus – etwa Rauch, der sich auflöst –, während Tinte und Text ihren harten Kern behalten. Und jeder ausgelöste Treffer hebt die Schwelle wieder an, mit einem abklingenden Cooldown. So kann ein flackerndes Element nicht immer wieder Frames für sich beanspruchen, während eine einzelne Texteinblendung normal durchkommt.
Was am Ende zählt
Die Summe ist überschaubarer, als es die Details vermuten lassen. Keyframes plus ein zusammengeführtes Transkript reichen für den Alltagsfall aus: das Modell soll sich das Ding wirklich ansehen, bevor es antwortet. Dafür braucht es keinen Dienst in der Cloud. Das läuft vollständig auf der eigenen Maschine.
Quelle: leoaido.com
