Runway Enhance Frame Rate יוצא ב-Dev API: מ־24 עד 120 fps, כולל NTSC

Runway השיקה מודל חדש לאינטרפולציית פריימים ב-API למפתחים שלה ב-17 בספטמבר 2026, והפרט שבאמת חשוב אינו הקצה העליון של הטווח — אלא הקצבים השבריים. Runway Enhance Frame Rate מתאים מחדש את קצב הצילום שכבר יש לכם ליעד של 24, 25, 30, 48, 50, 60 או 120 פריימים לשנייה, והוא גם מקבל את שלושת הקצבים ששידור וקולנוע באמת מספקים: 23.98, 29.97 ו-59.94. יומן השינויים למפתחים של Runway עצמה מתעד את המודל בשם enhance_frame_rate, שנקרא דרך אותה נקודת קצה POST /v1/video_upscale שהחברה כבר משתמשת בה עבור משפר האיכות היצירתי שלה, עם תקרה של 300 שניות קלט לכל משימה וחיוב של קרדיט אחד לכל 2 שניות.

שורת החיוב הזו היא ההפתעה השנייה. אינטרפולציית פריימים מתומחרת בדרך כלל לפי פלט — Magnific Video Upscaler של Runway עצמה באותו endpoint גובה 0.7 קרדיטים לכל פריים פלט ב-720p/1K — מה שאומר שהמרה מ-24 fps ל-120 fps עולה פי חמישה מהמרה מ-24 ל-25. enhance_frame_rate מחויב לפי שנייה של קלט. הכפלת פריימים פי 5 והכפלה פי 1.05 עולות בדיוק אותו דבר. אם התפקיד שלך הוא לספק קטע צילום אחד בכמה קצבי פריימים, השורה הבודדת הזו בטבלת התמחור הופכת את החשבון הרגיל.

גם התזמון אינו מקרי. הכלי העצמאי Frame Interpolation של Runway נמצא ברשימת הכלים שהוצאו משימוש הרשמית של החברה, כאשר האפליקציה Animate Keyframes מוגדרת כמחליפתו. Enhance Frame Rate אינו תחייה של אותו כלי ווב — אלא אינטרפולציית פריימים שנבנתה מחדש כמודל API, שמיועדת לפייפליינים ולא למי שמקליק דרך ציר זמן.

מה Enhance Frame Rate באמת עושה

זהו מודל לשינוי קצב, לא מודל גנרטיבי. אין פרומפט, אין תמונה, אין קליפ ייחוס. אתה מוסר לו וידאו שכבר קיים — בין אם ממצלמה, מעריכה או ממודל Runway אחר — והוא מסנתז את פריימי הביניים הדרושים כדי להגיע לקצב היעד. ההכרזה של Runway בחשבון ה-X שלה מנסחת זאת באותו אופן: "ממיר כל קטע וידאו למפרט שאתה צריך."

מבחינה מכנית זוהי משימה אסינכרונית בנקודת הקצה לשדרוג וידאו. שולחים URI של וידאו ב-POST, מגדירים model: "enhance_frame_rate", מקבלים חזרה מזהה משימה, ומבצעים polling לקבלת התוצאה. מכיוון שהיא חולקת נקודת קצה עם ה-upscaler של Runway, פייפליין שכבר מדבר עם /v1/video_upscale זקוק לשינוי פרמטר ולא לאינטגרציה חדשה.

יומן השינויים של Runway מפרט את הדברים הבאים כמפרט הנוכחי שמצהיר הספק. דבר מכל אלה לא אומת באופן בלתי תלוי — אין בנצ'מרק של צד שלישי לדגם הזה, והוא בן יום אחד בלבד במועד כתיבת הדברים.

• קצבי יעד — 24, 25, 30, 48, 50, 60 ו-120 fps, בנוסף ל-23.98, 29.97 ו-59.94 fps (הכתובים ב-API בתור 23_98, 29_97 ו-59_94)

• מגבלת קלט — 300 שניות לכל משימה

• מחיר — קרדיט אחד לכל 2 שניות של קלט; קרדיטים של Runway API הם $0.01 כל אחד

• גישה — POST /v1/video_upscale עם model: "enhance_frame_rate", ב-Runway Dev

• עבודה קודמת ב-Runway — סוג משימה frame_interpolation_v1 היה קיים תחת גרסת ה-API מ-2024-11-06; הכלי המקוון העצמאי Frame Interpolation הוצא משימוש

• הערכה עצמאית — לא פורסמה

סולם קצבי הפריימים, ולמה 23.98 הוא הכותרת האמיתית

כל כלי אינטרפולציה צרכני מציע קצבים שלמים. העמודה המעניינת כאן היא זו השברית, כי קצבים שבריים הם מה שמפרטי המסירה בעצם אומרים:

• 23.98 (23.976) — קצב NTSC-film. כמעט כל מאסטר לקולנוע ולסטרימינג, והקצב ש-DVD ו-Blu-ray הופקו לפיו.

• 24 — קצב הסרט האמיתי, שעדיין משמש ל-DCP ולהרבה תוצרי מסירה לפסטיבלים.

• 25 — שטחי PAL ו-EBU: הממלכה המאוחדת, רוב אירופה, אוסטרליה, חלקים נרחבים של אסיה ואפריקה.

• 29.97 — שידור NTSC, האח השברי של 30.

• 30 — קצב שלם (integer) ללכידת מסך, לתוכן אינטרנט ולצילומי משחקים.

• 48 — קולנוע בקצב פריימים גבוה (הקצב שבו צולמו והוקרנו סרטי "ההוביט").

• 50 — קצב פריימים גבוה של PAL, בדיוק 2× 25.

• 59.94 — קצב פריימים גבוה של NTSC, קצב שידור של 60 Hz בארה״ב וביפן.

• 60 — מספר שלם של 60 הרץ, היעד הנפוץ להשמעה חלקה באינטרנט.

• 120 — הילוך איטי, והעברה בקצב רענון גבוה.

הפער בין 24 ל-23.976 נראה זניח — והוא לא. במהלך שעת ריצה אחת השניים נסחפים זה מזה בכ-3.6 שניות. הזינו מאסטר 24.000 לשרשרת מסירה של 23.98, ותקבלו סחיפת סינכרון אודיו ושגיאות קדנס שבקרת איכות שידור תפסול — ולכן בתי פוסט נהגו היסטורית להריץ שלב קונפורם נפרד כדי לדגום מחדש קצבים, או סירבו לעבודה. כלי שפולט את הקצב השברי ישירות מסיר שלב מהשרשרת הזו. זו טענה הרבה יותר מצומצמת והרבה יותר משעממת מ"120 fps", ולכל מי שמספק תוכן לגוף שידור, זו הסיבה שכדאי לשים לב.

יעדי 48 ו-120 הם אלה שכדאי להיות ספקניים לגביהם בפועל. אינטרפולציה של חומר ב-24 fps עד 120 fps משמעה להמציא ארבעה פריימים עבור כל פריים אמיתי, ובתנועה מהירה, הסתרה או טשטוש תנועה כבד, אינטרפולטורים מכל סוג יוצרים רוחות רפאים ועיוותים. Runway אינה מפרסמת ניתוח ארטיפקטים, לא השוואה מול שום אינטרפולטור אחר, ולא הנחיות איכות לפי שוט — כך שהעמדה הכנה היא שהמפרט תומך ב-120, ומה ש-120 נראה על הצילום שלך אינו נבדק.

מה זה עולה, בפרוטרוט

האריתמטיקה נקייה באופן יוצא דופן מכיוון שהיחידה היא שניות קלט. בקצב של קרדיט אחד לכל 2 שניות, ו-$0.01 לקרדיט ב-API למפתחים של Runway (תשלום מראש, מינימום $10 עבור 1,000 קרדיטים):

• קליפ של 10 שניות, בכל קצב יעד — 5 קרדיטים, כ-$0.05

• סרטון של 30 שניות — 15 קרדיטים, בערך $0.15

• קליפ באורך 60 שניות — 30 קרדיטים, כ-0.30 דולר

• קליפ באורך 5 דקות, תקרת 300 השניות — 150 קרדיטים, בערך $1.50

• קליפ באורך 90 שניות, 24 → 25 fps — 45 קרדיטים, כ-0.45 דולר

• אותו קליפ באורך 90 שניות, 24 → 120 fps — 45 קרדיטים, בערך $0.45

שתי השורות האחרונות האלה הן כל טיעון התמחור. במודל של תמחור לפי פריים פלט, העבודה השנייה הייתה כרוכה במספר פריימים גדול פי 5, ולכן בחשבון גדול פי 5 בערך. כאן זה בחינם.

ההשוואה מול המתחרה באותו endpoint ממחישה את הנקודה היטב. Magnific Video Upscaler מחייב לפי פריים פלט — 0.7 קרדיטים ב-720p/1K, 0.9 ב-2K, 1.2 ב-4K, עם מינימום של קרדיט אחד לכל יצירה. קליפ באורך 10 שניות ב-30 fps הוא 300 פריימים בפלט, כך שתעריף 720p/1K מגיע ל-210 קרדיטים, או כ-$2.10. אותו קליפ בדיוק דרך enhance_frame_rate עולה 5 קרדיטים, כ-$0.05. אם אתם רוצים קצב פריימים גבוה יותר ולא תמונה גדולה יותר, השימוש ב-upscaler עולה בערך פי ארבעים יותר. שימו לב גם שהפעלת תוספת ה-fps האופציונלית של ה-upscaler משנה את מספר הפריימים בפלט ולכן מייקרת את החשבון עוד יותר — מסמכי התמחור של Runway אומרים זאת במפורש.

הסתייגות אחת בנוגע לעלות שראוי לציין: עמוד התמחור למפתחים של Runway הוא הסמכות כאן, לא המאמר הזה, ומחיר הקרדיט דווח כנמצא בבחינה לקראת תמחור מותאם אישית מאז אוגוסט 2026. בדוק בפורטל לפני שתקצה תקציב לאצווה גדולה.

המגבלה של 300 שניות, ואיך לעקוף אותה

כל משימה מוגבלת ל-300 שניות של קלט. זה נדיב עבור שוט וקצר עבור ריל, לכן כל דבר ארוך יותר חייב להיות מחולק לקטעים — והאופן שבו מפצלים חשוב יותר מהתקרה עצמה.

חתוך בגבולות סצנה, לא לפי שעון קבוע. אינטרפולטורים מסיקים תנועה בין פריימים סמוכים; בחתך חד, לפריים האחרון של שוט A ולפריים הראשון של שוט B אין כלל קשר תנועה, ומודל שאינו מזהה את החתך ימציא בשמחה מורף ביניהם. יומן השינויים של Runway אינו מתעד זיהוי סצנות אוטומטי עבור מודל זה, כך שההנחה הבטוחה היא שאין כזה. חלק לקטעים בחתכים, בצע אינטרפולציה לכל קטע, והרכב מחדש על ציר זמן בקצב החדש.

העצה הזו אינה ייחודית ל-Runway — זוהי ההסתייגות הסטנדרטית לגבי תזמון מחדש מבוסס AI בכל מקום. מאמר SMPTE משנת 2025 על פוסט-פרודקשן בסיוע AI, המתאר צינור אינטרפולציה מאופטם ב-TensorRT להמרות כגון 23.976 → 25 ו-29.97 → 23.976, מעלה את אותה נקודה: תוכן שעבר המרת פריימים זקוק לשברי פריימים בנקודות חיתוך סצנות ולבקרת איכות לאחר מכן, אחרת המודל הוזה על פני החיבור. צפו שהמעבר הראשון ידרוש החלפת פריימים ידנית סביב מעברים קשים.

היכן הוא ממוקם לעומת החלופות

אינטרפולציית פריימים היא בעיה שנפתרה פחות או יותר כבר זמן מה, בשתי צורות ששתיהן נראות שונות מזו.

• חבילות דסקטופ — המודלים Apollo ו-Chronos של Topaz Video AI הם נקודת הייחוס לריטיימינג ממוקד איכות. רישיון perpetual, ה-GPU שלך, בלי מונה לפי שנייה, וסבב כיוונון שמתגמל מישהו שיודע מה הוא מסתכל עליו.

• אינטרפולטורים בקוד פתוח — RIFE ומודלים דומים, בהרצה עצמית, למעשה בחינם מבחינת עלות שולית ברגע שהחומרה כבר בבעלותך, והבסיס לרוב הפייפליינים המותאמים אישית שבתי פוסט בנו בעצמם.

• Runway Enhance Frame Rate — ללא מחשוב מקומי, קריאת API, חיוב לפי שניות קלט, וקצבי NTSC השבריים שהשניים האחרים הותירו לך היסטורית להתאים סביבם ידנית.

הפשרה ברורה. עבור שוט חד-פעמי על תחנת עבודה שכבר בבעלותך, אינטרפולטור מקומי יהיה זול יותר ויספק לך כיוונונים ש-Runway לא חושפת. עבור חומר גלם שמגיע בתוך צינור אוטומטי, או מטריצת תוצרים שבה אותו קליפ צריך לצאת בקצב 23.98 עבור טריטוריה אחת ו-25 עבור אחרת, API שמחזיר את הקצב השברי ישירות מסיר שלב קונפורם — והתמחור לפי שנייה בקלט אומר שפלט בריבוי קצבים לא עולה דבר נוסף.

שכבת הניתוב שסביבו

Retiming הוא שלב אחד בצינור עיבוד שיש בו שלב של מודל שפה במקום כלשהו בקרבתו. רשימת השוטים והערות ה-conform, מעבר הכתוביות והכיתובים שצריך לתזמן מחדש לקצב הפריימים החדש, מטא-הנתונים של ההפצה לפי טריטוריה, יומן ה-QC — כל זה הוא עבודת טקסט, וזה החלק בצינור עיבוד וידאו שאף אחד לא מתקצב אותו.

השכבה הזו פועלת על מפתח אחד על פני 200 המודלים בקטלוג של OrcaRouter, כשמחירי המחירון של הספקים מועברים הלאה עם 0% תוספת ומעבר אוטומטי בין ספקים במקרה של תקלה, כך שאפשר לנסות מודל חדש או זול יותר על תעבורה חיה בלי להמר על נתיב פרודקשן. ליתר דיוק לגבי ההיקף: Runway Enhance Frame Rate הוא מודל של Runway Dev API, שנקרא בנקודת הקצה של Runway עצמה, ו-OrcaRouter לא משרת אותו. מה שאנחנו מכסים הוא כל מה שסביבו.

מה שעדיין לא ידוע

כמעט שום דבר לגבי איכות. המודל הזה בן בערך יום בזמן כתיבת הדברים, וכל מה שלמעלה בנוגע להתנהגותו מגיע מיומן השינויים וההכרזה של Runway עצמה. באופן ספציפי, לא מאומת:

• התנהגות ארטיפקטים בתנועה מהירה, אוקלוזיה, טשטוש תנועה ומקורות בקצב סיביות נמוך — אין בדיקות שפורסמו על ידי איש

• האם הוא מזהה חיתוכי סצנות באופן אוטומטי, או שממזג ביניהם

• האם השמע מועבר כמו שהוא, נדגם מחדש, או נזרק כאשר קצב הפריימים משתנה

• כיצד הוא משתווה באיכות ל-RIFE, Apollo או Chronos — אין השוואה ראש בראש

• האם המחיר לכל שנייה של קלט יישמר כשקצב היעד עולה, או שיועבר למדרגת תמחור אחרת בהמשך

התייחס ליעדי 120 fps ו-48 fps כאל טענות בלבד עד שתעביר דרכם את הצילומים שלך, ובדוק את הטיפול בחיתוך בקליפ הראשון שתשלח.

מי צריך לזוז עכשיו?

פעלו עכשיו אם אתם מספקים לפי מפרטי שידור או מפרטים לריבוי טריטוריות וכיום משלמים על שלב קונפורם, אם הצילומים שלכם כבר זורמים דרך צינור אוטומטי שיכול לקלוט עוד קריאת API אחת, או אם אתם רוצים הילוך איטי ממצלמה שמעולם לא צילמה במהירות גבוהה והייתם מעדיפים לא להריץ GPU.

המתינו אם אתם זקוקים ליותר מחמש דקות בעבודה אחת ואינכם יכולים לפצל בנקודות חיתוך, אם אתם זקוקים גם להעלאת הרזולוציה — זה האפסקיילר, במחירים לפי פריים — או אם כבר יש לכם אינטרפולטור שולחני וזהו שוט חד-פעמי. והמתינו אם האיכות היא הגורם המכריע ולא הנוחות: אף אחד מחוץ ל-Runway לא פרסם מספר, וההשוואה העצמאית הראשונה היא הדבר ששווה לחכות לו.

הדפוס שכדאי לשים לב אליו הוא האם Runway ממשיכה להרחיב את נקודת הקצה הזו דגם אחר דגם. היא כבר כוללת מגביר רזולוציה יצירתי וכעת גם ריטיימר, שניהם על POST /v1/video_upscale, ושניהם מתומחרים ביחידות שונות לחלוטין. עבור כל מי שבונה צינורות מסירה, היחידה — שניות קלט ולא פריימים של פלט — היא החלק שכדאי לתכנן סביבו.