Runway Enhance Frame Rate arriva sull'API Dev: da 24 a 120 fps, NTSC incluso

Runway ha introdotto un nuovo modello di interpolazione dei fotogrammi sulla sua API per sviluppatori il 17 settembre 2026, e il dettaglio che conta davvero non è il top di gamma — sono le frequenze frazionarie. Runway Enhance Frame Rate ricampiona temporalmente il materiale che hai già a una frequenza obiettivo di 24, 25, 30, 48, 50, 60 o 120 fps, e accetta anche le tre frequenze che il broadcast e il cinema utilizzano realmente: 23.98, 29.97 e 59.94. Il changelog per sviluppatori di Runway documenta il modello come enhance_frame_rate, richiamato tramite lo stesso endpoint POST /v1/video_upscale che l'azienda usa già per il suo upscaler creativo, con un limite di 300 secondi di input per job e un costo di 1 credito ogni 2 secondi.

Quella riga di fatturazione è la seconda sorpresa. L'interpolazione dei frame viene di solito tariffata sull'output — il Magnific Video Upscaler di Runway su quello stesso endpoint addebita 0,7 crediti per frame di output a 720p/1K — il che significa che una conversione da 24 fps a 120 fps costa cinque volte quanto una conversione da 24 a 25. enhance_frame_rate viene addebitato per secondo di input. Una moltiplicazione dei frame di 5× e una di 1,05× costano esattamente lo stesso. Se il tuo lavoro consiste nel consegnare un singolo filmato a diverse frequenze di frame, quella singola riga nella tabella dei prezzi inverte la consueta aritmetica.

Anche il tempismo è significativo. Lo strumento autonomo Frame Interpolation di Runway figura nell'elenco ufficiale degli strumenti deprecati dell'azienda, con l'app Animate Keyframes indicata come sua sostituta. Enhance Frame Rate non è una rinascita di quello strumento web: è l'interpolazione dei fotogrammi ricostruita come modello API, pensata per le pipeline anziché per chi clicca attraverso una timeline.

Cosa fa realmente Enhance Frame Rate

Questo è un modello di retiming, non generativo. Non c'è alcun prompt, nessuna immagine, nessuna clip di riferimento. Gli si consegna un video già esistente — qualcosa proveniente da una fotocamera, da un montaggio o da un altro modello Runway — e sintetizza i fotogrammi intermedi necessari per raggiungere la frequenza target. L'annuncio di Runway sul proprio account X lo presenta allo stesso modo: "converte qualsiasi filmato nelle specifiche di cui hai bisogno."

Meccanicamente è un'attività asincrona sull'endpoint di upscale video. Si effettua il POST di un URI video, si imposta model: "enhance_frame_rate", si riceve un id attività e si esegue il polling per il risultato. Poiché condivide un endpoint con l'upscaler di Runway, una pipeline che comunica già con /v1/video_upscale necessita di una modifica di parametro anziché di una nuova integrazione.

Il changelog di Runway elenca quanto segue come specifica attuale dichiarata dal fornitore. Nulla di tutto ciò è stato verificato in modo indipendente — non esiste alcun benchmark di terze parti per questo modello, e al momento della stesura ha un giorno di vita.

• Frequenze target — 24, 25, 30, 48, 50, 60 e 120 fps, più 23,98, 29,97 e 59,94 fps (scritti nell'API come 23_98, 29_97 e 59_94)

• Limite di input — 300 secondi per processo

• Prezzo — 1 credito ogni 2 secondi di input; i crediti dell'API Runway costano $0,01 ciascuno

• Accesso — POST /v1/video_upscale con model: "enhance_frame_rate", su Runway Dev

• Precedente in Runway — un tipo di task frame_interpolation_v1 esisteva nella versione API 2024-11-06; lo strumento web standalone Frame Interpolation è deprecato

• Valutazione indipendente — nessuna pubblicata

La scala dei frame rate, e perché 23.98 è la vera notizia

Ogni strumento di interpolazione consumer offre frequenze intere. La colonna interessante qui è quella frazionaria, perché le frequenze frazionarie sono ciò che le specifiche di consegna dicono effettivamente:

• 23.98 (23.976) — la frequenza del film NTSC. Quasi tutti i master cinematografici e di streaming, nonché la frequenza sulla quale sono stati autorati DVD e Blu-ray.

• 24 — vero frame rate cinematografico, ancora utilizzato per DCP e molti deliverable per festival.

• 25 — Territori PAL ed EBU: il Regno Unito, gran parte dell'Europa, l'Australia, vaste aree dell'Asia e dell'Africa.

• 29.97 — trasmissione NTSC, il fratello frazionario di 30.

• 30 — frequenza intera per la cattura dello schermo, filmati web e di gioco.

• 48 — cinema ad alta frequenza di fotogrammi (la frequenza a cui sono stati girati e proiettati i film de Lo Hobbit).

• 50 — alta frequenza fotogrammi PAL, esattamente 2× 25.

• 59.94 — NTSC alta frequenza di fotogrammi, la frequenza di consegna broadcast di 60 Hz negli Stati Uniti e in Giappone.

• 60 — intero 60 Hz, il target comune per una riproduzione web fluida.

• 120 — slow motion e consegna ad alto refresh.

La differenza tra 24 e 23,976 sembra banale e non lo è. Nell'arco di un'ora di durata, le due frequenze divergono di circa 3,6 secondi. Se si immette un master a 24,000 in una catena di consegna a 23,98, si ottengono derive di sincronizzazione audio ed errori di cadenza che non supererebbero il QC di trasmissione — ed è per questo che le case di post-produzione storicamente eseguivano una fase di conform separata per ricampionare le frequenze, oppure rifiutavano il lavoro. Uno strumento che genera direttamente la frequenza frazionaria elimina una fase da quella catena. Questa è un'affermazione molto più ristretta e molto più noiosa di "120 fps", e per chiunque consegni a un broadcaster è il motivo per cui vale la pena interessarsi.

I target a 48 e 120 fps sono quelli di cui diffidare nella pratica. Interpolare materiale a 24 fps fino a 120 fps significa inventare quattro fotogrammi per ogni fotogramma reale e, in caso di movimenti rapidi, occlusioni o motion blur intenso, gli interpolatori di ogni tipo producono ghosting e warping. Runway non pubblica alcuna analisi degli artefatti, alcun confronto con altri interpolatori né indicazioni sulla qualità per singola ripresa — quindi la posizione onesta è che le specifiche supportano i 120 fps, e non è stato testato come appaiono i 120 fps sul tuo footage.

Quanto costa, analizzato nel dettaglio

L'aritmetica è insolitamente semplice perché l'unità è in secondi di input. A 1 credito ogni 2 secondi, e $0,01 per credito sull'API per sviluppatori di Runway (prepagata, minimo di $10 per 1.000 crediti):

• Una clip di 10 secondi, a qualsiasi velocità target — 5 crediti, circa $0,05

• Una clip di 30 secondi — 15 crediti, circa $0,15

• Una clip di 60 secondi — 30 crediti, circa 0,30 $

• Una clip di 5 minuti, il tetto dei 300 secondi — 150 crediti, circa 1,50 $

• Una clip di 90 secondi, 24 → 25 fps — 45 crediti, circa 0,45 $

• La stessa clip di 90 secondi, da 24 → 120 fps — 45 crediti, circa 0,45 $

Quelle ultime due righe sono l'intera argomentazione sul prezzo. In un modello per frame di output, il secondo lavoro avrebbe un conteggio di frame 5× e quindi all'incirca 5× la fattura. Qui è gratis.

Il confronto con il concorrente sullo stesso endpoint rende concreto il concetto. Magnific Video Upscaler fattura per frame di output — 0,7 crediti a 720p/1K, 0,9 a 2K, 1,2 a 4K, con un minimo di un credito per generazione. Una clip di 10 secondi a 30 fps è di 300 frame di output, quindi la tariffa 720p/1K arriva a 210 crediti, ovvero circa 2,10 $. La clip identica tramite enhance_frame_rate costa 5 crediti, circa 0,05 $. Se vuoi una frequenza di frame più alta e non un'immagine più grande, ricorrere all'upscaler costa circa quaranta volte di più. Nota anche che abilitare il boost fps opzionale dell'upscaler modifica il numero di frame di output e quindi aumenta ulteriormente quel costo — la documentazione sui prezzi di Runway lo dice esplicitamente.

Un'avvertenza sui costi che vale la pena segnalare: la pagina dei prezzi per sviluppatori di Runway è l'autorità in materia, non questo articolo, e il prezzo dei crediti è segnalato come in fase di revisione verso una tariffazione personalizzata da agosto 2026. Controlla il portale prima di stanziare un budget per un lotto consistente.

Il limite di 300 secondi e come aggirarlo

Ogni job è limitato a 300 secondi di input. È generoso per uno shot e breve per un reel, quindi qualsiasi cosa più lunga deve essere segmentata — e come si segmenta conta più del limite stesso.

Taglia ai confini di scena, non su un clock fisso. Gli interpolatori inferiscono il movimento tra fotogrammi adiacenti; in corrispondenza di un taglio netto, l'ultimo fotogramma dell'inquadratura A e il primo fotogramma dell'inquadratura B non hanno alcuna relazione di movimento, e un modello che non rileva il taglio inventerà allegramente un morph tra i due. Il changelog di Runway non documenta il rilevamento automatico delle scene per questo modello, quindi l'ipotesi prudente è che non ce ne sia alcuno. Suddividi in blocchi in corrispondenza dei tagli, interpola ciascun blocco, riassembla su una timeline alla nuova frequenza.

Quel consiglio non è specifico di Runway — è l'avvertenza standard sul retiming AI ovunque. Un paper SMPTE del 2025 sulla post-produzione assistita dall'IA, che descrive una pipeline di interpolazione ottimizzata per TensorRT per conversioni come 23,976 → 25 e 29,97 → 23,976, fa la stessa osservazione: i contenuti sottoposti a conversione di frame necessitano di interruzioni di frame in corrispondenza dei tagli di scena, e di un controllo qualità successivo, altrimenti il modello produce allucinazioni attraverso la giunzione. Aspettatevi che la prima passata richieda la sostituzione manuale dei frame in corrispondenza delle transizioni difficili.

Come si posiziona rispetto alle alternative

L'interpolazione dei fotogrammi è un problema più o meno risolto da un po', in due forme che sono entrambe diverse da questa.

• Suite desktop — I modelli Apollo e Chronos di Topaz Video AI sono il punto di riferimento per il retiming orientato alla qualità. Una licenza perpetua, la propria GPU, nessun contatore al secondo e una passata di tuning che premia chi sa cosa sta guardando.

• Interpolatori open source — RIFE e modelli simili, self-hosted, di fatto gratuiti al margine una volta che si possiede l'hardware, e la base della maggior parte delle pipeline personalizzate che le case di post-produzione si sono costruite da sole.

• Runway Enhance Frame Rate — nessun calcolo locale, una chiamata API, fatturazione per secondo di input e le frequenze NTSC frazionarie che gli altri due ti hanno storicamente lasciato da conformare a mano.

Il trade-off è chiaro. Per una ripresa una tantum su una workstation che già possiedi, un interpolatore locale sarà più economico e ti offre controlli che Runway non espone. Per materiale che arriva all'interno di una pipeline automatizzata, o una matrice di deliverable in cui lo stesso clip deve uscire a 23,98 per un territorio e a 25 per un altro, un'API che restituisce direttamente il frame rate frazionario elimina una fase di conform — e il prezzo per secondo di input significa che l'output multi-rate non comporta alcun costo aggiuntivo.

Il livello di routing che lo circonda

Il retiming è una fase di una pipeline che ha uno step di modello linguistico da qualche parte nelle vicinanze. La shot list e le note di conform, il passaggio di sottotitoli e didascalie che deve essere ri-temporizzato al nuovo frame rate, i metadati di consegna per territorio, il log di QC — questo è lavoro testuale, ed è la parte di una pipeline video per cui nessuno stanzia un budget.

Quel layer gira su una sola chiave per tutti i 200 modelli del catalogo OrcaRouter, con i prezzi di listino dei provider passati con markup 0% e failover automatico tra provider, così un modello più recente o più economico può essere provato su traffico reale senza scommettere una rotta di produzione su di esso. Per essere precisi sull'ambito: Runway Enhance Frame Rate è un modello Runway Dev API, chiamato sull'endpoint di Runway stesso, e OrcaRouter non lo eroga. Ciò che copriamo è tutto ciò che gli sta attorno.

Ciò che non è ancora noto

Quasi nulla sulla qualità. Al momento in cui scrivo, questo modello ha all'incirca un giorno di vita, e tutto quanto sopra sul suo comportamento proviene dal changelog e dall'annuncio di Runway. Nello specifico, non verificato:

• Comportamento degli artefatti su movimento rapido, occlusione, motion blur e sorgenti a basso bitrate — nessun test pubblicato da nessuno

• Se rileva automaticamente i tagli di scena oppure se esegue una dissolvenza tra di essi

• Se l'audio viene mantenuto, ricampionato o scartato quando la frequenza dei fotogrammi cambia

• Come si confronta in qualità con RIFE, Apollo o Chronos — non esiste un confronto diretto

• Se il prezzo per secondo di input rimane valido man mano che la frequenza target aumenta, oppure viene riclassificato in seguito

Considera i target di 120 fps e 48 fps come semplici dichiarazioni finché non ci avrai provato il tuo materiale, e controlla la gestione dei tagli sul primo clip che invii.

Chi dovrebbe muoversi ora?

Agisci ora se consegni secondo specifiche broadcast o multi-territorio e attualmente paghi per una fase di conform, se il tuo footage scorre già attraverso una pipeline automatizzata in grado di assorbire una chiamata API in più, o se vuoi lo slow motion da una camera che non ha mai girato ad alta velocità e preferisci non far girare una GPU.

Aspetta se ti servono più di cinque minuti in un singolo lavoro e non puoi segmentare ai tagli, se hai bisogno anche di aumentare la risoluzione — quello è l'upscaler, a prezzi per fotogramma — o se possiedi già un interpolatore desktop e questa è una ripresa una tantum. E aspetta se la qualità è il fattore decisivo anziché la comodità: nessuno al di fuori di Runway ha pubblicato un numero, e il primo confronto indipendente è la cosa per cui vale la pena aspettare.

Il pattern da tenere d'occhio è se Runway continua ad estendere questo endpoint modello dopo modello. Include già un upscaler creativo e ora un retimer, entrambi su POST /v1/video_upscale, entrambi con prezzi calcolati su unità completamente diverse. Per chiunque costruisca pipeline di delivery, l'unità — secondi di input anziché frame di output — è la parte su cui vale la pena progettare.