Runway Enhance Frame Rate ist auf der Dev API verfügbar: 24 bis 120 fps, NTSC inklusive

Runway hat am 17. September 2026 ein neues Frame-Interpolationsmodell in seine Developer-API aufgenommen, und das Detail, auf das es wirklich ankommt, ist nicht das obere Ende der Spanne – es sind die Bruchraten. Runway Enhance Frame Rate setzt vorhandenes Material auf eine Zielrate von 24, 25, 30, 48, 50, 60 oder 120 fps neu und akzeptiert außerdem die drei Raten, die Rundfunk und Kino tatsächlich liefern: 23,98, 29,97 und 59,94. Runways eigener Developer-Changelog dokumentiert das Modell als enhance_frame_rate, aufgerufen über denselben POST /v1/video_upscale-Endpunkt, den das Unternehmen bereits für seinen kreativen Upscaler verwendet, begrenzt auf 300 Sekunden Eingabe pro Auftrag und abgerechnet mit 1 Credit pro 2 Sekunden.

Diese Abrechnungszeile ist die zweite Überraschung. Frame-Interpolation wird üblicherweise nach Ausgabe bepreist – der eigene Magnific Video Upscaler von Runway am selben Endpoint berechnet 0,7 Credits pro Ausgabeframe bei 720p/1K – was bedeutet, dass eine Konvertierung von 24 fps auf 120 fps fünfmal so viel kostet wie eine Konvertierung von 24 auf 25 fps. enhance_frame_rate wird pro Sekunde Eingabe berechnet. Eine 5-fache Frame-Vervielfachung und eine 1,05-fache kosten genau gleich viel. Wenn es Ihre Aufgabe ist, ein und dasselbe Material in mehreren Bildraten auszuliefern, kehrt diese einzelne Zeile in der Preistabelle die übliche Rechnung um.

Auch der Zeitpunkt ist bezeichnend. Runways eigenständiges Frame-Interpolation-Tool steht auf der offiziellen Liste veralteter Tools des Unternehmens, wobei die App Animate Keyframes als sein Ersatz genannt wird. Enhance Frame Rate ist keine Wiederbelebung dieses Web-Tools – es ist Frame Interpolation, neu aufgebaut als API-Modell, ausgerichtet auf Pipelines statt auf jemanden, der durch eine Timeline klickt.

Was Enhance Frame Rate tatsächlich bewirkt

Dies ist ein Retiming-Modell, kein generatives. Es gibt keinen Prompt, kein Bild, keinen Referenzclip. Man übergibt ihm ein bereits existierendes Video – egal ob von einer Kamera, einem Schnitt oder einem anderen Runway-Modell – und es synthetisiert die Zwischenbilder, die nötig sind, um die Zielrate zu erreichen. Runways Ankündigung auf dem eigenen X-Konto formuliert es genauso: „konvertiert jedes Material in die Spezifikationen, die du brauchst.“

Mechanisch gesehen ist es eine asynchrone Aufgabe am Video-Upscale-Endpunkt. Sie senden per POST eine Video-URI, setzen model: "enhance_frame_rate", erhalten eine Task-ID zurück und pollen nach dem Ergebnis. Da es sich einen Endpunkt mit dem Upscaler von Runway teilt, braucht eine Pipeline, die bereits mit /v1/video_upscale spricht, nur eine Parameteränderung statt einer neuen Integration.

Das Änderungsprotokoll von Runway führt Folgendes als aktuelle, vom Anbieter angegebene Spezifikation auf. Nichts davon wurde unabhängig verifiziert – es gibt keinen Benchmark dieses Modells von Drittanbietern, und es ist zum Zeitpunkt des Schreibens einen Tag alt.

• Zielraten — 24, 25, 30, 48, 50, 60 und 120 fps, dazu 23,98, 29,97 und 59,94 fps (in der API als 23_98, 29_97 und 59_94 geschrieben)

• Eingabelimit — 300 Sekunden pro Auftrag

• Preis — 1 Credit pro 2 Sekunden Eingabe; Credits der Runway API kosten je 0,01 $.

• Zugriff — POST /v1/video_upscale mit model: "enhance_frame_rate", auf Runway Dev

• Stand der Technik bei Runway — unter der API-Version 2024-11-06 existierte ein Aufgabentyp frame_interpolation_v1; das eigenständige Web-Tool Frame Interpolation ist veraltet

• Unabhängige Bewertung — keine veröffentlicht

Die Framerate-Leiter, und warum 23,98 die eigentliche Schlagzeile ist

Jedes Consumer-Interpolationstool bietet ganzzahlige Bildraten. Die interessante Spalte ist hier die mit den Bruchraten, denn Bruchraten sind das, was in den Auslieferungsspezifikationen tatsächlich steht:

• 23,98 (23,976) — die NTSC-Filmrate. Nahezu jedes Kino- und Streaming-Master und die Bildrate, mit der DVD und Blu-ray erstellt wurden.

• 24 — echte Filmrate, noch immer für DCP und viele Festival-Deliverables verwendet.

• 25 — PAL- und EBU-Gebiete: das Vereinigte Königreich, der größte Teil Europas, Australien, große Teile Asiens und Afrikas.

• 29,97 — NTSC-Rundfunk, das fraktionale Geschwister von 30.

• 30 — ganzzahlige Bildrate für Bildschirmaufnahmen, Web- und Spielaufnahmen.

• 48 — High-Frame-Rate-Kino (die Bildrate, mit der die Hobbit-Filme gedreht und projiziert wurden).

• 50 — PAL-Hochbildrate, genau 2× 25.

• 59,94 — NTSC-Hochbildrate, die 60-Hz-Ausstrahlungsrate für Rundfunk in den USA und Japan.

• 60 — Integer 60 Hz, das gängige Ziel für flüssige Wiedergabe im Web.

• 120 — Zeitlupe und Wiedergabe mit hoher Bildwiederholrate.

Die Lücke zwischen 24 und 23,976 wirkt trivial und ist es nicht. Über eine Stunde Laufzeit driften die beiden um rund 3,6 Sekunden auseinander. Speist man einen 24,000-Master in eine 23,98-Auslieferungskette ein, bekommt man Audio-Sync-Drift und Cadence-Fehler, die bei der Broadcast-QC durchfallen — weshalb Postproduktionshäuser historisch einen separaten Conform-Schritt zum Resampling der Raten durchführten oder den Auftrag ablehnten. Ein Tool, das die gebrochene Bildrate direkt ausgibt, entfernt eine Stufe aus dieser Kette. Das ist eine viel engere, viel langweiligere Behauptung als „120 fps“, und für alle, die an einen Sender liefern, ist es der Grund, sich darum zu kümmern.

Die 48- und 120-Ziele sind diejenigen, bei denen in der Praxis Skepsis angebracht ist. Die Interpolation von 24-fps-Material auf 120 fps bedeutet, für jedes echte Bild vier Bilder zu erfinden, und bei schnellen Bewegungen, Verdeckungen oder starker Bewegungsunschärfe erzeugen Interpolatoren jeder Art Ghosting und Warping. Runway veröffentlicht keine Artefaktanalyse, keinen Vergleich mit irgendeinem anderen Interpolator und keine Qualitätshinweise pro Aufnahme — die ehrliche Position ist daher, dass die Spezifikation 120 unterstützt und dass ungetestet ist, wie 120 auf Ihrem Material aussieht.

Was es kostet, durchgerechnet

Die Arithmetik ist ungewöhnlich sauber, weil die Einheit Eingabesekunden ist. Bei 1 Credit pro 2 Sekunden und 0,01 $ pro Credit bei Runways Developer-API (Prepaid, mindestens 10 $ für 1.000 Credits):

• Ein 10-Sekunden-Clip, zu jedem beliebigen Ziel-Tarif — 5 Credits, etwa 0,05 $

• Ein 30-Sekunden-Clip — 15 Credits, etwa 0,15 $

• Ein 60-Sekunden-Clip — 30 Credits, etwa 0,30 $

• Ein 5-Minuten-Clip, die 300-Sekunden-Obergrenze — 150 Credits, etwa 1,50 $

• Ein 90-Sekunden-Clip, 24 → 25 fps — 45 Credits, etwa 0,45 $

• Derselbe 90-Sekunden-Clip, 24 → 120 fps – 45 Credits, etwa 0,45 $

Diese letzten beiden Zeilen sind das ganze Preisargument. Bei einem Modell, das pro ausgegebenem Frame abrechnet, hätte der zweite Job die fünffache Frame-Anzahl und damit ungefähr die fünffache Rechnung. Hier ist er kostenlos.

Der Vergleich mit dem Nachbarn auf demselben Endpoint macht die Sache konkret. Magnific Video Upscaler rechnet pro Ausgabeframe ab – 0,7 Credits bei 720p/1K, 0,9 bei 2K, 1,2 bei 4K, mit einer Untergrenze von einem Credit pro Generierung. Ein 10-Sekunden-Clip mit 30 fps ergibt 300 Ausgabeframes, der 720p/1K-Tarif landet also bei 210 Credits, etwa 2,10 $. Derselbe Clip über enhance_frame_rate kostet 5 Credits, etwa 0,05 $. Wenn Sie eine höhere Bildrate und kein größeres Bild möchten, kostet der Griff zum Upscaler rund vierzigmal mehr. Beachten Sie außerdem, dass das Aktivieren des optionalen fps-Boosts des Upscalers die Anzahl der Ausgabeframes ändert und damit diese Rechnung weiter erhöht – die Preisdokumentation von Runway sagt das ausdrücklich.

Ein erwähnenswerter Kostenvorbehalt: Runways Entwickler-Preisseite ist hier die maßgebliche Quelle, nicht dieser Artikel, und der Credit-Preis wird Berichten zufolge seit August 2026 im Hinblick auf individuelle Preisgestaltung überprüft. Prüfen Sie das Portal, bevor Sie einen großen Batch einplanen.

Die 300-Sekunden-Obergrenze und wie man sie umgeht

Jeder Auftrag ist auf 300 Sekunden Eingabe begrenzt. Das ist großzügig für eine Einstellung und kurz für ein Reel, also muss alles Längere segmentiert werden – und wie du segmentierst, ist wichtiger als die Obergrenze selbst.

Schneide an Szenengrenzen, nicht nach festem Takt. Interpolatoren leiten Bewegung zwischen benachbarten Frames ab; bei einem harten Schnitt haben der letzte Frame von Einstellung A und der erste Frame von Einstellung B überhaupt keine Bewegungsbeziehung, und ein Modell, das den Schnitt nicht erkennt, erfindet munter einen Morph zwischen ihnen. Runways Changelog dokumentiert für dieses Modell keine automatische Szenenerkennung, daher ist die sichere Annahme, dass es keine gibt. Zerlege an Schnitten in Chunks, interpoliere jeden Chunk, setze auf einer Timeline mit der neuen Rate wieder zusammen.

Diese Empfehlung gilt nicht speziell für Runway – sie ist der allgemeine Vorbehalt beim KI-Retiming. Ein SMPTE-Paper aus dem Jahr 2025 über KI-gestützte Postproduktion, das eine TensorRT-optimierte Interpolationspipeline für Konvertierungen wie 23,976 → 25 und 29,97 → 23,976 beschreibt, macht denselben Punkt: Frame-konvertierter Inhalt braucht Frame-Breaks an Szenenwechseln und anschließend QC, sonst halluziniert das Modell über die Klebestelle hinweg. Rechnen Sie damit, dass der erste Durchlauf bei schwierigen Übergängen einen manuellen Frame-Austausch benötigt.

Wie es im Vergleich zu den Alternativen abschneidet

Frame-Interpolation ist seit einiger Zeit ein mehr oder weniger gelöstes Problem, in zwei Formen, die beide anders aussehen als diese hier.

• Desktop-Suiten — Die Apollo- und Chronos-Modelle von Topaz Video AI sind der Referenzpunkt für qualitätsorientiertes Retiming. Eine unbefristete Lizenz, die eigene GPU, keine sekundengenaue Abrechnung und ein Tuning-Durchlauf, der belohnt, wer weiß, worauf zu achten ist.

• Open-Source-Interpolatoren – RIFE und ähnliche Modelle, selbst gehostet, an der Marge praktisch kostenlos, sobald man die Hardware besitzt, und die Grundlage für die meisten der maßgeschneiderten Pipelines, die Postproduktionshäuser selbst gebaut haben.

• Runway Enhance Frame Rate — keine lokale Berechnung, ein API-Aufruf, Abrechnung pro Eingabesekunde und die fraktionalen NTSC-Bildraten, um die Sie sich bei den anderen beiden bisher von Hand kümmern mussten.

Der Trade-off ist nachvollziehbar. Für einen einmaligen Shot auf einer Workstation, die Sie bereits besitzen, ist ein lokaler Interpolator günstiger und bietet Ihnen Regler, die Runway nicht bereitstellt. Für Material, das in einer automatisierten Pipeline eintrifft, oder eine Deliverable-Matrix, bei der derselbe Clip für ein Territorium mit 23,98 und für ein anderes mit 25 herauskommen muss, macht eine API, die die fraktionale Bildrate direkt zurückgibt, einen Conform-Schritt überflüssig – und der Preis pro Eingabesekunde bedeutet, dass die Multi-Rate-Ausgabe nichts extra kostet.

Die Routing-Schicht darum herum

Retiming ist eine Stufe in einer Pipeline, die irgendwo in der Nähe einen Sprachmodell-Schritt hat. Die Shotlist und die Conform-Notizen, der Untertitel- und Caption-Durchlauf, der auf die neue Bildrate neu getimt werden muss, die Liefermetadaten je Territorium, das QC-Log – das ist Textarbeit, und es ist der Teil einer Video-Pipeline, für den niemand Budget einplant.

Diese Ebene läuft mit einem einzigen Schlüssel über die 200 Modelle im OrcaRouter-Katalog, wobei die Listenpreise der Anbieter mit 0 % Aufschlag durchgereicht werden und ein automatisches Failover zwischen Anbietern erfolgt, sodass ein neueres oder günstigeres Modell im Live-Traffic ausprobiert werden kann, ohne darauf einen Produktionspfad zu verwetten. Um den Umfang genau zu benennen: Runway Enhance Frame Rate ist ein Modell der Runway Dev API, das über den eigenen Endpunkt von Runway aufgerufen wird, und OrcaRouter stellt es nicht bereit. Was wir abdecken, ist alles drumherum.

Was noch nicht bekannt ist

Fast nichts über die Qualität. Dieses Modell ist zum Zeitpunkt des Verfassens ungefähr einen Tag alt, und alles oben über sein Verhalten stammt aus dem Changelog und der Ankündigung von Runway selbst. Konkret unbestätigt:

• Artefaktverhalten bei schnellen Bewegungen, Verdeckung, Bewegungsunschärfe und Quellen mit niedriger Bitrate — keine veröffentlichten Tests von irgendjemandem

• Ob es Szenenwechsel automatisch erkennt oder über sie hinweg überblendet

• Ob Audio bei einer Änderung der Bildrate durchgeschleift, neu abgetastet oder verworfen wird

• Wie es qualitativ im Vergleich zu RIFE, Apollo oder Chronos abschneidet – es gibt keinen Direktvergleich

• Ob der Preis pro Eingabesekunde bei steigender Zielrate bestehen bleibt oder später neu gestaffelt wird

Behandeln Sie die 120-fps- und 48-fps-Ziele als Behauptungen, bis Sie Ihr eigenes Filmmaterial damit getestet haben, und prüfen Sie das Schnittverhalten beim ersten Clip, den Sie senden.

Wer sollte jetzt handeln?

Handeln Sie jetzt, wenn Sie nach Broadcast- oder Multi-Territory-Spezifikationen liefern und derzeit für einen Conform-Schritt bezahlen, wenn Ihr Material bereits durch eine automatisierte Pipeline läuft, die noch einen weiteren API-Aufruf verkraftet, oder wenn Sie Zeitlupe aus einer Kamera möchten, die nie Hochgeschwindigkeitsaufnahmen gemacht hat, und lieber keine GPU betreiben möchten.

Warte, wenn du in einem einzigen Job mehr als fünf Minuten brauchst und nicht an Schnitten segmentieren kannst, wenn zusätzlich die Auflösung erhöht werden muss – das ist der Upscaler, zu Preisen pro Frame – oder wenn du bereits einen Desktop-Interpolator besitzt und dies eine einmalige Aufnahme ist. Und warte, wenn Qualität statt Bequemlichkeit der entscheidende Faktor ist: Niemand außerhalb von Runway hat eine Zahl veröffentlicht, und der erste unabhängige Vergleich ist das, worauf es sich zu warten lohnt.

Das Muster, das es zu beobachten gilt, ist, ob Runway diesen Endpunkt Modell für Modell weiter ausbaut. Er umfasst bereits einen kreativen Upscaler und jetzt einen Retimer, beide unter POST /v1/video_upscale, beide nach völlig unterschiedlichen Einheiten abgerechnet. Für alle, die Delivery-Pipelines bauen, ist die Einheit – Eingabesekunden statt Ausgabeframes – der Teil, um den herum man designen sollte.