Runway Enhance Frame Rate is uitgebracht op de Dev API: 24 tot 120 fps, NTSC inbegrepen

Runway heeft op 17 september 2026 een nieuw frame-interpolatiemodel aan zijn developer-API toegevoegd, en het detail dat er echt toe doet is niet de bovenkant van het bereik — het zijn de fractionele snelheden. Runway Enhance Frame Rate zet bestaande footage om naar een doelframerate van 24, 25, 30, 48, 50, 60 of 120 fps, en accepteert ook de drie snelheden die broadcast en cinema daadwerkelijk leveren: 23,98, 29,97 en 59,94. Runway's eigen developer-changelog documenteert het model als enhance_frame_rate, aangeroepen via hetzelfde POST /v1/video_upscale-endpoint dat het bedrijf al gebruikt voor zijn creatieve upscaler, met een limiet van 300 seconden invoer per taak en een facturering van 1 credit per 2 seconden.

Die factureringsregel is de tweede verrassing. Frame-interpolatie wordt meestal geprijsd op basis van de uitvoer — Runway's eigen Magnific Video Upscaler rekent op datzelfde endpoint 0,7 credits per uitvoerframe bij 720p/1K — wat betekent dat een conversie van 24 fps naar 120 fps vijf keer zoveel kost als een conversie van 24 naar 25. enhance_frame_rate wordt gefactureerd per seconde invoer. Een framevermenigvuldiging van 5× en een van 1,05× kosten exact hetzelfde. Als het je taak is om één stuk beeldmateriaal op meerdere framerates te leveren, dan draait die ene regel in de prijstabel de gebruikelijke rekensom om.

De timing is ook veelzeggend. Runway's zelfstandige Frame Interpolation-tool staat op de officiële lijst met verouderde tools van het bedrijf, waarbij de Animate Keyframes-app als vervanging wordt genoemd. Enhance Frame Rate is geen herleving van die webtool — het is frame-interpolatie die opnieuw is opgebouwd als een API-model, gericht op pipelines in plaats van op iemand die door een tijdlijn heen klikt.

Wat Enhance Frame Rate daadwerkelijk doet

Dit is een retimingmodel, geen generatief model. Er is geen prompt, geen afbeelding, geen referentieclip. Je geeft het een video die al bestaat — afkomstig van een camera, een montage of een ander Runway-model — en het synthetiseert de tussenliggende frames die nodig zijn om op de doelsnelheid uit te komen. Runway's aankondiging op zijn eigen X-account omschrijft het op dezelfde manier: "converteert elke footage naar de specs die je nodig hebt."

Mechanisch gezien is het een asynchrone taak op het video-upscale-endpoint. Je doet een POST met een video-URI, stelt model: "enhance_frame_rate" in, krijgt een taak-id terug en pollt op het resultaat. Omdat het een endpoint deelt met de upscaler van Runway, is voor een pipeline die al met /v1/video_upscale communiceert een parameterwijziging nodig in plaats van een nieuwe integratie.

De changelog van Runway vermeldt het volgende als de huidige, door de leverancier opgegeven specificatie. Niets daarvan is onafhankelijk geverifieerd — er bestaat geen benchmark van dit model door derden, en op het moment van schrijven is het één dag oud.

• Doelsnelheden — 24, 25, 30, 48, 50, 60 en 120 fps, plus 23,98, 29,97 en 59,94 fps (in de API geschreven als 23_98, 29_97 en 59_94)

• Invoerlimiet — 300 seconden per taak

• Prijs — 1 credit per 2 seconden invoer; Runway API-credits kosten $0,01 per stuk

• Toegang — POST /v1/video_upscale met model: "enhance_frame_rate", op Runway Dev

• Eerder voorbeeld bij Runway — er bestond een taaktype frame_interpolation_v1 onder de API-versie van 2024-11-06; de zelfstandige webtool Frame Interpolation is verouderd

• Onafhankelijke evaluatie — geen enkele gepubliceerd

De framerate-ladder, en waarom 23,98 het echte nieuws is

Elke interpolatietool voor consumenten biedt gehele framerates. De interessante kolom hier is de fractionele, want fractionele framerates zijn wat de leveringsspecificaties daadwerkelijk zeggen:

• 23,98 (23,976) — de NTSC-filmsnelheid. Bijna elke bioscoop- en streamingmaster, en de snelheid waartegen DVD en Blu-ray werden vervaardigd.

• 24 — echte filmsnelheid, nog steeds gebruikt voor DCP en veel festival-deliverables.

• 25 — PAL- en EBU-gebieden: het VK, het grootste deel van Europa, Australië, grote delen van Azië en Afrika.

• 29,97 — NTSC-uitzending, het fractionele broertje van 30.

• 30 — integer framesnelheid voor schermopname, web- en gamebeeldmateriaal.

• 48 — cinema met een hoge framesnelheid (de snelheid waarmee de Hobbit-films werden opgenomen en geprojecteerd).

• 50 — PAL hoge framesnelheid, precies 2× 25.

• 59,94 — NTSC hoge framesnelheid, de 60 Hz uitzendsnelheid in de VS en Japan.

• 60 — geheel getal 60 Hz, het gebruikelijke doelwit voor vloeiende weergave op het web.

• 120 — slow motion en weergave met hoge verversingssnelheid.

Het verschil tussen 24 en 23,976 lijkt triviaal en is dat niet. Over een speelduur van één uur drijven de twee ongeveer 3,6 seconden uit elkaar. Stop een 24,000-master in een 23,98-uitleveringsketen en je krijgt drift in de audiosynchronisatie en cadansfouten die omroep-QC zal afkeuren — daarom voerden postproductiehuizen historisch een aparte conformstap uit om snelheden te resamplen, of weigerden ze de klus. Een tool die de fractionele framerate rechtstreeks levert, haalt een stap uit die keten. Dat is een veel smallere, veel saaiere bewering dan "120 fps", en voor iedereen die aan een omroep uitlevert, is dat de reden waarom het ertoe doet.

De 48- en 120-doelen zijn degene waar je in de praktijk sceptisch over moet zijn. 24 fps-materiaal naar 120 fps interpoleren betekent vier frames verzinnen voor elk echt frame, en bij snelle bewegingen, occlusie of sterke bewegingsonscherpte produceren interpolators van welke soort dan ook ghosting en warping. Runway publiceert geen artefactanalyse, geen vergelijking met welke andere interpolator dan ook, en geen kwaliteitsrichtlijnen per shot — dus de eerlijke positie is dat de specificatie 120 ondersteunt, en hoe 120 er op jouw footage uitziet, is ongetest.

Wat het kost, uitgewerkt

De berekening is ongewoon eenvoudig omdat de eenheid invoerseconden is. Bij 1 credit per 2 seconden, en $0,01 per credit op de developer-API van Runway (prepaid, minimaal $10 voor 1.000 credits):

• Een clip van 10 seconden, tegen elk doeltarief — 5 credits, ongeveer $0,05

• Een clip van 30 seconden — 15 credits, ongeveer $0,15

• Een clip van 60 seconden — 30 credits, ongeveer $0,30

• Een clip van 5 minuten, de bovengrens van 300 seconden — 150 credits, ongeveer $1,50

• Een clip van 90 seconden, 24 → 25 fps — 45 credits, ongeveer $0,45

• Dezelfde clip van 90 seconden, 24 → 120 fps — 45 credits, ongeveer $0,45

Die laatste twee regels zijn het hele prijsargument. Bij een model per outputframe zou de tweede klus een 5× zo groot aantal frames zijn en dus ongeveer 5× de rekening. Hier is het gratis.

De vergelijking met de buur op hetzelfde endpoint maakt het punt concreet. Magnific Video Upscaler factureert per outputframe — 0,7 credits bij 720p/1K, 0,9 bij 2K, 1,2 bij 4K, met een minimum van één credit per generatie. Een clip van 10 seconden met 30 fps is 300 outputframes, dus het 720p/1K-tarief komt uit op 210 credits, of ongeveer $2,10. De identieke clip via enhance_frame_rate kost 5 credits, ongeveer $0,05. Als je een hogere framerate wilt en geen groter beeld, kost het inzetten van de upscaler ongeveer veertig keer zoveel. Merk ook op dat het inschakelen van de optionele fps-boost van de upscaler het aantal outputframes verandert en de rekening daardoor verder opdrijft — de prijsdocumentatie van Runway zegt dit expliciet.

Eén voorbehoud over de kosten dat het vermelden waard is: de pagina met ontwikkelaarsprijzen van Runway is hier de autoriteit, niet dit artikel, en er wordt gemeld dat de creditprijs sinds augustus 2026 wordt herzien richting prijzen op maat. Controleer het portaal voordat u een grote batch begroot.

De limiet van 300 seconden, en hoe je die kunt omzeilen

Elke taak is beperkt tot 300 seconden aan invoer. Dat is ruim voor een shot en kort voor een reel, dus alles wat langer is, moet worden opgesplitst — en hoe je opsplitst, is belangrijker dan de limiet zelf.

Knip op scènegrenzen, niet volgens een vaste klok. Interpolatoren leiden beweging af tussen aangrenzende frames; bij een harde cut hebben het laatste frame van shot A en het eerste frame van shot B helemaal geen bewegingsrelatie, en een model dat de cut niet detecteert, verzint met alle plezier een morph tussen beide. De changelog van Runway documenteert geen automatische scènedetectie voor dit model, dus de veilige aanname is dat die er niet is. Splits op cuts, interpoleer elk deel, en zet ze weer samen op een tijdlijn met de nieuwe snelheid.

Dat advies is niet specifiek voor Runway — het is overal de standaardwaarschuwing bij AI-retiming. Een SMPTE-paper uit 2025 over AI-ondersteunde postproductie, waarin een TensorRT-geoptimaliseerde interpolatiepijplijn wordt beschreven voor conversies zoals 23,976 → 25 en 29,97 → 23,976, maakt hetzelfde punt: frame-geconverteerde content heeft frameonderbrekingen nodig bij scènecuts, en QC achteraf, anders hallucineert het model over de las heen. Verwacht dat de eerste pass handmatige framevervanging nodig heeft rond moeilijke overgangen.

Hoe het zich verhoudt tot de alternatieven

Frame-interpolatie is al een tijdje een min of meer opgelost probleem, in twee vormen die er allebei anders uitzien dan deze.

• Desktop-suites — Topaz Video AI's Apollo- en Chronos-modellen zijn het referentiepunt voor kwaliteitsgerichte retiming. Een eeuwigdurende licentie, je eigen GPU, geen meter die per seconde loopt, en een afstemmingsronde die iemand beloont die weet waar hij naar kijkt.

• Open-source-interpolatoren — RIFE en vergelijkbare modellen, zelf gehost, in feite gratis aan de marge zodra je de hardware bezit, en de basis van de meeste aangepaste pipelines die postproductiebedrijven zelf bouwden.

• Runway Enhance Frame Rate — geen lokale rekenkracht, één API-aanroep, facturering per inputseconde, en de fractionele NTSC-framerates waar je bij de andere twee van oudsher met de hand omheen moest conformeren.

De afweging is duidelijk. Voor een eenmalige opname op een werkstation dat je al bezit, is een lokale interpolator goedkoper en krijg je knoppen die Runway niet beschikbaar stelt. Voor beeldmateriaal dat binnenkomt in een geautomatiseerde pijplijn, of een leveringsmatrix waarin dezelfde clip op 23.98 moet uitkomen voor het ene territorium en op 25 voor het andere, verwijdert een API die de fractionele framerate rechtstreeks retourneert een conformstap — en de prijs per inputseconde betekent dat de multi-rate-uitvoer niets extra kost.

De routeringslaag eromheen.

Retiming is één fase in een pipeline die ergens in de buurt een taalmodelstap heeft. De shotlist en de conform-notities, de ondertitel- en captionronde die opnieuw moet worden getimed naar de nieuwe framerate, de leveringsmetadata per territorium, het QC-logboek — dat is tekstwerk, en het is het onderdeel van een videopipeline waarvoor niemand budget uittrekt.

Die laag draait op één sleutel voor de 200 modellen in de OrcaRouter-catalogus, met de lijstprijzen van providers doorgegeven tegen 0% opslag en automatische failover tussen providers, zodat een nieuwer of goedkoper model op live verkeer kan worden geprobeerd zonder er een productiepad op te verwedden. Om precies te zijn over de scope: Runway Enhance Frame Rate is een Runway Dev API-model, aangeroepen op Runway's eigen endpoint, en OrcaRouter serveert het niet. Wat wij dekken is alles eromheen.

Wat is nog niet bekend

Bijna niets over kwaliteit. Dit model is op het moment van schrijven ongeveer een dag oud, en alles hierboven over het gedrag ervan komt uit Runway's eigen changelog en aankondiging. Specifiek onbevestigd:

• Artefactgedrag bij snelle beweging, occlusie, bewegingsonscherpte en bronnen met lage bitrate — geen gepubliceerde tests door wie dan ook

• Of het scènecuts automatisch detecteert, of eroverheen overvloeit

• Of audio wordt doorgegeven, opnieuw gesampled of weggegooid wanneer de framesnelheid verandert

• Hoe het qua kwaliteit zich verhoudt tot RIFE, Apollo of Chronos — er bestaat geen rechtstreekse vergelijking

• Of de prijs per inputseconde standhoudt naarmate de doelratio stijgt, of later in een andere tariefcategorie wordt ingedeeld.

Beschouw de 120 fps- en 48 fps-doelen als claims totdat je je eigen footage erdoorheen hebt gehaald, en controleer de cut-verwerking op de eerste clip die je verstuurt.

Wie moet er nu zetten?

Stap nu over als je levert volgens broadcast- of multi-territory-specificaties en momenteel betaalt voor een conformstap, als je footage al door een geautomatiseerde pipeline stroomt die nog één API-call kan verwerken, of als je slow motion wilt van een camera die nooit high speed heeft gefilmd en je liever geen GPU wilt draaien.

Wacht als je meer dan vijf minuten nodig hebt voor één enkele taak en niet kunt segmenteren bij cuts, als je ook de resolutie omhoog wilt hebben — dat is de upscaler, tegen prijzen per frame — of als je al een desktop-interpolator hebt en dit een eenmalige opname is. En wacht als kwaliteit de beslissende factor is in plaats van gemak: niemand buiten Runway heeft een getal gepubliceerd, en de eerste onafhankelijke vergelijking is het wachten waard.

Het patroon om in de gaten te houden is of Runway dit endpoint model voor model blijft uitbreiden. Het heeft al een creative upscaler en nu een retimer, beide op POST /v1/video_upscale, beide geprijsd in volledig verschillende eenheden. Voor iedereen die deliverypipelines bouwt, is de eenheid — invoerseconden in plaats van uitvoerframes — het onderdeel waar je omheen moet ontwerpen.