Runway Enhance Frame Rate släpps på Dev API: 24 till 120 fps, NTSC ingår

Runway släppte en ny modell för bildinterpolering i sitt utvecklar-API den 17 september 2026, och detaljen som faktiskt spelar roll är inte toppen av skalan – det är de fraktionella frekvenserna. Runway Enhance Frame Rate tidjusterar material du redan har till ett mål på 24, 25, 30, 48, 50, 60 eller 120 fps, och den accepterar även de tre frekvenser som broadcast och biograf faktiskt levererar: 23,98, 29,97 och 59,94. Runways egen ändringslogg för utvecklare dokumenterar modellen som enhance_frame_rate, anropad via samma POST /v1/video_upscale-slutpunkt som företaget redan använder för sin kreativa uppskalare, med en gräns på 300 sekunder indata per jobb och debitering på 1 kredit per 2 sekunder.

Den faktureringsraden är den andra överraskningen. Bildruteinterpolering prissätts vanligtvis efter utdata – Runways egen Magnific Video Upscaler på samma endpoint debiterar 0,7 krediter per utdatabildruta vid 720p/1K – vilket innebär att en konvertering från 24 fps till 120 fps kostar fem gånger så mycket som en konvertering från 24 till 25. enhance_frame_rate debiteras per sekund av indata. En 5× bildrutemultiplikation och en på 1,05× kostar exakt lika mycket. Om ditt jobb är att leverera ett och samma videomaterial i flera bildfrekvenser, inverterar den enda raden i pristabellen den vanliga matematiken.

Tidpunkten är också talande. Runways fristående Frame Interpolation-verktyg finns med på företagets officiella lista över utfasad verktyg, där appen Animate Keyframes anges som ersättare. Enhance Frame Rate är inte en återupplivning av det webbverktyget – det är frame interpolation som har byggts om till en API-modell, riktat mot pipelines snarare än mot någon som klickar sig genom en tidslinje.

Vad Enhance Frame Rate faktiskt gör

Det här är en retimingmodell, inte en generativ sådan. Det finns ingen prompt, ingen bild, inget referensklipp. Du ger den en video som redan finns – allt från en kamera, en redigering eller en annan Runway-modell – och den syntetiserar de mellanliggande bildrutorna som behövs för att nå målbildfrekvensen. Runways tillkännagivande på deras eget X-konto uttrycker det på samma sätt: "konverterar valfritt material till de specifikationer du behöver."

Mekaniskt sett är det en asynkron uppgift på video-upscale-endpointen. Du POST:ar en video-URI, anger model: "enhance_frame_rate", får ett uppgifts-id tillbaka och pollar efter resultatet. Eftersom den delar en endpoint med Runways upscaler behöver en pipeline som redan kommunicerar med /v1/video_upscale en parameterändring snarare än en ny integration.

Runways ändringslogg listar följande som den aktuella specifikationen enligt leverantören. Inget av det har verifierats oberoende — det finns ingen tredjepartsbenchmark för den här modellen, och den är en dag gammal när detta skrivs.

• Målfrekvenser – 24, 25, 30, 48, 50, 60 och 120 fps, plus 23.98, 29.97 och 59.94 fps (skrivs i API:et som 23_98, 29_97 och 59_94)

• Indatagräns – 300 sekunder per jobb

• Pris — 1 kredit per 2 sekunders indata; Runway API-krediter kostar 0,01 USD styck

• Åtkomst — POST /v1/video_upscale med model: "enhance_frame_rate", på Runway Dev

• Tidigare teknik hos Runway — en uppgiftstyp frame_interpolation_v1 fanns under API-versionen 2024-11-06; det fristående webbverktyget Frame Interpolation är föråldrat

• Oberoende utvärdering — ingen publicerad

Bildfrekvensstegen, och varför 23,98 är den egentliga rubriken

Alla interpoleringsverktyg för konsumentbruk erbjuder heltalsfrekvenser. Den intressanta kolumnen här är den fraktionella, eftersom fraktionella frekvenser är vad leveransspecifikationerna faktiskt säger:

• 23,98 (23,976) — NTSC-filmhastigheten. Nästan varje master för bio och streaming, och den hastighet som DVD och Blu-ray mastrades mot.

• 24 — äkta filmhastighet, används fortfarande för DCP och många festivalleveranser.

• 25 — PAL- och EBU-områden: Storbritannien, större delen av Europa, Australien, stora delar av Asien och Afrika.

• 29.97 — NTSC-sändning, 30:s fraktionella syskon.

• 30 — heltalsbildfrekvens för skärminspelning, webb- och spelmaterial.

• 48 — bio med hög bildfrekvens (den bildfrekvens som Hobbit-filmerna spelades in och projicerades i).

• 50 — PAL hög bildfrekvens, exakt 2× 25.

• 59.94 — NTSC hög bildfrekvens, sändningstakten på 60 Hz i USA och Japan.

• 60 — heltal 60 Hz, det vanliga målet för smidig uppspelning på webben.

• 120 — slow motion och leverans med hög uppdateringsfrekvens.

Gapet mellan 24 och 23,976 verkar trivialt och är det inte. Under en timmes speltid glider de två isär med ungefär 3,6 sekunder. Mata in en 24,000-master i en 23,98-leveranskedja och du får ljudsynkdrift och kadensfel som broadcast-QC kommer att underkänna – vilket är anledningen till att posthus historiskt körde ett separat conform-steg för att sampla om hastigheter, eller tackade nej till jobbet. Ett verktyg som matar ut den fraktionella hastigheten direkt tar bort ett steg från den kedjan. Det är ett mycket snävare, mycket tråkigare påstående än "120 fps", och för alla som levererar till en broadcaster är det anledningen till att bry sig.

De 48- och 120-målen är de man i praktiken bör vara skeptisk till. Att interpolera 24 fps-material upp till 120 fps innebär att hitta på fyra bildrutor för varje verklig, och vid snabba rörelser, ocklusion eller kraftig rörelseoskärpa producerar interpolatorer av alla slag spökbilder och förvrängning. Runway publicerar ingen artefaktanalys, ingen jämförelse mot någon annan interpolator och ingen kvalitetsvägledning per tagning – så den ärliga hållningen är att specifikationen stöder 120, och hur 120 ser ut på ditt material är otestat.

Vad det kostar, genomräknat

Beräkningen är ovanligt enkel eftersom enheten är indatasekunder. Med 1 kredit per 2 sekunder och $0,01 per kredit i Runways utvecklar-API (förbetalt, minst $10 för 1 000 krediter):

• Ett 10-sekundersklipp, vid valfri målhastighet — 5 krediter, cirka 0,05 USD

• Ett 30-sekundersklipp — 15 krediter, cirka 0,15 dollar

• Ett klipp på 60 sekunder — 30 credits, cirka 0,30 $

• Ett 5-minutersklipp, taket på 300 sekunder — 150 krediter, ungefär 1,50 $

• Ett klipp på 90 sekunder, 24 → 25 fps — 45 krediter, cirka $0,45

• Samma 90-sekundersklipp, 24 → 120 fps — 45 krediter, cirka $0,45

De två sista raderna utgör hela argumentet för prissättningen. I en modell med pris per utdatabildruta skulle det andra jobbet bli 5× så många bildrutor och därför ungefär 5× så hög nota. Här är det gratis.

Jämförelsen mot grannen på samma endpoint gör poängen konkret. Magnific Video Upscaler debiterar per genererad bildruta — 0,7 credits vid 720p/1K, 0,9 vid 2K, 1,2 vid 4K, med en lägsta avgift på en credit per generering. Ett 10 sekunder långt klipp i 30 fps består av 300 genererade bildrutor, så 720p/1K-taxan landar på 210 credits, eller cirka 2,10 $. Det identiska klippet via enhance_frame_rate kostar 5 credits, cirka 0,05 $. Om du vill ha en högre bildfrekvens och inte en större bild kostar det ungefär fyrtio gånger mer att ta till upscalern. Notera också att om du aktiverar upscalerns valfria fps-boost ändras antalet genererade bildrutor och höjer därför den räkningen ytterligare — Runways prisdokumentation säger det uttryckligen.

Ett kostnadsförbehåll värt att påpeka: Runways prissida för utvecklare är den auktoritativa källan här, inte den här artikeln, och kreditpriset har rapporterats vara under översyn mot anpassad prissättning sedan augusti 2026. Kontrollera portalen innan du budgeterar för en stor batch.

Gränsen på 300 sekunder, och hur man kringgår den

Varje jobb är begränsat till 300 sekunders indata. Det är generöst för en tagning och kort för en reel, så allt som är längre måste segmenteras – och hur du segmenterar spelar större roll än själva gränsen.

Klipp vid scengränser, inte efter en fast klocka. Interpolatorer härleder rörelse mellan intilliggande bildrutor; vid ett hårt klipp har den sista bildrutan i tagning A och den första bildrutan i tagning B ingen rörelserelation alls, och en modell som inte upptäcker klippet kommer gladeligen att hitta på en morph mellan dem. Runways ändringslogg dokumenterar inte automatisk scendetektering för den här modellen, så det säkra antagandet är att det inte finns någon. Stycka vid klipp, interpolera varje stycke och sätt ihop igen på en tidslinje med den nya frekvensen.

Det rådet är inte specifikt för Runway — det är den vanliga varningen för AI-omtimning överallt. Ett SMPTE-papper från 2025 om AI-assisterad postproduktion, som beskriver en TensorRT-optimerad interpolationspipeline för konverteringar som 23.976 → 25 och 29.97 → 23.976, framför samma poäng: bildruteomvandlat innehåll behöver bildrutebrytningar vid scenklipp, och QC efteråt, annars hallucinerar modellen över skarven. Räkna med att den första genomkörningen behöver manuell bildruteersättning runt svåra övergångar.

Var den står jämfört med alternativen

Bildruteinterpolering har varit ett i stort sett löst problem ett tag, i två former som båda ser annorlunda ut än den här.

• Programs viter för skrivbordet – Topaz Video AI:s modeller Apollo och Chronos är referenspunkten för kvalitetsfokuserad retiming. En evig licens, din egen GPU, ingen sekundmätare, och en finjusteringsomgång som belönar den som vet vad den tittar på.

• Interpolatorer med öppen källkod – RIFE och liknande modeller, självhostade, i praktiken gratis vid marginalen när du väl äger hårdvaran, och grunden för de flesta av de anpassade pipelines som postproduktionshus byggde själva.

• {{1}}Runway Enhance Frame Rate{{/1}} — ingen lokal beräkning, ett API-anrop, fakturering per indatasekund och de fraktionella NTSC-frekvenserna som de andra två historiskt har lämnat åt dig att anpassa för hand.

Avvägningen är tydlig. För en enstaka tagning på en arbetsstation du redan äger blir en lokal interpolator billigare och ger dig rattar som Runway inte exponerar. För material som kommer in i en automatiserad pipeline, eller en leveransmatris där samma klipp måste komma ut i 23,98 för ett territorium och 25 för ett annat, tar ett API som returnerar den fraktionella bildfrekvensen direkt bort ett conform-steg — och priset per indatasekund innebär att utdata med flera bildfrekvenser inte kostar något extra.

Routningslagret runt det

Retiming är ett steg i en pipeline som har ett språkmodellssteg någonstans i närheten. Taglistan och conform-anteckningarna, undertext- och bildtextpasset som måste tidsjusteras till den nya bildfrekvensen, leveransmetadatan per territorium, QC-loggen — det är textarbete, och det är den del av en videopipeline som ingen budgeterar för.

Det lagret körs på en enda nyckel över de 200 modellerna i OrcaRouter-katalogen, med leverantörernas listpriser vidarebefordrade med 0 % påslag och automatisk redundansväxling mellan leverantörer, så att en nyare eller billigare modell kan testas på livetrafik utan att satsa en produktionsväg på den. För att vara exakt om omfattningen: Runway Enhance Frame Rate är en Runway Dev API-modell, som anropas på Runways egen slutpunkt, och OrcaRouter tillhandahåller den inte. Det vi täcker är allt runtomkring den.

Vad som ännu inte är känt

Nästan ingenting om kvalitet. Den här modellen är ungefär en dag gammal när detta skrivs, och allt ovan om dess beteende kommer från Runways egen ändringslogg och tillkännagivande. Specifikt overifierat:

• Artefaktbeteende vid snabb rörelse, ocklusion, rörelseoskärpa och källor med låg bitrate – inga publicerade tester av någon

• Om den automatiskt upptäcker scenbyten eller tonar över dem

• Huruvida ljudet förs vidare, omsamplas eller tas bort när bildfrekvensen ändras

• Hur den står sig kvalitetsmässigt jämfört med RIFE, Apollo eller Chronos – ingen direkt jämförelse finns

• Huruvida priset per indatasekund håller när målhastigheten ökar, eller får nya nivåer senare

Behandla målen 120 fps och 48 fps som påståenden tills du har kört ditt eget material genom dem, och kontrollera klipphanteringen på det första klippet du skickar.

Vem ska flytta nu?

Agera nu om du levererar enligt specifikationer för broadcast eller flera territorier och för närvarande betalar för ett conform-steg, om ditt material redan flödar genom en automatiserad pipeline som kan absorbera ytterligare ett API-anrop, eller om du vill ha slow motion från en kamera som aldrig filmade i hög hastighet och du helst inte vill köra en GPU.

Vänta om du behöver mer än fem minuter i ett enda jobb och inte kan segmentera vid klipp, om du behöver upplösningen uppskalad också — det är uppskalaren, till priser per bildruta — eller om du redan äger en desktop-interpolator och detta är en engångstagning. Och vänta om kvaliteten är den avgörande faktorn snarare än bekvämligheten: ingen utanför Runway har publicerat en siffra, och den första oberoende jämförelsen är det som är värt att vänta på.

Mönstret att hålla utkik efter är om Runway fortsätter att bygga ut denna endpoint modell för modell. Den har redan en kreativ uppskalare och nu en retimer, båda på POST /v1/video_upscale, båda prissatta i helt olika enheter. För alla som bygger leveranspipelines är enheten – indatasekunder snarare än utdatabildrutor – den del som är värd att designa kring.