Runway Enhance Frame Rate trafia do Dev API: od 24 do 120 fps, w tym NTSC

Runway udostępnił nowy model interpolacji klatek w swoim API dla deweloperów 17 września 2026 r., a szczegół, który naprawdę ma znaczenie, to nie najwyższa wartość z zakresu — lecz wartości ułamkowe. Runway Enhance Frame Rate zmienia tempo posiadanego już materiału do docelowych 24, 25, 30, 48, 50, 60 lub 120 fps, a obsługuje także trzy wartości, które faktycznie stosuje się w nadawaniu i kinie: 23,98, 29,97 i 59,94. Własny changelog dla deweloperów Runway opisuje ten model jako enhance_frame_rate, wywoływany przez ten sam endpoint POST /v1/video_upscale, którego firma używa już do swojego kreatywnego upskalera, z limitem 300 sekund materiału wejściowego na zadanie i rozliczaniem 1 kredytu za 2 sekundy.

Ta pozycja rozliczeniowa to druga niespodzianka. Interpolacja klatek jest zwykle rozliczana na podstawie liczby klatek wyjściowych — własny Magnific Video Upscaler Runwaya na tym samym endpoincie pobiera 0,7 kredytu za klatkę wyjściową przy 720p/1K — co oznacza, że konwersja z 24 fps na 120 fps kosztuje pięć razy tyle, co konwersja z 24 na 25. enhance_frame_rate jest rozliczany za sekundę wejścia. Pomnożenie liczby klatek 5× i 1,05× kosztuje dokładnie tyle samo. Jeśli Twoim zadaniem jest dostarczenie jednego materiału w kilku liczbach klatek na sekundę, ten jeden wiersz w tabeli cen odwraca zwykłą arytmetykę.

Wybór momentu również jest wymowny. Samodzielne narzędzie Frame Interpolation firmy Runway znajduje się na oficjalnej liście przestarzałych narzędzi firmy, a aplikacja Animate Keyframes została wskazana jako jego następca. Enhance Frame Rate nie jest wskrzeszeniem tego narzędzia internetowego — to interpolacja klatek przebudowana jako model API, skierowana do potoków przetwarzania, a nie do osoby klikającej na osi czasu.

Co tak naprawdę robi Enhance Frame Rate

To model retimingu, a nie model generatywny. Nie ma promptu, obrazu ani klipu referencyjnego. Przekazujesz mu wideo, które już istnieje — cokolwiek z kamery, z montażu albo z innego modelu Runway — a on syntetyzuje klatki pośrednie potrzebne do osiągnięcia docelowej częstotliwości. Ogłoszenie Runway na jego własnym koncie X ujmuje to tak samo: „konwertuje dowolny materiał do potrzebnych ci specyfikacji”.

Technicznie rzecz biorąc, jest to asynchroniczne zadanie w punkcie końcowym skalowania wideo. Wysyłasz żądanie POST z URI wideo, ustawiasz model: "enhance_frame_rate", otrzymujesz identyfikator zadania i odpytujesz o wynik. Ponieważ współdzieli punkt końcowy z upscalerem Runway, pipeline, który już komunikuje się z /v1/video_upscale, wymaga zmiany parametru, a nie nowej integracji.

W changelogu Runway wymieniono poniższe jako aktualną specyfikację podaną przez dostawcę. Żadna z tych informacji nie została niezależnie zweryfikowana — nie istnieje żaden test porównawczy tego modelu przeprowadzony przez stronę trzecią, a w chwili pisania ma on zaledwie jeden dzień.

• Docelowe liczby klatek — 24, 25, 30, 48, 50, 60 i 120 fps, a także 23,98, 29,97 i 59,94 fps (zapisane w API jako 23_98, 29_97 i 59_94)

• Limit danych wejściowych — 300 sekund na zadanie

• Cena — 1 kredyt za 2 sekundy danych wejściowych; kredyty Runway API kosztują $0.01 za sztukę

Dostęp — POST /v1/video_upscale z model: "enhance_frame_rate", na Runway Dev

• Wcześniejsze rozwiązania w Runway — typ zadania frame_interpolation_v1 istniał w wersji API z 2024-11-06; samodzielne narzędzie internetowe Frame Interpolation jest wycofywane

• Niezależna ocena — nie opublikowano żadnej

Drabinka klatek na sekundę, czyli dlaczego 23,98 to prawdziwy nagłówek

Każde konsumenckie narzędzie do interpolacji oferuje całkowite wartości. Ciekawa jest tutaj kolumna z wartościami ułamkowymi, ponieważ to właśnie ułamkowe wartości podają w rzeczywistości specyfikacje dostarczenia:

• 23,98 (23,976) — częstotliwość klatek filmu NTSC. Niemal każdy master kinowy i streamingowy oraz częstotliwość, względem której przygotowywano DVD i Blu-ray.

• 24 — rzeczywista częstotliwość filmowa, wciąż używana w DCP i wielu materiałach festiwalowych.

• 25 — terytoria PAL i EBU: Wielka Brytania, większość Europy, Australia, duże części Azji i Afryki.

• 29,97 — transmisja NTSC, ułamkowe rodzeństwo 30.

• 30 — całkowita liczba klatek dla przechwytywania ekranu, materiałów internetowych i gier.

• 48 — kino o wysokiej liczbie klatek na sekundę (liczba klatek, przy której kręcono i wyświetlano filmy o Hobbicie).

• 50 — PAL wysoka częstotliwość odświeżania, dokładnie 2× 25.

• 59,94 — wysoka częstotliwość odświeżania NTSC, 60 Hz — częstotliwość transmisji w Stanach Zjednoczonych i Japonii.

• 60 — liczba całkowita 60 Hz, powszechny cel dla płynnego odtwarzania w przeglądarce.

• 120 — zwolnione tempo i wysokie odświeżanie.

Różnica między 24 a 23,976 wygląda na trywialną, ale taka nie jest. W ciągu godziny materiału te dwa formaty rozjeżdżają się o około 3,6 sekundy. Wprowadź master 24,000 do łańcucha dostarczania 23,98, a dostaniesz dryf synchronizacji audio i błędy kadencji, które nie przejdą kontroli jakości emisji — dlatego studia postprodukcyjne historycznie przeprowadzały osobny etap konformowania, aby przepróbkować częstotliwości, albo odmawiały wykonania zlecenia. Narzędzie, które bezpośrednio generuje ułamkową częstotliwość, usuwa jeden etap z tego łańcucha. To znacznie węższe i znacznie nudniejsze twierdzenie niż „120 fps”, ale dla każdego, kto dostarcza materiał do nadawcy, to właśnie powód, by się tym przejmować.

Wartości docelowe 48 i 120 to te, do których w praktyce należy podchodzić sceptycznie. Interpolowanie materiału 24 fps do 120 fps oznacza wymyślanie czterech klatek na każdą prawdziwą, a przy szybkim ruchu, okluzji lub silnym rozmyciu ruchu interpolatory wszelkiego rodzaju powodują powstawanie duchów i zniekształceń. Runway nie publikuje żadnej analizy artefaktów, żadnego porównania z jakimkolwiek innym interpolatorem ani żadnych wskazówek dotyczących jakości dla poszczególnych ujęć — więc uczciwe stanowisko jest takie, że specyfikacja obsługuje 120, a to, jak 120 wygląda na twoim materiale, nie zostało przetestowane.

Ile to kosztuje, krok po kroku

Arytmetyka jest wyjątkowo prosta, ponieważ jednostką są sekundy wejściowe. Przy 1 kredycie za 2 sekundy i 0,01 USD za kredyt w interfejsie API dla deweloperów Runway (przedpłata, minimum 10 USD za 1000 kredytów):

• 10-sekundowy klip, przy dowolnej docelowej szybkości — 5 kredytów, około 0,05 USD

• 30-sekundowy klip — 15 kredytów, około 0,15 USD

• 60-sekundowy klip — 30 kredytów, około 0,30 USD

• 5-minutowy klip, górny limit 300 sekund — 150 kredytów, około 1,50 USD

• 90-sekundowy klip, 24 → 25 fps — 45 kredytów, około 0,45 USD

• Ten sam 90-sekundowy klip, 24 → 120 fps — 45 kredytów, około 0,45 USD

Te dwa ostatnie wiersze to cały argument dotyczący ceny. W modelu rozliczanym za klatkę wyjściową drugie zadanie oznaczałoby 5× większą liczbę klatek, a więc około 5× wyższy rachunek. Tutaj jest za darmo.

Porównanie z sąsiadem na tym samym punkcie końcowym czyni ten argument konkretnym. Magnific Video Upscaler rozlicza się za każdą klatkę wyjściową — 0,7 kredytu przy 720p/1K, 0,9 przy 2K, 1,2 przy 4K, z minimalną opłatą jednego kredytu za generację. 10-sekundowy klip przy 30 fps to 300 klatek wyjściowych, więc stawka 720p/1K daje 210 kredytów, czyli około 2,10 USD. Ten sam klip przetworzony przez enhance_frame_rate kosztuje 5 kredytów, około 0,05 USD. Jeśli chcesz wyższą liczbę klatek na sekundę, a nie większy obraz, sięgnięcie po upscaler kosztuje około czterdzieści razy więcej. Zauważ również, że włączenie opcjonalnego zwiększenia fps w upscalerze zmienia liczbę klatek wyjściowych, a zatem jeszcze bardziej zwiększa ten rachunek — dokumentacja cenowa Runway mówi o tym wprost.

Jedno zastrzeżenie dotyczące kosztów, które warto podkreślić: wiążące są tu strony Runway z cennikiem dla deweloperów, a nie ten artykuł, a cena kredytów podobno od sierpnia 2026 r. jest weryfikowana pod kątem cennika indywidualnego. Sprawdź portal, zanim zaplanujesz budżet na dużą partię.

Limit 300 sekund i jak go obejść

Każde zadanie ma limit 300 sekund materiału wejściowego. To dużo w przypadku pojedynczego ujęcia, ale mało w przypadku rolki, więc wszystko dłuższe trzeba podzielić na segmenty — a sposób podziału ma większe znaczenie niż sam limit.

Cięcie na granicach scen, a nie według sztywnego zegara. Interpolatory wnioskują ruch między sąsiednimi klatkami; przy twardym cięciu ostatnia klatka ujęcia A i pierwsza klatka ujęcia B nie mają ze sobą żadnego związku ruchowego, a model, który nie wykryje cięcia, chętnie wymyśli między nimi morf. Changelog Runway nie dokumentuje automatycznego wykrywania scen dla tego modelu, więc bezpiecznym założeniem jest, że go nie ma. Dziel na fragmenty przy cięciach, interpoluj każdy fragment, złóż z powrotem na osi czasu w nowym tempie.

Ta rada nie dotyczy wyłącznie Runway — to standardowe zastrzeżenie dotyczące retimingu AI wszędzie. Artykuł SMPTE z 2025 r. o postprodukcji wspomaganej przez AI, opisujący zoptymalizowany pod TensorRT potok interpolacji dla konwersji takich jak 23,976 → 25 i 29,97 → 23,976, mówi to samo: materiał po konwersji klatek wymaga przerw w klatkach przy cięciach scen, a następnie kontroli jakości, bo inaczej model halucynuje na łączeniu. Należy się spodziewać, że pierwszy przebieg będzie wymagał ręcznego zastąpienia klatek wokół trudnych przejść.

Jak wypada na tle alternatyw

Interpolacja klatek od jakiegoś czasu jest problemem w miarę rozwiązanym — w dwóch formach, z których obie wyglądają inaczej niż ta.

• Pakiety desktopowe — modele Apollo i Chronos w Topaz Video AI to punkt odniesienia dla retimingu nastawionego na jakość. Licencja wieczysta, własny GPU, brak licznika naliczającego opłaty za sekundę i przebieg dostrajania, który nagradza kogoś, kto wie, na co patrzy.

• Interpolatory open source — RIFE i podobne modele, hostowane samodzielnie, w praktyce darmowe na poziomie kosztu krańcowego, gdy masz już sprzęt, oraz podstawa większości niestandardowych pipeline’ów, które studia postprodukcyjne zbudowały samodzielnie.

• Runway Enhance Frame Rate — brak lokalnych obliczeń, wywołanie API, rozliczanie za sekundę materiału wejściowego oraz ułamkowe szybkości NTSC, które pozostałe dwa od zawsze pozostawiały ci do ręcznego dopasowania.

Ten kompromis jest czytelny. W przypadku jednorazowego ujęcia na stacji roboczej, którą już masz, lokalny interpolator będzie tańszy i da ci kontrolki, których Runway nie udostępnia. W przypadku materiału, który trafia do zautomatyzowanego potoku, albo matrycy dostarczanych materiałów, w której ten sam klip musi wyjść w 23.98 dla jednego terytorium i w 25 dla innego, API bezpośrednio zwracające ułamkową szybkość klatek usuwa etap konformowania — a cena za sekundę materiału wejściowego oznacza, że wyjście w wielu szybkościach nie kosztuje nic dodatkowo.

Warstwa routingu wokół tego

Retiming to jeden z etapów potoku, w którym gdzieś w pobliżu znajduje się krok z modelem językowym. Lista ujęć i notatki z konformowania, etap napisów i podpisów, który trzeba ponownie zsynchronizować z nową liczbą klatek na sekundę, metadane dostarczania dla poszczególnych terytoriów, dziennik QC — to praca z tekstem i to ta część potoku wideo, na którą nikt nie przewiduje budżetu.

Ta warstwa działa na jednym kluczu obejmującym 200 modeli w katalogu OrcaRouter, z cenami listowymi dostawców przekazywanymi przy 0% marży i automatycznym przełączaniem awaryjnym między dostawcami, dzięki czemu nowszy lub tańszy model można wypróbować na ruchu na żywo, nie stawiając na nim ścieżki produkcyjnej. Mówiąc precyzyjnie o zakresie: Runway Enhance Frame Rate to model Runway Dev API, wywoływany na własnym punkcie końcowym Runway, a OrcaRouter go nie obsługuje. Obejmujemy wszystko wokół niego.

Co jeszcze nie jest znane

Prawie nic o jakości. Ten model ma w chwili pisania około jednego dnia, a wszystko powyżej na temat jego zachowania pochodzi z własnego dziennika zmian i ogłoszenia Runway. Konkretnie niezweryfikowane:

• Zachowanie artefaktów przy szybkim ruchu, okluzji, rozmyciu ruchu i źródłach o niskiej przepływności — brak opublikowanych testów przez kogokolwiek

• Czy automatycznie wykrywa cięcia scen, czy też płynnie przechodzi między nimi

• Czy dźwięk jest przepuszczany, ponownie próbkowany czy odrzucany, gdy zmienia się częstotliwość klatek

• Jak wypada pod względem jakości w porównaniu z RIFE, Apollo lub Chronos — nie istnieje bezpośrednie porównanie

• Czy cena za sekundę danych wejściowych utrzyma się wraz ze wzrostem docelowej stawki, czy później zostanie przypisana do innego progu cenowego

Traktuj wartości docelowe 120 fps i 48 fps jako deklaracje, dopóki nie przepuścisz przez nie własnego materiału, i sprawdź obsługę cięć na pierwszym klipie, który wyślesz.

Kto powinien się teraz ruszyć?

Działaj teraz, jeśli dostarczasz materiały zgodnie ze specyfikacjami broadcast lub dla wielu terytoriów i obecnie płacisz za etap konformowania; jeśli Twój materiał już przepływa przez zautomatyzowany pipeline, który może przyjąć jeszcze jedno wywołanie API; albo jeśli chcesz uzyskać zwolnione tempo z kamery, która nigdy nie nagrywała w wysokiej prędkości, a wolisz nie uruchamiać GPU.

Poczekaj, jeśli w pojedynczym zadaniu potrzebujesz więcej niż pięciu minut i nie możesz segmentować w miejscach cięć, jeśli potrzebujesz także podniesienia rozdzielczości — to upscaler, w cenach za klatkę — albo jeśli masz już interpolator na komputer stacjonarny, a to jednorazowe ujęcie. Poczekaj też, jeśli decydującym czynnikiem jest jakość, a nie wygoda: nikt poza Runway nie opublikował liczby, a pierwsze niezależne porównanie to coś, na co warto poczekać.

Wzorzec, na który warto uważać, to czy Runway nadal będzie rozszerzać ten endpoint o kolejne modele. Ma już kreatywny upscaler, a teraz także retimer — oba pod POST /v1/video_upscale, oba wyceniane w zupełnie różnych jednostkach. Dla każdego, kto buduje potoki dostarczania, to jednostka — sekundy na wejściu, a nie klatki na wyjściu — jest elementem, wokół którego warto projektować.